其他分享
首页 > 其他分享> > 复杂环境下落地Service Mesh的挑战与实践

复杂环境下落地Service Mesh的挑战与实践

作者:互联网

在私有云集群环境下建设 Service Mesh ,往往需要对现有技术架构做较大范围的改造,同时会面临诸如兼容困难、规模化支撑技术挑战大、推广困境多等一系列复杂性问题。本文会系统性地讲解在美团在落地 Service Mesh 过程中,我们面临的一些挑战及实践经验,希望能对大家有所启发或者帮助。

一、美团服务治理建设进展

1.1 服务治理发展史

首先讲一下 OCTO,此前美团技术团队博客也分享过很多相关的文章,它是美团标准化的服务治理基础设施,现应用于美团所有事业线。OCTO 的治理生态非常丰富,性能及易用性表现也很优异,可整体概括为 3 个特征:

  1. 属于公司级的标准化基础设施。技术栈高度统一,覆盖了公司 90% 以上的应用,日均调用量达数万亿次。

  2. 经历过较大规模的技术考验。覆盖数万个服务、数十万个节点。

  3. 治理能力丰富。协同周边治理生态,实现了 SET 化、链路级复杂路由、全链路压测、鉴权加密、限流熔断等治理能力。

回顾美团服务治理体系的发展史,历程整体上划分为四个阶段:

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

  2. 第二阶段重点提升性能及易用性。4 核 4GB 环境下使用 1KB 数据进行 echo 测试,QPS 从 2 万提升至接近 10 万,99 分位线 1ms;也建设了分布式链路追踪、分阶段耗时精细埋点等功能。

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

  4. 第四阶段是建设了跨地域的容灾及扩展能力。在每天数千万订单量级下实现了单元化,也实现了所有 PaaS 层组件及核心存储系统的打通。

1.2 服务治理体系的困境

目前,美团已具备了较完善的治理体系,但仍有较多的痛点及挑战。大的背景是公司业务蓬勃发展,业务愈发多元化,治理也愈发精细化,这带来了较多新的问题:

  1. 业务与中间件强耦合,制约彼此迭代。当中间件引入 Bug,可能成百上千、甚至数千个业务需要做配合升级,中间件的新特性也依赖业务升级后才能使用,成本很高。

  2. 中间件版本碎片化严重。发布出去的组件基本托管在业务侧,很难统一进行管控,这也频繁造成业务多类的问题。

  3. 异构体系融合难。新融入公司的技术体系往往与美团不兼容,治理体系打通的成本很高,难度也很大。此前,美团与大众点评打通治理,不包含业务迁移,就历时 1 年半的时间;近期,摩拜使用的 gRPC 框架也无法与系统进行通信,但打通迫在眉睫。

  4. 非 Java 语言治理体系能力弱,多个主流语言无官方 SDK。多元业务场景下,未来多语言也是个趋势,比如在机器学习领域,Python 语言不太可能被其他语言完全代替。

二、服务治理体系优化的思路与挑战

2.1 优化思路

总结来看,OCTO 在服务层实现了统一抽象来支撑业务发展,但它并未解决这层架构可以独立演进的问题。

1.2节中问题1与问题2的本质是“耦合”,问题3与问题4的本质是“缺乏标准服务治理运行时”。在理想的架构中,异构语言、异构治理体系可以共用统一的标准治理运行时,仅在业务使用的 SDK 部分有轻微差异。

所以,我们整体的优化思路分为三步:隔离解耦,在隔离出的基础设施层建设标准化治理运行时,标准之上建体系。

上述解决方案所对应的新架构模式下,各业务进程会附属一个 Proxy 进程,SDK 发出以及接收的流量均会被附属的 Proxy 拦截。像限流、路由等治理功能均由 Proxy 和中心化的控制大脑完成,并由控制面对接所有治理子系统集成。这种模式下 SDK 很轻薄,异构的语言、异构的治理体系就很容易互通,从而实现了物理解耦,业界将这种模式称为 Service Mesh(其中 Proxy 被称为数据面、中心化控制大脑被称为控制面)。

2.2 复杂性挑战

美团在实践中所面临的复杂性划主要包括以下4类:

  1. 兼容性:技术改造涉及范围较大,一方面需要通过保证现有通信方式及平台使用方式不变,从而来保障业务研发效率,另一方面也要解决运行载体多样性、运维体系兼容等问题。

  2. 异构性:第一是多语言互通问题;第二是打通治理体系内的众多治理子系统,像服务鉴权、注册中心等系统的存储及发布订阅机制都是不同的;第三是快速打通新融入公司的异构治理体系。

  3. 大规模支撑:出于性能方面考虑,开源 Istio 等产品不宜直接应用于大规模的生产环境,美团控制面需具备百万级链接下高吞吐、低延迟、高精确的系统能力。

  4. 重交易型业务容错性低:交易型业务场景下,业务对 Service Mesh 的性能、稳定性往往持怀疑态度;美团基础架构团队也强调在业务价值导向下,基于实际业务价值进行运营推广,而不是采用从上至下的偏政策性推广方式。

三、美团落地 Service Mesh 的解决方案

3.1 整体架构

美团采用数据面基于 Envoy 二次开发、控制面自研为主、SDK 协同升级的方案(内部项目名是 OCTO Mesh )。架构简介如下:

3.2 兼容性解决方案

兼容性的目标及特征用一句话来总结就是:业务接入无感知。为此,我们做了以下三件事情:

(1) 与现有基础设施及治理体系兼容

(2) 协议兼容

(3) Mesh 与非 Mesh 模式的无缝切换

3.3 异构性解决方案

异构性的目标及特征用一句话总结就是:标准化服务治理运行时。具体可拆分为3个子目标:

针对上述3个子目标,我们所采取的方案如下:

通过 Service Mesh 实现体系融合的前后对比如下:

通过上述方案,针对异构性方面取得了较好的效果:

3.4 规模化解决方案

3.4.1 开源 Istio 问题分析

规模化的目标及特征用一句话总结是:具备支撑数万服务、百万节点体量的系统能力,并支持水平扩展。挑战主要有3个:

经过对 Istio 架构进行深入分析,我们发现核心问题聚焦在以下3个瓶颈点:

3.4.2 措施一:横向数据分片

针对 Istio 控制面各实例承载全集群数据的问题,对应的措施是通过横向逻辑数据分片支持扩展性,具体方案设计如下:

通过管理链接关系实现了按事业群隔离、按服务灰度等平台能力,最关键的还是解决了 Mesh 体系水平扩展的问题。

3.4.3 措施二:纵向分层订阅

针对 Istio 独立管理各 Proxy 链接的 I/O 冗余问题,对应的措施是通过分层订阅减少冗余 I/O。Proxy 不直接与存储等系统对接,而是在中间经过一系列的处理,关键点有两个:

结果方面有效应对了网络抖动或批量发版的瞬间风暴压力,压测单 Pilot 实例可以承载 6 万以上的链接,时延 TP99 线 < 2.3ms、数据零丢失。

3.4.4 措施三:集中式健康检测

针对大规模集群内指数级膨胀的节点间健康监测次数,对应的措施是摒弃了 P2P 检测模式,我们参考并优化了 Google 的 Traffic Drector 中心化管理的健康检测模式。这种模式下检测次数大大减少,一个周期内 10 万节点集群的检测次数,从 100 亿次下降到 10 万次。

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

3.5 交易型场景困境下的解决方案

3.5.1 业务属性分析

美团内部业务线较多,包括外卖、配送、酒店、旅游、单车、团购等,其中绝大多数业务都带有交易属性,交易链路上一个流量异常就可能影响到订单。业务系统对新技术领域的探索往往比较慎重,期望在新技术充分验证后再启动试点,所以除小语种及亟待与公司打通的单车业务外,推广的难度是非常大的。此外,基础架构部秉承“以客户为中心”的原则,研发、运维、测试人员均是我们的“客户”,所以技术升级会重点从业务价值入手,并非简单依靠从上至下的政策推动力。

所以,我们对外的承诺是:通信足够快、系统足够稳定、接入足够平滑高效。

3.5.2 精细化运营体系建设

针对推广的困境,我们首先做了两件事情:

针对上述困境,我们进行深度思考后建立了一个精细化的运营体系:

运营体系具备 “接入过程无感”、“精细化流量粒度灰度”、“异常自动回滚恢复” 三个核心能力,在运营体系建设后推广运营较为顺利,目前线上接入的 600+ 服务、线下接入的 3500+ 服务中,90% 以上是依托运营平台接入 Mesh 的。

3.5.3 通信性能优化

在性能损耗优化这个方向,除使用 UDS 规避网络栈外,我们也通过增量聚合下发、序列化优化两个措施减少不必要的解包,提升了通信性能。

经过压测,去除非核心功能在 2 核 4G 环境用 1KB 数据做 echo 测试,QPS 在 34000 以上,一跳平均延迟 0.207ms,时延TP99 线 0.4ms 左右。

3.5.4 流量多级保护

美团落地 Service Mesh 在稳定性保障方面建设投入较多,目前尚无 Service Mesh 引发的故障,具体包含三个方面:

四、总结

本文系统性的介绍美团在 Service Mesh 落地进程中面临的“兼容性”、“异构性”、“规模化”、“交易属性业务容错性低”这四类复杂性挑战,针对上述挑战,我们也详细介绍了大规模私有云集群场景下的优化思考及实践方案。

基于上述实践,目前美团线上落地服务数超过 600,线下服务数超过 3500+,初步验证了模式的可行性。短期价值方面,我们支持了摩拜等异构治理体系的快速融合、多语言治理能力的统一;长期价值仍需在实践中继续探索与验证,但在标准化服务治理运行时并与业务解耦、中心化管控下更丰富的治理能力输出两个方面,是非常值得期待的。

标签:服务,Service,美团,业务,Mesh,Proxy,下落,治理
来源: https://blog.51cto.com/u_15197658/2769203