如何让开源产品接受我们的改动？ 如何让社区和客户认可我们的产品？开源方案选择之第一代Service Mesh Linkerd • 无控制平面 • Scala编写，基于JVM资源消耗大 • 可扩展性有限，dtab不易理解和使用 • 功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 公司和产品在社区知名度和影响力有限国内公司的选择之一：自研 华为：CES Mesher • 使用Golang编写 • 由go chassis演进而来 • 走的是已有类库->加proxy->再加 控制平面的路线 • 部分对接Istio • 细节暂时不清楚，即将开源 新浪微博：Motan Mesh • 也是使用Golang编写 • 全新实现（原有类库是基于Java） 老成持重的稳健思路：以proxy为切入口，第 之后再缓缓图之。 这个产品思路唯一的麻烦在于编程语言的选择国内公司的选择之二：开源方案定制 腾讯：Tencent Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践

MESH 落地的问题 • SOFA MESH 的通用落地方案 • DNS 服务寻址方案 • X-PROTOCOL 通用协议 • 问答SOFA MESH • 从 ISTIO 克隆并保持同步更新 • 使用 SOFA-MOSN 代替 ENVOY 作为数据平面 • 打包 • 安装 • 部署 • 测试 • 支持主流的微服务框架 • SOFA • HSF • DUBBO • SPRING CLOUD • ADAPTER 自己做控制平面KUBERNETES NATIVE 微服务 • 使用 Kubernetes 作为注册中心 • Service • Endpoint • Pod • 使用 DNS 寻址 • 使用 iptables/ebpf 透明地路由所有网络流量 • 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • • …MESH 落地碰到的问题 • 客户端服务发现与负载均衡无法与 ISTIO 一起工作 • ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 RPC 服务，每个服务有自己的版本 • …ISTIO 控制平面路由的抽象模型 INBOUND OUTBOUNDSOFA 服务注册模型落地一个微服务框架需要的工作

Sidecar 的证书管理方案 使用可信身份服务构建敏感数据下发通道 Service Mesh Sidecar 的 TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes Secret 证书管理流程 在 Kubernetes 场景下，证书是通过 secret 的方式来管理，使用时通过 secret mount SDS Server 采用 mTLS 通信，采用静态证书方案，通过 Secret Mount 方式获取通信证书  Sidecar 与 SDS Server 采用 UDS 方式实现纯内存通信，不需要使用证书。基于 Secret Discovery Service Sidecar 的证书管理方案 Envoy SDS 证书管理流程基于 Secret Discovery Service Sidecar Service Sidecar 的证书管理方案 蚂蚁金服证书管理方案  基于 Citadel 对接内部密钥管理系统  使用 AppLocalToken 替换 Service Account  支持多种Sidecar 通过Citadel Agent 获取证书使用可信身份服务构建敏感数据下发通道 背景介绍 通过应用Pod 中增加一个安全 Sidecar，以API接口的形式为APP及其他Sidecar

2018 年协议，安全持续升 级（QUIC，MQTT，国密）， 云原生 再启程 03前世 F5 BigIP Netscaler自研四层网络代理 2011 2014 2018 未来 Ø 全面使用DPDK技术重构 Ø EBPF，XDP Ø 可编程交换芯片（P4语言） Ø 四层负载均衡-IPVS Ø NAT网关蚂蚁七层网络代理 Google Spanner?蚂蚁七层网络接入代理 Spanner蚂蚁七层网络接入代理 缓存证书等服务端信息，避免 再次握手时重复传输数据 • ECDHE-keyshare扩展 将TLS1.3草案中的1-RTT机制通 过扩展的方式提前应用 • ECC-signature扩展 使用高效ECDSA签名算法的同 时，兼容广泛使用的RSA证书 按需握手 • 业务可根据需求灵活选择明文 或密文传输，提升业务效率 动态Record Size • 平衡吞吐与时延 高效 优化 灵活 TLS扩展安全合规能力持续升级 ü 一条TCP连接对应一个Read协程，执行收包，协议解析 ü 一个请求对应一个worker协程，执行业务处理，proxy和Write逻辑SOFAMosn能力扩展 ü 协议扩展 MOSN 通过使用同一的编解码引擎以及编/解码器核心接口，提供协议的 plugin 机制，包括支持 • SofaRPC • HTTP1.x,/HTTP2.0 • Dubbo ü NetworkFilter 扩展

灵活的适配器模型，使其以下操作变得简 单： • 运维添加、使用和删除适配器 • 开发人员创建新的适配器（超过20个适配器）Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Mixer v1 架构的缺点 • 管理开销 • 管理Mixer是许多客户不想负担的 • 进程外适配器强制运维管理适配器，增加此负担 • 性能 • 即使使用缓存，在数据路径中同步调用Mixer也会增加端到端延迟 授权和认证功能是天然适合mixer pipeline的，但是由于mixer 设计 的延迟和SPOF（单点故障）特性，导致直接在Envoy中实现 (Envoy SDS) • 复杂性 • Mixer使用一组称为模板的核心抽象，来描述传递给适配器的数据。 这些包括“metrics”，“logentry”，“tracepan”等。这些抽 象与后端想要消费的数据不匹配，导致运维需要编写一些手动配置， 以便在规范的 • 数据平面可替换原则 • 集中式服务： • 提高基础设施后端的可用性 • 为前提条件检查结果提供集群级别的全局2级缓存 • 灵活的适配器模型，使其以下操作变得简 单： • 运维添加、使用和删除适配器 • 开发人员创建新的适配器（超过20个适配器）合并没问题，如何合并才是问题 Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？Envoy在设计上是可扩展的 Part

C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 • 老牌代理系统，业界广 泛使用，服务各类场景 • C++实现 • CNCF第三个毕业项目， ISTIO原生数据平面 • 开发活跃，最新版为1.9.0 • Google, Lyft主导，业界 众多公司使用中，重点搭 载ISTIO使用，服务各类 场景 • Rust实现 • CNCF项目，最早的 Service Mesh数据平面 18.9.1 • Golang实现 • 新生项目，初期旨在搭建 RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4 conn goroutine conn.read conn goroutine conn.read …… 调度切换/就绪通知技术案例 – 长连接网关RawEpoll模式 RawEpoll模式：使用epoll感知到可读事件之后，再从协程池中为其分配协程进行处理。 大幅减少goroutine实例数量，从而降低内存、调度开销 Netpoll implmented in Golang runtime

• SOFA/NodeJS/C++/Python/.. • 业务低成本融入服务，运维体系为什么要自研Golang版本ServiceMesh 2 Ø跨团队协作需要考虑技术栈落地成本 ü 参与团队分别使用C，Golang，Java等多种技术栈 Ø基于蚂蚁SOFA体系的Mesh化思考 ü 无法保证上下游应用同时升级到Mesh模式 ü 基于RPC内容的流量调度 ü 升级窗口有限，方案必须简单高效 Ø运维体系，容器化建设等方面适配 优化：减少解包等绑核 2 Ø单核绑核 runtime 执行性能更好 ü单次写操作绑核 3us，不绑核 5us Ø更好的 G-P-M cache locality 亲和性 üRuntime 内存使用率提升，arena 区内存申请频率低，大小更小 üMheap 申请系统内存减少约60%内存 3 ØSLAB-style buffer pool ü减少内存 copy ü压测场景下内存复用率90% -> mheap -> arena ü大于 32K 的大内存分配顺序 mheap -> arena ØGC 优化 ü避免入堆 ü减少内存 copy ü内存使用整体化，降低 scanobject 成本 ü使用 GC 亲和的数据结构 ü适度使用 sync.Pool ü…IO 4 Ø优化 ü尽可能多读，同时减少SetReadDeadline频繁调用，实现见 IOBuffer.ReadOnce ü适度

并行调用Proxy 服务治理 • 服务治理平台、配置中心 • 监控、日志、分布式跟踪 • 异步调用、压测7/24 流量代理机制 PHP服务发布入流量代理 PHP并行调用出流量代理 16年起开始使用流量代理机制解决跨语言服务治理问题8/24 分享主题：字号 分享嘉宾 发布服务数 2000+ 注册实例数 2万+ 全天调用量 3500亿 微服务体系规模 服务量级的增长使得Java应用的服务治理问题 自研数据平面与 控制平面方案 使存量服务接入Mesh 方案 对接大量内部系统 关键收益均由数据平面产生 非完善的控制平面功能 技术体系内不引入Go语言 最成熟的服务端语言为Java 使用Java开发 数据平面Agent14/24 整体架构 数据平面 • 现有协议的流量转发 • Agent平滑升级机制 控制平面 • 轻量的Pilot Proxy • 向Istio的标准协议靠拢 与业务容器共享CPU、内存资源配额 为Agent JVM分配256M内存资源 服务器消耗增加约10% 分配方式 内存资源 服务器资源 维持现有内存使用率与 服务器配置的最坏情况 实际需预留 600M内存22/24 数据平面兼容原有架构 对接原有系统 • 使用原有系统SDK、私有协议 直连访问 兼容未升级服务 • Proxy Agent支持以原有通信 协议处理请求、发起调用23/24 总结与展望

Server 管控规则 灰度发布 网格增强组件 原生组件 APP： Traffic Management APP ...产品化增强-服务注册发现 出于历史原因，我们使用了Kubernetes来部署服务，但并未使用Kubernetes内置的 服务发现功能。 Process Service-A Service-B Service-C Coarse grained Service Management Server Sidecar Sidecar Client Service Mesh Service Mesh Control Plane API Gateway：应用网关逻辑 • 使用不同端口为不同租户提供访问入口 • 租户间的隔离和访问控制 • 用户层面的访问控制 • 按用户的API访问限流 • API访问日志和计费 Service Mesh：统一的微服务通信管理 • ：避免不同功能的网络之间的 相互影响； 网络设计冗余，增强系统网络的健壮性； 为不同的网络提供不同的 SLA ；通过网络隔离提高安全性；通过叠加多个网络增加系统带宽 上图中的Kubernets集群使用了Knitter网络插件，部署了四个网络平面产品化增强-支持多网络平面 Istio1.0中不支持多网络平面，当服务地址和Envoy地址分别位于两个网络上时，会导致转发请求时 发生死循环，导致socket耗尽，Envoy不停重启。

Pod） Daemonset 对容器的影响 影响大。Pod中增加sidecar容器，加大整个Pod的资源需 求，对K8s的调度形成压力，特别是在资源紧张的情况下； 而且还容器导致资源浪费（sidecar的使用率问题） 影响小。宿主机预留部分资源启动daemonset 即可 运维难度 难度大。Sidecar故障会影响同一个pod的业务容器，同 生共死 难度小。Sidecar故障可以将流量临时切到 remote 高，而且全量升级sidecar对整个系统的动荡太大 难度小。切换流量到remote proxy可以实现用 户无感知无损升级。可以轻易的实现全网一月 一升级，快速的迭代、落地、反馈 动态扩容难度 单机使用，无须扩容 需预先根据宿主机的配置调整Proxy的资源以 应对客户端增多的情况。容量超标则临时转移 到remote proxyRemote Proxy的价值 • 主要职责：备份流量、临时流量、非主要流量 内部实现一套可插拔的鉴权框 架也能接受混合部署 vs. 绑定K8s • 历史原因导致长期都会物理机 和容器并存，内部需求必须要 同时支持物理机和云 • 绑定K8s能够享受K8s的红利， 但也限制了使用范围 +服务治理程度更接地气 • 不停的迭代、落地、反馈，打 造一系列的实用的治理功能 • 规则路由、标签路由、邻近机房 路由、Hash路由、基于权重的路 由、熔断、健康探测、超时重试、 限流降级等等