深入 Kubernetes 的“无人区” —— 蚂蚁金服双十一的调度系统 曹寅2/19 一、蚂蚁金服的Kubernetes现状 二、双十一Kubernetes实践 三、展望未来迎接挑战 目 录 contents 目录3/19 一、蚂蚁金服的Kubernetes现状 Part 1：4/19 发展历程与落地规模 Part 1：蚂蚁金服的Kubernetes现状 平台研发 灰度验证 灰度验证 云化落地 规模化落地 2018年下半年开始投 入 Kubernetes 及其配 套系统研发 2019年初于生产环境 开始灰度验证，对部分 应用做平台迁移 2019年4月完成云化环境 适配，蚂蚁金服云上基础 设施全部采用 Kubernetes 支撑618 2019年7月到双十一前完成 全站 Kubernetes 落地，超过 90% 的资源通过 Kubernetes 分配，核心链路100%落地支撑

• Q&A技术架构的演进 • 单体架构 • 一个框架 • 一个数据库 • 分模块整合架构（前后端分析） • 不同的框架或业务模块 • 多种数据源 • 微服务架构 • 各种语言、各种框架或子系统 • 各种数据源 • ServiceMesh一般的开发流程 • 1. 开启一个新的 feature； • 2. Developer 从 develop 分支新建一个 feature/new_branch 的开发； • 3. 开发完成后，提交 merge request（MR）请求合并到 develop 分支； • 4. MR 触发 Jenkins，Jenkins/Drone 触发 Sonar 代码质量检测系统； • 5. Sonar 将 report 和 issue 以 comments 的方式写到 Gitlab MR 中； • 6. Developer 对 MR 进行反复修复直至通过 Sonar 的分析； 是一种文化：一切自动化，工具化，规范化；选择哪个 CI/CD 工具？Docker stats 查看 Docker 服务所占用的CPU和内存开销DroneDrone • 一款使用 Go 开发，基于容器技术的 CI/CD 系统，能够单独部署，支持几乎所有的 Git 平台（Github,Gitlab,Bitbucket,Gogs,Gitea 等）。 • 它的特点： • 一个 .drone.yml 搞定（简单） • 原生

Director的选择：ServiceMesh先行 Traffic Director 官方文档如是说：“按您的节奏进行现代化改造”Part 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ 托管式实例组：效仿容器和k8s的方式来管理虚拟机 容器的硬件配置 实例模版的硬件配置 硬件 镜像文件的基础镜像 实例模版的操作系统配置 操作系统 镜像文件 自动启动脚本 创建应用 启动业务容器 按照实例模版启动虚拟机+应用

中兴通讯ServiceMesher 社区成立以来组织了一系列翻译活动，如： • Envoy 官方文档 • Knative 入门 • Istio 官方文档 1.1 版本和 1.4 版本 社区官网投稿情况： • 翻译文章：147 篇 • 原创文章：122 篇 /03 社区活动2019年 10 月31 日 正式开始 istio 1.5 官网文档的翻译。 2 个月 累计合并 PR 数超过 300 个。 300+ 300+ 超过 60 人参与了官网的翻译。 60+ 持续时间 合并 PR 数 参与人数 20 万+ 翻译字数 累计翻译的文档中汉字数超过 20 万。 /04 Istio.io 社区化翻译活动Istio 官网本地化活动卓越贡献者 官余棚 @gorda 罗小东 @ilylia 于晓博 @yuxiaobo96 高国良 @gauliang /05 Istio 官网本地化活动详见：https://github

项目地址：github.com/mosn/mosn 项目域名：mosn.io Modular Open Smart Network-proxy9/10 MOSN 未来发展思路与方向 更完善的文档及 Demo 安全审计 社区 更多的协议及服务框架支持 Dubbo、SpringCloud、 RocketMQ、gRPC、HTTP3、 MQTT、QUIC、TLS1.3 等 多协议 支持模块化

仅适用于 JAVA 应用、Spring Boot 框架 • 侵入性强 • 升级成本高、版本碎片化严重 • 内容多、门槛高 • 治理功能仍然不全5/总页数 优点 • 微服务治理与业务逻辑解耦 • 异构系统的统一治理 • 三大技术优势： • 可观察性 • 流量控制 • 安全 Service Mesh 的优缺点 缺点 • 增加了复杂度 • 整体链路的复杂度 • 操作运维的复杂度 • 需要更专业的运维技能 微服务高可用设计手段 - 服务限流 • 对于一个应用系统来说一定会有极限并发/请求数，即总有一个TPS/QPS阀值， 如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过 载保护，防止大量请求涌入击垮系统。 • 服务限流其实是指当系统资源不够，不足以应对大量请求，即系统资源与访问量 出现矛盾的时候，我们为了保证有限的资源能够正常服务，因此对系统按照预设 的规则进行流量限制或功能限制的一种方法。 的规则进行流量限制或功能限制的一种方法。 • 限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行 限速来保护系统，一旦达到限制速率则可以拒绝服务或进行流量整形。 • 限流无非就是针对超过预期的流量，通过预先设定的限流规则选择性的对某些请 求进行限流“熔断”。22/总页数 治理策略 & 高可用 • 微服务高可用设计手段 - 服务限流 • 接入层限流 • 调用外部限流服务限流 • 切面层/代理层限流

• 历史问题 • 分布式系统性能测试问题 定位难 • 多版本并发测试 • 故障注入较困难（代码侵 入性强） • 测试环境不稳定，后端Pod 频繁重启 • 解决方案 • Contour产品化 • Istio的灰度发布和流量管理 • Istio的Tracing产品化落地场景—云存储系统 • 历史问题 • 灰度发布 • 预上线系统验证体系 • 系统故障隔离 • 跨集群访问 • 线上问题链路追踪 • Istio南北流量分流策略产品化 • 基于Istio的QoS产品化 • 跨集群流量调度 • 基于Istio的Tracing产品化落地场景—大数据产品 • 系统优化之路 • 多版本灰度升级 • 根据流量做横向伸缩 • 分布式系统性能测试问题 定位难 • 解决方案 • Istio南北流量分流策略产品化 • 基于Istio的QoS产品化 • 基于Istio的Tracing产品化 • 跨集群流量调度七牛容器云产品逻辑架构 生态链七牛容器云产品未来发展 • 更多功能 • 故障熔断 • 故障注入 • 业务配置动态分发 • 优化升级 • 性能优化： • DPDK + eBPF • 系统优化 • 根据需求裁剪Istio。解耦Envoy和其他组件 • 裁剪Istio相关CRD，简化系统结构ServiceMesher公众号 SOFAStack公众号 http://www.servicemesher.com

Kubernetes 集群运维实践 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT自我介绍 •嵌入式、微服务框架 •2017 年加入阿里巴巴，负责阿 里集团数十万集群节点规模化运 维管理系统的研发工作 •2019 年参与集团全面上云项目 并经历了整体架构的云原生升级 演进，稳定支撑双11峰值流量分享内容 • 阿里全站上云 • 神龙 (what & why) • 规模化集群运维实践 [分钟，天]成本 效率 稳定云化架构 物理机 + 本地存储 + Underlay网 络 神龙/ECS + 远程存储 + Overlay网络 集团机房 云上机房 基础设施 IDC 系统 基础运维 天基系统 CMDB 安全审计 单机监控 ASI 平台 kubelet/Pouch CI/CD k8s extended Service Mesh 安全容器 运维管控 在离线混部 额度管控 卡中断打散 • 稳定性要求高 • 性能、宕机、夯机、抖动系统架构 • 基础监控 • 秒级、分钟级监控 • 内核性能指标采集 • 监控大盘 • 在线率 • 宕机率 • 抖动率 • 基线系统 • 基础环境一致性故障自愈 (1-5-10) • 监控、故障发现 (1-5) • 本地检测 (walle, NPD) + 外部系统 (IDC、aliyun) • SLI、SLO、SLA •

产品的研发工作 开源配置中心 Apollo 主要作者 https://github.com/ctripcorp/apollo 毕业于复旦大学软件工程系 曾就职于携程、大众点评，负责中间件、后台系统等研发工作3/39 一、为什么需要 Service Mesh? 二、在当下『路口』的思考 三、蚂蚁金服的产品实践 四、展望未来 目 录 contents 目录4/39 每次升级都要重新发布应用 业务进程专注于业务逻辑 SDK 中的大部分功能， 拆解为独立进程， 以 Sidecar 的模式运行 将服务治理能力下沉到基础设施，实现独立演进，透明升级7/39 异构系统统一治理 Part 1： 为什么需要Service Mesh? 多语言、多协议 图片来源：https://www.redhat.com/en/topics/microservices/w Greenfield vs Brownfield Greenfield • 绿地，未开发过的土地 • 全新的项目/新系统 图片来源：https://faasandfurious.com/90 Brownfield • 棕地，已开发/污染过的土地 • 成熟的项目/遗留系统12/39 Part 2： 在当下『路口』的思考 • 大量的应用还跑在非 k8s 体系上（VM、独立的注册中心等）

Service Mesh架构在陌陌的落地实践13/24 方案选型 与现有架构的兼容性 现阶段的关键需求 技术储备与原则类因素 自研数据平面与 控制平面方案 使存量服务接入Mesh 方案 对接大量内部系统 关键收益均由数据平面产生 非完善的控制平面功能 技术体系内不引入Go语言 最成熟的服务端语言为Java 使用Java开发 数据平面Agent14/24 整体架构 数据平面 • 现有协议的流量转发 sidecar模式 • 与业务进程相同Pod不同Container 陌陌微服务容器化部署比例在80%以上 并且还在进一步推进 业务接入方式 • 研发人员：升级SDK版本 • SRE：发布系统配置发布项 sidecar模式部署17/24 数据平面升级方式 – 平滑升级机制 平滑要求 • 业务进程不重启 • 流量保持不变 方案选择 • FD迁移 vs 哨兵集群 原理 • sendmsg 服务器配置的最坏情况 实际需预留 600M内存22/24 数据平面兼容原有架构 对接原有系统 • 使用原有系统SDK、私有协议 直连访问 兼容未升级服务 • Proxy Agent支持以原有通信 协议处理请求、发起调用23/24 总结与展望 实践感悟 • Service Mesh通过一种全新的架构理念，系统地解决了微服务领域的关键架构痛点 • 是否应用Service Mesh架构以及如何