作者：汤长征、十眠
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 相干信息！