带你去看美团架构( 二 ) _美团架构

其实，业界对命名服务 AP/CP 模式都有相应实现和应用，很多企业使用 CP 模式，原因可能有以下几点:

架构行为简单：CP 系统在出现分区时行为比较简单，冷冻处理，粗暴但相对不容易出错。
启动门槛低：一些成熟的开源一致性组件，比如 ZK、etcd 都是 CP 系统，能够开箱即用，在数据规模可控的情况下，基本能够满足企业的需求。

另外，我们了解到，一些公司使用特殊的方式弱化了这个问题，比如将 CP 系统进一步拆分到更小的域中（比如一个 IDC），缩小分区的粒度，而全局有多个 CP 系统自治。当然，这个可能跟调用方服务方的跨度限制或者说调用配套部署有关系，但也有可能带来更复杂的问题（比如 CP 系统之间的数据同步），这里就不做详细的讨论了。
除去 MNS 1.0 本身的架构缺陷，我们还需要面临另一个问题，当初在项目启动时，云原生尚处于起步阶段，而如今，一些基于云原生理念兴起的网络基础设施，尤其是 Service Mesh 在美团快速发展，也需要 MNS 进行改造去适配新的流量通道和管控组件，这也是此次 MNS 2.0 演进的目标之一。
综上，我们以 AP 化、Mesh 化为主要目标，正式开始了从 MNS 1.0 向 MNS 2.0 的演进。
三、MNS 2.01. 整体架构

文章插图

图 4 MNS 2.0 整体架构
MNS 2.0 的整体架构自上而下主要分为四层：

业务系统层：这一层与 MNS 1.0 架构类似，依然是嵌入到业务系统中的 SDK 或框架，但是不再感知服务列表和路由计算，从而变得更加的轻薄。
代理接入层：这一层主要变化是加入了 Service Mesh 的 Sidecar 和 MNS-API 。前者将命名服务的部分链路接入 Mesh；后者为 MNS 增加了更丰富的 HTTP 调用，帮助一些没有使用 SDK 或框架的业务快速接入到命名服务。整个代理接入层的改造使得 MNS 对接入业务更加亲和。
控制服务层：新增注册中心控制服务，这也是 MNS 2.0 的核心。主要分为以下三个模块：a. 网关管控模块：提供集中式的鉴权、限流 / 熔断、统计等 SOA 服务化的管控能力，同时避免海量代理组件直连存储层。b. 数据分发模块：数据的通道，包括注册数据的上传、订阅数据的下发，可进行精细化数据拆分和平行扩展来适配热点服务。c. 变更捕获模块：服务注册发现的审计，包括对第三方系统进行事件通知和回调，支持多元化的服务数据营运需求。另外，控制服务层还包括全链路 SLA 监控等新的子模块，以及健康检查 Scanner 这样的传统 MNS 组件。
数据存储层：我们进一步丰富了命名服务的存储和分发介质，提高了数据层的整体性能。主力存储使用 K/V 存储系统（美团 Cellar 系统）替代 MNS-ZK，有效地提高了数据的吞吐能力，支持网络分区后的数据读写以及宕机灾备，同时保留 ZK 做一些轻量级的 Notify 功能。新增的关系型数据库和消息队列（美团 Mafka 系统），配合控制层的变更捕获模块，提供更方便的数据挖掘结构和外部扇出。
旁路于上面 4 层的是外部营运设施，主要是业务端的可视化 Portal，用户可以在上面对自身服务进行监控和操作，美团的基础研发部门也可以在上面进行一些集中式的管控。

综上所述，MNS 2.0 整体架构在兼容 1.0 的前提下，重点变化是：新增了控制服务层并对底层存储介质进行拆解。下面，我们来看一下服务注册发现功能在 MNS 2.0 中的实现流程：