需求 • 趋势Service Mesh Meetup · BeiJing 平台体系 微博Service Mesh实践 - WeiboMesh �4 Java Server Java Client Registry Motan ➢ 服务治理理 ➢ 动态路路由 Vintage ➢ 注册中⼼心 Opendcp ➢ 智能弹性调度 Graphite ➢ 实时统计监控 平台微服务相关建设⽐比较完善 WeiboMesh Server(php/java/..) golang/php/java Registry grpc/yar/motan ➢ 语⾔言特性 ➢ 历史积累 ➢ 业务侵⼊入较⼤大，client太重 ➢ 性能 ➢ 扩展性差 ➢ 推⼴广困难 Register Subscribe NotifyService Mesh Meetup · BeiJing 服务治理理 �9 微博Service Mesh Meetup · BeiJing Weibo Mesh 总体架构 �15 微博Service Mesh实践 - WeiboMesh Weibo Mesh Service A Client Weibo Mesh Service B container container Registry ClientService Mesh Meetup · BeiJing �16

stream bytes Network Network Protocol Stream Proxy Proxy Protocol Stream Network Network线程模型 0.1.0 9 Client Listener Read / Codec Read / Codec Read / Codec accept Stream Event Handler Pool Server Server worker worker Read / Codec Read / Codec Read / Codec Write Write Write write send线程模型 0.2.0 9 Client Listene r Read / Codec Read / Codec Read accept Stream Event Handler Pool Server Server Server / Codec Read / Codec Read Write Write Write write data Codec Worker Pool线程模型规划: SEDA 10 Client Listener IO Pool Server Server Server IO Event Handler Pool data Codec Worker Pool Stream

MSB(Consul) Service Registry Registration Registration Pilot Pull Services xDS Client Request Client Request Client RequestConsul Registry遇到的坑： 1.0版本的Consul Registry只能算PoC（原型验证），远未达到产品要求 CPU占用率超高不下 API Management Ingress Sidecar Service Discovery & Traffic Management Server Sidecar Sidecar Client Service Mesh Service Mesh Control Plane API Gateway：应用网关逻辑 • 使用不同端口为不同租户提供访问入口 • 租户间的隔离和访问控制 将TCP纳入Service Mesh管控还不成熟，成本远大于收益 Ø Service Mesh应主要关注L7，而不是L4 Shard A Shard B Shard C client 一致性哈希 client client产品化增强-TCP Service的处理 在Service Mesh中 Bypass TCP流量，让TCP请求跳过Service Mesh的处理，缺省发送到原 始请求目的地。

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

作为服务发现组件 • 数据面：cNginx • 控制面：Consul 管理后台5/24 服务治理能力 – 基于严选第一代ServiceMesh（cNginx） 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：基于 Consul √ 调用控制 协议支持：HTTP 1.X/2.X，可扩展至 TCP √ 路由控制：提供简单的路由能力 √ 负载均衡：支持 数据面：Envoy • 控制面：Pilot，Mixer，Citadel，Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：云外基于 Consul，云内基于 K8s 默认的 ETCD √ 调用控制 协议支持：HTTP 1.X/2.X，GRPC,WebSocket，Dubbo， • Envoy(client模式)的 RT overhead 是0.6ms左右12/24 性能视角 – cNginx vs Envoy（优化后） • 优化方案 • 采用 sriov 容器网络 • Envoy：将1.13版本中 connection loadbalancer 特性移植到 1.10.x 版本 • Envoy 优化后在低并发（<64）的情况下，容器网络 client sidecar

Interface2 Interface1 Interface3 SOA架构：单进程多接口 服务注册中心 注册interface3 注册interface2 注册interface1 client 1. 查找interface2 以接口为 单位注册 客户端调用参考配置和示例代码： client Node podIstio 的DNS寻址 userservice pod DNS userservice pod userservice pod 1. 服务部署 • ServiceType=ClusterIP 7. 请求转发给对端sidecar kubernetes Pod IP=192.168.1.101 Pod IP=192.168.1.102 Pod IP=192.168.1.103 client Node pod Sidecar 6. Sidecar收到请求 • 从TCP options中的 original dest 获取ClusterIP • 根据ClusterIP从 VirtualHost

version 2.0.0落地形态 Traffic RulesSOFA MOSN Virtual Host Domain [172.16.3.8:1220] SOFA Listener 调用流程 Client com.svc.user Core DNS 172.16.3.8 IP TABLES dest 172.16.3.8:12220 SOFA Listener original dest Upstream protocol X APP [light client] app user version 1.0.0 Downstream protocol X SOFA MOSN Upstream protocol X Downstream protocol X APP [light client] app order version 1.0.0 DUBBO

通信场景下，为保证平滑无损的TLS切换能力，需 要分别控制 Server (Provider) 和 Client (Consumer)端的 TLS 行为  对于Server 端利用Istio 的Policy CRD 实现 Namespace + Service 粒度的开关控制  对于Client 端理想情况下，希望是通过Istio 的 DestinationRule 和 VirtualService VirtualService 来控制。但由于相 关条件尚未具备，因此通过现有注册中心来控制 Client TLS 能力Service Mesh Sidecar 的TLS 生产级落地实践Service Mesh Sidecar 的TLS 生产级落地实践 灰度控制 新功能总是离不开灰度过程，社区已有的Policy CRD 实现 Namespace + Service 的灰度能力不能满足 蚂蚁金服生产落地的要求，需要具备单机灰度、回滚能力。

软负载（服务发现）5/21 Sidecar Motorcycle (MOSN/Envoy) Service Mesh is Patterns SofaRPC API Gateway MQ Client Service Code6/21 LB\Ingress API Gateway Sidecar App POD Sidecar App POD Traffic Control Centralized API Gateway Decentralized Hybrid Cloud Bridge 云原生下 MOSN 的多面性 Message Server MQ Client20/21 分享主题：字号 分享嘉宾 开源？ Gateway Core 融合\贡献 Istio 更多尝试 More Mesh感谢聆听 欢迎关注，获取最新分布式架构内容 关注服务网格，关注

Xeon(R) CPU E5-2640 v3 @ 2.60GHz p kernel：3.10.0 p 压测版本: 0.2.1 – 2018.08版本 p 部署模式: Client <-> MOSN<-> Service p Client模拟方式:通过蚂蚁内部压测平台建立10w条SOFARPC链接 p 压测内容: 1K 请求/响应持续演进实践总结 ü 架构上，从一开始就遵循分层设计，模块解耦，统一编程模型接口，保证足够的架