作者：汤长征、十眠
MSE 服务治理帮助我们系统以很低的成本无侵入的方式快速实现了全链路灰度能力，进一步提升了我们系统的稳定性，让我们新需求的迭代上线更加地安心。
—来电科技架构师 汤长征
来电科技自 2014 年起开始进入共享充电领域，定义并开创了行业，属于行业内最早的共享充电企业。主要业务覆盖充电宝自助租赁、定制商场导航机开发、广告展示设备及广告传播等服务。来电科技拥有业内立体化产品线，大中小机柜以及桌面型，目前全国超过 90% 的城市实现业务服务落地，注册用户超2亿人，实现全场景用户需求。
来电科技的业务场景丰富且系统众多，在技术架构上已完成容器化以及微服务化改造，微服务框架使用的是 Spring Cloud 与 Dubbo。随着近年来的高速发展，充电宝设备节点以及业务量都在快速增加。来电科技的整体应用架构也随着业务的高速发展，持续不断地进化。微服务治理是微服务化深入的必经之路，今天我来和大家分享一下来电科技在微服务化深入过程中探索的这一历程：缘起： 回顾来电科技当时的业务、架构现状和痛点。初见： 分享在技术选型之路上我们为什么选择 阿里云微服务引擎 MSE（Microservices Engine，全文以下简称 MSE） 。落地： 我们是怎么一步步落地、在短时间内低成本落地全链路灰度能力以及无损上下线等能力。
展望： MSE 与来电科技携手进一步深化微服务化之路。
缘起
来电科技内部技术趋势满足如下三点
- 微服务全面落地
- 全面接入 K8s
- 快速迭代，稳定发布的诉求
来电科技在 2019 年 10 月开始，服务开始全面进行微服务改造，容器化改造完成；在 20 年 12 月，此时来电科技已经全面微服务化，全面接入 K8s。
可以看到随着来电微服务化进程的逐渐深入，在这个微服务深化的过程中，我们逐步会面临一系列的挑战，总的而言，我们讲这些挑战分为三个大的层面，他们分别是效率，稳定和成本。我们进行微服务化，本身的使命是让业务的迭代更加高效，但当我们的微服务数量逐步增多，链路越来越长，如果不进行进一步的治理，那么引发的效率问题可能会大于微服务架构本身带来的架构红利。
因此在 2021 年 6 月，来电科技对微服务进行了可观测建设；21 年 9 月开始进行微服务治理能力构建。
全面容器化的优势
容器化总结来说有以下这些优势
- 部署方便，发布效率大大提升
- 弹性扩缩容
- 大大节约服务器成本
- 运维成本降低
简单讲一下全面容器化给来电科技系统带来的好处，首先就是应用部署变得非常方便，同时由于 K8s 的标准化使得 CI/CD 也变得简单，整体的发布效率大大提升；同时部署在 K8s 上的应用天然具备弹性扩缩容的能力，可以有效应对流量洪峰；同时由于上了 K8s 后，服务按需使用资源，相比原先按照峰值长期固定保有服务器，资源利用率相对比较低，现在可以大大节约服务器成本。相比传统集群运维非常繁琐，同时对运维人员技能要求也非常高：既要精通 lua /ansible 脚本等，又要懂云产品网络配置和监控运维。系统的运维成本非常高，阿里云容器服务 ACK 的标准化界面能很好解决高密部署以及系统运维的问题，极大降低成本。
稳定发布三板斧的诉求
日常发布中，我们常常会有如下一些错误的想法：
-
这次改动的内容比较小，而且上线要求比较急，就不需要测试直接发布上线好了
-
发布不需要走灰度流程，快速发布上线即可
-
灰度发布没有什么用，就是一个流程而已，发布完就直接发布线上，不用等待观察
-
虽然灰度发布很重要，但是灰度环境很难搭建，耗时耗力优先级并不高
这些想法都可能让我们进行一次错误的发布。
阿里巴巴内部有安全生产三板斧概念: 可灰度、可观测、可回滚。所有研发同学必须要掌握发布系统的灰度、观测和回滚功能如何使用。
互联网频繁发布是常态，对于来电科技来说也是如此，系统具备灰度、观测、回滚的能力是微服务系统必须具备的能力，灰度可以说是发布之前的必备流程，也是提升线上稳定性的关键因素。当服务有新版本要发布上线时，通过引流一小部分流量到新版本，可以及时发现程序问题，有效阻止大面积故障的发生。业界上已经有比较成熟的服务发布策略，比如蓝绿发布、A/B 测试以及金丝雀发布，这些发布策略主要专注于如何对单个服务进行发布。
来电科技的微服务数目众多，服务之间的依赖关系错综复杂，如果采用多套环境的硬隔离，会使得成本大幅升高，发布方式变得复杂。有时某个功能发版依赖多个服务同时升级上线。希望可以对这些服务的新版本同时进行小流量灰度验证，通过构建从 Ingress 网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证，这就是微服务治理中的全链路灰度的能力。
自研的挑战
来电科技有考虑过自研微服务治理，来电科技架构师 汤长征 同学也参与过 Dubbo 的开源社区，微服务治理研发对于来电科技来说并不是非常困难的事情，但是自研微服务治理组件还是存在以下必不可少的成本问题。
- 接入成本高
- 维护成本高
- 功能单一，不灵活，可扩展性低
- 可定位性变差
考虑到对生产应用进行微服务治理，微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以 SDK 的方式被业务代码所依赖，而这些逻辑的变更和升级，都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的接入与升级成本。同时需要对开源的服务框架做治理功能的研发，就意味着需要出人力对微服务治理的组件进行管理与运维，同时自建会使得功能非常贴近业务，也意味着功能将会做得比较薄比较单一，未来的可扩展性就显得比较弱。同时全链路灰度的实现技术细节也是非常之多，动态路由，节点打标，流量打标，分布式链路追踪，技术的实现成本高。由于 Dubbo、Spring Cloud 等服务框架本身的复杂性，同时随着微服务数量逐步增多，链路越来越长，相关的微服务治理问题的定位与解决也成了让人头疼的问题，如果有 Spring Cloud Alibaba、Dubbo 等专业的团队支持，微服务化深入也会变得更加从容。
初见
第一次接触MSE服务治理这块产品，就有许多的点命中我们的诉求，以下几点对我们微服务治理改造来说都是很吸引的点
- 无侵入
MSE 微服务治理能力基于Java Agent字节码增强的技术实现，无缝支持市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，用户不用改一行代码就可以使用。只需开启 MSE 微服务治理专业版，在线配置，实时生效。
- 接入简单
只需在阿里云容器的应用市场安装 mse-pilot，然后在 MSE 控制台开启命名空间级别的服务治理，重启应用即可接入，当然卸载服务治理也是非常容易的，只需在控制台关闭服务治理，卸载 mse-pilot 即可，不需要改变业务的现有架构，随时可上可下，没有绑定。
- 功能强大，持续发展
从开发态、测试态到运行态全生命周期的服务治理覆盖，使得研发同学可更加专注于业务本身。
MSE 微服务治理还提供了以下解决方案，解决微服务治理难点，快速提升企业的微服务治理能力。稳定性领域：线上故障紧急诊断排查与恢复、线上发布稳定性解决方案、微服务全链路灰度解决方案。降本增效领域：日常测试环境降本隔离解决方案、微服务无缝迁移上云解决方案、微服务开发测试提效解决方案。
- 可视化
MSE 服务治理专业版提供了微服务治理流量的可视化视图
对于灰度流量灰没灰到，灰了多少，配完路由规则后流量实时生效，做到一眼可见，心中有数。
同时对于无损上下线的场景，MSE 提供端到端全生命周期的防护，一眼可以看出流量有无损失，损失在什么部分。
- 拥抱云原生
进入云原生体系之后，以 K8s 为主的云原生体系强调集群之间的灵活调度型，以 POD 为单位任意的调度资源，在被调度后 POD 的 IP 也将相应的发生变化，传统的服务治理体系，通常以 IP 为维度进行治理策略的配置，MSE 使用更加云原生的方式使用标签为维度进行微服务治理策略的配置。
同时在 K8s 环境下与 K8s 的体系深度集成，推出多种完整解决方案，无损上下线使得应用在弹性伸缩的过程中保持流量无损，通过 Jenkins 构建 CI/CD 实现在 K8s 环境下的金丝雀发布，基于 Ingress 实现全链路灰度等。
当时 MSE 的一些局限
当然在 21 年 9 月刚接触 MSE 微服务治理的过程中发现 MSE 为服务治理的全链路能力还是存在一些局限性的，首先就是只支持微服务网关 Spring Cloud Gateway 与 Zuul 以及云网关，当时并不能支持自建的 Nginx 网关，同时在 Dubbo 的场景下只支持按照接口参数维度的路由，对于运维同学来说还需要了解业务接口的实现，过于精细化控制，上生产的成本过高；同时全链路灰度的入口仅仅支持 Http 网关或者应用作为灰度流量的入口，并不能支持 TCP 网关作为流量的入口。
落地
我们与来电科技的架构师深入了解后，对用户的灰度场景进行了进一步的抽象与总结，只有深入到业务中去才能更加了解客户的需求。我们总结出如下三个场景
MSE 全链路灰度场景
场景一：对经过机器的流量进行自动染色，实现全链路灰度
-
进入带 tag 的节点后续调用优先选择带有相同 tag 的节点，即对经过 tag 节点的流量进行"染色"
-
有 tag 的调用链路上找不到相同 tag 的节点，则 fallback 到无 tag 的节点
-
有 tag 的调用链路经过无 tag 的节点，如果链路后续调用有 tag 的节点，则恢复 tag 调用的模式
场景二：通过给流量带上特定的 header 实现全链路灰度
客户端通过在请求中增加制定环境的标识，接入层根基表示进行转发至表示对应环境的网关，对应环境的网关通过隔离插件调用标识对应的项目隔离环境，请求在业务项目隔离环境中闭环。
场景三：通过自定义路由规则来进行全链路灰度
通过在灰度请求中增加指定的 header，且整条调用链路会将该 header 透传下去，只需在对应的应用配置该 header 相关的路由规则，带指定 header 的灰度请求进入灰度机器，即可按需实现全链路流量灰度。
我们考虑到场景一其实就能完美满足来电科技全链路灰度的场景，同时它也是绝大部分云上客户的诉求，场景二和三可以作为更加高阶的玩法。
由于对经过应用的流量打标染色并进行全链路灰度，所以我们支持了任意的流量入口，也支持 Ingress、自建网关的灰度，在支持应用级别的灰度的同时兼容自定义的路由，更加灵活的方式满足了来电科技全链路灰度的场景。
来电全链路灰度落地方案
来电的业务架构如下，最上层是移动端等用户界面，自建的 Nginx 网关作为接入层，服务层就是各种服务，使用的是 Spring Cloud 与 Dubbo 作为服务框架。
来电科技全链路灰度落地的架构如下：
在 Nginx 层配置流量分流的配置，10% 的流量进入灰度环境，90% 的流量进入未打标即线上正式环境，然后经过灰度环境的流量会自动被 MSE 染上对应环境的颜色，从而进行全链路的灰度路由，保证流量在灰度环境中闭环，如果没有灰度环境的机器，比如支付中心只有线上的机器，那么流量会走线上环境，当我们数据中心又存在灰度环境的机器，那么灰度流量还会重新回到数据中心的灰度环境中。
MSE 服务预热能力
当我们在白天高峰期做发布，通常都会导致业务流量出现损失，我们的研发人员不得不选择在晚上业务低峰期做变更，这大大降低了研发人员的幸福指数，因为他们不得不面临熬夜加班的困境。如果能在白天大流量高峰期也能进行流量无损的变更，那么这对于研发人员来说将是大大提升研发效率的事情。
来电科技也遇到类似的问题，当业务流量过大的场景下，进行应用发布，系统服务刚启动阶段，应用由于存在冷启动的过程，此时的应用容量往往会比正常情况下低，但是线上的流量是无法区分当前的服务是否是刚启动的，依旧会有大流量持续涌入，此时就会导致系统过载而崩溃，出现流量损失。如果我们的微服务应用具备服务预热的能力，使得流量按照一定的曲线进行缓慢增长，从而保证服务进行充分的预热，即使是在高并发大流量场景中，保护应用在安全启动。
MSE 提供的一种基于 Agent 的无侵入预热微服务应用的方法能有效让用户在不修改任何代码的情况下即可为应用提供服务预热能力。
未来
MSE 服务治理专业版以无侵入的方式提供了全链路灰度、离群实例摘除、金丝雀发布、微服务治理流量可观测等核心能力，以更经济的方式、更高效的路径帮助来电科技在云上快速构建起完整微服务治理体系，有效提升线上稳定性，保证服务 99.9% 的可用率。
随着来电科技微服务化的深入，除了全链路灰度、无损上下线还有更多的场景逐渐出现，微服务全生命周期的治理将覆盖从发布、运行、故障排查、故障恢复以及全链路流量的治理，MSE 微服务治理将携手帮助来电科技持续提升微服务研发效能与服务的高可用率。
点击此处，查看更多 MSE 相关信息！