全文约6200字，预计阅读时间15分钟

导读

服务网格（ Servicemesh ）于 2018 年夏天随着 Istio1.0 的正式发布席卷全球，国内各大公司也遍地开花，其所带来的理念逐步为各方所接受并风靡。爱番番基于自身的痛点和 ToB 行业的特点，携手公司基础架构，于 2020 年 8 月底正式启动了 Servicemesh 项目，仅用 3 个月就快速完成了 Java 业务应用的全切，成为百度第一个将商用生产系统完全基于原生 Kubernetes + Istio 运行的产品。

1. 缘起：沉没式治理

1. 多语言治理难。存在着 Java、Golang、Nodejs、Python 等语言，在服务治理上主要支撑 Java 的需求，其余语言的治理或自成一套，或基本缺失。其将带来很大的治理成本和系统风险。
2. 业务耦合。当前采用 Smart Client 的服务治理框架，推动迭代升级困难。服务治理的周期平均在三个月以上，带来极大的运维升级成本。
3. 能力缺失。当前采用的服务治理框架缺乏足够的治理手段，如限流熔断、混沌、金丝雀、服务分组、流量录制回放、动态配置等能力的支持。
4. 人肉配置。当前服务治理框架将治理粒度全部降到方法级，其直接导致过于大量（ 2k+ 方法）的人肉配置要求带来的事实上的不可配置。直接导致爱番番服务治理平台处于事实上的无人使用状态。也正因此出过一些严重的线上问题。

2. 抉择：下一代的服务治理体系

2.1 什么是服务网格

• 数据平面主要由一系列的智能代理（默认为 Envoy）组成，管理微服务之间的网络通信以及收集和报告所有 mesh 中的遥测数据。
• 控制平面负责管理和配置代理来路由流量。

  
  

2.2 服务网格的曲折前进

1. 腾讯云基于 Istio 推出了 TCM，支持进行集群托管或者自建，可对多地域流量管控；
2. 蚂蚁 Sofa-Mosn 另辟蹊径，以 Golang 语言重写 Mesh 并进行独立演化，在国内大放异彩；
3. 美团点评也正在大力推进 OCTO2.0 服务治理体系，进行基于 Envoy+ 自研控制面板的Mesh 转型；
4. 百度内部有 BMesh 和天合Mesh 两款 Mesh 产品；
5. 头条、快手正在进行对应的建设，网易轻舟进行了 Mesh化，陌陌构建了Java 版 Mesh；
6. Azure、AWS、Google Cloud 都推出了Mesh产品；
7. ......

1. Envoy（ Istio 默认使用了 Envoy ）已成为事实标准；
2. Istio 项目还在快速迭代演进并趋于生产稳定；
3. 全球主流云厂商和国内大量公司都已落地 Mesh；
4. 目前主流做法采用（二次开发）Envoy + 自研控制面板；
5. 业内正在尝试通过中间件下沉享有 Mesh 红利。

1. 从 ROI 来说，我们并不希望自己从 0-1 去自建 Mesh，我们希望集中更多资源投入业务迭代中，所以我们抱定「 满足 80% 的能力，剩余的 20% 可以妥协可以增强 」的思路来进行下一步的选择。
2. 从语言栈来说，由于 Mesh 本质是「 寄生 」在应用机器上的进程，所以资源控制本身尤其重要。因而现阶段选择 Java 语言来进行 Sidecar 的开发并不明智，也这是 Linkerd1.0 失败的主要原因。所以我们并不打算引入 Java 技术栈的 Mesh。
3. 从开源生态来说，Istio 经历几年的锤炼，虽然还有诸多不完美的地方，但其以强大的能力、巨头的背书、以及生态的活跃等方面来说，已经成为业内事实上的 Mesh 标准。所以我们希望基于 Istio 构建爱番番的 Mesh 体系。
4. 与百度基础架构的协作上，关于是否直接复用厂内的 Mesh 产品这一问题，我们与基础架构云原生的同学进行了多轮沟通，由于「 私有化 / 多云部署 」这一前提，爱番番本身希望尽量以不改变开源组件原有结构的方式进行轻量部署，如尽量不与厂内独有基础设施进行耦合、如按照完全原生的方式落地等。

2.3 ToB和Toc场景对Mesh核心诉求的差异性

• ToC场景：【性能】早于【可移植】考虑
• ToB场景：【可移植】早于【性能】考虑

3. 实践：平滑迁移与赋能业务

3.1 爱番番现状

3.2 平滑迁移

3.2.1 POC验证

3.2.2 迁移方案

1. 监控先行；
2. 业务方低感知；
3. 尽可能无损。

3.2.3 迁移难点

• 无法进行流量闭环假设。复杂的分布式拓扑中，迁移时候极难挑选出完全闭环的子拓扑进行先行迁移验证。而一旦在没有任何准备的情况下，将服务迁移上容器网络集群，这时候调用链中的某一环仍然留在主机网络集群上，则极容易引起线上事故。为了解决这个问题：

1. 通过 Skywalking 进行链路拓扑的观察，在迁移前期验证阶段时，尽量让流量不至过于分散；

2. 借助老注册中心和灰度名单，实现容器网络集群中的服务在访问非灰度应用的时候，可直连调回主机。通过这种方式，即可放心地进行服务迁移而无需关注是否进行流量闭环。

   
   

• 容器网络环境初期不稳定。在最开始迁移的初期，新集群偶尔会出现 Node、API Server等基础设施的不稳定，如果不进行任何干预和快速应对，则可能会导致严重的业务问题。为了解决这一问题，我们在多个环节进行了可用性的保障，包括：
1. 在基础设施层面，针对于 api server、etcd 等的抖动迅速止损和优化，并制定相应稳定性保障的 SOP；
2. 在网关入口层面，基于任意产品线、任意灰度比例进行灰度和回切操作；
3. 对于幂等的请求，提供失败时自动 fallback 的机制；
4. 对于失败的请求，提供自动熔断和恢复的能力；
5. 对于常见容易遗漏的定时任务和异步 MQ 消费者进程，进行标识后，一键回切时可进行自动缩容；
6. Mesh 容器集群里进行调用时，在调用方会进行连接/读取超时&重试的能力支持。
   
   
• 大规模的迁移较难对业务方屏蔽影响。基本涉及所有300+的业务应用的迁移，在高速迭代的业务场景之下，如何尽量降低业务方的成本，来实现快速的切换工作。针对这一问题，我们主要有三方面的举措：
  
1. SDK 默认尽量向前兼容。避免业务方进行大面积改造；
2. 在 CICD层面，屏蔽了新老集群的部署细节，并可以按产品线进行按批次灰度，用一套模板来管控两套集群配置，通过这些方式实现在CICD环节对业务方的完全透明；
3. 对于大规模迁移过程中发现的紧急问题，通过凤巢商业平台团队提供的launcher热加载机制，实现自动替换注入升级包来完成新功能的零侵入替换和快速验证。
   
   
• 对于 Istio 的引入带来的治理挑战。Istio 的引入，对于以 Smart Client 理念去构筑的原服务治理框架带来了颠覆性的改变，这块也会带来对应的适应和切换的成本，我们如下进行应对：
1. 理念转变：整体理念即服务治理理念和模型全面向Istio靠齐，逐步放弃全部基于 ServiceID（方法级）进行治理的思路；
2. 配置优化：引入Istio后，会在整个调用链路上加入两跳，针对这两跳，重新审视连接/读取超时重试、tcp backlogsize 等核心配置的关系，避免引起不必要的稳定性故障；
3. 入口收敛：Istio 引入后绝大部分的治理能力都通过 CRD 进行交互。我们将其治理入口暂时集成在 CD 系统上，禁止在kiali等其他地方进行核心配置变更，通过入口收敛来杜绝无序混乱的线上管理；
4. 妥协增强：Istio 本身功能非常强大，但部分能力还需要进一步增强，比如限流熔断、混沌工程等，于是我们也是在 tradeoff 之后进行取舍，对于部分功能做阉割妥协（如短暂放弃集群限流），对于部分功能做补齐（如引入 chaosmesh 增强混沌）。通过这种方式，达到能够快速享受 Istio 红利的目的。

3.2.4 迁移节奏

3.3 红利释放

3.3.1 全链路灰度发布

以一个 case 为例，爱番番的「全链路灰度发布」平台，基于istio通过同构底层「分组多维路由」的架构设计，在解决业内主流 flagger/helm 方案弊端的同时，完成了一套架构对 ABTest、金丝雀、容量评估、多路复用、Set化 在内的多个核心能力的支撑（部分能力研发进行中），对分组节点的全生命周期和流量进行了集中管控。针对于服务端场景，通过 FGR Operator 协调 k8s 以及 istio vs/dr 资源，并打通监控报警与 CICD。针对于端上场景，与对应的前端资源打包和获取的流程整合，进行用户级的打标和路由分发。这在传统解决方案中，需要付出大量的研发成本才能实现，而依托于 istio ，我们的整体资源投入得到了大幅的缩减。

3.3.2 爱番番对Istio的应用现状

Istio 具备丰富的治理能力，在服务连接、服务发现、服务保护、服务可观察等方面都有丰富的能力进行支撑。目前，爱番番对 Istio 的使用包括但不限于：

服务连接

1. 通讯：基于 Http1 的原协议长连；基于 K8s service 的服务发现；

2. 负载均衡：默认 RR，对于特殊的应用需求（如爱番番的数据库中间件 dataio ）采用一致性哈希；

3. 路由分组：金丝雀能力、测试环境多路复用、网关入口流量路由、abtest、开发机直连、灰度链路等。

服务保护

1. 授权：敏感接口调用权限管控（如获取用户手机号）；

2. 限流熔断：基于连接数的单机限流，基于慢调用/异常数/率的熔断；

3. 故障注入：东西流量的故障模拟，其余由 chaosmesh/chaosblade 支持。

服务运营

1. 服务管控：并未使用开源 kiali 管理端，而将对应的节点信息呈现在爱番番一站式平台上，并提供基础的一站式管理能力，如限流熔断、配置管控、服务迁移等；

2. APM：Istio 本身的 APM 中，Logging 基于 EFK架构 进行采集、Metrics 基于Prometheus 进行采集，通过 Grafana 进行一站式管理。业务应用的 APM 暂时维持现状，仍然采用无 Mesh 的 Skywalking + EFK + Prometheus + Grafana 进行管控。

3.4 爱番番切换Servicemesh带来的收益

4. 结篇：星辰大海

5. 作者介绍 

6. 往期精选

爱番番携手基础架构部全面解锁Kubernetes

爱番番反哺SkyWalking构建开源APM网格

领域驱动设计(DDD)在百度爱番番的实践