Mesh的技术选型， 架构设计以及开源策略。 前言技术选型 Technical 1ü 性能要求 • 以蚂蚁金服的体量，性能不够好则难于接受 • 架构与性能之间的权衡和取舍需要谨慎考虑 ü 稳定性要求 • 以蚂蚁金服的标准，稳定性的要求自然是很高 • 高可用方面的要求很非常高 ü 部署的要求 • 需要用于多种场合：主站，金融云，外部客户 • 需要满足多种部署环境：虚拟机/容器，公有云/私有云，k8s 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio • 第一选择，重点关注对象 • 奈何迟迟不能发布生产可用版本 • 性能和稳定性远远不能满足蚂蚁的 要求 • 但我们非常认可Istio的理念和方向 C++带来的技术栈选择问题 • 我们有太多的扩展和定制 • 而且，proxy不仅仅用于mesh Istio • 控制平面：Istio是目前做的最好的 • 认可Istio的设计理念和产品方向 • 性能和稳定性是目前最大问题 • 对非k8s环境的支持不够理想 • 没有提供和侵入式框架互通的解决方案Sofa Mesh：istio的增强扩展版 Pilot Auth Mixer Envoy Pilot

PPT自我介绍 •嵌入式、微服务框架 •2017 年加入阿里巴巴，负责阿 里集团数十万集群节点规模化运 维管理系统的研发工作 •2019 年参与集团全面上云项目 并经历了整体架构的云原生升级 演进，稳定支撑双11峰值流量分享内容 • 阿里全站上云 • 神龙 (what & why) • 规模化集群运维实践 • 未来工作云原生全景图阿里全站上云 • 2018年底：阿里经济体全面上云 • 2019上云第一仗：基础设施上云 交付周期 周 分钟级 弹性扩缩容 - 支持 性能 独占 独占 (优于普通ECS) 硬件故障率 硬盘1年故障率 2% 0.8%% (无本地盘) 硬件维修周期 [周, 月] [分钟，天]成本 效率 稳定云化架构 物理机 + 本地存储 + Underlay网 络 神龙/ECS + 远程存储 + Overlay网络 集团机房 云上机房 基础设施 IDC 系统 基础运维 天基系统 CMDB 安全审计 业务线多、应用数量多、应用类型复杂 (有状态、无状态、多语言) • 基础环境复杂 • 大规模 在线、离线 混部 (运维打通) • 装机模板、OS版本、内核版本多；内核补丁、参数不同；其他如网卡中断打散 • 稳定性要求高 • 性能、宕机、夯机、抖动系统架构 • 基础监控 • 秒级、分钟级监控 • 内核性能指标采集 • 监控大盘 • 在线率 • 宕机率 • 抖动率 • 基线系统 • 基础环境一致性故障自愈

Maglev Ipvs Katran GFE BFE TGW Nginx Apache httpd SOFAMosn Envoy Linkerd网络的挑战网络的挑战 高效接入 访问加速 容量 稳定性 高可用 灵活弹性 安全合规 防攻击蚂蚁金服网络接入十年变迁 2010年前部署商用设备 前世 01 2010 开始网络代理白盒 化，定制业务逻辑，软 硬件一体解决方案 自研 02 2015 Mobile，iot设备等多终端支持 • OpenSSL Committer无线移动战役 操作响应慢 操作无响应 Push没消息 Push消息慢 海外消息慢 收发图片慢 建连时长 建连成功率 链路稳定性 链路一致性 RPC错误率 Push实时性 海外RTT 数据效率 快 速 稳 定 高 效 移动客户痛点 性能指标 线下支付 大促 国际支付咻一咻与敬业福咻一咻的挑战 • 大规模场景下需要面对的资源占用，自动化问题、性能问题，稳定性问题兼容问题 § 不同的应用，部分Mesh化 § 同一个应用，部分Mesh化 § 蚂蚁基础设施适配 § TLS加密链路平滑迁移 Localhost or Iptables 透明劫持和加速大规模问题 10万+实例 动态服务发现 运维 § 对控制平面性能，稳定性带来巨 大挑战 § 单实例数万路由节点，数千路由 规则，不仅占用内存，对路由匹

基于容器服务的大促备战 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT我是谁挑战在哪里？ 极限并发 人为失误 系统瓶颈 雪崩 单点失效 成本控制 用户体验 最终一致性 稳定性 资源不足 资源利用率 安全风险备战工具箱 服务化 开发运维一体化 弹性 极致性能 高可用 全站上云 安全加固 人工智能 大数据 离线计算 全链路压测 边缘计算 敏捷调度

先原生，后二开 • 先管控面，后数据面落地场景—Spock测试平台 • 历史问题 • 分布式系统性能测试问题 定位难 • 多版本并发测试 • 故障注入较困难（代码侵 入性强） • 测试环境不稳定，后端Pod 频繁重启 • 解决方案 • Contour产品化 • Istio的灰度发布和流量管理 • Istio的Tracing产品化落地场景—云存储系统 • 历史问题 • 灰度发布 •

单体架构 Logic Logic Logic Logic 支付宝移动网关的前身（2009-2013） 特点： • ALL in One • 简单 HTTP 缺点： • 研发效能低 • 稳定性差9/21 APP 微服务网关架构 APP1 Logic Logic API Gateway APP2 Logic Logic 微服务网关架构（2013-2016) LB spanner

Kubernetes 实践 Part 2：8/19 资源分时调度 Part 2：双十一 Kubernetes 实践 快速腾挪的问题 1.实例上下线需要预热 2. 腾挪耗时不可控 3. 大规模腾挪的稳定性技术风险 9/19 资源分时链路切换 Part 2：资源分时调度 Kubernetes Node 分时调度 Agent Pod 资源 Node 分时调度 Agent Pod

业务架构 单元化 • 高可用 • 一致性 • 可扩展 • 高性能6/20 业务背景 业务诉求 • 运维成本  突发流量应用 | 机房 生命周期 • 运维效率  大规模下基础设施稳定性 • 业务 Mesh 化  精细化流量控制  基础组件升级 • 业务可复制  业务敏捷  SaaS 面向站点级别输出7/20 PaaS 能力 • 面向多租户多环境； • 基础资源管控；

框架不断升级 14% 2.机器资源逐年增加 27% 1.业务和框架耦合 32%8 因为我们要解决在 SOA 下面，没有解决但亟待解决的： 基础架构和业务研发的耦合，以及未来无限的对业务透明的稳定性与高可用相关诉求。 为什么要 Service Mesh-结论9 为什么要 ServiceMesh-结论-方案 应用A 应用 应用B 应用C 应用D 应用E SOA 解耦了不同的业务团队之前的耦合

借助Service Mesh解决现有架构痛点10/24 架构痛点分析 服务治理能力滞后 非Java应用 Java应用 SDK迭代进度缓慢 SDK推广升级缓慢 危害 无法实现架构统一 稳定性受损、引发故障 架构方案受限 …11/24 引入Service Mesh 是否足够成熟 是否有替代方案 是否可接受成本 是否能兑现价值 观察阶段 试验阶段 评估阶段 启动阶段 思考