SOFA MESH 的通用协议扩展 Service Mesh Meetup #3 深圳站 邵俊雄（熊啸） 2018.08.25AGENDA • SOFA MESH 介绍 • SERVICE MESH 落地的问题 • SOFA MESH 的通用落地方案 • DNS 服务寻址方案 • X-PROTOCOL 通用协议 • 问答SOFA MESH • 从 ISTIO 克隆并保持同步更新 • 使用 寻址 • 使用 iptables/ebpf 透明地路由所有网络流量 • 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • …MESH 落地碰到的问题 • 客户端服务发现与负载均衡无法与 ISTIO 一起工作 • ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO Kubernetes 服务 RPC Service 的域名就是其接口X-PROTOCOL 通用协议扩展目标 • Kubernetes Native，高性能，低侵入性的通用 Mesh 落地方案 • 支持新 RPC 框架和通信协议低成本接入 • 协议扩展对 Mesh 控制平面透明化 • 允许对协议多层次，插件化的扩展X-PROTOCOL 配置SOFA MOSN 调用流程 Upstream protocol

今年规划（Roadmap）内部Service Mesh的演进 我是作者名称服务化体系1.0 • OSP（Open Service Platform） • Thrift over Netty • 基于Java语法的DSL • Zookeeper • 胖客户端 • 基本服务治理功能 App OSP Server Service Registry Service Config Center 服务发现

160 byte -> 76 byte • Session Ticket扩展 用于会话复用，加速握手过程 • Cached-info扩展 缓存证书等服务端信息，避免 再次握手时重复传输数据 • ECDHE-keyshare扩展 将TLS1.3草案中的1-RTT机制通 过扩展的方式提前应用 • ECC-signature扩展 使用高效ECDSA签名算法的同 时，兼容广泛使用的RSA证书 按需握手 按需握手 • 业务可根据需求灵活选择明文 或密文传输，提升业务效率 动态Record Size • 平衡吞吐与时延 高效 优化 灵活 TLS扩展安全合规能力持续升级 国密算法 • 拥抱监管 • 安全可控 • 金融科技 AntTLS库 • 基于OpenSSL • 全面拥抱TLS1.3 • 国密优化实现，国密单证书标准支撑 • 支持SGX等可信机制 • 多硬件卡Engine • Mobile，iot设备等多终端支持 就近就优海外接入，智能调度 § 蚂蚁全球加速节点，全协议支持 § 支持UDPA § QUIC/HTTP3 § 接入层容器化，混部 § 支持QUIC协议的LB建设 § Web Assembly模块扩展东西流量的服务发现与路由 F5（ipvs） APP APP APP APP 配置中心 APP APP APP APP Proxy APP APP APP APPService Mesh

广州站Agenda Ø 背景 & 概览 Ø 持续演进路径 & 技术案例 Ø 实践案例 Ø 规划 & 展望 Ø QA背景 & 概览数据平面概览 SOFAMOSN • C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 • 老牌代理系统，业界广 泛使用，服务各类场景 • C++实现 • CNCF第三个毕业项目， ISTIO原生数据平面 • 开发活跃，最新版为1.9.0 • Google 场景 • Rust实现 • CNCF项目，最早的 Service Mesh数据平面 • 开发活跃，最新版为 18.9.1 • Golang实现 • 新生项目，初期旨在搭建 RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFA on ADS Ø X-Protocol协议扩展机制， 以及Dubbo支持 Ø 支持network/stream filter 扩展 Ø 支持WRR负载均衡 Ø 支持subset复杂匹配路由 Ø 无损平滑迁移 Ø ProtocolEngine协议扩展 机制 Ø 支持Router模式 Ø GRPC支持 Ø 协议自动识别 Ø 链式路由扩展 Ø 完善流量管理策略，包括 Retry、DirectResponse、

Ø定义网络链接生命周期，事件机制 Ø定义可编程的网络模型，核心方法，监控指标 Ø定义可扩展的插件机制PROTOCOL 5 Ø定义编解码核心数据结构 üMesh处理三段式：Headers + Data + Trailers Ø定义协议Codec核心接口 ü编码：对请求数据进行编码并根据控制指令发送数据 ü解码：对IO数据进行解码并通过扩展机制通知订阅方 •定义扩展机制通知解码事件STREAMING 6 Ø定义Stream模型 Ø定义Stream层编/解码核心接口 ü 核心数据结构复用Protocol层 Ø定义可扩展的插件机制 Ø对于满足请求Stream池化的需求 Ø需处理上层传入的状态事件PROXY 7 Ø基于Stream抽象提供多协议转发能力 Ø执行Stream扩展Filters Ø提供可扩展的路由寻址能力 Ø提供可扩展的后端管理，负载均衡，健康检查能力 Ø维护上/下游核心指标转发流程 8 IO Read r data Log Writer Pool send encode Q u e u e C模块划分 11要点总结 12 Ø模块化，分层解耦 Ø统一的编程模型接口 Ø可扩展的事件驱动模型 Ø可扩展的路由/后端管理机制 Ø更好的吞吐量3 能力核心能力 1 网络处理 •网络编程接口 •链接管理 •事件机制 •Metrics 收集 •TCP 代理 •TLS 支持 •TProxy

Fork，增强，扩展，定制，集成 回馈社区，反哺开源 维持版本更新，同步升级 未来肯定会开源 可扩展和可定制化是必备的 可 控 性 社 区 支 持 技术输出 内部落地 如何让开源产品接受我们的改动？ 如何让社区和客户认可我们的产品？开源方案选择之第一代Service Mesh Linkerd • 无控制平面 • Scala编写，基于JVM资源消耗大 • 可扩展性有限，dtab不易理解和使用 可扩展性有限，dtab不易理解和使用 • 功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio • 腾讯：Tencent Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践 • 从Istio中剥离Pilot和Envoy • 去掉Mixer和Auth

精细化路由  安全防护  多协议  可运维  可扩展 • 多版本发布 • 压测引流 • 服务分组 • 加密链路 • 国密算法 • 服务鉴权 • TCP、Http、SOFA • 透明劫持 • 平滑升级 • 可观测性 • 网络包过滤器 • 协议包过滤器 • 协议扩展 • 可观测性扩展 • 路由扩展 • 集群管理扩展 模块化 安全 智能 高性能3/10 MOSN 助力业界最大规模之一的 更多的协议及服务框架支持 Dubbo、SpringCloud、 RocketMQ、gRPC、HTTP3、 MQTT、QUIC、TLS1.3 等 多协议 支持模块化 自适应限流 多协议深度扩展能力 多进程 WAF WebAssembly 兼容用户态协议栈 Lua 支持 核心和开放能力 适配 Istio，兼容 UDAP 协议 Zookeeper，Etcd Open Tracing

voy在设计上是可扩展的 Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？ 扩展点： ● L4/L7 filters ● Access loggers ● Tracers ● Health checkers ● Transport sockets ● Retry policy ● Resource monitors ● Stats sink 扩展方式： ● C++ C++ ● Lua(目前仅限于HTTP Traffic) ● Go extensions (beta, for Cilium)Envoy最新的扩展方式：Web Assembly Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？ - Support WebAssembly (WASM) in Envoy - https://github.com/envoyproxy/envoy/issues/4272 的机器码，因此WebAssembly运行速度和机器码接近。（类 比Java bytecode） (摘录自http://blog.enixjin.net/webassembly-introduction/)使用Web Assembly扩展Envoy的好处 Part 2：ServiceMesh灵魂拷问二：性能有了，架构怎么办？ • 避免修改Envoy • 避免网络远程调用（check & report） • 通过动态装载（重载）来避免重启envoy

Server(php/java/..) golang/php/java Registry grpc/yar/motan ➢ 语⾔言特性 ➢ 历史积累 ➢ 业务侵⼊入较⼤大，client太重 ➢ 性能 ➢ 扩展性差 ➢ 推⼴广困难 Register Subscribe NotifyService Mesh Meetup · BeiJing 服务治理理 �9 微博Service Mesh实践 - 数据交互 • 全⾯面/灵活可扩展 服务治理理Service Mesh Meetup · BeiJing 跨语⾔言服务化⽅方式对⽐比 �11 微博Service Mesh实践 - WeiboMesh Http代理理 RPC模块 Agent代理理 研发成本 低 ⾼高 中 维护成本 低 ⾼高 中 使⽤用成本 低 低 中 治理理功能 中 ⾼高 ⾼高 扩展能⼒力力 低 中 ⾼高Service motan2/simple pointerService Mesh Meetup · BeiJing Weibo Mesh 控制⾯面 �24 微博Service Mesh实践 - WeiboMesh ➢ 策略略扩展：Filter Chain ➢ 流量量调度：MCS（Mesh Command System）Service Mesh Meetup · BeiJing Motan Filter Chain �25

业务背景4/20 业务背景 业务架构 演进 • 容量  应用|数据库|机房 • 容灾  机房|地域5/20 业务背景 业务架构 单元化 • 高可用 • 一致性 • 可扩展 • 高性能6/20 业务背景 业务诉求 • 运维成本  突发流量应用 | 机房 生命周期 • 运维效率  大规模下基础设施稳定性 • 业务 Mesh 化  精细化流量控制  容灾切换和恢复 应急预案管理 … 分钟级容灾切换和恢复 全面变更风险管理 无限弹性可扩展 业务架构 产品层 云原生 PaaS 产品架构方案 7/209/20 二、多集群管控 多集群管控10/20 为什么要有集群联邦 • 异构屏蔽：  底层集群变化； • 统一管控：  业务弹性建站管控统一； • 可扩展：  多租硬隔离；  体量（单集群内节点数 1w+，Pod 10w+），集群数量多； 10w+），集群数量多； 多集群管控11/20 多集群管控 联邦核心能力 • 跨集群资源同步  Template,Override,Placement 模型;  状态回流；  扩展 CRD； • 跨集群发现12/20 联邦架构 • 关系型存储；  数据量  容灾 • 基于部署单元分发 多集群管控13/20 三、发布运维体系 发布运维体系14/20 应用管理&交付 • 基于统一管控背景下的