计算密集型应用以ServiceMesh为支点解决分布式问题的探索与实践_王志龙

计算密集型应用以ServiceMesh为支点解决分布式问题的探索与实践 京东集团架构师/王志龙 个人简介 10年+互联网一线研发及架构经验，KubernetesContributor，LayottoWasmMaintainer，专注云原生领域，擅长性能极限优化。 曾工作于腾讯、阿里，参与过微信PaaS云平台从0到1建设，阿里ServerlessC++和GolangRuntime研发及落地。 目前工作于京东集团搜索与推荐部，负责京东搜推微服务治理和新一代Serverless云化平台研发工作。 目录 一、Mesh溯源及背景介绍二、落地挑战和方案选型三、业务赋能探索&实践四、技术布局与未来展望 一、Mesh溯源及背景介绍 起源于Buoyant内部分享，从落地到概念 专门的一层基础设施；负责可靠传输；轻量的网络代理；对应用程序透明 2016.09.29Buoyant 2016.01.15初次发布 2016.09.29概念诞生 Micro-Service=>ServiceMesh一脉相承 WilliamMorganBuoyantCEO 服务网格理念的提出 者和先行者 以及最早的布道师 典型形式——Sidecar部署 一般为Pod多容器，但是随着Node模式的演进，载体多样化起来，但整体形式一致 服务网格和Sidecar的关系 绿方块为服务，蓝方块为边车部署的代理，多个Sidecar之间的连接和交互组成了Mesh 右转90° 从微信Svrkit框架与业务分离方案，回看Mesh的意义 基础框架作为承上启下的重要一环：对下充分利用底层系统能力，对上提供灵活可靠的底座 栏目 栏目细分 方案1框架(bin)+业务(so) 方案2框架(so)+业务(bin) 方案3 框架，业务一起编译 方案4框架(bin)+业务(bin) 方案5 框架(bin+支持插件)+业务（bin） 方案6 框架(bin)+业务（bin+多so） 方案7框架bin+ filterbin+业务bin 方案八 框架bin容器+多bin 目标 消除框架侵入 √ √ √ √ √ √ √ √ 消除代码浸入 √ √ √ √ √ √ √ √ 可观察性 中 中 中 高 高 高 高 高 可测试性 中 中 中 高 高 高 高 高 可扩展性 中 中 中 较高 高 很高 很高 很高 分离度 中 中 低 较高 高 很高 很高 很高 业务代码修改量 低 低 不需要 低 低 低 低 低 运维修改量 较高 较高 低 中 中 高 高 高 基础模块梳理量 高 高 中 高 高 高 高 高 框架开发量 中 中 低 较高 高 高 高 高 与框架发展契合度 低 低 低 高 高 高 高 高 潜在风险 So符号未定义和 符号冲突 符号冲突 - - - So符号未定义 和符号冲突 - - 当年的基于EnvoyHTTP通道传输私有协议方案 如今的ServiceMesh百家争鸣，百花齐放 Mesh——协调微服务能力和分布式压力的一个支点 微服务分散能力 解决系统复杂度问题逻辑垂直拆分 …… 日益复杂多样的需求 高效迭代和极致性能大促突发大流量挑战跨部门跨语言联动共性问题难聚焦复用小语种服务治理弱 …… 分布式分散压力 解决系统性能问题物理横向拆分 …… 二、落地挑战和方案选型 搜推广等计算密集型应用特点及落地挑战 数据 量大 计算 密集 链路 复杂 实时 性高 技术选型 Proxy性能损耗vsProxyless业务耦合——Proxy无损耗？！ VS MOSN多协议框架快速落地，中长期使用MoE“双语”扩展 处理性能高 （C++） 研发效能高 （Golang） MoE——MosnOnEnvoy 多集群多主控制面架构 多形态数据面&多数据面+多控制面架构 三、业务赋能探索&实践 跨语言、多协议去中心化网关 HTTP网关下沉到数据面=>私有协议RPC调用 TP99降低50%，抖动明显好转，可用率提高一个数量级 异构环境负载均衡——加权最小连接数 加权后不同规格机器可以相对均匀，TP99降5ms，但是个别算力或容器跟物理机差别大的，依然会不均匀 复合多策略负载均衡——加权&本地耗时感知&远端负载感知 可根据业务需要设置CPU保护水位，打开远端负载感知常规流量CPUTP7563%=>60%，TP99降8ms EDF 基于Envoyfilter下发的混合跳步CPU/QPS自适应限流 应对突发大流量与业务内嵌限流的关键指标对比CPU/QPS动态限流应对常规流量，可用率更高，TP99更低 对比项 业务内嵌 MOSN 差值 生效速度 19s 12s -36% 限流CPU 80% 78% -2.5% 限流可用率 83% 88% +6% cpu超过上限值，快速限流 （按当前cpu与上限值等比例限流） cpu在上下限内，缓慢探测 （按delta比例小幅探） cpu低于下限值，快速恢复 （按delta比例大幅扩大流量） Little’slaw:L=λW 传输BDP=BW*RTT应用TW=TPS*LATENCY T≈QPS*Avg(RT) 测试环境治理——单模块Mock测试 屏蔽个性化影响，提高压测效率；数据面一次修改，所有模块透明复用，一劳永逸；目前测试提效20%+ 流量分组——以Debug流量为例 路由动态别名，实例按需分组，赋能异常流量测试，跨集群流量调度，动态扩分片，全流量实验 基于eBPF的旁路无侵入观测 零侵入，跨语言，高扩展，低损耗——有效快速解决跨语言异构系统、多模块的问题紧急排查和定位 四、技术规划与未来展望 Attachment 1MB 3MB 5MB 10MB RDMA Avg-Latency:431,90th-Latency:437,99th- Latency:443,99.9th-Latency:446,Throughput:1942.76MB/s,QPS:1.98938k,ServerCPU- utilization:105%,ClientCPU-utilization:33%2000qps Avg-Latency:1180,90th-Latency:1188,99th- Latency:1203,99.9th-Latency:1208,Throughput:2040.34MB/s,QPS:0.696435k,ServerCPU-utilization:108%,ClientCPU-utilization:34% 700qps Avg-Latency:1918,90th-Latency:1930,99th- Latency:1945,99.9th-Latency:1952,Throughput:2188.17MB/s,QPS:0.448137k,ServerCPU-utilization:129%,ClientCPU-utilization:36% 450qps Avg-Latency:3774,90th-Latency:3781, 99th-Latency:3793,99.9th-Latency:3808,Throughput:2491.11MB/s,QPS:0.25509k,ServerCPU-utilization:130%,ClientCPU-utilization:37% 250qps TCP/IP Avg-Latency:632,90th-Latency:781,99th- Latency:857,99.9th-Latency:982,Throughput:1459.37MB/s,QPS:1.4944k,ServerCPU- utilization:83%,ClientCPU-utilization:31%1500qps Avg-Latency:1898,90th-Latency:2131,99th- Latency:2357,99.9th-Latency:2484,Throughput:1495.25MB/s,QPS:0.510379k,ServerCPU-utilization:86%,ClientCPU-utilization:26% 510qps Avg-Latency:2569,90th-Latency:2656, 99th-Latency:3939,99.9th-Latency:4227,Throughput:1830.62MB/s,QPS:0.37491k,ServerCPU-utilization:99%,ClientCPU-utilization:33% 375qps Avg-Latency:6127,90th-Latency:7398,99th- Latency:7662,99.9th-Latency:8391,Throughput:1477.67MB/s,QPS:0.151314k,ServerCPU-utilization:86%,ClientCPU-utilization:25% 150qps LiMoE=LayottoinMOSNonEnvoy“能力X性能” IstioEcosystem——基于Admiral智能自动化流量调控 WLARALB 服务集合 跨逻辑集群 跨物理集 群 智能流控 MeshNode化架构赋能新一代Serverless平台 欢迎技术交流