Service Mesh Meetup #4 上海站 蚂蚁金服Service Mesh 渐进式迁移方案 2018.11.25 敖小剑 @ 蚂蚁金服 中间件 龙轼 @UC 基础研发部1 Service Mesh演进路线 1 2 实现平滑迁移的关键 3 DNS寻址方案的演进 4 5 总结 DNS寻址方案的后续规划ü 对未来长期目标的认可 • Service Mesh（带控制平面，如Istio） 还有很多应用没有实现微服务化 • 还有很多应用没有运行在kubernetes之上 • Istio目前还不够稳定，也无法原生支持我们的规模 • 现有系统中的众多应用不可能一夜之间全部迁移 ü 最重要的：平滑迁移 • 微服务 + Service Mesh + Kubernetes 是目标 • 但是如何从现有体系向目标迈进，必须给出可行的实践指导 ü Roadmap • 预计2019年初 ）非常自然 • 容易落地 • 快速达成短期目标 ü 缺点是再往后走 • 由于没有k8s的底层支持，就不得不做大量工作 • 尤其istio的非k8s支持，工作量很大 • 而这些投入，在最终迁移到k8s时，又被废弃 ü 结论： • 不符合蚂蚁的远期规划（k8s是我们的既定目标） • 会造成投资浪费（k8s铺开在即） 演进路线2分析 部署在 非k8s上 Service Mesh (Sidecar模式)

七牛容器云Service Mesh实践 冯玮 七牛容器云架构师 2018.11.25 Service Mesh Meetup #4 上海站Ingress Controller • 流量管理 • 安全管理 • 统一配置 • 反向代理Contour • 本质上还是Ingress Controller • Kubernetes深度整合 • Gimbal生态组件Contour特点 • 基于Envoy 南北流量产品化 • TLS管理优化 • Contour增强 • 入口流量管控 • 跨集群调度 • 发展策略 • API版本兼容两种方式 • 数据面优先，控制面按需迭代七牛容器云Service Mesh发展 • 产品发展 • 依托容器云PaaS中台 • 辐射业务线：Spock，Kodo，Dora等 • 先内部普及踩坑，后私有云能力产品化 • 使用规模 • 80%以上产品线部署Contour & Istio 定位难 • 解决方案 • Istio南北流量分流策略产品化 • 基于Istio的QoS产品化 • 基于Istio的Tracing产品化 • 跨集群流量调度七牛容器云产品逻辑架构 Kubernetes + Docker + 生态链七牛容器云产品未来发展 • 更多功能 • 故障熔断 • 故障注入 • 业务配置动态分发 • 优化升级 • 性能优化： • DPDK + eBPF • 系统优化

李斌 阿里云容器服务 全民双十一 基于容器服务的大促备战 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT我是谁挑战在哪里？ 极限并发 人为失误 系统瓶颈 雪崩 单点失效 成本控制 用户体验 最终一致性 稳定性 资源不足 资源利用率 安全风险备战工具箱 服务化 开发运维一体化 弹性 极致性能 高可用 全站上云 安全加固 人工智能 大数据 离线计算 全链路压测 边缘计算 敏捷调度 故障演练人为失误 http://integracon.com/11-leading-causes-downtime/ 45%最佳实践之容器化DevOps 杭州 容器集群 集群 伦敦 Serverless集群 自动安全扫描 镜像签名 全球自动分发 智能构建 上海 边缘集群 ECS ECI 应用定义 ACR 镜像服务 镜像快照两个数字背后的故事 延时降低75% 混合云2.0架构 交付效率提升3倍 全链路安全架构 实时风险监测、告警、阻断 极速弹性 分钟级1000节点伸缩 异构算力 利用率提升5倍 沙箱容器 强隔离，90%原生性能 容器云应用市场 合作伙伴计划 阿里云容器服务Thank you ! 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT

微服务结合容器云平台的思考和实践 2018.06.25 徐运元关于我 2008年毕业于浙江大学，曾在思科和浙大网新有超过 9年的工作经验和5年的云计算领域工作经验，带领团 队完成公司第一代基于Kubernetes的云平台开发和第 二代基于Kubernetes的DevOps云平台开发 来自于浙江大学SEL实验室目录 CONTENTS Kubernetes平台下的微服务演进 Pilot核心功能解读 流量管理 • 服务降级 • … • 微服务拆分原则 • 业务API设计 • 数据一致性保证 • 可扩展性考虑 • …Kubernetes对于微服务的支撑 功能列表 详情 快速资源分配 容器编排和调度 服务部署&弹性伸缩 Deployment 服务注册&服务发现 Service概念和分布式DNS API网关 简单路由功能 统一日志中心 Fluentd & ES 统一监控中心 Prometheus -N ISTIO_REDIRECT iptables -t nat -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-port ${PROXY_PORT} #所有进入容器的流量送入Envoy iptables -t ${table} -A PREROUTING -p tcp -j ISTIO_INBOUND iptables -t nat -A ISTIO_INBOUND

多终端&协议接入 架构升级 云原生生态融合 § MQTT协议的IOT设备接入 § 就近就优海外接入，智能调度 § 蚂蚁全球加速节点，全协议支持 § 支持UDPA § QUIC/HTTP3 § 接入层容器化，混部 § 支持QUIC协议的LB建设 § Web Assembly模块扩展东西流量的服务发现与路由 F5（ipvs） APP APP APP APP 配置中心 APP APP APP 流量控制蚂蚁金服率先大规模落地SOFAMesh UDPA 安全 统一数据 平面API 存量连接无损迁移 提升5倍发布效率 TLS双向加密 支持国密算法 WAF 流量镜像 多协议 SOFARPC Dubbo HTTP1.1/2 平滑升级 性能 单跳CPU增加5%消耗 0.2ms RT 蚂蚁金服100+应用，10w+容器已经mesh化，部分业务链路通过下沉， RT降低了7%，平稳支撑了618大促。SOFAMosn 流量镜像，RBAC鉴权SOFAMosn能力扩展 心跳检查在Service Mesh场景下网络代理有着不同于接入层的挑战 • 无论应用是否接入Mesh，接入了多少Mesh，都需要保证可正常处理请求，做到可 灰度、可回滚的兼容，平滑迁移 • 通用的框架能力（SOFAMosn/Envoy）无法直接满足复杂的、定制的业务能力，需 要进行针对性的扩展实现 • 需要融合主站已有的应用体系，如注册中心、配置中心等，这些也需要扩展实现 •

应用代码 业务应用开发 基础设施开发 Mesh 化10 三、方案落地 方案落地11 最终选型：自研数据面+轻量 SDK，我们给出的答案是 MOSN。 方案落地-选型 开源/自研：全部迁移到 envoy？不现实，自有协议+历史负担。 SDK/透明劫持：运维和可监控性不好，性能不高，风险不太可控。12 方案落地-目标架构 MOSN APP Pod MOSN APP Pod 方案落地-拷问 现有框架升级 容器如何替换 MOSN 如何升级 需要业务改代码吗 能回滚吗？ 没资源给你做 buffer 能不能快一点 升级过程不要影响我业务 其他你随便 1问 2问 3问App 容器 14 方案落地-框架升级前 应用代码 SOFABoot SOFABoot/SOFARPC API JVM SOFABoot 研发框架App 容器 15 方案落地-框架升级后 SOFABoot/SOFARPC API SOFABoot_New JVM RPC 检测 pod 变量，注 入启动参数 判断开启了 MOSN 发布和订阅服务 直接调用，关闭寻 址功能 其他16 方案落地-容器替换 Pod Pod Old Pod New With MOSN Pod New With MOSN 扩容 缩容 资源 Buffer Pod APP：4C8G Pod APP：4C8G

严选 ServiceMesh 实践 王国云 网易资深专家 严选中台技术团队负责人/容器化负责人1/24 背景 2016.4 2016.7 2017 严选正式对外发布 技术团队规模：10+ 单体 严选初创 严选业务快速增长 RPC框架、cNginx发布 技术团队规模：50+ Service Mesh 架构试点 严选业务快速增长 服务化 技术团队规模：200+ Service 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 • 增强流量管理能力 • 将更多治理特性（如限流、熔断、故障注入）与业务架构解耦 • 支持更多的协议 • 增强控制面 • 配合业务容器化上云及混合云架构8/24 行业技术演进 - 通用型 Service Mesh 出现 2017年1月23日 加入 CNCF 2017年4月25日 1.0Releases Linkerd 2016年9月13日 采用 sriov 容器网络 • Envoy：将1.13版本中 connection loadbalancer 特性移植到 1.10.x 版本 • Envoy 优化后在低并发（<64）的情况下，容器网络 client sidecar 优于 VM 网络直连 • Envoy 优化后在高并发（>=64）的情况下 • 容器网络 client sidecar 接近 VM 网络直连 • 容器网络 client

• 部署方式 • 升级方式 • 容灾方式 • 性能问题 • 资源问题 • 兼容问题 关键设计 关键问题16/24 数据平面部署方式 容器化运行方式 • sidecar模式 • 与业务进程相同Pod不同Container 陌陌微服务容器化部署比例在80%以上 并且还在进一步推进 业务接入方式 • 研发人员：升级SDK版本 • SRE：发布系统配置发布项 sidecar模式部署17/24 平滑要求 • 业务进程不重启 • 流量保持不变 方案选择 • FD迁移 vs 哨兵集群 原理 • sendmsg / recvmsg接口发送FD • 步骤：listener、存量连接、存量数据 Java实现 • 借助JNI与Netty Java实现FD迁移18/24 数据平面升级方式 – 发布流程 容器化发布方式 • 发布过程同时存在新旧两个Agent • 注入新Container 对象池化：减少资源消耗与GC压力 • 响应等待机制：非阻塞等待 两次请求转发小于0.2ms Agent外部 • 提升服务器性能（缩减耗时绝对值） API层接口耗时增长小于6%21/24 数据平面资源占用 与业务容器共享CPU、内存资源配额 为Agent JVM分配256M内存资源 服务器消耗增加约10% 分配方式 内存资源 服务器资源 维持现有内存使用率与 服务器配置的最坏情况 实际需预留 600M内存22/24

并平稳支撑了618大促 规模落地 04 2019年下半年，在蚂蚁主站的大促核心应用中全面铺 开，落地规模非常庞大，而且最终如『丝般顺滑』地 支撑了双十一大促。 数百个 数十万 应用 容器 <0.2ms 数千万 平均RT 峰值QPS 2019年9月，SOFAStack 双模微 服务平台入驻阿里云开始公测， 支持 SOFA, Dubbo 和 Spring Cloud Pod SOFA 应用 SOFA SDK SOFA SDK 安全加固 基于 SDK 的传统微服务 基于 Sidecar 的 Service Mesh 微服务 互联互通，平滑迁移，灵活演进20/39 Part 3： 蚂蚁金服的产品实践 大规模场景下的服务发现 • Pilot 的问题 • 集群容量无法支撑海量数据 • 全量推送性能差 • 沿用 SOFA 管控性和可观测性不好23/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 初始状态24/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 透明迁移调用方25/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 透明迁移服务方26/39 Part 3： 蚂蚁金服的产品实践 平滑迁移 终态27/39 Part 3： 蚂蚁金服的产品实践 多协议支持

1.12中Part 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ 有了高大上的容器/k8s/云原生， 还要不要支持土里土气的 虚拟机？Part 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ Google Traffic Director 支持虚拟机，而且可以 虚拟机和容器相互访问 Linkerd 1.* 天然支持 Envoy 天然支持 Istio 开始准备支持，后 开始准备支持，后 来实质性取消，基 本只有k8s好用 Linkerd 2.0 只支持k8s AWS app mesh 支持虚拟机，而且 可以虚拟机和容器 相互访问 ServiceMesh主流产品对虚拟机的支持情况Part 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ Linkerd 1.* Envoy App Mesh Traffic Director Istio Linkerd 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ Linkerd 1.* Envoy Istio Linkerd 2.* 支持 不支持 第一个转折容易理解：相比虚拟机，k8s提供了太多便利 • 容器 • kubernetes • 云原生Part 3：ServiceMesh灵魂拷问三：要不要支持虚拟机？ Linkerd 1.* Envoy AWS App Mesh Google Traffic