TechNomads

根据美团下一代服务治理系统 OCTO2.0 的探索与实践整理总结而来

一、OCTO现状

OCTO 是美团标准化的服务治理基础设施，治理能力统一、性能及易用性表现优异、治理能力生态丰富，已广泛应用于美团各事业线。但是存在一些问题：

• 对多语言支持不够好。 美团技术栈使用的语言主要是 Java，占比到达80%以上，上面介绍的诸多治理能力也集中在 Java 体系。 但美团同时还有其他近10种后台服务语言在使用，这些语言的治理生态均十分薄弱，同时在多元业务的模式下必然会有增长的多语言需求，为每一种语言都建设一套完善的治理体系成本很高，也不太可能落地。
• 中间件和业务绑定在一起，制约着彼此迭代。 一般来说，核心的治理能力主要由通信框架承载，虽然做到了逻辑隔离，但中间件的逻辑不可避免会和业务在物理上耦合在一起。这种模式下，中间件引入Bug需要所有业务配合升级，这对业务的研发效率也会造成损害；新特性的发布也依赖业务逐个升级，不具备自主的控制能力。
• 异构治理体系技术融合成本很高。
• 治理决策比较分散。 每个节点只能根据自己的状态进行决策，无法与其他节点协同仲裁。
  

针对以上痛点，我们考虑依托于 Service Mesh 解决。Service Mesh 模式下会为每个业务实例部署一个 Sidecar 代理，所有进出应用的业务流量统一由 Sidecar 承载，同时服务治理的工作也主要由 Sidecar 执行，而所有的 Sidecar 由统一的中心化控制大脑控制面来进行全局管控。这种模式如何解决上述四个问题的呢？

• Service Mesh 模式下，各语言的通信框架一般仅负责编解码，而编解码的逻辑往往是不变的。核心的治理功能（如路由、限流等）主要由 Sidecar 代理和控制大脑协同完成，从而实现一套治理体系，所有语言通用。
• 中间件易变的逻辑尽量下沉到 Sidecar 和控制大脑中，后续升级中间件基本不需要业务配合。SDK 主要包含很轻薄且不易变的逻辑，从而实现了业务和中间件的解耦。
• 新融入的异构技术体系可以通过轻薄的 SDK 接入美团治理体系（技术体系难兼容，本质是它们各自有独立的运行规范，在 Service Mesh 模式下运行规范核心内容就是控制面和Sidecar），目前美团线上也有这样的案例。
• 控制大脑集中掌控了所有节点的信息，进而可以做一些全局最优的决策，比如服务预热、根据负载动态调整路由等能力。

总结一下，在当前治理体系进行 Mesh 化改造可以进一步提升治理能力，美团也将 Mesh 化改造后的 OCTO 定义为下一代服务治理系统 OCTO2.0（内部名字是OCTO Mesh）。

二、技术选型及架构设计

2.1 OCTO Mesh 技术选型

美团octo系统在内部运行了多年，跟service mesh差异是非常大的。因此方案设计不能照搬，寻找适合自己的道路。

经过考量，数据面基于 Envoy 二次开发，控制面自研为主

2.2 OCTO Mesh 架构设计

上面这张图展示了 OCTO Mesh 的整体架构。从下至上来看，逻辑上分为业务进程及通信框架 SDK 层、数据平面层、控制平面层、治理体系协作的所有周边生态层。
先来重点介绍下业务进程及SDK层、数据平面层：

• OCTO Proxy （数据面Sidecar代理内部叫OCTO Proxy）与业务进程采用1对1的方式部署。

• OCTO Proxy 与业务进程采用 UNIX Domain Socket 做进程间通信（这里没有选择使用 Istio 默认的 iptables 流量劫持，主要考虑美团内部基本是使用的统一化私有协议通信，富容器模式没有用 Kubernetes 的命名服务模型，iptables 管理起来会很复杂，而 iptables 复杂后性能会出现较高的损耗。）；OCTO Proxy 间跨节点采用 TCP 通信，采用和进程间同样的协议，保证了客户端和服务端具备独立升级的能力。

• 为了提升效率同时减少人为错误，我们独立建设了 OCTO Proxy 管理系统，部署在每个实例上的 LEGO Agent 负责 OCTO Proxy 的保活和热升级，类似于 Istio 的 Pilot Agent，这种方式可以将人工干预降到较低，提升运维效率。

• 数据面与控制面通过双向流式通信。路由部分交互方式是增强语义的 xDS，增强语义是因为当前的 xDS 无法满足美团更复杂的路由需求；除路由外，该通道承载着众多的治理功能的指令及配置下发，我们设计了一系列的自定义协议。
  
  控制面（内部名字是Adcore）自研为主，整体分为：Adcore Pilot、Adcore Dispatcher、集中式健康检查系统、节点管理模块、监控预警模块。此外独立建设了统一元数据管理及 Mesh 体系内的服务注册发现系统 Meta Server 模块。每个模块的具体职责如下：

• Adcore Pilot 是个独立集群，模块承载着大部分核心治理功能的管控，相当于整个系统的大脑，也是直接与数据面交互的模块。

• Adcore Dispatcher 也是独立集群，该模块是供治理体系协作的众多子系统便捷接入 Mesh 体系的接入中心。

• 不同于 Envoy 的 P2P 节点健康检查模式，OCTO Mesh 体系使用的是集中式健康检查。

• 控制面会节点管理系统负责采集每个节点的运行时信息，并根据节点的状态做全局性的最优治理的决策和执行。

• 监控预警系统是保障 Mesh 自身稳定性而建设的模块，实现了自身的可观测性，当出现故障时能快速定位，同时也会对整个系统做实时巡检。

• 与Istio 基于 Kubernetes 来做寻址和元数据管理不同，OCTO Mesh 由独立的 Meta Server 负责 Mesh 自身众多元信息的管理和命名服务。

三、关键设计解析

大规模治理体系 Mesh 化建设成功落地的关键点有：

• 系统水平扩展能力方面，可以支撑数万应用/百万级节点的治理。
• 功能扩展性方面，可以支持各类异构治理子系统融合打通。
• 能应对 Mesh 化改造后链路复杂的可用性、可靠性要求。
• 具备成熟完善的 Mesh 运维体系。

围绕这四点，便可以在系统能力、治理能力、稳定性、运营效率方面支撑美团当前多倍体量的新架构落地。

3.1 大规模系统 Mesh 化系统能力建设

对于社区 Istio 方案，要想实现超大规模应用集群落地，需要完成较多的技术改造。主要是因为 Istio 水平扩展能力相对薄弱，内部冗余操作较多，整体稳定性建设较为薄弱。针对上述问题，我们的解决思路如下：

• 控制面每个节点并不承载所有治理数据，系统整体做水平扩展，在此基础上提升每个实例的整体吞吐量和性能。
• 当出现机房断网等异常情况时，可以应对瞬时流量骤增的能力。
• 只做必要的 P2P 模式健康检查，配合集中式健康检查进行百万级节点管理。
  
  按需加载和数据分片主要由 Adcore Pilot 配合 Meta Server 实现。

Pilot 的逻辑架构分为 SessionMgr、Snapshot、Diplomat 三个部分，其中 SessionMgr 管理每个数据面会话的全生命周期、会话的创建、交互及销毁等一系列动作及流程；Snapshot 维护数据最新的一致性快照，对下将资源的更新同步给 SessionMgr 处理，对上响应各平台的数据变更通知，进行计算并将存在关联关系的一组数据做快照缓存。Diplomat 模块负责与服务治理系统的众多平台对接，只有该模块会与第三方平台直接产生依赖。

控制面每个 Pilot 节点并不会把整个注册中心及其他数据都加载进来，而是按需加载自己管控的 Sidecar 所需要的相关治理数据，即从 SessionMgr 请求的应用所负责的相关治理数据，以及该应用关注的对端服务注册信息。另外同一个应用的所有 OCTO Proxy 应该由同一个Pilot 实例管控，否则全局状态下又容易趋近于全量了。具体是怎么实现的呢？答案是 Meta Server，自己实现控制面机器服务发现的同时精细化控制路由规则，从而在应用层面实现了数据分片。

Meta Server 管控每个Pilot节点负责应用 OCTO Proxy的归属关系。当 Pilot 实例启动会注册到 Meta Server，此后定时发送心跳进行续租，长时间心跳异常会自动剔除。在 Meta Server 内部实现了较为复杂的一致性哈希策略，会综合节点的应用、机房、负载等信息进行分组。当一个 Pilot 节点异常或发布时，隶属该 Pilot 的 OCTO Proxy 都会有规律的连接到接替节点，而不会全局随机连接对后端注册中心造成风暴。当异常或发布后的节点恢复后，划分出去的 OCTO Proxy 又会有规则的重新归属当前 Pilot 实例管理。对于关注节点特别多的应用 OCTO Proxy，也可以独立部署 Pilot，通过 Meta Server 统一进行路由管理。

3.2 异构治理系统融合设计

3.3 稳定性保障设计

Service Mesh 改造的系统避不开“新”和“复杂”两个特征，其中任意一个特征都可能会给系统带来稳定性风险，所以必须提前做好整个链路的可用性及可靠性建设，才能游刃有余的推广。美团主要是围绕控制故障影响范围、异常实时自愈、可实时回滚、柔性可用、提升自身可观测性及回归能力进行建设。

3.4 运维体系设计

为了应对未来百万级 Proxy 的运维压力，美团独立建设了 OCTO Proxy 运维系统 LEGO，除 Proxy 保活外也统一集中控制发版。具体的操作流程是：运维人员在 LEGO 平台发版，确定发版的范围及版本，新版本资源内容上传至资源仓库，并更新规则及发版范围至 DB，发升级指令下发至所要发布的范围，收到发版命令机器的 LEGO Agent 去资源仓库拉取要更新的版本（中间如果有失败，会有主动 Poll 机制保证升级成功），新版本下载成功后，由 LEGO Agent 启动新版的 OCTO Proxy。