带你去看美团架构 _美团架构

文章整理：加米谷大数据
一、MNS 1.0 简介

文章插图

图 1 MNS 1.0 架构
从架构上看，MNS 1.0 主要分为三层：首先是嵌入业务内部的 SDK，用作业务自定义调用；然后是驻守在每个机器上的 SgAgent，以代理的方式将一些易变的、消耗性能的计算逻辑与业务进程分离开来，从而降低 SDK 对业务的侵入，减少策略变动对业务的干扰；远端是集中式的组件，包括健康检查模块 Scanner，鉴权缓存模块 MNSC，以及基于 ZooKeeper（以下简称 ZK）打造的一致性组件 MNS-ZK，作为通知和存储模块。在层级之间设立多级缓存，利用“边缘计算”思想拆分逻辑，简化数据，尽量将路由分配等工作均摊到端上，从而降低中心组件负载。
更多详情大家可参考《美团大规模微服务通信框架及治理体系 OCTO 核心组件开源》一文中的 OCTO-NS 部分。
在体量方面，MNS 1.0 已经接入了美团所有的在线应用，涉及上万项服务、数十万个节点，并覆盖了美团所有的业务线，日均调用达万亿级别，目前我们已将其开源。
总的来讲，作为公司级核心服务治理组件，MNS 1.0 在架构上带有明显的 CP 属性，在保持架构简洁、流程清晰的同时，还支持了业务大量迭代的需求，较好地帮助公司业务实现了服务化、标准化的目标。
二、MNS 1.0 遇到的问题和挑战

文章插图

图 2 近三年美团业务增长数据
但是随着美团业务的快速增长，公司的服务数、节点数、服务信息量、服务变动频次等维度都在快速增长，有些服务甚至呈现出跨数量级的增长。在这样的情况下，命名服务也面临着一些新的问题和挑战：

可用性：公司业务持续高速增长，很多都需要进行跨地域的部署。在 MNS 1.0 架构下，地域之间的专线如果断连，会发生一个地域命名服务整体不可用的情况；其次，强一致组件存在单点问题，Leader 出现故障，整个集群中断服务；另外，在多客户端和大数据传输的命名服务场景下，CP 系统恢复困难，RTO 达到小时级别。MNS 1.0 曾经出现过后端集中式组件单机连接超过十万且活跃链接数过半的情况，出现问题之后，现场恢复的负荷可想而知，这些都给命名系统的可用性带来很大的风险。
扩展性：相对于需要支持的业务数量，MNS 1.0 整体平行扩展能力不足。MNS-ZK 的单集群规模上限不超过 300（实际只能达到 250 左右，这与 ZooKeeper 内部的 myid 等机制有关），否则同步性能会急剧恶化；其次，集群写入不可扩展，参与写入节点越多性能越差；另外，服务信息快照在固定的时间片内持续增长，增加 IO 压力的同时也延长了迁移的同步时间。而扩展性上的短板，导致 MNS 1.0 难以应对突发的流量洪峰，易出现“雪崩” 。
性能：写入操作受 CP 属性限制，串行性能较低。MNS-ZK 整体到 7000 左右的写量就已接近上限。其次，在热点服务场景下，数据分发较慢，这跟数据粒度较粗也有一定关系。而数据粒度粗、量大，也会在组件间传输消息时，导致临时对象频繁生成，引起 GC 。另外，MNS 1.0 的后端集群负载还存在均衡性问题，一是因为原架构中缺乏集中管控服务，无法进行动态的集群与数据拆分伸缩，二是因为强一致属性下，集群节点间基于 Session 的迁移现场较重，很容易因一个节点挂掉而引起连锁反应。

文章插图

图 3 命名服务应该是 AP 系统
从可用性、扩展性、性能等三个方面，MNS 1.0 暴露出很多的问题，究其根源，原来的命名服务作为一个 CP 系统，为获得“数据一致性”而牺牲了部分情况下的可用性。其实，对于命名服务而言，一致性并没有这么重要，最多是调用方在一定时间内调多了或调漏了服务方而已，这个后果在不可靠网络的大前提下，即使命名服务没有出现问题，也可能经常会出现。借助端的自我检查调整机制，其影响可以说微乎其微。而另一方面，如果是一个机房或一个地域的调用方和服务方没有问题，但是因为这个区域和命名服务主集群断开了链接，从而导致本域内不能互调，这个就显得不太合理了。
所以总结一下，我们认为，命名服务的本质是建立和增强服务本身的连通性，而不是主动去破坏连通性。命名服务本质上应该是一个 AP 系统。