163yun.com 网易云Service Mesh的产品架构与实现 刘超 网易研究院云计算技术部首席架构师www.163yun.com 关于我 • 刘超 • 网易云 解决方案总架构师 • 10余年云计算领域研发及架构经验，先后在EMC，CCTV证券资 讯频道，HP，华为，网易从事云计算和大数据架构工作 • 毕业于上海交通大学。 • 曾出版《Lucene应用开发揭秘》 • 多

• 使用Golang编写 • 由go chassis演进而来 • 走的是已有类库->加proxy->再加 控制平面的路线 • 部分对接Istio • 细节暂时不清楚，即将开源 新浪微博：Motan Mesh • 也是使用Golang编写 • 全新实现（原有类库是基于Java） 老成持重的稳健思路：以proxy为切入口，第 一时间获取跨语言和技术栈下沉的红利，立足 之后再缓缓图之。 径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践 • 从Istio中剥离Pilot和Envoy • 去掉Mixer和Auth • 定制Pilot，实现ETCD Adapter • 脱离k8s运行Sofa Mesh在技术选型时考虑 Envoy • 数据平面：Envoy最符合要求 • XDS API的设计更是令人称道 • C++带来的技术栈选择问题 Envoy Pilot Auth Mixer Golang Sidecar Istio现有架构 Sofa Mesh架构 1. 用Golang开发 Sidecar，替代Envoy 2. Mixer被部分合 并进入Sidecar 3. Pilot/Auth 做扩展和增强 Control plane Control plane Data plane Data plane Mixer架构设计

性能 安全软硬件一体解决方案 Intel QAT Cavium Nitrox软硬件一体解决方案 SSL握手性能 提升3倍 • 对Spanner实现了异步化改造 • 对openssl进行了异步化引擎改造 • 实现多芯片卡的负载均衡协议实现的改造-MTLS MTLS：1) 轻量级TLS库，小于50k；2) 优化的TLS协议 0-RTT • 减少握手延迟 • 代价：握手前发送的数据不能 平衡吞吐与时延 高效 优化 灵活 TLS扩展安全合规能力持续升级 国密算法 • 拥抱监管 • 安全可控 • 金融科技 AntTLS库 • 基于OpenSSL • 全面拥抱TLS1.3 • 国密优化实现，国密单证书标准支撑 • 支持SGX等可信机制 • 多硬件卡Engine • Mobile，iot设备等多终端支持 • OpenSSL Committer无线移动战役 操作响应慢 操作无响应 Push没消息 支持国密算法 WAF 流量镜像 多协议 SOFARPC Dubbo HTTP1.1/2 平滑升级 性能 单跳CPU增加5%消耗 0.2ms RT 蚂蚁金服100+应用，10w+容器已经mesh化，部分业务链路通过下沉， RT降低了7%，平稳支撑了618大促。SOFAMosn https://github.com/sofastack/sofa-mosn Written in go SOFAMosn是一个云原生安全网络代理

SOFAMOSN • C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 • 老牌代理系统，业界广 泛使用，服务各类场景 • C++实现 • CNCF第三个毕业项目， ISTIO原生数据平面 • 开发活跃，最新版为1.9.0 • Google, Lyft主导，业界 众多公司使用中，重点搭 载ISTIO使用，服务各类 场景 • Rust实现 • CNCF项目，最早的 CNCF项目，最早的 Service Mesh数据平面 • 开发活跃，最新版为 18.9.1 • Golang实现 • 新生项目，初期旨在搭建 RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 log Ø IO、协议、前后端核心 metrics技术案例 – 协议自动识别 TLS链接 核心实现思路： Ø TLS通过ALPN来识别。 Ø TLS不带ALPN或者明文，通过预读首部字段识别。 ALPN扩展 预读字段 是 否 获取ALPN协商 所得协议 有 无 遍历所有协议 实现，执行 ProtocolMatch 返回AGAIN 匹配成功，获 取对应协议 无法识别协议，

发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容： - Service Mesh产品动态 - Service Mesh发展趋势 - Service Mesh与云原生 今天的内容可以视为是上次演讲部分内容的深度展开，如社区 关心的Mixer v2，以及我个人看到的一些业界新的技术方向， 如web assembly技术，还有产品形态上的创新，如google traffic director对ser Backend ？ Adapters Configurations 优点： • 架构更优雅，职责更分明，边界更清晰 • Out-of-Process Adapter不再是Istio的组成部分 • 安装部署 • 配置 • 维护Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Mixer v1 架构的优点 • 集中式服务： • 提高基础设施后端的可用性 • 的延迟和SPOF（单点故障）特性，导致直接在Envoy中实现 (Envoy SDS) • 复杂性 • Mixer使用一组称为模板的核心抽象，来描述传递给适配器的数据。 这些包括“metrics”，“logentry”，“tracepan”等。这些抽 象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置， 以便在规范的 Istio 样式和后端特定的样式之间进行映射。原本期望 这种映射可以在适配器中实现很大程度上的自动化，但是最终还是

业务服务 配置中心 启动获取 Monitor Turbine K8S流量 SC流量 同集群调用微服务 Spring Cloud管理平台基于Kubernetes的Spring Cloud实现 Devops: Experience Auto Scaling & Self Healing Resilience & Fault Tolerance Distributed Tracing RETURNPilot-Agent主要功能分析-生产Envoy配置 envoy的配置主要在pilot-agent的init方法与proxy命令处理流程的前半部分生成。其中init方法为pilot-agent二进制的命令行配置大 量的flag与flag默认值，而proxy命令处理流程的前半部分负责将这些flag组装成为envoy的配置ProxyConfig对象。下面分析几个相对重 要的配置。 role pilot-age Pilot-Agent主要功能分析-生产Envoy配置 agent.waitForExit会调用envoy.Run方法启动envoy进程，为此需要获取envoy二进制所在文件系统路径和命令行 参数两部分信息： 1. envoy二进制所在文件系统路径：evony.Run通过proxy.config.BinaryPath变量得知envoy二进制所在的文件 系统位置，proxy就是envoy对象，co

请求获取证书，并利用 gRPC stream 能力实现证书动态轮转。 当然，Sidecar 和 SDS Server 的通信也需要保证自身的通信安全，存在以下两种方案：  Sidecar 与 SDS Server 采用 mTLS 通信，采用静态证书方案，通过 Secret Mount 方式获取通信证书  Sidecar 与 SDS Server 采用 UDS 方式实现纯内存通信，不需要使用证书。基于 Secret SDS 证书管理流程基于 Secret Discovery Service Sidecar 的证书管理方案 Istio With Envoy SDS Istio 基于 Envoy 的 SDS方案，实现了 SDS Server 和 SDS 配置管理。Istio 方案中选择 UDS 通信方案，Istio的 方案证书管理流程由 Citadel , Citadel Agent , Pilot 协同完成 JWT-SVID，并构造 HTTP 请求，调用安全Sidecar提供的 JWT- SVID 验证接口。  安全Sidecar通过密钥对 JWT-SVID 进行验签。  从 JWT-SVID 的 Body 部分中获取 SPIFFE ID。  将 SPIFFE ID 内容解释为几个关键属性 (例如租户 ID、应用名等)，并返回给应用 B。  应用 B 根据安全Sidecar返回的可信属性，进行权限校

@UC 基础研发部1 Service Mesh演进路线 1 2 实现平滑迁移的关键 3 DNS寻址方案的演进 4 5 总结 DNS寻址方案的后续规划ü 对未来长期目标的认可 • Service Mesh（带控制平面，如Istio） • Kubernetes • 微服务 ü 现实中有很多挑战 • 还有很多应用没有实现微服务化 • 还有很多应用没有运行在kubernetes之上 • (Sidecar模式) 部署在 非k8s上 Service Mesh (Istio模式) 应用终极形态 应用现状 1 1 1 2 2 2 3 4 4 4 比较理想，绝大部分 投入最终都将保留 Service Mesh (Sidecar模式) Service Mesh (Istio模式) 带完善的控制 平面，如Istio 只有Sidecar， 直接集成周边 (完善后的)Istio， 和社区方案统一 第二步：引入 Sidecar，对接 周边生态 特殊：已经在路 线4上演进的应用， 快速会师到路线11 Service Mesh演进路线 2 2 实现平滑迁移的关键 3 4 5 总结 DNS寻址方案的演进 DNS寻址方案的后续规划保证迁移前后服务间网络互通 Service A Service B Service C SOFA Registry

Daemonset • 每台宿主机一台Proxy • Proxy地址文件 • Mount到所有pod • 客户端容器监听文件，根据地 址文件找Proxy • 切换地址到remote proxy，轻 易实现优雅退出和滚动升级 • 增强隔离性 • Local Proxy被pod共享 • 自保护，对来源方限流和流量 转移 • 资源适配 • 根据宿主机的硬件配置定制不 同资源配置的Daemonset 服务端agent成为必选项会增加运维压力 • OSP server默认没有agent，web server只带一个 服务注册agent • 服务端的一些治理、trace、鉴权功能通过代码插 件的方式实现 • 治理效果考虑 • 服务端嵌入治理功能可以让治理效果更好，如提 供主动GC、线程池隔离等 • 因为是内部项目，优雅性和治理效果之间，选择 了后者 App Local Proxy OSP 影响小。宿主机预留部分资源启动daemonset 即可 运维难度 难度大。Sidecar故障会影响同一个pod的业务容器，同 生共死 难度小。Sidecar故障可以将流量临时切到 remote proxy解决 升级难度 难度大。升级Sidecar需要业务容器一起发布，协调成本 高，而且全量升级sidecar对整个系统的动荡太大 难度小。切换流量到remote proxy可以实现用 户无感知无损升级。可以轻易的实现全网一月

- 专注业务实现 - 无需感知Mesh - 专注服务间通讯和相 关能力 - 与业务逻辑无关 将SDK客户端 的功能剥离 混合在一个进程内， 应用既有业务逻辑， 也有各种功能， 每次升级都要重新发布应用 业务进程专注于业务逻辑 SDK 中的大部分功能， 拆解为独立进程， 以 Sidecar 的模式运行 将服务治理能力下沉到基础设施，实现独立演进，透明升级7/39 com/sofastack/sofa-rpc28/39 Part 3： 蚂蚁金服的产品实践 虚拟机支持 • 云原生架构下，sidecar 借助于 k8s 的 webhook/operator 机制可以方便地实现注入、升级 等运维操作 • 然而大量系统还没有跑在 k8s 上，所以我们通过 agent 的模式来管理 sidecar 进程，从而可 以使 Service Mesh 能够帮助老架构下的应用完 MCP • 协议标准化 • 能力差异化 36/39Part 3： 展望未来 支持透明劫持 • 很多用户对性能要求没那么敏感，同时有大量遗留系统希望通过 Service Mesh 实现统一管控 • 增强管控性和可观测性 37/3938/39 一、为什么需要 Service Mesh? 二、在当下『路口』的思考 三、蚂蚁金服的产品实践 四、展望未来 总