SOFA MESH 的通用协议扩展 Service Mesh Meetup #3 深圳站 邵俊雄（熊啸） 2018.08.25AGENDA • SOFA MESH 介绍 • SERVICE MESH 落地的问题 • SOFA MESH 的通用落地方案 • DNS 服务寻址方案 • X-PROTOCOL 通用协议 • 问答SOFA MESH • 从 ISTIO 克隆并保持同步更新 • 使用 服务治理规则，服务，实例和配置都是 Kubernetes 资源 • 使用 Controller Pattern 通过 CRD 扩展新的能力 • …MESH 落地碰到的问题 • 客户端服务发现与负载均衡无法与 ISTIO 一起工作 • ENVOY 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 RPC 服务，每个服务有自己的版本 DUBBO 服务的路由规则 XDS 适配 • 开发 DUBBO 协议支持SOFA MESH 的统一解决方案 • 采用 Kubernetes Native 方式落地微服务应用 • 使用 INTERFACE 作为 DNS 来寻址服务 • 开发一个通用协议处理框架 • 避免为不同的微服务框架修改 PILOT 代码 • 通过插件的方式按需支持新的协议 • 对应用代码无侵入性 • 为微服务框架提供轻量化客户端落地一个微服务框架需要的工作

2010年前部署商用设备 前世 01 2010 开始网络代理白盒 化，定制业务逻辑，软 硬件一体解决方案 自研 02 2015 年无线通道协议，安 全升级， 连接收编 All in 无线 03 PC时代 移动时代 万物互联云原生时代 2018 年协议，安全持续升 级（QUIC，MQTT，国密）， 云原生 再启程 03前世 F5 BigIP Netscaler自研四层网络代理 2011 支持蚂蚁LDC架构，三地五中心容灾架构 • 全面上线SSL加速卡，提供软硬件一体加速方案 2015 • All in 无线，通信通道全面升级（MMTP，MTLS协议） 2016 • 安全防护能力提升，WAF，流量镜像 2018至 今 • 通信协议，架构，安全再次升级（物联终端接入，QUIC协议，国密，可信计算， 海外加速，云原生）金融级三地五中心容灾架构（LDC） 单机房 LDC 同城双活 LDC 异地多活 实现多芯片卡的负载均衡协议实现的改造-MTLS MTLS：1) 轻量级TLS库，小于50k；2) 优化的TLS协议 0-RTT • 减少握手延迟 • 代价：握手前发送的数据不能 保证防重放攻击，因此要求应 用程序自己保证防重放攻击 Small Ticket • 自定义Session Ticket编码格式 • 160 byte -> 76 byte • Session Ticket扩展 用于会话复用，加速握手过程

广州站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 xDS 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模型 ü 向上确保协议行为一致性 ü ü 为网络协议请求/响应提供可编程的抽象载体 ü 考虑PING-PONG，PIPELINE，分帧STREAM三种典型流程特征 Ø定义Stream生命周期，核心事件 Ø定义Stream层编/解码核心接口 ü 核心数据结构复用Protocol层 Ø定义可扩展的插件机制 Ø对于满足请求Stream池化的需求 Ø需处理上层传入的状态事件PROXY 7 Ø基于Stream抽象提供多协议转发能力 Ø执行Stream扩展Filters Ø执行Stream扩展Filters Ø提供可扩展的路由寻址能力 Ø提供可扩展的后端管理，负载均衡，健康检查能力 Ø维护上/下游核心指标转发流程 8 IO Read Codec Stream Route / LB Codec Stream IO write F1 F2 F1 F2 F1 F2 IO Read Filters IO Write Filters Stream Filters

ZooKeeper 多协议接入 TLS，国密 WAF，DDos2/10 MOSN 核心能力沉淀  精细化路由  安全防护  多协议  可运维  可扩展 • 多版本发布 • 压测引流 • 服务分组 • 加密链路 • 国密算法 • 服务鉴权 • TCP、Http、SOFA • 透明劫持 • 平滑升级 • 可观测性 • 网络包过滤器 • 协议包过滤器 • 协议扩展 • 可观测性扩展 可观测性扩展 • 路由扩展 • 集群管理扩展 模块化 安全 智能 高性能3/10 MOSN 助力业界最大规模之一的 Service Mesh 实践 核心支付链路覆盖 容器规模 几十万 峰值 QPS 千万 CPU 0%~2% MEM 15M RT 0.2ms 极低消耗 100% 1~2 次/年  10+次 /月 快速迭代4/10 这两年，MOSN 如何走过 2017年底 开始调研 安全审计 社区 更多的协议及服务框架支持 Dubbo、SpringCloud、 RocketMQ、gRPC、HTTP3、 MQTT、QUIC、TLS1.3 等 多协议 支持模块化 自适应限流 多协议深度扩展能力 多进程 WAF WebAssembly 兼容用户态协议栈 Lua 支持 核心和开放能力 适配 Istio，兼容 UDAP 协议 Zookeeper，Etcd

Server(php/java/..) golang/php/java Registry grpc/yar/motan ➢ 语⾔言特性 ➢ 历史积累 ➢ 业务侵⼊入较⼤大，client太重 ➢ 性能 ➢ 扩展性差 ➢ 推⼴广困难 Register Subscribe NotifyService Mesh Meetup · BeiJing 服务治理理 �9 微博Service Mesh实践 - 相同的治理理功能，不不同语⾔言的服务都要做⼀一遍？Service Mesh Meetup · BeiJing 跨语⾔言服务化的本质 �10 微博Service Mesh实践 - WeiboMesh • 协议中⽴立/跨语⾔言 数据交互 • 全⾯面/灵活可扩展 服务治理理Service Mesh Meetup · BeiJing 跨语⾔言服务化⽅方式对⽐比 �11 微博Service Mesh实践 - WeiboMesh Http代理理 RPC模块 Agent代理理 研发成本 低 ⾼高 中 维护成本 低 ⾼高 中 使⽤用成本 低 低 中 治理理功能 中 ⾼高 ⾼高 扩展能⼒力力 低 中 ⾼高Service Mesh Meetup · BeiJing Service Mesh �12 微博Service Mesh实践 - WeiboMeshService Mesh Meetup · BeiJing

相似的解决方案：数据面+控制面+应用 • 不同的协议层次：SDN 2-4层，Service Mesh 主要为7层 SDN对Service Mesh发展的启发： Ø 北向接口 • 面向业务和运维 • 具有较高的抽象层次，比较容易提取统一的控制面标准？ • 主要面向layer 7及以上？ • SMI能否统一控制面标准？如何避免成为最小公分母，扩展支持其它协议？ Ø 南向接口 • 面向流量和路由配置 面向流量和路由配置 • xDS v2将统一数据面标准？ • xDS接口包含有较多实现相关内容：Listener, Filter, 能否可以成为一个通用的接口协议？ 是否会出现Envoy之外的大量数据面实现？ • 建议：对xDS接口进行改进，去掉实现相关内容 Ø Service Mesh的发展 • 控制面对数据面软硬件的统一控制能力？ • 通过控制面API接入各种丰富的应用场景 - 下一个热点？总体架构-高层视图 Service纳入Service Mesh管控？ l 收益 Ø TCP Service可以享受流量管理，可见性，策略控制等Istio承诺的益处 l 成本 Ø Istio不理解TCP上的应用层协议，其对TCP Service的缺省处理会影响应用层逻 辑 -例子：Envoy的LB算法不能处理应用后端集群的Sharding Ø Istio中和HTTP Service 端口冲突会的TCP Service请求会被Envoy直接丢弃

基于严选第一代ServiceMesh（cNginx） 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：基于 Consul √ 调用控制 协议支持：HTTP 1.X/2.X，可扩展至 TCP √ 路由控制：提供简单的路由能力 √ 负载均衡：支持 RR、权重、一致性 Hash 等 √ 流量复制：不提供 × 故障转移：继承 Nginx 的 Failover 基础架构与业务架构可以独立演进 • 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 • 增强流量管理能力 • 将更多治理特性（如限流、熔断、故障注入）与业务架构解耦 • 支持更多的协议 • 增强控制面 • 配合业务容器化上云及混合云架构8/24 行业技术演进 - 通用型 Service Mesh 出现 2017年1月23日 加入 CNCF 2017年4月25日 1.0Releases 基于Istio+Envoy 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：云外基于 Consul，云内基于 K8s 默认的 ETCD √ 调用控制 协议支持：HTTP 1.X/2.X，GRPC,WebSocket，Dubbo， Thrift √ 路由控制：静态路由、动态路由、流量染色、分流控制等 √ 负载均衡：支持 RR、权重、一致性 Hash

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

envoy？不现实，自有协议+历史负担。 SDK/透明劫持：运维和可监控性不好，性能不高，风险不太可控。12 方案落地-目标架构 MOSN APP Pod MOSN APP Pod 服务发现 More Sidecar More Sidecar Pilot MQ Kubernetes Sidecar Operator 产品层 运维能力 监控能力 流量调控 安全能力 扩展能力 HTTP/RPC13