导读：服务网格（ Servicemesh ）于 2018 年夏天随着 Istio1.0 的正式发布席卷全球，国内各大公司也遍地开花，其所带来的理念逐步为各方所接受并风靡。爱番番基于自身的痛点和 ToB 行业的特色，携手公司基础架构，于 2020 年 8 月底正式启动了 Servicemesh 项目，仅用 3 个月就快速完成了 Java 业务应用的全切，成为百度第一个将商用生产系统彻底基于原生 Kubernetes + Istio 运行的产品。前端
全文6492字，预计阅读时间12分钟。node
1、缘起：沉浸式治理
爱番番做为一站式智能营销和销售的加速器，旨在助力企业实现业务增加。在沟通、营销、销售、洞察等领域持续发力，在 ToB SaaS 行业中面临着激烈的竞争，这就意味着在技术上对系统稳定性和研发人效有着很是高的要求。而回头来看，当下爱番番在业务上面临着诸多挑战：算法
1.多语言治理难。存在着 Java、Golang、Nodejs、Python 等语言，在服务治理上主要支撑 Java 的需求，其他语言的治理或自成一套，或基本缺失。其将带来很大的治理成本和系统风险。数据库
2.业务耦合。当前采用 Smart Client 的服务治理框架，推进迭代升级困难。服务治理的周期平均在三个月以上，带来极大的运维升级成本。后端
3.能力缺失。当前采用的服务治理框架缺少足够的治理手段，如限流熔断、混沌、金丝雀、服务分组、流量录制回放、动态配置等能力的支持。api
4.人肉配置。当前服务治理框架将治理粒度所有降到方法级，其直接致使过于大量（ 2k+ 方法）的人肉配置要求带来的事实上的不可配置。直接致使爱番番服务治理平台处于事实上的无人使用状态。也正所以出过一些严重的线上问题。网络
于是服务治理的现状即：治理边际成本没法降低，反而呈指数上升趋势，治理因为成本太高只能基于问题驱动进行。这也是业内不少公司服务治理的现状。最终在效能、稳定性、能力三方面，都面临着很大的挑战。同时，因为居高不下的治理成本，咱们业务上要进行「 多云/私有化部署 」的售卖目标看起来将会遥遥无期。架构
笔者称这种治理为：沉没式治理。看着永远在治理，其实永远在沉没。负载均衡
2、抉择：下一代的服务治理体系
为了解决以上问题，扭转沉没式治理的困境，咱们展开了一次艰难而不得不进行的选择。是否可以有办法，既可解决 Smart Client 带来的多语言&业务耦合的难题，又能够具有功能丰富而治理粒度适宜的服务治理能力？并且考虑到有限的资源，可以以拿来主义的务实态度去进行问题的解决？框架
通过层层筛选和论述，摆在咱们眼前的答案逐渐清晰了起来：服务网格（Servicemesh）。咱们选择了目前的事实上的云原生标准服务网格设施：Istio。
2.1 什么是服务网格
服务网格（ Servicemesh，如下简称 Mesh ）概念于 2017 年春正式提出，并与2018年夏随着Google、IBM、Lyft 共建的 Istio1.0 的正式发布席卷全球。其出现主要在于解决 Smart Client 带来的一大难题 —— 「 如何解决服务治理与业务代码强耦合以及跨语言场景治理效率低下 」的问题。Mesh 给出的解决方案即：倡导将服务治理能力进行就近下沉，统一由 Sidecar 进行接管南北东西流量。这样最直接的好处便可以实现解耦，应用自身 “黑盒化”，总体服务治理进一步实现标准化，达到运营效率提高。在此之上，快速进行各类服务治理能力的加强，“一处开发，到处具有” ，完全解放生产力，以下图所示：
Istio 从逻辑上能够分为数据平面和控制平面，以下图：
-
数据平面主要由一系列的智能代理（默认为 Envoy）组成，管理微服务之间的网络通讯以及收集和报告全部 mesh 中的遥测数据。
-
控制平面负责管理和配置代理来路由流量。
2.2 服务网格的曲折前进
服务网格是一个新的概念，但自己并非一个新奇的架构设计，早在十多年前，Airbnb 就已经在其治理框架 Smartstack 中进行了实践，携程的 OSP ，以及充斥在各类云（mesos/marathon、k8s）里面的服务治理解决方案都早已经是相似的 Local Agent 架构。但此时，业内并未造成统一的标准，而其运维的复杂度也让诸多人望而却步。而随着 k8s 从新定义了基础设施，服务网格则应运而生从新定义了 Local Agent。
随着服务网格的大放异彩，对应的问题也随之而来。很多人对于 Mesh 理念延伸出的问题如性能、稳定性和资源开销表现出不一样程度的担心和质疑，其也直接致使了最具盛名的 Linkerd 的折戟，以及 Istio 架构上的曲折前进。Istio在经历了控制平面性能漫长的质疑期后，终于不破不立移除了 Mixer，引入了 WASM 机制在数据面上进行插件化能力加强。这是很艰难而勇敢的一步，但也一样会面临新的风险。
时至今日，是否要用 Mesh，何时使用 Mesh，如何用好 Mesh，Mesh 的定位和将来仍然为你们所津津乐道。这也正是其的魅力所在。而从总体上看，Istio 开源社区表现出了积极开放的心态，咱们有理由相信，Istio 在成为服务网格的事实标准以后，可以不断释放更大能量。
纵观目前业内 Mesh 的落地状况：
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 产品这一问题，咱们与基础架构云原生的同窗进行了多轮沟通，因为「 私有化 / 多云部署 」这一前提，爱番番自己但愿尽可能以不改变开源组件原有结构的方式进行轻量部署，如尽可能不与厂内独有基础设施进行耦合、如按照彻底原生的方式落地等。
因而爱番番和基础架构双方商定最终方案为：暂时不直接采用基础架构的 Mesh，而改由基础架构为咱们运维 k8s 集群以及搭建 calico 网络，并采用百度天合产品进行集群的管控。爱番番在此基础上选择 Istio1.7 原生组件进行落地。
2.3 ToB和Toc场景对Mesh核心诉求的差别性
在 ToC 场景，性能每每会被高优考虑，Mesh 目前的性能（RT & OPS）并不出众，官方方案会带来几毫秒~十毫秒不等的延时。业内自研/二次开发方案作得较好的约在 0.5~2ms 之间不等。在 toc 高流量场景下，Mesh 的落地会有必定的阻碍。在性能问题解决以后，才可能会去考虑是否是能很好迁移之类的问题。
而在 ToB SaaS 场景，核心点即【可移植】，可以很好地支撑私有化、多云部署，产品须要具有良好的可迁移性和可维护性。相比之下，Mesh绝对的性能要求在中前期并非须要最高优考量的点。而在中后期，随着中间件能力的下沉，更高的性能要求才会逐步提上议程。
即两者差别性：
-
ToC场景：【性能】早于【可移植】考虑
-
ToB场景：【可移植】早于【性能】考虑
而爱番番，则是典型的 ToB 场景。Mesh 在作开箱即用上，可以很好地起到做用。
3、实践：平滑迁移与赋能业务
3.1 爱番番现状
爱番番目前拥有华北、华南、华东3个 IDC，300+ 的 k8s node，300+ 的应用，3k+ 的服务点，8k+ 的pod。日均 10+ 亿pv。主业务产品大多部署在华东集群上，于是本次迁移主要针对华东集群。
3.2 平滑迁移
3.2.1 POC验证
咱们选择了 Istio1.7 版本，以爱番番的实际使用场景做为基准进行 POC 的性能测试后，发现单机性能暂时能够知足爱番番当前需求，在单机 100 QPS 左右，引入 Istio 的性能损耗在 1%如下。而且基于 Istio 的核心能力进行了验证。
3.2.2 迁移方案
迁移的大原则有以下几个：
1.监控先行；
2.业务方低感知；
3.尽量无损。
基于大原则，产出的迁移方案总体架构以下：
整体方案简述：以 calico 为网络设施构建一套新的 Mesh 容器网络集群，以入口网关进行灰度。两个集群之间采用 Istio-Gateway 进行通讯，并在多环节进行容错处理。以 Istio 做为服务治理的核心重构基础设施。整个过程当中，对于灰度迁移过程，以及新集群的表现进行可视化观察。总体迁移过程经过 CICD 以及 SDK 两个层面来最大化实现对业务方的细节屏蔽。
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 迁移节奏
Mesh 项目于20年8月底正式启动，9月初完成 POC 验证，9月底完成 MVP 交付，并切换爱番番 17% 的应用，在10月以后，进行逐步扩量，并不断加强新集群稳定性，同时开始释放 Istio能力，最终在20年11月底完成华东主集群业务应用的全量切换。总体投入5人力，仅历时3个月完成从验证到切换的过程，成为百度第一个将商用生产系统彻底基于原生 Kubernetes+Istio运行的产品。
3.3 红利释放
在完成 istio 的主体切换后，咱们并无停下脚步，而是紧接着开始进行了业务上的赋能以最大化发挥出 mesh 的价值点。咱们基于 mesh 这一标准化的底座，交付了近 20个 功能点，帮助咱们的业务实现了效能、稳定性、功能、成本上的全面提高。
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带来的收益
经过切换 Mesh，标志着爱番番云原生又一核内心程碑的达成，爱番番对自身业务的服务治理进行了底层解构并初步重塑，初步改变了沉没式治理的现状。以前的多语言治理难、业务耦合、能力缺失、人肉配置困境获得较大的缓解，在功能上，快速补充了超过 10+ 个以前缺失的核心治理能力，在效能上，将服务治理的生命周期从数月直线拉低到分钟级，CI pipeline 时间节省 20%，解放了业务方和架构方的效能，测试环境多路复用能力更是能够颠覆现有开发模式，实现并行开发测试，并同时节省 30%以上 的测试联调等待时间；在稳定性上，提供了限流熔断和混沌工程的能力，为业务提供了坚实的自我保护手段。经过金丝雀发布，更是能够实现上线流量的无损的同时，让研发人员告别深夜发布的局面；依托于 istio 构建的稳定性保障体系更是让爱番番总体稳定性获得了飞跃式的提高。这仅是如今就能带来的收益，而其将来的收益远不止此。
4、结篇：星辰大海
当下，着眼于务实的角度，爱番番的服务治理仍然面临着不小的挑战须要去一一攻克，以最大化发挥出 Istio 的核心红利。另外一边，咱们其实并不知足于将 Servicemesh 定义为南北东西向流量的管控上，面对效能难题，Servicemesh 的红利其实可以更大的释放，解决更大范围的痛点，沉没式的治理不只存在于分布式服务框架中，也会长期存在于全部的中间件里。咱们也关注到业内包括 Istio 本身自己也有一些对应的探索，咱们也坚信这在将来必将成为「多语言微服务架构」背景下的主流趋势，爱番番也基于自身痛点开始主导 apm mesh — Apache Skywalking Satellite 的孵化并成功 Release。咱们更但愿爱番番的 Servicemesh 体系，可以真正意义上成为「下一代的中间件治理核心」。相信这会在不久的将来和公司其余部门的携手合做下达成，完全告别沉没式治理，加速交付客户价值点。
本期做者 | 橙子，百度爱番番业务部首席架构师，腾讯云最具价值专家，QCon出品人，ArchSummit明星讲师， Apache Commiter，历任多家公司平台&基础架构&运维负责人。
招聘信息
不管你是后端，前端 ，大数据仍是算法，这里有若干职位在等你，欢迎投递简历，关注同名公众号百度Geek说，输入内推便可，爱番番业务部期待你的加入！
阅读原文
---------- END ----------
百度Geek说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢迎各位同窗关注