蚂蚁金服网络代理演进之路 肖涵（涵畅） 蚂蚁金服高级技术专家 2019.10.26 Service Mesh Meetup #7 成都站网络代理是什么？ 南北流量 东西流量 Server App 负载均衡器 NAT网关 防火墙 负载均衡器 NAT网关 防火墙 负载均衡器 负载均衡器 路由器 路由器 Internet网络代理有什么？ Maglev Ipvs Katran 云原生 再启程 03前世 F5 BigIP Netscaler自研四层网络代理 2011 2014 2018 未来 Ø 全面使用DPDK技术重构 Ø EBPF，XDP Ø 可编程交换芯片（P4语言） Ø 四层负载均衡-IPVS Ø NAT网关蚂蚁七层网络代理 Google Spanner?蚂蚁七层网络接入代理 Spanner蚂蚁七层网络接入代理 AGNA （Ant Global Network Sidecar专注服务间通讯 混合在一个进程内， 应用既有业务逻辑， 也有各种功能 业务进程专注于业务逻辑Service Mesh 为什么蚂蚁需要Service Mesh • 拥抱微服务，云原生 • 异构语言体系融合 • 统一服务治理 • 运维体系有利支撑 • 全局流量管理，打通南北，东西 • 金融级网络安全为金融业务而生的SOFAMesh Pod Spring Cloud 应用 SOFAMosn

SOFAMOSN 持续演进路径及实践案例 陈逸凡 wugou.cyf@antfin.com 2019.1.6 Service Mesh Meetup #5 广州站Agenda Ø 背景 & 概览 Ø 持续演进路径 & 技术案例 Ø 实践案例 Ø 规划 & 展望 Ø QA背景 & 概览数据平面概览 SOFAMOSN • C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4.0 Ø TCP代理/7层通用代理 Ø 简单匹配路由 Ø 集群管理 & 基本负载均衡(RR、 RANDOM) Ø SofaRpc及HTTP/1 2018.08版本 p 部署模式: Client <-> MOSN<-> Service p Client模拟方式:通过蚂蚁内部压测平台建立10w条SOFARPC链接 p 压测内容: 1K 请求/响应持续演进实践总结 ü 架构上，从一开始就遵循分层设计，模块解耦，统一编程模型接口，保证足够的架 构扩展性。 ü 性能上，针对IO、协议、内存、协程进行持续优化。相比最初版本，SOFARPC 协 议上对

上海站 蚂蚁金服Service Mesh 渐进式迁移方案 2018.11.25 敖小剑 @ 蚂蚁金服 中间件 龙轼 @UC 基础研发部1 Service Mesh演进路线 1 2 实现平滑迁移的关键 3 DNS寻址方案的演进 4 5 总结 DNS寻址方案的后续规划ü 对未来长期目标的认可 • Service Mesh（带控制平面，如Istio） • Kubernetes • 微服务 接受范围内 • 每一步都简单方便，切实可行 可操纵性 • 操作层面上要有足够的弹性 • 每个步骤都是可分批进行 • 步步为营，扩大战果 • 杜绝一刀切k8s和Service Mesh落地方案演进路线 部署在 非k8s上 不是Service Mesh形态 部署在K8s上 非SM 部署在 非k8s上 Service Mesh (Sidecar模式) 部署在K8s上 Service Mesh 好处是第一步（非k8s上向Sidecar模式演进）非常自然 • 容易落地 • 快速达成短期目标 ü 缺点是再往后走 • 由于没有k8s的底层支持，就不得不做大量工作 • 尤其istio的非k8s支持，工作量很大 • 而这些投入，在最终迁移到k8s时，又被废弃 ü 结论： • 不符合蚂蚁的远期规划（k8s是我们的既定目标） • 会造成投资浪费（k8s铺开在即） 演进路线2分析 部署在 非k8s上

/02 /03 背景 问题 实践 微服务体系演进历程 架构痛点与解决思路 Service Mesh落地方案3/24 背景 /01 陌陌微服务体系演进历程4/24 单体应用到微服务 单体应用 微服务架构 应用拆分 加入PHP API层 PHP API层成为后续多语言服务治理的关键挑战5/24 微服务体系演进 MOA 1.0微服务体系演进历程 自研服务框架产品MOA（Momo service Architecture）于2013年初上线推广 微服务体系的其他产品也均为自研方案6/24 MOA 1.0微服务体系整体架构 注册中心 • Redis作为底层存储 • 跨语言地址发现服务Lookup • 中心化存活检测 多语言支持 • Java、PHP、Python、Go、NodeJs • Redis传输协议 / 复用Redis客户端 • 服务发布Proxy / 并行调用Proxy 服务治理 服务治理 • 服务治理平台、配置中心 • 监控、日志、分布式跟踪 • 异步调用、压测7/24 流量代理机制 PHP服务发布入流量代理 PHP并行调用出流量代理 16年起开始使用流量代理机制解决跨语言服务治理问题8/24 分享主题：字号 分享嘉宾 发布服务数 2000+ 注册实例数 2万+ 全天调用量 3500亿 微服务体系规模 服务量级的增长使得Java应用的服务治理问题

Mesh 架构全面落地 基础架构三问： 1. 服务治理：RPC 框架 vs 服务治理平台 2. 多语言 vs Java 3. 开源 vs 自研2/24 /01 /02 /03 严选 Service Mesh 演进 混合云架构落地实践 规划与展望3/24 严选ServiceMesh演进 /014/24 严选第一代 Service Mesh 架构 • 使用 Consul 作为服务发现组件 大大降低了中间件的研发投入和演进成本，也降低了业务和中间件的耦合成本 • 基础架构与业务架构可以独立演进 • 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 • 增强流量管理能力 • 将更多治理特性（如限流、熔断、故障注入）与业务架构解耦 • 支持更多的协议 • 增强控制面 • 配合业务容器化上云及混合云架构8/24 行业技术演进 - 通用型 Service 容器网络 client sidecar 接近 VM 网络直连 • 容器网络 client sidecar 远远优于 VM cNginx（256并发 6.707 vs 15.771）13/24 当前演进方向 整体基于 Envoy+Istio 方案： • 数据面以 Envoy Proxy 作为代理组件 • 控制面以 Pilot 为核心组件 • 平台开放与扩展主要通过 Kubernetes

服务发现 负载均衡 熔断限流 服务路由 …… 混合在一个进程内， 应用既有业务逻辑， 也有各种功能， 每次升级都要重新发布应用 升级成本高 版本碎片化严重 中间件演进困难6/39 微服务治理与业务逻辑解耦 Part 1： 为什么需要Service Mesh? Service 业务逻辑 SDK 协议编解码 服务发现 负载均衡 熔断限流 业务进程专注于业务逻辑 SDK 中的大部分功能， 拆解为独立进程， 以 Sidecar 的模式运行 将服务治理能力下沉到基础设施，实现独立演进，透明升级7/39 异构系统统一治理 Part 1： 为什么需要Service Mesh? 多语言、多协议 图片来源：https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh 2018年初开始用Golang 开发 Sidecar SOFAMosn， 年中开源基于 Istio 的 SOFAMesh 技术探索 02 2018年开始内部落地，第一 批场景是替代 Java 语言之外 的其他语言的客户端 SDK， 之后开始内部小范围试点 小规模落地 03 2019年上半年，作为蚂蚁金融级 云原生架构升级的主要内容之一， 逐渐铺开到蚂蚁主站的业务应用， 并平稳支撑了618大促

第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 Pilot-Agent核心流程解读Kubernetes平台下的微服务演进当我们在讨论微服务的时候我们在讨论什么？ • 解决如何微服务的问题 • 解决微服务化后带来的问题 温饱问题 • 计算资源的快速分配 • 基本的监控 Configmap、Secret 负载均衡 简单负载均衡，基于Iptables Roundrobin 流量控制 简单根据服务实例进行控制云平台微服务演进之基于API网关的微服务方案 API网关功能增强 • 安全认证 • 流量控制 • 审计日志 • 黑白名单 • …K8S集群 云平台微服务演进之基于Spring Cloud的微服务方案 NS A Service Zuul Nginx Eureka Server Kubernetes + Spring Cloud 看起来很美背后 • 功能上的重叠 • 服务降级 • 细粒度的鉴权（服务间的调用） • RPC支持 • 跨语言的问题 • …云平台微服务演进之Service Mesh云平台微服务演进之Service Mesh Pilot Envoy • 服务发现 • Envoy生命周期管理 • Envoy配置下发 • 服务模型 • 配置模型 •

Mesh的实践分享 郑德惠 2019.1.6 Service Mesh Meetup #5 广州站• 唯品会内部Service Mesh的演进 • 与Istio的区别 • 实践中踩过的坑 • 今年规划（Roadmap）内部Service Mesh的演进 我是作者名称服务化体系1.0 • OSP（Open Service Platform） • Thrift over Netty • Service Registry Service Config Center 服务发现 服务注册 服务元数据下发 OSP client 服务路由 网络传输 服务元数据上报缺点 • 语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2.0 - Service Mesh雏形 • 物理机、sidecar • Local & Remote，主与备 • 轻量级客户端、本地调用 Service Config Center Remote Proxy Cluster API Gateway 备用链路 服务发现 服务注册 配置下发 服务路由 网络传输 OSP client多语言客户端接入 • HTTP & TCP • Local & Remote • 根据接入对象的不同，制定 不同的接入策略，达到 • 接入简单 • 保证性能 • 节省资源 Java App Local

chassis演进而来 • 走的是已有类库->加proxy->再加 控制平面的路线 • 部分对接Istio • 细节暂时不清楚，即将开源 新浪微博：Motan Mesh • 也是使用Golang编写 • 全新实现（原有类库是基于Java） 老成持重的稳健思路：以proxy为切入口，第 一时间获取跨语言和技术栈下沉的红利，立足 之后再缓缓图之。 这个产品思路唯一的麻烦在于编程语言的选择国内公司的选择之二：开源方案定制 内公司的选择之二：开源方案定制 腾讯：Tencent Service Mesh • 数据平面选择Envoy：成熟产品，符合 腾讯语言体系，内部广泛使用 • 控制平面据传“挣扎了一下”，最终还 是选择Istio，进行定制和扩展，解耦k8s国内公司的选择之三：另辟蹊径 UCloud：Service Mesh • 非常有意思的轻量ServiceMesh实践 • 从Istio中剥离Pilot和Envoy 蚂蚁有丰富的业务场景，技术体系也经历了很长时间的发展，沉淀了很多自研产品 • 蚂蚁本身业务上的开放策略，要求技术也要开放，而且要在更丰富的场景下去磨炼 • 在此期间，我们趟坑无数，走了N多弯路，演进了N个版本，我们期望能过通过开源和 开放，让社区跑的更快，节省更多时间 • 我们认为金融领域下的分布式架构设计有独特的原则，作为实践者，我们期望能在标准 化上跟社区一起沉淀和共建，期望做些贡献，有些建树Sofa

PPT自我介绍 •嵌入式、微服务框架 •2017 年加入阿里巴巴，负责阿 里集团数十万集群节点规模化运 维管理系统的研发工作 •2019 年参与集团全面上云项目 并经历了整体架构的云原生升级 演进，稳定支撑双11峰值流量分享内容 • 阿里全站上云 • 神龙 (what & why) • 规模化集群运维实践 • 未来工作云原生全景图阿里全站上云 • 2018年底：阿里经济体全面上云 额度管控 监控体系 多租隔离 上层业务 集 团 业 务运维挑战 • 规模大 • 集群规模大 (数十个集群)，节点数量多 (数十万节点) • 业务线多、应用数量多、应用类型复杂 (有状态、无状态、多语言) • 基础环境复杂 • 大规模 在线、离线 混部 (运维打通) • 装机模板、OS版本、内核版本多；内核补丁、参数不同；其他如网卡中断打散 • 稳定性要求高 • 性能、宕机、夯机、抖动系统架构 回滚 • 故障自愈 • 运维事件 • 业务置换Machine Operator未来工作 • 稳定性、资源利用率、运维效率 • 基于安全容器的新混部架构 • 全业务上云、Serverless 演进 • 精细化观测和全链路诊断❖ No data, No BB ❖ Automate Everything ❖ Think big, Go deep ❖ We are hiring!Thank