广西住房与城乡建设厅网站电话,手机端wordpress模板下载,阿克苏网站建设咨询,上海十大装修公司品牌排行榜| 本文根据美团基础架构部技术专家舒超在2019 ArchSummit#xff08;全球架构师峰会#xff09;上的演讲内容整理而成。 命名服务主要解决微服务拆分后带来的服务发现、路由隔离等需求#xff0c;是服务治理的基石。美团命名服务#xff08;以下简称MNS#xff09;作为服务… | 本文根据美团基础架构部技术专家舒超在2019 ArchSummit全球架构师峰会上的演讲内容整理而成。 命名服务主要解决微服务拆分后带来的服务发现、路由隔离等需求是服务治理的基石。美团命名服务以下简称MNS作为服务治理体系OCTO的核心模块目前承载美团上万项服务日均调用达到万亿级别。为了更好地支撑美团各项飞速发展的业务MNS开始从1.0向2.0演进。本文将围绕本次演进的初衷、实现方案以及落地的效果等方面进行展开同时本文还介绍了命名服务作为一个技术中台组件对业务的重要价值以及推动业务升级的一些成果。希望本文对大家能够有所启发。 一、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遇到的问题和挑战 但是随着美团业务的快速增长公司的服务数、节点数、服务信息量、服务变动频次等维度都在快速增长有些服务甚至呈现出跨数量级的增长。在这样的情况下命名服务也面临着一些新的问题和挑战 可用性公司业务持续高速增长很多都需要进行跨地域的部署。在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的迁移现场较重很容易因一个节点挂掉而引起连锁反应。 从可用性、扩展性、性能等三个方面MNS 1.0暴露出很多的问题究其根源原来的命名服务作为一个CP系统为获得“数据一致性”而牺牲了部分情况下的可用性。其实对于命名服务而言一致性并没有这么重要最多是调用方在一定时间内调多了或调漏了服务方而已这个后果在不可靠网络的大前提下即使命名服务没有出现问题也可能经常会出现。借助端的自我检查调整机制其影响可以说微乎其微。而另一方面如果是一个机房或一个地域的调用方和服务方没有问题但是因为这个区域和命名服务主集群断开了链接从而导致本域内不能互调这个就显得不太合理了。 所以总结一下我们认为命名服务的本质是建立和增强服务本身的连通性而不是主动去破坏连通性。命名服务本质上应该是一个AP系统。 其实业界对命名服务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.0 1.整体架构 MNS 2.0的整体架构自上而下主要分为四层 业务系统层这一层与MNS 1.0架构类似依然是嵌入到业务系统中的SDK或框架但是不再感知服务列表和路由计算从而变得更加的轻薄。代理接入层这一层主要变化是加入了Service Mesh的Sidecar和MNS-API。前者将命名服务的部分链路接入Mesh后者为MNS增加了更丰富的HTTP调用帮助一些没有使用SDK或框架的业务快速接入到命名服务。整个代理接入层的改造使得MNS对接入业务更加亲和。控制服务层新增注册中心控制服务这也是MNS 2.0的核心。主要分为以下三个模块 网关管控模块提供集中式的鉴权、限流/熔断、统计等SOA服务化的管控能力同时避免海量代理组件直连存储层。数据分发模块数据的通道包括注册数据的上传、订阅数据的下发可进行精细化数据拆分和平行扩展来适配热点服务。变更捕获模块服务注册发现的审计包括对第三方系统进行事件通知和回调支持多元化的服务数据营运需求。另外控制服务层还包括全链路SLA监控等新的子模块以及健康检查Scanner这样的传统MNS组件。数据存储层我们进一步丰富了命名服务的存储和分发介质提高了数据层的整体性能。主力存储使用K/V存储系统美团Cellar系统替代MNS-ZK有效地提高了数据的吞吐能力支持网络分区后的数据读写以及宕机灾备同时保留ZK做一些轻量级的Notify功能。新增的关系型数据库和消息队列美团Mafka系统配合控制层的变更捕获模块提供更方便的数据挖掘结构和外部扇出。旁路于上面4层的是外部营运设施主要是业务端的可视化Portal用户可以在上面对自身服务进行监控和操作美团的基础研发部门也可以在上面进行一些集中式的管控。综上所述MNS 2.0整体架构在兼容1.0的前提下重点变化是新增了控制服务层并对底层存储介质进行拆解。下面我们来看一下服务注册发现功能在MNS 2.0中的实现流程 服务注册代理接入层透传业务注册请求经过控制服务层的管控模块Gateway一系列SOA和审计流程后写入注册数据到存储层。数据感知控制服务监听数据变动服务注册写入新信息后分发模块Delivery更新内存中的缓存数据流经过捕获模块CDC将注册信息关系化后存储到DB。服务发现代理层请求经过控制服务的管控模块Gateway效验后从分发模块Delivery的缓存中批量获取服务端注册信息。Cache Miss场景时从存储层读取数据。外部交互层外部系统当下通过代理层接入整个MNS体系避免直连存储带来的各类风险问题。未来营运平台可直接使用准实时DB数据以OLAP方式进行关系化数据的分析。接下来我们一起来看下MNS2.0的主要演进成果。 2.演进成果 2.1 流量洪峰平行扩展 流量洪峰对于不同领域而言有不同的时段。对于O2O领域比如美团来说就是每天中午的外卖高峰期然后每天晚上也会有酒旅入住的高峰等等。当然基于其它的业务场景也会有不同的高峰来源。比如通过“借势营销”等运营手段带来的高峰量可能会远超预期进而对服务造成巨大的压力。 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恢复后流量再切回。 网络分区可用MNS 1.0阶段网络分区对可用性的影响巨大分区后MNS-ZK直接拒绝服务。新架构将存储迁移到KV系统后在网络专线抖动等极端情况下各区域依然能正常提供数据读取功能。同时我们与公司存储团队共建C SDK的地域就近读写功能。一方面提高跨域服务注册发现的性能另一方面实现了网络分区后各区域内命名服务可读、可写的目标提高了系统的可用性整个命名服务对网络的敏感度降低。 目前控制服务层在平行扩缩容时间和集群原地恢复时间等方面都达到了分钟级集群也没有节点上限从而能够有效应对突发的流量防止服务出现“雪崩”。 2.2 推送风暴性能提升 另一个典型的场景是推送“风暴”在服务集中发布、出现网络抖动等情况下会导致命名服务出现”一横一纵”两种类型的放大效应横向是“关注放大”类似于社交网络中某大V消息需要分发给众多的粉丝服务越核心放大的效果越明显。纵向是“级联放大”命名服务的上下游会逐级进行拷贝发送甚至一级上下游会针对一个消息有多次的交互NotifyPull。 “关注放大”和“级联放大”本身都是无法避免的这是由系统属性决定而我们能做的就是从两方面去平滑其带来的影响 正面提升核心模块性能增强吞吐、降低延迟 结构化聚合注册信息控制服务的数据分发模块在内存中存储结构化的服务注册信息提供批量数据的读取能力降低多次网络RTT传输单个数据以及数据结构转化带来的高耗时。 2.高并发的吞吐能力控制服务通过无锁编程处理关键路径的竞争问题借助应用侧协程机制提供高并发、低延迟的数据分发功能。与存储团队共建实现KV系统就近区域读写提高命名服务的服务注册数据写入性能。另外包括前面提到的控制服务集群的平行扩展能力其实也是整体性能提升的一种方式。 侧面疏通区分冷热数据降低推送的数据量提高效能 自然界中普遍存在“80/20法则”命名服务也不例外。服务注册信息的结构体中元素80%的改动主要是针对20%的成员比较典型的就是服务状态。因此我们将单个整块的服务信息结构体拆分为多个较小的结构体分离存储当数据变动发生时按需分发对应的新结构体能够降低推送的数据量有效减少网络带宽的占用避免代理组件重复计算引起的CPU开销数据结构变小后内存开销也得到显著降低。 那是否需要做到完全的“按需更新”仅推送数据结构中变动的元素呢我们认为完全的“按需更新”需要非常精细的架构设计并会引入额外的计算存储开销。比如我们需要将变动成员分开存储以实现细粒度Watcher或用专门服务识别变动元素然后进行推送。 同时还要保证不同成员变动时每次都要推送成功否则就会出现不一致等问题。在组件计算逻辑所需的数据发生变化时也会带来更多的改动。在命名服务这样的大型分布式系统中“复杂”、“易变”就意味着稳定性的下降和风险的上升。所以根据“80/20法则”我们进行尺度合理的冷热数据分离这是在方案有效性和风险性上进行权衡后的结果。 经过改造MNS 2.0相比MNS 1.0的吞吐能力提升8倍以上推送成功率从96%提升到99%1K大小服务列表服务发现的平均耗时从10s降低到1sTP999从90s下降到10s整体优化效果非常明显。 2.3 融入Service Mesh 在MNS 2.0中我们将代理服务SgAgent部分注册发现功能合并到了Mesh数据面其流程如下图所示 关于美团服务治理功能与Service Mesh结合的技术细节这部分的内容我们今年会单独做一个专题来进行分享感兴趣的同学可以关注“美团技术团队”微信公众号敬请期待。 2.4 无损迁移 除了上面说到的MNS 2.0的这些重点演进成果之外我们还想谈一下整个命名服务的迁移过程。像MNS这样涉及多个组件、部署在公司几十万个机器节点上、支撑数万业务系统的大规模分布式系统如何进行平滑的数据迁移而不中断业务正常服务甚至不让业务感知到是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作为主要存取介质等等。取舍的核心原则是改造目标时强调业务收益落地过程中减少业务感知。 目前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化技术与美团点评实践解密》。这里主要是从命名服务对单元化支撑的角度去解答这个问题。 如上图所示业务多种来源的外网流量在通过网关进入内网后会借助命名服务提供的能力SDK/Agent并按照业务自定义的核心数据维度和机器属性给流量打上单元化标签然后路由到标签匹配的下一跳从而实现了单元间流量隔离。一个单元内部从服务节点到各种存储组件都依赖于命名服务提供的单元识别和路由能力来完成隔离所以命名服务在单元化中主要起底层支撑的作用。目前单元化在美团的重点业务比如外卖、配送已经建设的比较完备通过一定的单元冗余度能在一个单元出现问题时切换到另一个可用的镜像单元显著提高了业务整体可用性。 接下来我们再来看一下泳道场景。目前泳道在美团这边主要用于业务做完代码UT之后的线下集成测试阶段同时结合容器实现一个即插即用的上下游调用环境去验证逻辑。命名服务在其中起到的作用与单元化类似根据泳道发布平台对机器的配置自动编排上下游的调用关系。如下图所示 当下一跳存在泳道节点时测试流量进入泳道。反之测试流量回流到主干。每个节点重复上述过程。 4.2 平滑发布弹性伸缩 命名服务另外一个重要场景是服务的平滑发布我们与发布平台配合控制发布流量的自动摘除与恢复实现服务发布操作的自动化与透明化。具体流程如下图所示 早期的发布流程存在异常调用的风险上线过程中存在一段服务实例不可用的“时间窗口”此时流量再进入可能导致调用失败然后会报错。为保证发布的稳定性需要操作人员手动进行流量排空流程上效率低、易出错浪费业务团队的时间。针对这项业务痛点命名服务向发布系统提供针对服务实例的流量管控能力实现进程重启前自动摘除并清空来源请求升级完毕后提供自动流量恢复的平滑发布功能。智能地解决发版过程中的异常调用问题提高公司的服务上线效率降低了业务团队的运维成本。 弹性伸缩是容器一个很大的卖点。但是在伸缩过程中有很多问题需要考虑比如扩缩容策略包括调用亲和度配置路由均衡等等。命名服务和容器化合作提供业务的上下游调用关系、分组设置信息、容器下线流量无损摘除等服务同时保障伸缩服务注册及时、高效。如下图所示 4.3 服务数据 MNS服务数据对业务的赋能主要分为两个部分一是将自身运行状态以业务可理解的SLA暴露出来方便业务评估命名服务健康状况。对于命名服务来说SLA指标主要有推送成功率和推送耗时两种其实推送耗时也可以看做成功率的一个衡量维度这里暂时不做太详细的区分。 MNS 1.0精准量化运行状况的困难在于一方面MNS的发布/订阅机制重度依赖ZK受限于ZK的自身实现和链路上众多不同组件的异构性及时获取完整链路的推送行为数据很困难。另一方面由于节点数众多全量采集服务发现数据对公司的监控上报系统以及采集之后的计算也是很大的负担。 在MNS 2.0中我们首先在架构上显著弱化了ZK的地位它基本上只作为一致性通知组件。我们自研的MNS-Control可以充分DIY埋点场景保证了主要推送行为抓取的可控性。其次我们采用了分级采样计算在全面梳理了公司现有的服务节点数比例后将典型的服务列表数划分为几个档次比如1000个节点的服务为一档100个又为一档并创建相应的非业务哨兵服务然后在不同机房选取适量的采样机器定期注册拉取来评估整体的运行情况。这样既做到了上报量的精简又兼顾了上报数据的有效性。详细操作流程如下图所示 控制层周期性修改采样服务中的服务数据触发服务发现的数据推送流程。 参与指标统计的机器节点本地代理进程获取到注册信息推送后上报送达时间到运维平台并由其写入存储层。 控制层对数据库中的数据进行聚合计算最后上报监控系统展示指标数据。此外通过与监控团队合作解决全量部署的Agent埋点监控问题。 命名服务存储的服务信息有很高的业务价值从中可以知道服务的部署情况、发布频次以及上下游拓扑信息等等。所以“赋能”的第二个部分在于借助这些信息我们可以挖掘出业务服务部署运维上不合理的地方或风险点不断推动优化从来避免一些不必要的损失。目前已经在推动的项目包括 单进程多端口改造业务使用这种方式去区分不同的调用端口从而造成端口资源的浪费而且调用下游还要感知部署信息这种机器属性粒度细节的暴露在云原生时代是不太恰当的。我们协助业务将调用行为改成单端口多接口的形式在协议内部去区分调用逻辑。大服务列表的拆分随着业务的发展单个服务的节点数呈爆发式增长甚至出现了一个服务有接近7W的节点数的情况对发布、监控、服务治理等底层设施产生很大的压力。我们通过和业务的沟通发现大列表产生的原因主要有两点1. 单机性能不够只能以实例抗2. 服务内容不够聚焦。换句话说因为服务还不够“微”所以导致逻辑越来越庞大有需求的调用方和自身实例相应增加代码风险也在增大。因此我们和业务一起梳理分析架构和调用将核心共用模块与业务逻辑群分拆出来减少冗余调用最终使一些大服务节点数量从数万降低到数千实现了数量级的下降。上下游均衡部署这个比较容易理解结合调用端与服务端比例、服务方机器性能以及调用失败率等信息可以作为服务业务在各机房间均衡调整机器数量的参考。另一方面我们也在减少基本就近调用策略的粒度目前只保留了“同IDC”和“同城”两种去掉了之前的“同中心策略”减轻业务服务部署的心智负担。后期随着机房数量的降低和同地域机房间延时的可控同城路由可能是最终的方案。在架构上MNS 2.0依赖DB和其它一些数仓介质进行多种维度的数据上卷和下钻并结合一些定制的风险策略逻辑去帮助业务发现和规避问题目前这个事情也在进行中。 五、未来展望 未来美团命名服务主要会朝两个方向发展 进一步收集、挖掘服务数据的价值打造服务数据平台赋能业务升级。从单纯实现业务注册发现路由等需求到通过数据反向推动业务架构流程改造升级这也是美团核心价值观“以客户为中心”的一种体现。深度结合Service Mesh等云原生基础设施的演进。云原生理念及相关设施架构的快速发展必然会造成传统服务治理组件架构上流程的变动深度拥抱云原生并享受基础功能下沉带来的“红利”是命名服务一个比较确定的方向。作者简介 舒超美团资深技术专家OCTO服务治理团队研发核心成员。张翔美团高级工程师美团OCTO服务治理团队研发核心成员。招聘信息 美团OCTO服务治理团队诚招C/Java高级工程师、技术专家。我们致力于研发公司级、业界领先的基础架构组件研发范围涵盖分布式框架、命名服务、Service Mesh等技术领域。欢迎有兴趣的同学投送简历至techmeituan.com邮件备注美团OCTO团队。
