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

侧面疏通，区分冷热数据，降低推送的数据量，提高效能
自然界中普遍存在“80/20 法则”，命名服务也不例外。服务注册信息的结构体中元素，80% 的改动主要是针对 20% 的成员，比较典型的就是服务状态。因此，我们将单个整块的服务信息结构体，拆分为多个较小的结构体分离存储；当数据变动发生时，按需分发对应的新结构体，能够降低推送的数据量，有效减少网络带宽的占用，避免代理组件重复计算引起的 CPU 开销，数据结构变小后，内存开销也得到显著降低。
那是否需要做到完全的“按需更新”，仅推送数据结构中变动的元素呢？我们认为，完全的“按需更新”需要非常精细的架构设计，并会引入额外的计算存储开销。比如，我们需要将变动成员分开存储以实现细粒度 Watcher，或用专门服务识别变动元素然后进行推送。
同时，还要保证不同成员变动时，每次都要推送成功，否则就会出现不一致等问题。在组件计算逻辑所需的数据发生变化时，也会带来更多的改动。在命名服务这样的大型分布式系统中，“复杂”、“易变”就意味着稳定性的下降和风险的上升。所以根据“80/20 法则”，我们进行尺度合理的冷热数据分离，这是在方案有效性和风险性上进行权衡后的结果。

文章插图

图 10 冷热数据分拆推送
经过改造，MNS 2.0 相比 MNS 1.0 的吞吐能力提升 8 倍以上，推送成功率从 96% 提升到 99%+，1K 大小服务列表服务发现的平均耗时，从 10s 降低到 1s，TP999 从 90s 下降到 10s，整体优化效果非常明显。
2.3 融入 Service Mesh在 MNS 2.0 中，我们将代理服务 SgAgent 部分注册发现功能合并到了 Mesh 数据面，其流程如下图所示：

文章插图

图 11 命名服务与 Service Mesh 的融合
关于美团服务治理功能与 Service Mesh 结合的技术细节，这部分的内容，我们今年会单独做一个专题来进行分享，感兴趣的同学可以关注“美团技术团队”微信公众号，敬请期待。
2.4 无损迁移除了上面说到的 MNS 2.0 的这些重点演进成果之外，我们还想谈一下整个命名服务的迁移过程。像 MNS 这样涉及多个组件、部署在公司几十万个机器节点上、支撑数万业务系统的大规模分布式系统，如何进行平滑的数据迁移而不中断业务正常服务，甚至不让业务感知到，是 MNS 2.0 设计的一个重点。围绕业务服务无感知、具备快速回滚能力、新 / 老体系互备数据不丢失等要求，我们设计了如下图所示的迁移流程：

文章插图

图 12 MNS 2.0 的无损迁移
MNS 2.0 整体以服务为粒度进行迁移操作，设置标志位说明服务所处的状态，由接入代理层组件识别该标志做出相应的处理。标志位包括：

未迁移标志：服务注册 / 发现走 MNS 1.0 的流程，注册信息存储到重构前的 MNS-ZK 中。
迁移中标志：服务注册并行走 MNS 1.0 和 MNS 2.0 流程，数据同时写入新旧两个地方，服务发现执行 MNS 2.0 流程。
已迁移标志：服务注册 / 发现全部走 MNS 2.0 流程，注册信息仅存储到 MNS 2.0 的数据层。该阶段无法进行平滑的回滚，是项目长期验证后最终的迁移状态。

上述可以总结为：聚焦单个服务，阶段性迁移服务发现流量，从而达到类似系统新功能发布时“灰度上线”的能力。当然，这个策略还涉及一些细节在其中，比如，分开存储在双写时需要重点去保证异常情况下的最终一致性等等，鉴于篇幅原因，这里就不详细展开讨论了，而且业界针对这种情况都有一些成熟的做法。
另外，我们通过优化命名服务发布系统的发版形式，实现自动化的流量灰度策略，降低了人力成本，同时构建了自动化的迁移工具、巡检工具，高效地进行自动化的数据迁移工作，能够快速巡检迁移后的链路风险，保障新 MNS 2.0 的稳定上线。
2.5 演进总结在美团命名服务这样的大型分布式系统优化过程中，具体到架构和功能设计层面，我们也做了不少的权衡和取舍，前面我们也提到，放弃了增量式的精准变动信息推送方式。在考虑性能的前提下，也没有使用数据多维度营运能力更好的 MySQL 作为主要存取介质等等。取舍的核心原则是：改造目标时强调业务收益，落地过程中减少业务感知。