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

1、计算密集型应用以Service Mesh为支点解决分布式问题的探索与实践京东集团架构师/王志龙个人简介 10年+互联网一线研发及架构经验，Kubernetes Contributor，Layotto Wasm Maintainer，专注云原生领域，擅长性能极限优化。曾工作于腾讯、阿里，参与过微信 PaaS 云平台从0到1建设，阿里 Serverless C+和 Golang Runtime 研发及落地。目前工作于京东集团搜索与推荐部，负责京东搜推微服务治理和新一代 Serverless 云化平台研发工作。一、Mesh溯源及背景介绍二、落地挑战和方案选型三、业务赋能探索&实践四、技术布局与未来展

2、望目录一、Mesh溯源及背景介绍William MorganBuoyant CEO服务网格理念的提出者和先行者以及最早的布道师2016.09.29 Buoyant 2016.01.15 初次发布2016.09.29 概念诞生Micro-Service=Service Mesh 一脉相承专门的一层基础设施；负责可靠传输；轻量的网络代理；对应用程序透明起源于 Buoyant 内部分享，从落地到概念一般为 Pod 多容器，但是随着 Node 模式的演进，载体多样化起来，但整体形式一致典型形式 Sidecar 部署绿方块为服务，蓝方块为边车部署的代理，多个 Sidecar 之间的连接和交互组成了 Me

3、sh右转90服务网格和 Sidecar 的关系栏目栏目细分方案1框架(bin)+业务(so)方案2框架(so)+业务(bin)方案3框架，业务一起编译方案4框架(bin)+业务(bin)方案5框架(bin+支持插件)+业务（bin）方案6框架(bin)+业务（bin+多so）方案7框架bin+filter bin+业务bin方案八框架bin容器+多bin目标消除框架侵入消除代码浸入可观察性中中中高高高高高可测试性中中中高高高高高可扩展性中中中较高高很高很高很高分离度中中低较高高很高很高很高业务代码修改量低低不需要低低低低低运维修改量较高较高低中中高高高基础模块梳理量高高中高高高高高框架开发量中

4、中低较高高高高高与框架发展契合度低低低高高高高高潜在风险So符号未定义和符号冲突符号冲突-So符号未定义和符号冲突-从微信 Svrkit 框架与业务分离方案，回看 Mesh 的意义基础框架作为承上启下的重要一环：对下充分利用底层系统能力，对上提供灵活可靠的底座当年的基于 Envoy HTTP 通道传输私有协议方案如今的 Service Mesh 百家争鸣，百花齐放Mesh协调微服务能力和分布式压力的一个支点微服务微服务分散能力解决系统复杂度问题逻辑垂直拆分分布式分布式分散压力解决系统性能问题物理横向拆分日益复杂多样的需求高效迭代和极致性能大促突发大流量挑战跨部门跨语言联动共性问题难聚焦复用小语

5、种服务治理弱二、落地挑战和方案选型数据量大计算密集实时性高链路复杂搜推广等计算密集型应用特点及落地挑战VSMOSN 多协议框架快速落地，中长期使用 MoE“双语”扩展技术选型Proxy 性能损耗 vs Proxyless 业务耦合 Proxy无损耗？！MoE Mosn On Envoy研发效能高（Golang）处理性能高（C+）多集群多主控制面架构多形态数据面&多数据面+多控制面架构三、业务赋能探索&实践跨语言、多协议去中心化网关TP99 降低 50%，抖动明显好转，可用率提高一个数量级HTTP网关下沉到数据面=私有协议RPC调用加权后不同规格机器可以相对均匀，TP99 降 5ms，但是个别算

6、力或容器跟物理机差别大的，依然会不均匀异构环境负载均衡加权最小连接数可根据业务需要设置 CPU 保护水位，打开远端负载感知常规流量 CPU TP75 63%=60%，TP99 降 8 ms复合多策略负载均衡加权&本地耗时感知&远端负载感知EDF应对突发大流量与业务内嵌限流的关键指标对比CPU/QPS 动态限流应对常规流量，可用率更高，TP99更低cpu超过上限值，快速限流（按当前cpu与上限值等比例限流）cpu低于下限值，快速恢复（按delta比例大幅扩大流量）cpu在上下限内，缓慢探测（按delta比例小幅探）基于Envoyfilter下发的混合跳步CPU/QPS自适应限流对比项业务内嵌MO