共计 7565 个字符，预计需要花费 19 分钟才能阅读完成。
导读 ：服务网格（Servicemesh）于 2018 年夏天随着 Istio1.0 的正式公布席卷寰球，国内各大公司也遍地开花，其所带来的理念逐渐为各方所承受并风靡。爱番番基于本身的痛点和 ToB 行业的特点，携手公司基础架构，于 2020 年 8 月底正式启动了 Servicemesh 我的项目，仅用 3 个月就疾速实现了 Java 业务利用的全切，成为百度第一个将商用生产零碎齐全基于原生 Kubernetes + Istio 运行的产品。
全文 6492 字，预计浏览工夫 12 分钟。
一、缘起：沉迷式治理
爱番番作为一站式智能营销和销售的加速器，旨在助力企业实现业务增长。在沟通、营销、销售、洞察等畛域继续发力，在 ToB SaaS 行业中面临着强烈的竞争，这就意味着在技术上对系统稳定性和研发人效有着十分高的要求。而回头来看，当下爱番番在业务上面临着诸多挑战：
1. 多语言治理难。 存在着 Java、Golang、Nodejs、Python 等语言，在服务治理上次要撑持 Java 的需要，其余语言的治理或自成一套，或根本缺失。其将带来很大的治理老本和零碎危险。
2. 业务耦合。 以后采纳 Smart Client 的服务治理框架，推动迭代降级艰难。服务治理的周期均匀在三个月以上，带来极大的运维降级老本。
3. 能力缺失。 以后采纳的服务治理框架不足足够的治理伎俩，如限流熔断、混沌、金丝雀、服务分组、流量录制回放、动静配置等能力的反对。
4. 人肉配置。 以后服务治理框架将治理粒度全副降到办法级，其间接导致过于大量（2k+ 办法）的人肉配置要求带来的事实上的不可配置。间接导致爱番番服务治理平台处于事实上的无人应用状态。也正因而出过一些重大的线上问题。
因此服务治理的现状即：治理边际老本无奈降落，反而呈指数回升趋势，治理因为老本过高只能基于问题驱动进行。这也是业内很多公司服务治理的现状。最终在效力、稳定性、能力三方面，都面临着很大的挑战。同时，因为居高不下的治理老本，咱们业务上要进行「多云 / 私有化部署」的售卖指标看起来将会遥遥无期。
笔者称这种治理为： 沉没式治理。看着永远在治理，其实永远在沉没。
二、抉择：下一代的服务治理体系
为了解决以上问题，扭转沉没式治理的窘境，咱们开展了一次艰巨而不得不进行的抉择。是否可能有方法，既可解决 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.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 构建的稳定性保障体系更是让爱番番整体稳定性失去了飞跃式的晋升。这仅是当初就能带来的收益，而其将来的收益远不止此。
四、结篇：星辰大海
当下，着眼于求实的角度，爱番番的服务治理依然面临着不小的挑战须要去一一攻克，以最大化施展出 Istio 的外围红利。另一边，咱们其实并不满足于将 Servicemesh 定义为南北东西向流量的管控上，面对效力难题，Servicemesh 的红利其实可能更大的开释，解决更大范畴的痛点，沉没式的治理不仅存在于分布式服务框架中，也会长期存在于所有的中间件里。咱们也关注到业内包含 Istio 本人自身也有一些对应的摸索，咱们也深信这在将来必将成为「多语言微服务架构」背景下的支流趋势，爱番番也基于本身痛点开始主导 apm mesh — Apache Skywalking Satellite 的孵化并胜利 Release。咱们更心愿爱番番的 Servicemesh 体系，可能真正意义上成为 「下一代的中间件治理外围」。
置信这会在不久的将来和公司其余部门的携手单干下达成，彻底辞别沉没式治理，减速交付客户价值点。
本期作者 | 橙子，百度爱番番业务部首席架构师，腾讯云最具价值专家，QCon 出品人，ArchSummit 明星讲师，Apache Commiter，历任多家公司平台 & 基础架构 & 运维负责人。
招聘信息
无论你是后端，前端，大数据还是算法，这里有若干职位在等你，欢送投递简历，关注同名公众号百度 Geek 说，输出内推即可，爱番番业务部期待你的退出！
浏览原文
百度爱番番与 Servicemesh 不得不说的故事
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注