共计 6891 个字符，预计需要花费 18 分钟才能阅读完成。
导读：百度过来基于 rpc 框架的服务治理存在各种框架能力档次不齐、业务本身服务治理效率低、全局可观测性有余等诸多问题。本文介绍了百度外部落地 service mesh 的实际过程，以根底稳定性能力治理和流量调度治理能力为业务落地点，具体论述了外部落地的 service mesh 整体技术计划以及一系列关键技术，如性能的极致优化、扩大的高级策略、周边服务治理零碎等。
全文 6835 字，预计浏览工夫 13 分钟。
一、背景
百度大部分产品线已实现微服务的革新，数万个微服务对架构服务治理能力提出了更高的要求。传统的服务治理个别通过 rpc 框架去解决，多年以来百度外部也衍生出多种语言的 rpc 框架，比方 c ++、go、php 等等框架，根底服务治理能力和 rpc 框架耦合，rpc 框架能力参差不齐，给公司整体服务治理能力和效率晋升带来较多的痛点及挑战：
1. 高级架构能力无奈多语言、多框架复用
如某产品线近 2 年产生数次雪崩 case，底层依赖的 php、golang 等框架须要反复建设来定制动静熔断、动静超时等高级能力，而这些能力在其余 rpc 框架已反对；
如罕用架构降级、止损能力各个产品线反复建设，接口计划差别大，从运维层面，运维同学冀望根底的架构止损能力在不同产品线之间可能通用化，接口标准化，升高运维老本；
2. 架构容错能力治理周期长，根底能力覆盖度低
随着混沌工程全面落地，对架构能力有了更高要求。少数模块对单点异样，慢节点等异样不足根底容忍能力，推动每个模块独立修复，老本高，上线周期长。
如某产品线治理革新花了 2 个季度实现；举荐某类召回服务经常出现超时、重试配置等不合理的问题，集中管理调整老本比拟高。
3. 可观测性有余，是否有通用机制晋升产品线可观测性？
比方某举荐业务短少整体模块调用关系链和流量视图，线上故障靠人肉教训定位、新机房搭建周期长，效率低。
二、service mesh 解决什么问题？
为彻底解决以后业务服务治理的痛点和问题，咱们引入了 service mesh，基本思路解耦治理能力和框架，治理能力下沉到 sidecar。外部联结多个部门通过单干共建形式建设通用的 service mesh 架构，提供通用的根底稳定性能力和对立的流量管制接口。
咱们冀望 service mesh 在厂内业务落地解决什么问题？总结为两点：
1、根底稳定性能力的要害组件 – 为微服务提供通用的根底故障容错能力、根底故障检测能力、对立的干涉和管制接口；
2、流量治理的外围零碎 – 实现各产品线整体的连贯托管、全局流量的可观测、精密调度能力；
附 service mesh 定义：Linkerd CEO William Morgan 于 2016 年 9 月 29 日公开提出，service mesh 是用于解决服务间通信的基础设施层，用于在云原生利用简单的服务拓扑中实现牢靠的申请传递。在实践中，service mesh 通常是一组与利用一起部署，但对利用通明的轻量级网络代理。
三、技术挑战
咱们在落地 service mesh 理论过程中，面临以下几大挑战：
· 低侵入：百度大大小小有上百个产品线，模块数量级达到万级别，实例数达到百万级别，如何让业务在不改代码前提下无缝迁徙，低侵入接入是咱们在设计方案思考第一因素；
· 高性能：百度外围产品线在线服务对提早要求极高，比方举荐、搜寻等外围产品线，提早上涨几毫秒会间接影响用户的体验和公司支出，从业务角度不能承受接入 mesh 后带来的性能进化。因而咱们在落地过程中，投入很大精力来优化 mesh 的提早，升高接入 mesh 后的性能损耗；
· 异构零碎交融：首先咱们须要解决厂内多语言框架互通问题，其次须要对立接口和协定，买通厂内多个服务治理零碎，如服务发现、流量调度、故障止损等零碎；
· mesh 可靠性：在线业务对可靠性要求极高，要求咱们在落地过程中，充分考虑本身稳定性，防止出重大 case。
总结：咱们的需要是实现一套 低侵入、高性能、齐备的治理能力，可能解决业务理论问题 service mesh 架构。
四、整体架构
· 技术选型：咱们底层以开源 istio+envoy 组件为根底，基于厂内理论业务场景，适配厂内组件。抉择基于开源定制的次要起因是兼容社区，跟开源放弃标准协议，排汇社区的高级 feature 同时可能反哺到社区。
咱们外部落地的 mesh 整体架构如下，包含以下外围组件：
· Mesh 控制中心：
· 接入核心：sidecar 的注入，治理 sidecar 版本，对立上线入口；
· 配置核心：稳定性治理和流量治理入口，托管连贯、路由配置、通信等策略；
· 运维核心：mesh 的日常运维，如干涉去劫持操作；
· 控制面板：istio-pilot 组件，负责路由治理、通信策略等性能；
· 数据面板：envoy 组件，负责流量转发、负载平衡等性能；
· 依赖组件：交融厂内服务发现组件 naming service、外部各种 rpc 框架适配、监控零碎、底层 paas 反对；
· 周边治理生态：基于 mesh 对立治理接口衍生出的服务治理生态，如智能调参零碎、故障主动定位 & 止损零碎、故障治愈、混沌工程（基于 mesh 的精细化故障注入）。
接下来咱们从 接入形式、性能优化、稳定性治理、流量治理、周边零碎协同、稳定性保障等 关键技术来解析：
4.1 接入形式
社区采纳的 iptables 流量劫持计划，iptables 规定过多会导致性能问题，尤其在厂内数万个实例转发下受限 iptables 线性匹配规定，转发提早十分大，不能满足在线低提早的场景。
咱们的解决思路：基于本地 lookbackip 地址计划，envoy 买通外部服务发现组件，劫持服务发现申请，通过回传 lookback 地址通明劫持业务流量。同时本地 naming agent 定期探活 envoy，一旦 envoy 出现异常，主动回退到直连模式，防止 envoy 故障导致流量失落。
同时针对一些不走流量劫持的业务，咱们设计了 proxyless 计划，即通过 rpc 框架适配 istio 规范的 xds，接入 pilot 服务治理的通路，托管服务治理策略和参数散发失效。无论业务流量是否被劫持，都通过 mesh 标准化的干涉入口实现服务治理的对立管控和治理。目前 proxyless 计划已在外部 c ++ 等 rpc 框架实现适配，在搜寻、举荐等业务线落地。
总结：咱们通过基于服务发现流量劫持和 proxyless 两种通明迁徙的的接入计划，实现业务模块无需批改代码即可接入 mesh 的低侵入形式，升高业务接入 mesh 的老本。
4.2 性能极致优化
咱们在落地过程发现社区版本 envoy 提早、资源耗费较大，在一些大扇出简单场景下，流量劫持带来的提早上涨靠近 5ms，cpu 耗费占比 20% 以上，无奈满足厂内在线业务高吞吐、低提早场景。咱们剖析 evnoy 底层模型，实质起因是 envoy 是一个单过程多线程的 libevent 线程模型，一个 event-loop 只能应用一个核，一个回调卡住就会卡住整个线程，容易产生高延时，导致吞吐长尾控制能力比拟差。
咱们基于 envoy 扩大接口扩大 envoy 的网络模型 & 线程模型，引入 brpc 底层高性能的 bthread 协程模型。在咱们外部简称高性能 brpc-envoy 版本。同时咱们买通 pilot，实现原始 libevent 和 brpc-thread 在线切换，用户能够十分不便自助抉择开启高性能模型。_备注：brpc 百度外部 c ++ 高性能 rpc 开源框架，外部数几十个产品线再应用，实例数有数百万规模，已开源。_
测试下来后果，相比开源社区版本和 MOSN（蚂蚁自研已开源）等业界框架，CPU 升高 60%+，均匀提早升高 70%+，长尾提早均匀升高 75%+，性能大幅当先业界，彻底解决社区版 envoy 无奈满足大规模工业高性能场景的问题，为大规模落地 mesh 扫清阻碍。
同时咱们正在调研 ebpf、dpdk 等新技术，进一步升高提早和资源耗费。目前测试下来 ebpf 相比本地 lookbackip 转发性能有 20% 的晋升，dpdk 相比内核协定栈有 30% 的性能优化空间（在绑核条件下）。
4.3 稳定性治理
外部在线 & 离线服务大规模混部，线上混部环境简单，对模块的架构稳定性能力要求比拟高。咱们基于 mesh 提供通用的 故障容错能力、故障检测能力、对立的干涉和降级能力 来整体晋升产品线稳定性能力的 baseline：
4.3.1 部分故障容错能力：
为了晋升架构对日常机器故障的容错能力，咱们基于 envoy 扩大了高级稳定性容错策略，比方减少动静重试熔断策略，通过滑动窗口计算分位值耗时，动态控制重试比例，通过重试捞回申请同时也防止大量重试引发雪崩的危险。另外咱们引入反馈式的高级负载平衡策略，依据上游返回定制的错误码，降权 & 屏蔽故障实例，通过熔断爱护机制控制权值，防止失常实例被打挂。在咱们外部外围产品线上线后，大幅晋升模块在部分故障下的容错能力，架构韧性能力大大晋升。
（参考下图，某在线外围模块接入 mesh 后，可用性从之前 2 个 9 晋升到 4 个 9）
针对雪崩治理场景（咱们统计厂内外围产品线雪崩历史 case，90% 以上 case 都是雪崩治理能力缺失，比方重试风暴、超时倒挂、降级能力缺失导致），咱们基于 mesh 定制熔断能力的高级重试能力来克制重试风暴，提供动静超时机制来预防超时倒挂。在外围产品线的大范畴铺开后，笼罩近 2 年内雪崩 90%+ 故障场景，2020 年雪崩 case 比照 2019 年雪崩类 case 损失环比降落了 44%
4.3.2 部分故障检测能力：
过来故障检测依赖机器粒度的根底指标，粒度比拟粗，针对容器故障实例不足精密指标检测，无奈及时探测到故障实例，通常须要数小时才会检测到故障实例。咱们买通了下层故障自愈零碎，基于 envoy 扩大故障检测策略，提供通用、疾速间接的故障发现检测能力，内部故障自愈零碎通过 prometheus 接口采集故障实例，通过汇聚剖析，触发 paas 迁徙故障实例。对于已接入 mesh 的业务线，简直零老本代价下即可具备部分异样的疾速发现 & 定位能力，故障实例的检测时效性从原来数小时优化到分钟级。
4.3.3 对立的干涉和降级能力：
对于一些大规模故障，单靠架构本身容错解决不了，须要依赖稳定性预案去止损，比方典型的上游弱依赖摘除预案。过来依赖不同产品线和模块本身去建设降级能力，不同模块接口计划差别大，随着零碎一直迭代，降级能力可能呈现进化，运维老本和挑战比拟大。咱们联合 mesh 实现通用降级和干涉能力，如反对多协定场景下流量抛弃能力，实现对立的流量降级策略；通过对立的超时和重试干涉能力，实现秒级的干涉时效性。
通过落地 mesh 为多产品线提供对立的干涉和管制接口，为稳定性预案提供统一的操作接口，大大晋升了服务治理效率，产品线服务治理迭代周期从过来季度级缩短到月级。
如 20 年某业务线接入 mesh 两周实现 4 个方向 20+ 模块架构治理革新，而原来往往须要一个季度周期能力实现革新。
4.4 流量治理能力
· 流量可观测性：
过来构建产品线模块上下游调用链和根底黄金指标始终不足通用的解决方案，大多数都是基于 rpc 框架或者业务框架定制，模块调用链和黄金指标覆盖率低。比方某重要产品线端到端波及到 2000 多个模块，调用链关系十分复杂，具体流量的起源不够通明，重大影响运维效率。如机房搭建不晓得上下游的连贯关系，靠人肉梳理误差大，某产品线一次搭建周期将近 2 个月工夫。另外故障定位、容量治理等因为全局的可观测性有余，往往只能依赖教训定位，效率非常低下。
咱们整体思路以 mesh 为核心，联合周边 rpc 框架，构建全局 servicegraph 调用链。
· 一方面 通过 istio 外部 crd 形象表白出模块链路关系和链路属性，在 istio 下层自建 mesh 配置核心，屏蔽底层 crd 细节。以配置核心作为连贯托管的惟一入口，托管模块全链路的调用关系，新机房建设基于 servicegraph 疾速构建出新机房的拓扑，很大水平晋升机房搭建效率，缩短周期。
· 另一方面 同时联合 brpc 和 mesh，制订规范的黄金指标格局，建设对立的黄金指标数据仓库，反对上游的服务治理建设，比方容量治理剖析、故障定位、性能剖析、故障注入等。比方咱们正在落地的故障自感知、止损零碎基于 servicegraph 可自动化、疾速、精确实现线上故障的感知、止损。
· 流量精密调度：
厂内大部分产品线基于入口整体切流，始终不足对模块链路外部流量精密调度控制能力。咱们联合 mesh 的流量调度能力，买通厂内服务发现组件，整合一系列切流平台，对立流量调度入口到 mesh 控制中心。联合后面 servicegraph 提供的全局调用链，实现模块精密连贯关系的流量调度能力；另外咱们基于 mesh 实现模块实例粒度精密流量调度和流量复制能力，典型利用于模块的精密流量评估、线下压测、导流场景下。
4.5 周边生态协同
基于 mesh 提供对立的管制接口，衍生出周边服务治理零碎，典型场景如治理参数主动调参、故障主动止损、故障自愈等零碎。
· 主动调参零碎
服务治理参数依赖用户手工配置参数(超时比例、权重比例等)，齐全依赖人肉教训，频繁呈现配置不合理影响治理能力成果，同时线上环境差别比拟大，动态配置无奈适应线上简单环境变动。咱们设计出一套动静调参零碎，外围思路基于 mesh 的治理对立接口和联合线上指标实时反馈，实时调整治理参数。比方依据上游 CPU 利用率，动静调参拜访上游重试分位值比例；依据上游机器负载差异化，动静调参拜访上游权重。
在厂内外围产品线落地后，通过主动调参齐全代替人肉调参，实现服务治理参数自适应调整。
· 故障主动感知止损零碎
传统线上故障凭人工教训定位，产品线深度定制预案能力，强依赖有教训的工程师，新人上手老本高；并且预案止损操作散落在文档中，可维护性差，随着业务迭代可能生效或者逐渐进化，不可继续。
咱们基于 mesh 通用的干涉能力和对立管制接口，研发一套故障预案主动止损零碎，联合后面提到的 service graph 提供全局调用链和黄金指标，实现常见故障的主动感知、预案主动止损，升高故障止损的 mttr 工夫。同时买通混沌工程，定期端到端注入故障触发预案演练，防止预案能力进化。这套零碎目前典型利用在强弱依赖降级、精细化流量调度等预案场景，预计到年底，接入 mesh 的产品线大部分线上故障都能自动化解决。
· 对立协定，协同周边零碎
基于 mesh 配置核心提供规范的流量管制和服务治理接口（如流量降级接口），协同周边零碎生态，如主动调参、故障感知止损、故障自愈、流量调度。
基于开源 xds 协定，对立数据面协定，对接周边 rpc 框架，实现不同 rpc 框架可能对立管制。
4.6 本身稳定性保障
厂内业务比方搜寻、举荐等要害业务对稳定性要求极高，在线迁徙 mesh 好比”高速公路上换车轮“，必须保障对业务无损。因而稳定性建设是咱们在落地 mesh 过程重点关注点之一。
首先咱们通过多级兜底机制保障流量转发的可靠性。针对部分故障，如个别 envoy 实例配置、过程等异样，envoy 本身具备 fallback 机制，异样能够主动回退直连模式，无需人工染指。但一些大规模故障，比方 envoy 呈现大范畴故障，靠 envoy 本身机制曾经无奈保障（可能呈现劫持、非劫持模式来回稳定），咱们通过内部干涉平台一键下发转发黑名单，强制干涉 envoy 切到直连模式，全产品线止损时效性管制在 5 分钟以内；极其状况下，如 envoy 大范畴 hang 死，可能导致对外干涉接口生效，咱们筹备了兜底预案，联动 paas 批量强制杀掉 envoy 过程，回退到直连模式。
其次在服务治理配置公布方面，咱们外围思路管制故障隔离域，比方买通 mesh 配置核心，灰度管制配置公布的百分比；同时构建 mesh 接入一站式平台，梯度逐渐公布，管制 envoy 降级对业务的影响面。咱们引入 monitor 模块定期做端到端巡检，如配置一致性、envoy 节点服务异样、版本一致性等校验。
最初咱们定期通过混沌工程被动注入故障，比方模仿 envoy 异样、pilot 异样、配置核心异样等，进行极限异样 case 演练，防止本身稳定性架构能力进化。
五、总结
从 19 年年底开始立项，不到 2 年的时候，在外部数十个产品线已实现落地，其中一些外围产品线骨干模块已笼罩到 80% 以上，天级托管流量超过千亿。新接入模块简直零老本接入，即可具备根底稳定性治理和流量调度能力。咱们联合周边生态系统，构建一站式 mesh 接入平台，为各业务线提供低侵入、低成本、标准化的服务治理解决方案，系统性解决各个产品线的根底可用性问题，大幅升高治理迭代老本 & 周期，促成体系整体稳定性能力的晋升。
招聘信息
如果你对微服务感兴趣，请你分割我，咱们当面聊聊将来的 N 种可能性。无论你是后端，前端，大数据还是算法，这里有若干职位在等你，欢送投递简历，关注同名公众号百度 Geek 说，输出内推即可，咱们期待你的退出！
举荐浏览
|百度同学教你怎么成为复盘高手
|联邦计算在百度观星盘的实际
|百度爱番番与 Servicemesh 不得不说的故事
|一种基于实时分位数计算的零碎及办法
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注