Service Mesh 微服务架构设计 杨彪 美团点评高级架构师 2019.10.26 Service Mesh Meetup #7 成都站原蚂蚁金服专家，著有《分布式服务架构：原理、 设计与实战》和《可伸缩服务架构：框架与中间件》 两本书。有近10年互联网、游戏和支付相关的工作 经验，目前从事产业互联网。 杨彪，美团高级架构师1 漫谈服务架构的演进史 2 微服务架构设计的现状 3 Service Service Mesh微服务设计 4 Service Mesh的框架介绍1 漫谈服务架构的演进史 2 微服务架构设计的现状 3 Service Mesh微服务设计 4 Service Mesh的框架介绍我过往的经历情况 类型：传统互联网 模式：CS/BS模式 类型：互联网 模式：单体模式 类型：游戏 模式：单体模式 类型：互联网金融 模式：微服务模式Java版本演进史 JDK J2ME 10 Java SE 11应用架构演进史 C/S (Client/Server) B/S (Browser/Server) MVC (Model View Controller) SOA (Service-Oriented Architecture) 注 册 中 心 服 务 治 理 MSA (Microservice Architecture)基础架构演进史 Hardware

0 陌陌Service Mesh架构实践 高飞航 陌陌中间件架构师1/24 讲师简介 高飞航，陌陌中间件架构师 2011年 毕业于东北大学 加入淘宝网 交易平台团队 负责交易流程业务研发 2013年 加入陌陌 基础平台组 负责多项中间件产品研发、多机房架构建设 在微服务领域具备丰富的经验 当前关注Service Mesh、云原生等技术方向2/24 /01 /02 /03 背景 背景 问题 实践 微服务体系演进历程 架构痛点与解决思路 Service Mesh落地方案3/24 背景 /01 陌陌微服务体系演进历程4/24 单体应用到微服务 单体应用 微服务架构 应用拆分 加入PHP API层 PHP API层成为后续多语言服务治理的关键挑战5/24 微服务体系演进 MOA 1.0微服务体系演进历程 自研服务框架产品MOA（Momo service Oriented Oriented Architecture）于2013年初上线推广 微服务体系的其他产品也均为自研方案6/24 MOA 1.0微服务体系整体架构 注册中心 • Redis作为底层存储 • 跨语言地址发现服务Lookup • 中心化存活检测 多语言支持 • Java、PHP、Python、Go、NodeJs • Redis传输协议 / 复用Redis客户端 • 服务发布Proxy

163yun.com 网易云Service Mesh的产品架构与实现 刘超 网易研究院云计算技术部首席架构师www.163yun.com 关于我 • 刘超 • 网易云 解决方案总架构师 • 10余年云计算领域研发及架构经验，先后在EMC，CCTV证券资 讯频道，HP，华为，网易从事云计算和大数据架构工作 • 毕业于上海交通大学。 • 曾出版《Lucene应用开发揭秘》 • 多 多次作为邀请讲师参加Dockone容器技术大会，Segmentfault 开发者大会，InfoQ全球架构师峰会（明星讲师），CSDN SDCC大 会，51CTO WOTA大会等 • 知名技术博主，博客可搜索popsuper1982，多篇文章推荐至全 球最大IT社区CSDN首页及《程序员》杂志 • 在工作中积累了大量运营商系统，互联网金融系统，电商系统等 容器化和微服务化经验01 目录 02 03 微服务与Docker、Kubernetes 网易云微服务框架介绍 基于容器服务的微服务架构实践163yun.com 一、微服务与Docker、Kubernetes163yun.com 应用架构 数据架构 IT架构 微服务的交付形式Kubernetes 轻量级的IT运维模式Swarm 资源利用率高的任务执行模式Mesos 快速迭代 高并发 OPEX CAPEX 大数据分析，运营

大规模微服务架构下的 Service Mesh探索之路 敖小剑6月初在深圳举行的GIAC全球互联网架构大会上，蚂蚁金服第一次对外 透露了开发中的Service Mesh产品——Sofa Mesh。 今天我们将展开更多细节，详细介绍蚂蚁金服Sofa Mesh的技术选型， 架构设计以及开源策略。 前言技术选型 Technical 1ü 性能要求 • 以蚂蚁金服的体量，性能不够好则难于接受 以蚂蚁金服的体量，性能不够好则难于接受 • 架构与性能之间的权衡和取舍需要谨慎考虑 ü 稳定性要求 • 以蚂蚁金服的标准，稳定性的要求自然是很高 • 高可用方面的要求很非常高 ü 部署的要求 • 需要用于多种场合：主站，金融云，外部客户 • 需要满足多种部署环境：虚拟机/容器，公有云/私有云，k8s • 需要满足多种体系：Service Mesh，Sofa和社区主流开发框架 Service Mesh落地要面临的实际要求选择开源产品，还是选择自研？ 可扩展性有限，dtab不易理解和使用 • 功能不能满足蚂蚁的需求，没法做到 类似envoy xds那样的扩展性 • 未来发展前景黯淡 Envoy • 安心做数据平面， 提供XDS API • 设计优秀，性能和稳定性表现良好 • C++编写，和蚂蚁的技术栈差异大 • 蚂蚁有大量的扩展和定制化需求 • 我们非常认可envoy在数据平面上的表现开源方案选择之第二代Service Mesh Istio

社区（servicemesher.com）治理委员会核心成员 • 云原生社区（cloudnative.to）联合创始成员 • 百度云智学院认证讲师 • 目前在「百度云云原生团队」负责微服务治理与相关中间件研发 • 对云原生架构与技术、研发流程、团队文化有深入研究，对 Spring Cloud、 Service Mesh 等微服务治理框架有丰富实践经验2/总页数 /01 /02 /03 Service Mesh 与 Spring 用的互通、共治 注册中心与 高可用方案 通过治理策略 保证服务高可用3/总页数 Service Mesh 与 Spring Cloud 应用的互通、共治 /014/总页数 优点 • 微服务架构的集大成者 • 轻量级组件 • 开发灵活、简便 • 社区生态强大、活跃度高 Spring Cloud 的优缺点 缺点 • 仅适用于 JAVA 应用、Spring Boot 框架 • 侵入性强 • Istio-Handbook：Service Mesh 概述6/总页数 互联互通，平滑迁移 Spring Cloud & Dubbo Service Mesh Monolithic 混合微服务架构 Microservices • 微服务 & 单体 • Spring Cloud & Service Mesh7/总页数 运行时支撑服务 • 服务注册中心 • 服务网关 • 配置中心 混合微服务的互联互通

你是谁，你从哪里来，你要去哪里？ 小区保安： 轻松一刻：最近流行的梗，各种灵魂拷问Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ 要架构，还是要性能？ 让我们来对ServiceMesh做一次灵魂拷问，首先：Istio的回答：架构优先，性能暂放一边 Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Istio 0.1 - 1.0 Mixer 0.1 - 1.0 In- process AdapterIstio Control Plan 为什么Istio选择Mixer和Proxy分离的架构？ Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Proxy Mixer In- Process Adapter Infrastructure Backend Proxy 优点： • 架构优雅，职责分明，边界清晰 • Mixer的变动不影响Proxy • Proxy无需和Adapter耦合 7/39 Istio的新回答：架构继续优先，性能继续放一边 Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Istio 1.1 – 1.2 Mixer 1.1 - 1.2Istio Control Plan 为什么Istio选择Out-of-Process Adapter? Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Proxy Mixer

RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4.0 Ø TCP代理/7层通用代理 Ø 简单匹配路由 Ø 集群管理 & Client <-> MOSN<-> Service p Client模拟方式:通过蚂蚁内部压测平台建立10w条SOFARPC链接 p 压测内容: 1K 请求/响应持续演进实践总结 ü 架构上，从一开始就遵循分层设计，模块解耦，统一编程模型接口，保证足够的架 构扩展性。 ü 性能上，针对IO、协议、内存、协程进行持续优化。相比最初版本，SOFARPC 协 议上对 0.1.0 版本 QPS 提升了 基于链式路由机制扩展，使 用router match，subset等 开源能力实现 ü 适配蚂蚁三地五中心机房部 署，LDC/弹性架构 ü 蚂蚁内部划分R/G/C三种 zone类型，每个Zone的能 力不保证对等 ü 适用于单次简单路由无法解 决的复杂架构场景(如非对 等路由，不确定当前zone 是否有该服务的提供方) Service A MOSN 深圳机房 上海机房 Service

因为是内部项目，优雅性和治理效果之间，选择 了后者 App Local Proxy OSP OSP client App Envoy App EnvoyClient端不基于IPTable劫持 • Istio的设计很美好，但现实总是很残酷 • IPTable性能不总是足够好 • 任何组件都有不可用的时候。客户端无论如何都要有自切换的能力和可 用的备份 • 尽量减少外部组件依赖。业务/运维总会有各种特殊的需求，依赖外部组 需预先根据宿主机的配置调整Proxy的资源以 应对客户端增多的情况。容量超标则临时转移 到remote proxyRemote Proxy的价值 • 主要职责：备份流量、临时流量、非主要流量 • 高可用架构上的补充：sidecar是很美好，但总有一些时候，你的 sidecar挂掉时，你的客户端是不想/不能跟sidecar一起死的。此时 唯一能救火的，就是客户端能够自动切换（sdk自带），并且有 备份（remote 由、熔断、健康探测、超时重试、 限流降级等等 • 契约化治理，服务接口变更diff并 通知上游 • 环境无关，物理机、云、测试机 器、本机都能跑实践中踩过的坑 我是作者名称ZooKeeper的强耦合 • 初始设计没有抽象服务注册发现和服务配 置的接口，直接操作ZK并且依赖了ZK的特 性和原语 • ZK弊端显现 • 跨机房多活问题 • 性能问题 • 宠物对待 • API不友好问题 • 不能unwatch

技术团队规模：50+ Service Mesh 架构试点 严选业务快速增长 服务化 技术团队规模：200+ Service Mesh 架构全面落地 基础架构三问： 1. 服务治理：RPC 框架 vs 服务治理平台 2. 多语言 vs Java 3. 开源 vs 自研2/24 /01 /02 /03 严选 Service Mesh 演进 混合云架构落地实践 规划与展望3/24 严选ServiceMesh演进 严选ServiceMesh演进 /014/24 严选第一代 Service Mesh 架构 • 使用 Consul 作为服务发现组件 • 数据面：cNginx • 控制面：Consul 管理后台5/24 服务治理能力 – 基于严选第一代ServiceMesh（cNginx） 类型 功能 能力提供方 服务调用方（Client） 服务提供方（Server） 服务注册与发现 注册发现：基于 Consul Mesh 为严选带来了哪些架构收益 • 历史包袱：现有的服务在不改造的情况下引入了服务治理能力 • 大大降低了中间件的研发投入和演进成本，也降低了业务和中间件的耦合成本 • 基础架构与业务架构可以独立演进 • 为多语言栈提供了服务治理能力7/24 持续演进的诉求 • 提供高质量的服务治理能力 • 增强流量管理能力 • 将更多治理特性（如限流、熔断、故障注入）与业务架构解耦 • 支持更多的协议

Mesh 中的可观察性应用 高洪涛 Tetrate 创始工程师Who 高洪涛 美国S ervice Mesh 服务商 Tetrate 创始工程师。原华为软件开发云技术专家，对云原 生产品有丰富的设计，研发与实施经验。对分布式数据库，容器调度，微服务， ServicMesh 等技术有深入的了解。 目前为 Apache ShardingSphere 和 Apache SkyWalking 核心贡献者 Endpoint 观察维度 9/28遇到的挑战 /02 Service Mesh 场景下 SkyWalking 面临的挑战 ( Istio ) 10/28可观测性 11/28Istio 1.5 架构图 12/28挑战1：技术路线多变 基于 Log 成熟、但性能低 Mixer 基于 Metric 高效、但技术门槛高 Mixerless 13/28挑战2：无 Tracing VS 26/28维度匹配-service 命名规则 Version|App|Namespace|Cluster v1|projuctpage|bookinfo|product-demo 27/28感谢聆听 欢迎关注，获取最新分布式架构内容 关注服务网格，关注 ServiceMesher