美团Service Mesh服务治理体系落地实践

春哥叨叨

共 3230字,需浏览 7分钟

 ·

2022-04-25 07:33

点击上方蓝色字体,选择“设为星标”

优质文章,及时送达


美团主要的服务治理体系是围绕Octo搭建的,随着ServiceMesh的概念兴起,美团的服务治理解决方案,也在朝着Mesh方向演进。


美团服务治理的发展史,整体分为四个阶段:

  1.  基础治理的统一:实现了通信框架及注册中心的统一,由统一的治理平台支撑节点管理、流量管理、监控预警等运营能力;

  2. 提升性能及易用性:qps从2w提升到10w,99分为线1ms,建立分布式链路追踪、分阶段耗时精细化埋点等功能;

  3. 全方位丰富治理能力:落地了全链路压测平台、性能诊断优化平台、稳定性保障平台、鉴权加密等一系列平台,实现了链路级别的流量治理,全链路灰度发布等;

  4. 跨地域的容灾及扩展能力:每天数千万订单的单元化,实现了所有PaaS层组件及核心存储系统的打通;




目前所面对的特点有两个:业务发展多元化,治理需求精细化。


展开来说,比如业务和中间件强耦合,制约彼此迭代。中间件的bug会要求业务系统大面积的升级,整体迭代成本高。非java语言治理体系薄弱,很多主流中间件缺少相关sdk。


解决思路是,隔离出基础设施层建设标准化的治理运行时,在标准之上建立体系。



在业务进程旁附属一个Proxy进程,SDK发出及接收的流量会被附属的Proxy进程拦截。一些标准化的服务治理能力,如:限流、路由等,会由Proxy和中心化的控制大脑完成,并由控制面对接所有治理子系统集成。


这种方案下SDK很轻薄、异构语言、异构治理体系就很容易打通,和业界的Mesh思想很像(Proxy类似数据面,中心化控制类似于控制面)。


如图:


基于此思想,美团的整体服务治理方向,向着Mesh解决方案做迁移。


美团的数据面采用Envoy二次开发,控制面以自研为主,结合SDK协同升级方案。


  • 多语言轻薄的SDK与Proxy通过UDS交互,主要考虑到相比于透明流量劫持,UDS性能与可运维性更好。


  • 控制面与Proxy通过双向流通信,控制面与治理生态的多个子系统交互,将计算处理后的数据与策略下发到Proxy执行,协同配合完成路由、限流等核心治理功能。


  • 控制面中有多个自研独立服务:Pilot承载治理能力,与Proxy交互、Dispatcher负责屏蔽异构子系统差异、集中式健康检查节点状态、Config Server管理Mesh体系内相关策略、监控巡检系统负责提升稳定性。


  • Meta Server实现了Mesh体系内的节点注册和寻址,通过管理控制面和数据面连接关系,实现按业务群的隔离与水平扩展能力。


由于美团之前的服务治理体系是基于中心化Proxy的平台调度,迁移到Sidecar的Mesh方案下,需要做到业务无感,同时要保证较好的稳定性。


主要做法:


  • 与现有基础设施及治理体系兼容,将Mesh与Octo深度打通,保障各子系统使用方式不变;在运行层面支持容器、虚拟机、物理机;打通运维体系,保障服务治理基础设施可管理、可检测。


  • 协议兼容,服务间调用是多对多的关系,为实现Mesh与非Mesh的互通,需要在协议层面做到完全透明;对于异常处理,需要在SDK和Proxy之间达成共识,保证兼容;无法在控制面和数据面实现的能力,在SDK中执行通过上下文传递给Proxy,保障功能完全对齐。


  • Mesh与非Mesh模式的无缝切换,基于UDS通信,需要业务升级一次SDK版本,可以默认不开启Mesh状态;在可视化平台通过开关操作,可以无成本实现从Mesh模式与非Mesh模式之间的切换,并实时生效。


为解决异构性问题,采用了标准化服务治理运行时的手段。


比如,在架构层面由控制面实现统一的子治理系统对接,屏蔽了注册中心、鉴权、限流等具体实现机制的异构性问题。


  • 将数据面+控制面定义为标准化的服务治理运行时,在标准运行时内打通所有治理能力。


  • 建设统一接入中心Dispatcher,由其屏蔽对接子系统的异构性差异,从而实现外部系统的差异性对Pilot透明。


  • 对于异构语言、异构体系使用增强的统一协议交互,实现互通。


如图:



以摩拜单车流量改造对比查看:



美团的服务规模还是比较庞大的,需要对Istio做一定的改造升级,才可以支持美团规模化Mesh使用的问题。


规模化Mesh的目标:具备支撑数万服务、百万节点体量的系统能力、支持水平扩展。


面对Istio需要解决的问题:


  • 美团的体量是Istio产品上限的千倍。

  • 美团场景下,有极高的实时性与准确性要求,配置下发或丢失将引发流量异常。



问题分析:


  • Istio的每个控制面实例由ETCD存储系统的全部数据,无法水平扩展。

  • 每个Proxy独立与ETCD交互,同一个服务的Proxy请求内容相同,独立的交互方式有大量的IO冗余。当Proxy批量发版或网络抖动时,瞬时风暴会压垮ETCD。

  • 每个节点都会探活其他节点,10w+节点规模集群,每个检测周期都是百亿次的探活,会引发网络风暴。


解决措施


横向数据分片


对于Istio控制面实例承载的全集群数据问题,对应的措施是通过横向数据分片实现扩展性支持:

  1. proxy启动时,向Meta Server系统请求需要连接的Pilot IP,Meta Server将相同服务的Proxy尽量落到同一控制面节点,这样数据大体是一样的,每个Pilot实例按需加载,而不需要承载所有数据。

  2. 控制面节点异常或发布更新时,其所管理的Proxy会规律的迁移,恢复后,会接管其所负责的Proxy,实现了会话粘滞,实现了逻辑数据分片。



通过链接管理,实现了按事业群、按服务灰度的平台能力,同时解决了Mesh水平扩展问题。


纵向分层订阅


对于Istio独立管理各Proxy链接的IO冗余问题,对应的措施是通过分层订阅减少冗余IO。


Proxy不直接与存储系统对接,而是在中间经过多步处理:

  1.  基于快照缓存+索引机制,减少zk watcher同步。相同服务的Proxy所关注的内容是相同的,不同服务的Proxy的关注也会存在大量的冗余。分层订阅模式下,proxy不与注册中心直接交互,而是通过中间层的快照缓存分层方式,确保每个Pilot实例中zk相同路径的监听,最多1个watcher,获取到watcher通知后,pilot根据内存快照缓存+索引,向所有关注者分发,降低了冗余。

  2. 治理能力层和会话层,实现了类似于IO多路复用的能力,提升了并发吞吐。



基于此设计,有效的应对了网络抖动或批量发版的瞬间风暴压力。


集中式健康检测


对于大规模集群内指数级膨胀的节点健康检测次数,对应措施是摒弃了P2P检测模式。


当Pilot感知到Proxy异常时,会立即通知中心化健康检测系统进行检测,而不是等待检测周期窗口的到来,可以有效提升业务调用的成功率。



对于交易属性的业务,Mesh接入更加谨慎。




在业务接入之前,基础架构平台建设了精细化运营体系:

  1. 基于SOA分级,将服务划分为非核心和核心服务,对于非核心服务进行线下环境的重点突破。

  2. 在运营平台,通过校验SDK版本、运行时环境等信息,筛选出满足条件的服务,服务负责同学在平台可以实现开关启关闭、节点选择、指定Mesh流量等工作,与内部IM联动,提升了数据运营效率。

  3. 服务接入Mesh后,运营层面有足够的详细数据,基于稳定性策略,可以在Mesh模式异常时,自动切换回非Mesh模式。


在UDS通信之外,还实现了增量聚合下发、序列化优化措施,实现了不必要的解包,提升了通信效率。


为提升整体Mesh架构的可用性,做了多级的流量保护:

  1.  当proxy不可用时,流量自动fallcack到非mesh模式;支持按节点的1/1000比例的流量灰度控制。

  2. 基于FD迁移+SDK配合协议交互,实现Proxy无损热重启的能力。

  3. 控制面配置下发错误比停发配置更加危险,针对于此建设了应用层面和系统层面的周期性巡检,实现了端到端应用视角的验证正确性,避免因变更引发的异常。

  4. 建设限流、熔断等对中心化控制面的服务保护,让系统柔性可用,当控制面全面异常时,可以通过缓存机制实现一段时间的可用。

浏览 85
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报