基于Java语法的DSL • Zookeeper • 胖客户端 • 基本服务治理功能 App OSP Server Service Registry Service Config Center 服务发现 服务注册 服务元数据下发 OSP client 服务路由 网络传输 服务元数据上报缺点 • 语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2.0 - Service Service Mesh雏形 • 物理机、sidecar • Local & Remote，主与备 • 轻量级客户端、本地调用 • Local Proxy负责服务治理与 远程通信 • Remote Proxy负责备份和非 主流流量 JavaApp Local Proxy OSP Server Service Registry Service Config Center Remote Proxy Proxy Cluster API Gateway 备用链路 服务发现 服务注册 配置下发 服务路由 网络传输 OSP client多语言客户端接入 • HTTP & TCP • Local & Remote • 根据接入对象的不同，制定 不同的接入策略，达到 • 接入简单 • 保证性能 • 节省资源 Java App Local Proxy OSP Server Remote

都没有改造，直连 服务器端有改造，单跳 客户端有改造，单跳Service Mesh时代的客户端和寻址方式 服务发现 加密 负载均衡 请求路由 目标服务 的标识 序列化 链路追踪 故障注入 日志 监控 Metrics 熔断 限流 服务降级 前置条件检查 身份认证 密钥管理 访问控制 …… 下沉到 Service Mesh 轻量级客户端 传统 侵入式 客户端 客户端应该尽可能的轻薄通用: 实现简单，方便跨语言，减少升级可能 简化原有SDK （短期需求） • 同时引入域名和DNS，实现通用寻址 （长期目标） 引入DNS寻址方式(基于域名和DNS的Naming Service)Pod: 192.168.1.103 客户端通过域名来对服务进行访问 SOFA Mosn Service A PORT 12220 PORT 15001 Pod: 192.168.1.104 SOFA Mosn Service B PORT Discovery services renew RPC services Watch services renew RPC DNS b.svc -> 10.0.3.100 1. 在客户端代码中， 请求发送给”b.svc” 2.DNS解析”b.svc”到 clusterIP 10.0.3.100 3. 流量劫持到 sidecar1 Service Mesh演进路线 3 2

WebService 数据面 控制面 社区产品 蚂蚁产品6 二、为什么我们要 Service Mesh 为什么要 Service Mesh为什么要 Service Mesh-现状 5.客户端中间件版本的统一 9% 3.流量调度的诉求 18% 4.框架不断升级 14% 2.机器资源逐年增加 27% 1.业务和框架耦合 32%8 因为我们要解决在 SOA 下面，没有解决但亟待解决的： Mesh-结论9 为什么要 ServiceMesh-结论-方案 应用A 应用 应用B 应用C 应用D 应用E SOA 解耦了不同的业务团队之前的耦合 服务注册中心客户端 限流熔断客户端 动态配置客户端 故障注入客户端 Service Mesh 解耦了业务开发与基础团队之前的耦合 应用代码 业务应用开发 基础设施开发 Mesh 化10 三、方案落地 方案落地11 最终选型：自研数据面+轻量

作者名称我是作者名称Talk is cheap, Show me the code!• 当使用一个客户端实例和多个后端实例进行部署时，所有的调用仅 路由到单个后端实例。当部署第二个客户端时，它可能被路由到另 一个后端实例。这不是所需的那种负载均衡，因为它不允许独立地 扩展客户端和服务器。当客户端实例比服务器实例少时，一些服务 器实例将处于空闲状态，所以 Kubernetes Service 不太适合

部分节点宕机 • 网络分区 客户端容灾 • 注册中心完全不可用13/总页数 注册中心 - Consul Servers Quorum Size Failure Tolerance 1 1 0 2 2 0 3 2 1 4 3 1 5 3 2 6 4 2 7 4 3 • 服务端容灾与节点数14/总页数 注册中心 - Consul • 客户端容灾 客户端缓存 ！15/总页数 注册中心

透明地路由所有网络流量 • 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • …MESH 落地碰到的问题 • 客户端服务发现与负载均衡无法与 ISTIO 一起工作 • ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 作为 DNS 来寻址服务 • 开发一个通用协议处理框架 • 避免为不同的微服务框架修改 PILOT 代码 • 通过插件的方式按需支持新的协议 • 对应用代码无侵入性 • 为微服务框架提供轻量化客户端落地一个微服务框架需要的工作 • 部署 ZK 集群作为 RPC 框架的注册中心 • 开发 ZK Platform Adapter for DUBBO • 开发 DUBBO 服务的 XDS 配置下发

（MOSN） + 服务发现 负载均衡 熔断限流 服务路由 …… - 专注业务实现 - 无需感知Mesh - 专注服务间通讯和相 关能力 - 与业务逻辑无关 将SDK客户端 的功能剥离 混合在一个进程内， 应用既有业务逻辑， 也有各种功能， 每次升级都要重新发布应用 业务进程专注于业务逻辑 SDK 中的大部分功能， 拆解为独立进程， 以 开发 Sidecar SOFAMosn， 年中开源基于 Istio 的 SOFAMesh 技术探索 02 2018年开始内部落地，第一 批场景是替代 Java 语言之外 的其他语言的客户端 SDK， 之后开始内部小范围试点 小规模落地 03 2019年上半年，作为蚂蚁金融级 云原生架构升级的主要内容之一， 逐渐铺开到蚂蚁主站的业务应用， 并平稳支撑了618大促 规模落地

影子表弹性伸缩：数据迁移 迁移监听 在线双写 离线迁移 数据源切换 冗余数据清 理治理监控 配置动态化 负载均衡 熔断 & 禁用 安全 & 权限 & 脱敏 APM现有实现方案对比 客户端 • 支持任意数据库 • 数据库连接数占用高 • 仅支持单一开发语言 • 性能损耗低 • 无中心化 代理端 • 仅支持单一数据库 • 数据库连接数占用低 • 支持任意开发语言 •

Redis作为底层存储 • 跨语言地址发现服务Lookup • 中心化存活检测 多语言支持 • Java、PHP、Python、Go、NodeJs • Redis传输协议 / 复用Redis客户端 • 服务发布Proxy / 并行调用Proxy 服务治理 • 服务治理平台、配置中心 • 监控、日志、分布式跟踪 • 异步调用、压测7/24 流量代理机制 PHP服务发布入流量代理 PHP并行调用出流量代理

业务回归验证20/24 一些坑 • Envoy 目前编译版本存在 Bug • 在 Istio pilot 升级到加入 accesslog 相关配置下发功能版本后，Envoy 在一定压力访问或 有客户端主动断开请求时，会进入一段存在问题的断言（assert）逻辑，导致 envoy crash， 此时请求方体现为 502 异常 • 社区目前给出的优化建议是在 envoy 编译选项使用 -opt（默认为