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

目前，MNS 2.0 主要成果如下：

重构了 5 个已有的核心组件，研发了 2 个全新的系统，完成公司 PaaS 层数十个服务的功能的适配改造，目前已成功迁移全公司 80% 以上的服务，且在迁移过程中无重大事故。
RTO 从数小时降到分钟级，RPO 为 0；全链路推送耗时 TP999 从 90s 降到了 10s，推送成功率从 96% 提升到 99% 以上，基本完成了百万级别服务节点治理能力的建设。
集群数据按照业务线等多维度进行拆分，建立了基于分级染色的 SLA 指标和定期巡检机制，同时根据公司实际场景增加了众多的服务风控审计功能，保障了业务安全。
云原生方面，支持了 Service Mesh，注册发现流程融入了 Mesh 底层基础设施。

四、命名服务对业务的赋能命名服务本身作为基础的技术中台设施，在坚持“以客户为中心”，升级自身架构的同时，也从如下几个方面对美团的多个业务进行赋能。
4.1 单元化 & 泳道单元化（SET 化）是业界比较流行的容灾扩展方案，关于美团单元化的详细内容，可参考 OCTO 团队在本次 ArchSummit 中的另一个专题分享《SET 化技术与美团点评实践解密》。这里主要是从命名服务对单元化支撑的角度去解答这个问题。

文章插图

图 13 命名服务对单元化的支持
如上图所示，业务多种来源的外网流量在通过网关进入内网后，会借助命名服务提供的能力（SDK/Agent），并按照业务自定义的核心数据维度和机器属性，给流量打上单元化标签，然后路由到标签匹配的下一跳，从而实现了单元间流量隔离。一个单元内部，从服务节点到各种存储组件，都依赖于命名服务提供的单元识别和路由能力来完成隔离，所以命名服务在单元化中主要起底层支撑的作用。
目前单元化在美团的重点业务，比如外卖、配送已经建设的比较完备，通过一定的单元冗余度，能在一个单元出现问题时，切换到另一个可用的镜像单元，显著提高了业务整体可用性。
接下来，我们再来看一下泳道场景。目前泳道在美团这边主要用于业务做完代码 UT 之后的线下集成测试阶段，同时结合容器，实现一个即插即用的上下游调用环境去验证逻辑。命名服务在其中起到的作用与单元化类似，根据泳道发布平台对机器的配置，自动编排上下游的调用关系。如下图所示：

文章插图

图 14 泳道流量示意图
当下一跳存在泳道节点时，测试流量进入泳道。反之，测试流量回流到主干。每个节点重复上述过程。
4.2 平滑发布 & 弹性伸缩命名服务另外一个重要场景是服务的平滑发布，我们与发布平台配合，控制发布流量的自动摘除与恢复，实现服务发布操作的自动化与透明化。具体流程如下图所示：

文章插图

图 15 命名服务支持平滑发布
早期的发布流程，存在异常调用的风险，上线过程中存在一段服务实例不可用的“时间窗口”，此时流量再进入可能导致调用失败，然后会报错。为保证发布的稳定性，需要操作人员手动进行流量排空，流程上效率低、易出错，浪费业务团队的时间。针对这项业务痛点，命名服务向发布系统提供针对服务实例的流量管控能力，实现进程重启前自动摘除并清空来源请求，升级完毕后，提供自动流量恢复的平滑发布功能。智能地解决发版过程中的异常调用问题，提高公司的服务上线效率，降低了业务团队的运维成本。
【带你去看美团架构】弹性伸缩是容器一个很大的卖点。但是在伸缩过程中有很多问题需要考虑，比如扩缩容策略，包括调用亲和度配置，路由均衡等等。命名服务和容器化合作，提供业务的上下游调用关系、分组设置信息、容器下线流量无损摘除等服务，同时保障伸缩服务注册及时、高效。如下图所示：

文章插图

图 16 命名服务支持弹性伸缩
4.3 服务数据MNS 服务数据对业务的赋能主要分为两个部分，一是将自身运行状态以业务可理解的 SLA 暴露出来，方便业务评估命名服务健康状况。对于命名服务来说，SLA 指标主要有推送成功率和推送耗时两种（其实，推送耗时也可以看做成功率的一个衡量维度，这里暂时不做太详细的区分）。