关于后端:复杂环境下落地Service-Mesh的挑战与实践

导读

在公有星散群环境下建设 Service Mesh，往往须要对现有技术架构做较大范畴的革新，同时会面临诸如兼容艰难、规模化撑持技术挑战大、推广窘境多等一系列复杂性问题。本文会系统性地解说在美团在落地 Service Mesh 过程中，咱们面临的一些挑战及实践经验，心愿能对大家有所启发或者帮忙。

一、美团服务治理建设停顿

1.1 服务治理发展史

首先讲一下 OCTO，此前美团技术团队公众号也分享过很相干的文章，它是美团标准化的服务治理基础设施，现利用于美团所有事业线。OCTO 的治理生态十分丰盛，性能及易用性体现也很优异，可整体概括为 3 个特色：

1. 属于公司级的标准化基础设施。技术栈高度对立，笼罩了公司 90% 以上的利用，日均调用量达数万亿次。
2. 经验过较大规模的技术考验。笼罩数万个服务、数十万个节点。
3. 治理能力丰盛。协同周边治理生态，实现了 SET 化、链路级简单路由、全链路压测、鉴权加密、限流熔断等治理能力。

回顾美团服务治理体系的发展史，历程整体上划分为四个阶段：

1. 第一阶段是根底治理能力对立。实现通信框架及注册核心的对立，由对立的治理平台撑持节点治理、流量治理、监控预警等经营能力。
2. 第二阶段重点晋升性能及易用性。4 核 4GB 环境下应用 1KB 数据进行 echo 测试，QPS 从 2 万晋升至靠近 10 万，99 分位线 1ms；也建设了分布式链路追踪、分阶段耗时精密埋点等性能。
3. 第三阶段是全方位丰盛治理能力。落地了全链路压测平台、性能诊断优化平台、稳定性保障平台、鉴权加密等一系列平台，也实现了链路级别的流量治理，如全链路灰度公布等。
4. 第四阶段是建设了跨地区的容灾及扩大能力。在每天数千万订单量级下实现了单元化，也实现了所有 PaaS 层组件及外围存储系统的买通。

1.2 服务治理体系的窘境

目前，美团已具备了较欠缺的治理体系，但仍有较多的痛点及挑战。大的背景是公司业务蓬勃发展，业务愈发多元化，治理也愈发精细化，这带来了较多新的问题：

1. 业务与中间件强耦合，制约彼此迭代。当中间件引入 Bug，可能成千盈百、甚至数千个业务须要做配合降级，中间件的新个性也依赖业务降级后能力应用，老本很高。
2. 中间件版本碎片化重大。公布进来的组件根本托管在业务侧，很难对立进行管控，这也频繁造成业务多类的问题。
3. 异构体系交融难。新融入公司的技术体系往往与美团不兼容，治理体系买通的老本很高，难度也很大。此前，美团与公众点评买通治理，不蕴含业务迁徙，就历时 1 年半的工夫；近期，摩拜应用的 gRPC 框架也无奈与零碎进行通信，但买通火烧眉毛。
4. 非 Java 语言治理体系能力弱，多个支流语言无官网 SDK。多元业务场景下，将来多语言也是个趋势，比方在机器学习畛域，Python 语言不太可能被其余语言齐全代替。

二、服务治理体系优化的思路与挑战

2.1 优化思路

总结来看，OCTO 在服务层实现了对立形象来撑持业务倒退，但它并未解决这层架构能够独立演进的问题。

1.2 节中问题 1 与问题 2 的实质是“耦合”，问题 3 与问题 4 的实质是“不足规范服务治理运行时”。在现实的架构中，异构语言、异构治理体系能够共用对立的规范治理运行时，仅在业务应用的 SDK 局部有轻微差别。

所以，咱们整体的优化思路分为三步：隔离解耦 ， 在隔离出的基础设施层建设标准化治理运行时 ， 规范之上建体系。

上述解决方案所对应的新架构模式下，各业务过程会从属一个 Proxy 过程，SDK 收回以及接管的流量均会被从属的 Proxy 拦挡。像限流、路由等治理性能均由 Proxy 和中心化的管制大脑实现，并由管制面对接所有治理子系统集成。这种模式下 SDK 很轻薄，异构的语言、异构的治理体系就很容易互通，从而实现了物了解耦，业界将这种模式称为 Service Mesh（其中 Proxy 被称为数据面、中心化管制大脑被称为管制面）。

2.2 复杂性挑战

美团在实践中所面临的复杂性划次要包含以下 4 类：

1. 兼容性：技术改造波及范畴较大，一方面须要通过保障现有通信形式及平台应用形式不变，从而来保障业务研发效率，另一方面也要解决运行载体多样性、运维体系兼容等问题。
2. 异构性：第一是多语言互通问题；第二是买通治理体系内的泛滥治理子系统，像服务鉴权、注册核心等零碎的存储及公布订阅机制都是不同的；第三是疾速买通新融入公司的异构治理体系。
3. 大规模撑持：出于性能方面思考，开源 Istio 等产品不宜间接利用于大规模的生产环境，美团管制面需具备百万级链接下高吞吐、低提早、高准确的零碎能力。
4. 重交易型业务容错性低：交易型业务场景下，业务对 Service Mesh 的性能、稳定性往往持狐疑态度；美团基础架构团队也强调在业务价值导向下，基于理论业务价值进行经营推广，而不是采纳从上至下的偏政策性推广形式。

三、美团落地 Service Mesh 的解决方案

3.1 整体架构

美团采纳数据面基于 Envoy 二次开发、管制面自研为主、SDK 协同降级的计划（外部我的项目名是 OCTO Mesh）。架构简介如下：

• 各语言轻薄的 SDK 与 Proxy 通过 UDS（Unix Domain Socket）交互，次要出发点是思考到相比通明流量劫持，UDS 性能与可运维性更好。
• 管制面与 Proxy 通过双向流通信，管制面与治理生态的多个子系统交互，并将计算解决过的治理数据及策略数据下发给 Proxy 执行，协同配合实现路由、限流等所有外围治理性能。

• 管制面外部的 5 个模块都是自研的独立服务。

  • Pilot 承载外围治理能力，与 Proxy 间接交互。
  • Dispatcher 负责屏蔽异构子系统差别。
  • 集中式健康检查治理节点状态。
  • Config Server 治理 Mesh 体系内相干的策略，并将 Pilot 有状态的局部尽量迁徙进去。
  • 监控及巡检零碎负责晋升稳定性。
• 自研了的 Meta Server 零碎实现 Mesh 体系外部的节点注册和寻址，通过管理控制面与数据面的链接关系，也实现了按事业群隔离、程度扩大等能力。

3.2 兼容性解决方案

兼容性的指标及特色用一句话来总结就是：业务接入无感知。为此，咱们做了以下三件事件：

(1) 与现有基础设施及治理体系兼容

• 将 Service Mesh 与 OCTO 深度买通，确保各治理子系统的应用形式都不变。
• 运行载体方面，同时反对容器、虚拟机、物理机。
• 买通运维体系，保障服务治理基础设施处于可治理、可监测的状态。

(2) 协定兼容

• 服务间调用往往是多对多的关系，个别调用端与服务端无奈同时降级，为反对 Mesh 与非 Mesh 的互通，加强后的协定对业务齐全通明。
• 与语义相干的所有内容（比方异样等），均在 SDK 与 Proxy 之间达成共识，保障兼容。
• 无奈在管制面及数据面中实现的能力，在 SDK 中执行并通过上下文传递给 Proxy，保障性能齐全对齐，当然这种状况应该尽量避免的。

(3) Mesh 与非 Mesh 模式的无缝切换

• 基于 UDS 通信必然须要业务降级一次 SDK 版本，咱们在 2020 年初时事后公布早做部署，确保以后大部分业务曾经降级到新版本，但默认仍是不开启 Mesh 的状态。
• 在可视化平台下面通过开关操作，简直无老本实现从 Mesh 模式与非 Mesh 模式的切换，并具备实时失效的能力。

3.3 异构性解决方案

异构性的指标及特色用一句话总结就是：标准化服务治理运行时。具体可拆分为 3 个子指标：

• 标准化美团外部 6 种语言的治理体系。
• 架构层面由管制面对立对接各个治理子系统，屏蔽注册核心、鉴权、限流等零碎具体实现机制的异构性。
• 反对摩拜及将来新融入公司的异构治理体系与公司整体的疾速交融。

针对上述 3 个子指标，咱们所采取的计划如下：

• 将数据面 + 管制面定义为标准化的服务治理运行时，在规范运行时内买通所有治理能力。
• 建设对立接入核心零碎 Dispatcher，并由其对接并屏蔽治理子系统的异构性，从而实现内部零碎的差别对 Pilot 通明；下图中 Dispatcher 与 Pilot 间接交互，Meta Server 的作用是防止播送升高冗余。
• 重构或从零建设 SDK，目前应用的 6 种语言 SDK 均已落地并应用。
• 异构语言、异构体系均应用加强的对立协定交互，实现互通。

通过 Service Mesh 实现体系交融的前后比照如下：

• 引入 Service Mesh 前，单车向公司的流量以及公司向单车的流量，均是由两头的 adaptor 单点服务承接。除稳定性有较大隐患外，所有交互逻辑均须要开发两份代码，效率较差。
• 引入 Service Mesh 后，在一套服务治理设施内买通并间接交互，打消了核心 adaptor 带来的稳定性及研发效率方面的缺点；此外整个买通在 1 个月内实现，异构体系交融效率很高。

通过上述计划，针对异构性方面获得了较好的成果：

• 标准化 6 种语言治理体系，非 Java 语言的外围治理能力根本对齐 Java；新语言也很容易融入，提供的官网 Python 语言、Golang 语言的通信框架新版本（依靠于 OCTO Mesh），开发成本均管制在 1 个月左右。
• 反对异构治理子系统通过对立接入核心疾速融入，架构简洁、扩展性强。
• 反对异构治理体系疾速交融并在单车侧落地，异构治理体系买通老本也从 1.5 年升高到 1 个月。

3.4 规模化解决方案

3.4.1 开源 Istio 问题剖析

规模化的指标及特色用一句话总结是：具备撑持数万服务、百万节点体量的零碎能力，并反对程度扩大。挑战次要有 3 个：

• 美个人量是最风行开源产品 Istio 下限的上千倍。
• 极高的实时性、准确性要求；配置下发谬误或失落会间接引发流量异样。
• 起步较早，业界参考信息很少。

通过对 Istio 架构进行深入分析，咱们发现外围问题聚焦在以下 3 个瓶颈点：

• 每个管制面实例有 ETCD 存储系统的全副数据，无奈程度扩大。
• 每个 Proxy 链接相当于独立与 ETCD 交互，而同一个服务的 Proxy 申请内容都雷同，独立交互有大量的 I/O 冗余。当 Proxy 批量发版或网络抖动时，刹时风暴很容易压垮管制面及 ETCD。
• 每个节点都会探活所有其余节点。10 万节点规模的集群，1 个检测周期有 100 亿次探活，会引发网络风暴。

3.4.2 措施一：横向数据分片

针对 Istio 管制面各实例承载全集群数据的问题，对应的措施是通过横向逻辑数据分片反对扩展性，具体方案设计如下：

• Proxy 启动时会去向 Meta Server 零碎申请须要连贯的 Pilot IP，Meta Server 将雷同服务的 Proxy 尽量落到同一个管制面节点（外部策略更为简单，还要思考地区、负载等状况），这样每个 Pilot 实例按需加载而不用承载所有数据。
• 管制面节点异样或公布更新时，其所治理的 Proxy 也会有法则的迁徙，复原后在肯定工夫后还会接管其负责的 Proxy，从而实现了会话粘滞，也就实现逻辑下面的数据分片。

通过治理链接关系实现了按事业群隔离、按服务灰度等平台能力，最要害的还是解决了 Mesh 体系程度扩大的问题。

3.4.3 措施二：纵向分层订阅

针对 Istio 独立治理各 Proxy 链接的 I/O 冗余问题，对应的措施是通过分层订阅缩小冗余 I/O。Proxy 不间接与存储等零碎对接，而是在两头通过一系列的解决，关键点有两个：

• 关键点 1：基于快照缓存 + 索引的机制来缩小 ZK watcher 同步。以注册核心为例，惯例实现形式下，如果每个 Proxy 关注 100 个节点，1 万个节点就会注册 100 万个 watcher，雷同服务的 Proxy 所关注内容是雷同的，另外不同服务 Proxy 所关注的也有很多交加，其中蕴含大量的冗余。分层订阅模式下，Proxy 不与注册核心间接交互，通过两头的快照缓存与分层，确保每个 Pilot 实例中 ZK 雷同门路的监听最多只用 1 个 watcher，获取到 watcher 告诉后，Pilot 依据外部的快照缓存 + 索引向所有关注者散发，大大降低了冗余。
• 关键点 2：治理能力层及会话管理层实现了相似于 I/O 多路复用能力，通过并发晋升吞吐。

后果方面有效应对了网络抖动或批量发版的霎时风暴压力，压测单 Pilot 实例能够承载 6 万以上的链接，时延 TP99 线 < 2.3ms、数据零失落。

3.4.4 措施三：集中式衰弱检测

针对大规模集群内指数级收缩的节点间衰弱监测次数，对应的措施是摒弃了 P2P 检测模式，咱们参考并优化了 Google 的 Traffic Drector 中心化治理的衰弱检测模式。这种模式下检测次数大大减少，一个周期内 10 万节点集群的检测次数，从 100 亿次降落到 10 万次。

此外，当 Pilot 感知到 Proxy 异样时，会立刻告诉中心化衰弱检测系统启动检测，而不是期待检测周期窗口的到来，这能够无效晋升业务调用的成功率。

3.5 交易型场景窘境下的解决方案

3.5.1 业务属性剖析

美团外部业务线较多，包含外卖、配送、酒店、游览、单车、团购等，其中绝大多数业务都带有交易属性，交易链路上一个流量异样就可能影响到订单。业务系统对新技术畛域的摸索往往比拟谨慎，冀望在新技术充沛验证后再启动试点，所以除小语种及亟待与公司买通的单车业务外，推广的难度是十分大的。此外，基础架构部秉承“以客户为核心”的准则，研发、运维、测试人员均是咱们的“客户”，所以技术升级会重点从业务价值动手，并非简略依附从上至下的政策推动力。

所以，咱们对外的承诺是：通信足够快、零碎足够稳固、接入足够平滑高效。

3.5.2 精细化经营体系建设

针对推广的窘境，咱们首先做了两件事件：

• 寻找具备强诉求的业务试点，主观来说，美团技术栈内这类业务数量十分无限。
• 寻求标杆外围业务试点，充沛验证后推广给其余业务，但成果并不现实，与业务稳定性的诉求并不匹配。

针对上述窘境，咱们进行深度思考后建设了一个精细化的经营体系：

• 服务接入 Mesh 前。基于 SOA 分级将服务划分为非核心与外围两类，先针对非核心服务以及所有服务的线下环境进行重点冲破，实现了在宽泛的业务场景下，全面且充沛的验证零碎能力。
• 服务接入 Mesh 中。经营零碎通过校验 SDK 版本、运行时环境等信息，主动筛选出满足条件的服务，业务同学只须要在平台上做（1）开启开关、（2）抉择节点（3）指定 Mesh 流量比例三个步骤，就实现了到 Mesh 模式的切换，不需代码革新也不需公布服务，整个过程根本在 1 分钟左右实现；此外，通过与 IM 工具深度联动，晋升了推广与数据经营的效率。
• 服务接入 Mesh 后。一方面，业务侧包含架构侧的经营有具体的数据指标做比照参考；另一方面，经营零碎反对事后设置稳定性策略并做准实时的检测，当某个接入服务 Mesh 模式异样时，即时主动切换回非 Mesh 模式。

经营体系具备“接入过程无感”、“精细化流量粒度灰度”、“异样主动回滚复原”三个外围能力，在经营体系建设后推广经营较为顺利，目前线上接入的 600+ 服务、线下接入的 3500+ 服务中，90% 以上是依靠经营平台接入 Mesh 的。

3.5.3 通信性能优化

在性能损耗优化这个方向，除应用 UDS 躲避网络栈外，咱们也通过增量聚合下发、序列化优化两个措施缩小不必要的解包，晋升了通信性能。

通过压测，去除非外围性能在 2 核 4G 环境用 1KB 数据做 echo 测试，QPS 在 34000 以上，一跳均匀提早 0.207ms，时延 TP99 线 0.4ms 左右。

3.5.4 流量多级爱护

美团落地 Service Mesh 在稳定性保障方面建设投入较多，目前尚无 Service Mesh 引发的故障，具体蕴含三个方面：

• 首先做了流量多级爱护

  • 一方面，当 Proxy 不可用时，流量会主动 fallback 到非 Mesh 模式；另一方面，反对最精密反对按单节点的 1/1000 比例灰度。下图是具体的交互流程，当然，这两个个性与 Service Mesh 的最终状态是抵触的，只是作为零碎建设初期优先保障业务稳定性的过渡性计划，长期来看必然是要去除的（包含美团一些外围服务曾经齐全去除）。
  • 基于 FD 迁徙 + SDK 配合协定交互，实现 Proxy 无损热重启的能力。
• 管制面下发谬误配置比停发配置的结果更为严重，咱们建设了利用层面及零碎层面的周期巡检，从端到端的利用视角验证正确性，防止或缩小因变更引发的异样。
• 零碎交互方面，通过限流、熔断对中心化管制面做服务爱护；零碎内柔性可用，当管制面全副异样时，缓存机制也能帮助 Proxy 在肯定工夫内可用。

四、总结

本文系统性的介绍美团在 Service Mesh 落地过程中面临的“兼容性”、“异构性”、“规模化”、“交易属性业务容错性低”这四类复杂性挑战，针对上述挑战，咱们也具体介绍了大规模公有星散群场景下的优化思考及实际计划。

基于上述实际，目前美团线上落地服务数超过 600，线下服务数超过 3500+，初步验证了模式的可行性。短期价值方面，咱们反对了摩拜等异构治理体系的疾速交融、多语言治理能力的对立；长期价值仍需在实践中持续摸索与验证，但在标准化服务治理运行时并与业务解耦、中心化管控下更丰盛的治理能力输入两个方面，是十分值得期待的。

作者简介

继东、薛晨、业祥、张昀，均来自美团根底技术部 - 基础架构部。

招聘信息

根底技术部 - 基础架构部 - 中间件研发核心 - 服务框架组波及畛域次要包含 RPC 通信框架、Service Mesh、服务治理门户、Set 化、流程引擎零碎 Gravity 等。感兴趣的同学可投递简历至：tech@meituan.com（邮件主题请注明：基础架构部）。

| 想浏览更多技术文章，请关注美团技术团队（meituantech）官网微信公众号。在公众号菜单栏回复【2019 年货】、【2018 年货】、【2017 年货】、【算法】等关键词，可查看美团技术团队历年技术文章合集。