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

接下来，我们一起来看下 MNS2.0 的主要演进成果。
2. 演进成果2.1 流量洪峰 & 平行扩展流量洪峰对于不同领域而言有不同的时段。对于 O2O 领域比如美团来说，就是每天中午的外卖高峰期，然后每天晚上也会有酒旅入住的高峰等等。当然，基于其它的业务场景，也会有不同的高峰来源。比如通过“借势营销”等运营手段，带来的高峰量可能会远超预期，进而对服务造成巨大的压力。

文章插图

图 6 流量洪峰
MNS 1.0 受制于 MNS-ZK 集群数量上限和强一致性的要求，无法做到快速、平行扩展。MNS 2.0 的数据存储层重心是保证数据安全读写和分布式协调，在扩展能力层面不应该对其有太多的要求。MNS 2.0 的平行扩展能力主要体现在控制服务层，其具体功能包括以下两个方面:
集群分片：控制服务提供全量注册数据的分片能力，解决命名服务单独进行大集群部署时不能进行业务线隔离的风险。MNS-Control 网关模块分为 Master 和 Shard 等两类角色，协作提供大集群分片能力。

Master ：维护服务注册信息与各个分片集群（Shard）的映射关系，向代理层组件提供该类 Meta 数据。Master 接收各个 Shard 集群事件，新增、清理 Shard 中维护的注册信息。
Shard ：数据分片自治向代理组件提供服务注册 / 发现功能，实现按业务线隔离命名服务，同时按照 Master 发出的指令，调整维护的注册信息内容。
Services ：业务服务通过代理组件接入 MNS，代理组件启动时通过与 Master 的交互，获知归属的 Shard 集群信息以及 Fallback 处理措施。此后 Agent 只与业务线 Shard 进行命名数据交互，直到 Shard 集群不可用，重新执行“自发现”流程。
Fallback 措施：设置一个提供全量服务信息的默认 Shard 集群，当业务线 Shard 异常时。一方面，Agent 重启“自发现”流程，同时将命名请求重定向到默认的 Shard 集群，直到业务线 Shard 恢复后，流量再切回。

文章插图

图 7 控制服务数据分片示意图
网络分区可用：MNS 1.0 阶段，网络分区对可用性的影响巨大，分区后 MNS-ZK 直接拒绝服务。新架构将存储迁移到 KV 系统后，在网络专线抖动等极端情况下，各区域依然能正常提供数据读取功能。同时，我们与公司存储团队共建 C++ SDK 的地域就近读写功能。一方面，提高跨域服务注册发现的性能，另一方面，实现了网络分区后，各区域内命名服务可读、可写的目标，提高了系统的可用性，整个命名服务对网络的敏感度降低。

文章插图

图 8 命名服务的平行扩展
目前，控制服务层在平行扩缩容时间和集群原地恢复时间等方面，都达到了分钟级，集群也没有节点上限，从而能够有效应对突发的流量，防止服务出现“雪崩” 。
2.2 推送风暴 & 性能提升另一个典型的场景是推送“风暴”，在服务集中发布、出现网络抖动等情况下，会导致命名服务出现 " 一横一纵 " 两种类型的放大效应：横向是“关注放大”，类似于社交网络中某大 V 消息需要分发给众多的粉丝，服务越核心，放大的效果越明显。纵向是“级联放大”，命名服务的上下游会逐级进行拷贝发送，甚至一级上下游会针对一个消息有多次的交互（Notify+Pull）。

文章插图

图 9 命名服务领域的消息放大现象
“关注放大”和“级联放大”本身都是无法避免的，这是由系统属性决定，而我们能做的就是从两方面去平滑其带来的影响：
正面提升核心模块性能，增强吞吐、降低延迟

结构化聚合注册信息：控制服务的数据分发模块，在内存中存储结构化的服务注册信息，提供批量数据的读取能力；降低多次网络 RTT 传输单个数据以及数据结构转化带来的高耗时。
高并发的吞吐能力：控制服务通过无锁编程处理关键路径的竞争问题，借助应用侧协程机制，提供高并发、低延迟的数据分发功能。
与存储团队共建，实现 KV 系统就近区域读写，提高命名服务的服务注册（数据写入）性能。

另外，包括前面提到的控制服务集群的平行扩展能力，其实也是整体性能提升的一种方式。