蚂蚁金服ServiceMesh数据平面 SOFAMosn深层揭秘 奕杉Agenda Ø背景 Ø构架 Ø能力 Ø性能 ØRoadMap背景为什么蚂蚁需要ServiceMesh Ø拥抱微服务，云原生 • SOFA 5规划落地 • 兼容K8S的智能调度体系 Ø运维体系的有力支撑 • LDC • 弹性伸缩 • 蓝绿/容灾/.. Ø金融级网络安全 • 金融级鉴权体系 • 云原生zero trust网络安全趋势 2SOFAMosn内数据流 3NET/IO 4 Ø屏蔽IO处理细节 Ø定义网络链接生命周期，事件机制 Ø定义可编程的网络模型，核心方法，监控指标 Ø定义可扩展的插件机制PROTOCOL 5 Ø定义编解码核心数据结构 üMesh处理三段式：Headers + Data + Trailers Ø定义协议Codec核心接口 ü编码：对请求数据进行编码并根据控制指令发送数据 ü解码：对IO数据进行解码并通过扩展机制通知订阅方 为网络协议请求/响应提供可编程的抽象载体 ü 考虑PING-PONG，PIPELINE，分帧STREAM三种典型流程特征 Ø定义Stream生命周期，核心事件 Ø定义Stream层编/解码核心接口 ü 核心数据结构复用Protocol层 Ø定义可扩展的插件机制 Ø对于满足请求Stream池化的需求 Ø需处理上层传入的状态事件PROXY 7 Ø基于Stream抽象提供多协议转发能力 Ø执行Stream扩展Filters

• 基本服务治理功能 App OSP Server Service Registry Service Config Center 服务发现 服务注册 服务元数据下发 OSP client 服务路由 网络传输 服务元数据上报缺点 • 语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2.0 - Service Mesh雏形 • 物理机、sidecar • Local 无法动态根据系统指标调整阈值 • 目标 • 用户无需拍脑袋设值，服务治理中心根据 历史指标进行推荐，对不合理的设置进行 建议，如 • 根据应用的历史延迟时间推荐超时设置 • 根据应用的历史流量数据推荐限流设置 • 根据动态指标自动调整配置 • 如单个实例内指标异常（超时率、cpu异常等） 动态调整限流值或直接降级 Proxy Server Intelligent center 机器指标 重差异容易造成资源浪费（上游超时返回了下 游还继续往下调）和数据不一致风险（上游以 为写失败了下游却写成功了） • 目标 • 实时上下游超时治理 • 通过传递剩余超时时间，让下游可以判断是否 继续一些重量级操作 • 实时上下游限流治理 • 下游资源异常（DB调用超时、redis超时等）动 态调整上游限流值或直接降级 • 智能路由 • 根据实时数据优化不合理的跨机房调用 Proxy App 服务调用

Mesh 演进 混合云架构落地实践 规划与展望3/24 严选ServiceMesh演进 /014/24 严选第一代 Service Mesh 架构 • 使用 Consul 作为服务发现组件 • 数据面：cNginx • 控制面：Consul 管理后台5/24 服务治理能力 – 基于严选第一代ServiceMesh（cNginx） 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） × 超时控制、重试、重写、重定向等：继承 Nginx 的 timeout 机制 √ 监控/故障诊断 链路追踪：主要依靠中间件 APM APM 性能监控：主要依靠中间件 APM APM 遥感数据：主要依靠中间件 APM APM 访问日志：主要依靠日志平台 日志平台 日志平台6/24 Service Mesh 为严选带来了哪些架构收益 • 历史包袱：现有的服务在不改造的情况下引入了服务治理能力 （限流、熔断、降级、分流等） • Istio 以 Sidecar 的形式运行在 Pod 中， 自动注入，自动接管流量，部署过程对业务 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面：Envoy • 控制面：Pilot，Mixer，Citadel，Galley10/24 功能视角 - 服务治理能力 – 基于Istio+Envoy 类型 功能 能力提供方 服务调用方（Client）

王成昌（晙曦）蚂蚁金服技术专家2/20 一、业务背景 二、多集群管控 三、发布运维体系 目 录 contents 目录3/20 一、业务背景 业务背景4/20 业务背景 业务架构 演进 • 容量  应用|数据库|机房 • 容灾  机房|地域5/20 业务背景 业务架构 单元化 • 高可用 • 一致性 • 可扩展 • 高性能6/20 业务背景 业务诉求 • 运维成本  突发流量应用 容器镜像管理 批次发布 原生资源管理 Pod伸缩管理 集群伸缩管理 变更管控 配额管理 运维原子操作 精细化调度 接入层流程调拨 应用层流量调拨 跨集群状态 分发/汇聚 数据层流量调拨 压测/灰度 流量管理 单元化 元数据管理 弹性流量管理 跨集群发布策略 多集群管理 跨集群网络 跨集群镜像管理 蓝绿发布 灰度分组发布 中间件变配 （DRM/Scheduler/Message） Mesh流调拨和治理 联邦核心能力 • 跨集群资源同步  Template,Override,Placement 模型;  状态回流；  扩展 CRD； • 跨集群发现12/20 联邦架构 • 关系型存储；  数据量  容灾 • 基于部署单元分发 多集群管控13/20 三、发布运维体系 发布运维体系14/20 应用管理&交付 • 基于统一管控背景下的 Dockerfile 管理和生成； • 基于组件关联的

微服务结合容器云平台的思考和实践 2018.06.25 徐运元关于我 2008年毕业于浙江大学，曾在思科和浙大网新有超过 9年的工作经验和5年的云计算领域工作经验，带领团 队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 易于分配的存储 • 易于访问的外围（负载均衡） • 服务注册和发现 致富问题 • 认证和授权 • 智能路由 • 流量管理 • 服务降级 • … • 微服务拆分原则 • 业务API设计 • 数据一致性保证 • 可扩展性考虑 • …Kubernetes对于微服务的支撑 功能列表 详情 快速资源分配 容器编排和调度 服务部署&弹性伸缩 Deployment 服务注册&服务发现 Service概念和分布式DNS • 流量管理（超时、重试、熔断） • 故障处理 • 故障注入 • … Mixer • 前提条件检查：安全认证，黑白名单， ACL检查 • 限流管理 • 遥测报告：日志监控 控制平面 数据平面 Istio-Auth • 服务间认证 • 终端用户认证Istio的核心组件 • Envoy 是一个高性能轻量级代理，它掌控了service的入口流量和出口流量，它提供了很多内置功能，如动态负

表实现了一个全新的透明拦截组件#2 短时间内支持电商业务复杂的服务治理功能 •单元化？多环境？基于参数调用的路由？ 1. RPC 使用的是 Groovy 脚本，Mesh 不具备。 2. RPC 并没有将参数作为元信息放置 在请求头。#3 短时间内支持电商业务复杂的服务治理功能 •扩展 VirtualService 和 DestinationRule#3 短时间内支持电商业务复杂的服务治理功能 •未来计划在 Sidecar 热升级，流量无损切换 1. 迁移至新的 Listener Fd 2. 告之新的请求重启链路，继续处理 老的回调 3. 请求重新连接使用新的 Envoy 4. 直到老的不再收到回调数据，下线让我们一起兑现 Service Mesh 价值Thank you ! 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT

Mesh风头正劲Service Mesh产品多样化Service Mesh的优势 云原生 零入侵 可观察性 面向运维服务化之后，数据库怎么办？ 服务 • 无状态 • 根据规则路由 • 业务方处理事务 数据库 • 有状态 • 根据SQL路由 • 数据库自动处理事务数据库的进化趋势 • SQL • ACID • 分布式 RDBMS • SQL • BASE ACID • 分布式 NewSQL?数据库中间层的优势 系统 •事务 运维 • DBA 开发 • SQL数据库中间层应具备的能力 分片化 多副本 数据一致性 弹性化 治理能力 观察能力数据分片 App2 DB App1 App3 App2 DB1 DB2 DB3 App1 App3数据分片：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 App1 M App2 App3 write sync read数据分片 + 读写分离 App1 S1 App2 App3 M2 sync read S2 S3 M1 M3 write数据分片 + 读写分离：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 write sync read分布式事务：定义 传统事务：ACID

与现有架构的兼容性 现阶段的关键需求 技术储备与原则类因素 自研数据平面与 控制平面方案 使存量服务接入Mesh 方案 对接大量内部系统 关键收益均由数据平面产生 非完善的控制平面功能 技术体系内不引入Go语言 最成熟的服务端语言为Java 使用Java开发 数据平面Agent14/24 整体架构 数据平面 • 现有协议的流量转发 • Agent平滑升级机制 控制平面 控制平面 • 轻量的Pilot Proxy • 向Istio的标准协议靠拢 重点目标 长期规划15/24 数据平面实践细节 • 部署方式 • 升级方式 • 容灾方式 • 性能问题 • 资源问题 • 兼容问题 关键设计 关键问题16/24 数据平面部署方式 容器化运行方式 • sidecar模式 • 与业务进程相同Pod不同Container 陌陌微服务容器化部署比例在80%以上 sidecar模式部署17/24 数据平面升级方式 – 平滑升级机制 平滑要求 • 业务进程不重启 • 流量保持不变 方案选择 • FD迁移 vs 哨兵集群 原理 • sendmsg / recvmsg接口发送FD • 步骤：listener、存量连接、存量数据 Java实现 • 借助JNI与Netty Java实现FD迁移18/24 数据平面升级方式 – 发布流程 容器化发布方式

功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio • 第一选择，重点关注对象 • 奈何迟迟不能发布生产可用版本 奈何迟迟不能发布生产可用版本 • 性能和稳定性远远不能满足蚂蚁的 要求 • 但我们非常认可Istio的理念和方向 Conduit • 只支持k8s，而蚂蚁尚未普及k8s • 数据平面由Rust编写，过于小众，难于 从社区借力。 • 同样存在技术栈问题 • 公司和产品在社区知名度和影响力有限国内公司的选择之一：自研 华为：CES Mesher • 使用Golang编写 • 由go 第 一时间获取跨语言和技术栈下沉的红利，立足 之后再缓缓图之。 这个产品思路唯一的麻烦在于编程语言的选择国内公司的选择之二：开源方案定制 腾讯：Tencent Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service

traffic(For example: Rate limiting, Service priority, etc.)总结：他山之石，可以攻玉 • 解决类似的问题：运维和通信的问题 • 相似的解决方案：数据面+控制面+应用 • 不同的协议层次：SDN 2-4层，Service Mesh 主要为7层 SDN对Service Mesh发展的启发： Ø 北向接口 • 面向业务和运维 • 具有较高 Ø 南向接口 • 面向流量和路由配置 • xDS v2将统一数据面标准？ • xDS接口包含有较多实现相关内容：Listener, Filter, 能否可以成为一个通用的接口协议？ 是否会出现Envoy之外的大量数据面实现？ • 建议：对xDS接口进行改进，去掉实现相关内容 Ø Service Mesh的发展 • 控制面对数据面软硬件的统一控制能力？ • 通过控制面API接入各种丰富的应用场景 MSB-SDClient MSB-Consul Jaeger DexMesh数据面 Pod Microservice Envoy Desktop OtherSystems Mobile DexMesh Ingress Pod Microservice Envoy (Telemetry， Policy check) 配置数据(服 务信息，路由 信息等) 定制Istio组件 应用微服务