微服务治理正当时
——十眠
云原生应用平台
一、微服务治理的重要性与挑战
随着微服务技术的发展，微服务的概念早已深入人心，越来越多的企业开始选择微服务架构来开发自己的业务应用，因为微服务架构可以让业务迭代更高效。
依照微服务架构将业务进行解耦的过程中，微服务应用的数量会逐步增多，调用的链路也会越来越长，服务与服务之间的调用和依赖关系也变得愈加复杂。
在此过程中，如果不对微服务进行适当的治理，由于微服务间复杂的依赖关系，会导致很小的技术问题被放大，从而引发效率、稳定性等问题，最终导致的问题可能会远大于微服务架构本身带来的架构红利。
可见，微服务架构是一把双刃剑。
随着微服务架构的复杂化，大规模之下，再小的问题都会牵一发而动全身。因此，企业进行微服务化到一定程度之后，微服务治理是企业必然要面对的阶段，它是微服务发展的必经之路。架构越复杂，治理越是刚需。
原生微服务下，微服务治理需要面临以下三个方面的挑战：
第一，效率方面。
开发阶段需要考虑的是，应用上云之后，如何让本地的应用可以更好地部署到云上，对业务进行联调，包括流量需要能够轻松地从云上导到本地，便于做开发调试，或从本地很方便地调用到云上的微服务进行联调。通常微服务无法在本地完整地部署一整套系统，所以本地开发的应用只是微服务链路的一小部分。
微服务上云之后，与原先在自身机房进行开发联调相比，会变得更困难。同时在线上运维方面，通常需要频繁地对微服务进行变更，而这些变更可能会引发一系列问题。因此在白天的高峰期时往往无法做发布，因为发布过程中会有一些业务流量出现损失，使得研发人员不得不选择在半夜业务的低峰期进行变更。
此外，微服务框架通常会引入服务治理的逻辑，这些逻辑通常以 SDK 的方式被业务代码所依赖，因此涉及到此类逻辑的变更与升级都需要通过修改代码来实现，会造成非常大的升级成本。
进入到云原生体系后，以 QPS 为主的云原生体系强调的是集群间的灵活调度，以 POD 为单位任意调度资源。被调度后 POD IP 会发生改变，因此，传统的服务治理面对 IP 进行的治理规则都会失效。所以，如何让服务治理体系更适应云原生体系，也是需要解决的问题。
第二，稳定性方面，稳定性大于一切。
高可用问题是业务必须面对的。业务通常会在多个可用区进行部署，甚至需要考虑异地多活。
同时，微服务之间的调用更需要安全可信。层出不穷的安全漏洞在一定程度上也反映了当前上云阶段在安全方面存在的问题。此外，安全漏洞出现之后，中间件 SDK 的升级也会变得异常困难。即使数据库层面做了非常多权限管控，但由于微服务被授予数据访问较高的权限，微服务的调用被恶意攻击，也可能会导致敏感的数据被泄露。
第三，成本方面。
业务面临高速增长的流量，迫切需要快速弹性来补充更多的资源以承载业务的高峰；业务进入低谷时，又希望能进行缩容来节省资源。因此云产品提供快速灵活的弹性机制是微服务上云之后急需的一项能力。
微服务迁移上云的成本也非常高。迁移到某个云上以后发现效果不符合预期，选择下云，也会产生极大的成本。
而如果选择自研微服务，考虑到对生产的应用进行微服务治理，微服务框架通常会引入服务治理的逻辑，会以 SDK 的方式被业务代码所依赖，逻辑的变更与升级都需要通过修改代码的方式来实现，会造成非常大的接入和升级成本。
此外，对微服务治理功能的研发意味着需要付出人力对其组件进行管理运维，同时自建的方式也会使得功能非常贴近业务，也意味着功能比较单一，未来的可扩展性较弱。
与此同时，全链路灰度、无损上下线涉及的技术细节非常多。以全链路灰度为例，涉及到动态路由、节点打标、流量打标、分布式链路追踪等，技术实现成本非常高。
基于Dubbo、Spring Cloud 等服务框架本身的复杂性，随着微服务数量增多，调用链路也会越来越长，问题的定位与解决也成为了难以解决问题。
二、MSE 微服务治理
可以设想，如果依靠阿里巴巴或者阿帕奇等专业团队支持，企业在微服务深化的过程中是否会变得更加从容？
阿里云 MSE 微服务治理正是一款这样的产品。
MSE 微服务治理以无侵入的方式提供了全链路灰度、流量防护、离群实例摘除、金丝雀发布、微服务治理、流量可观测等核心能力。相比于自建系统，它提供了非常丰富的差异化能力，覆盖了从开发态、测试态、运行态的微服务全生命周期，同时无缝支持市面上近五年来全部 Spring Cloud 与Dubble框架，帮助企业以更经济、高效的路径在云上快速构建完整的微服务治理体系，能够有效提升微服务应用的开发效率和线上稳定性。
近日，阿里云MSE 微服务治理在原有的基础版和专业版之上推出了企业版，提供了微服务应用以及常用网关的流量管控与容错能力，从流量控制、并发控制、熔断降级、自适应保护、热点防控等多个维度保障业务的稳定性，帮助用户更好地应对流量激增或服务依赖不稳定的问题。企业版可以理解为开源了Sentinel 的商业版本。
同时, MSE 治理中心还增加了应用配置的能力，帮助用户动态管理代码中的配置项，可在多种业务场景下使用。一是业务逻辑预埋的功能开关，比如需要动态开启某个促销活动，将一些耗时的操作降级；二是无需应用重启就能动态调整应用操作级别，比如修改线上的日记级别，指定 AB Test 路径，动态调整线程池策略等；三是 list、 map 等复杂类型结构化的内容推送，比如可以定时推送大促商品名单，统一发放优惠券等。
上图右侧是基础版、专业版以及企业版的功能矩阵与功能区分。
MSE 服务治理希望助力企业构建完整的微服务治理体系，包括以下几个比较常用的能力：
① 无损上线：从微服务注册到服务预热，到Readiness 检查通过，再到正常的流量，通过全生命周期的全部方案来保证，无论业务在扩容、重启还是变更过程中，都能无损上线。
② 全链路灰度：提供了流量隔离的泳道能力，覆盖了网关、RPC 、Rocket MQ 等组件，提供了统一的打标切流能力、秒级的可观测能力、端到端的稳定基线环境，可以快速安全地验证新版本。
③ 日常环境隔离：它是基于全灰度的扩展，可以进行端云联调，在本地快速拉起服务进行 future 测试。
三、全链路灰度
软件是以持续迭代的方法不断演进的，软件迭代速度过慢会影响其完善速度。所以，如何快速安全地验证新版本软件的稳定性，也是业内一直关心且在持续探索的。
先了解几个关键词：
泳道：相同版本应用定义的一套隔离环境，只有满足了流控路由规则的请求。流量才会路由到对应泳道里的打标应用。每条泳道与一个标签相对应，泳道组里标签相同的多个应用节点必定属于同一个泳道，一个应用可以属于多个泳道，一个泳道可以包含多个应用，应用和泳道是多对多的关系。
基线环境：未打标的应用属于基线稳定版本的应用，即稳定的线上环境。
流量回退：泳道中所部署的服务数量并非要求与基线环境完全一致，当泳道中不存在调用链中所依赖的其他服务时，流量需要回退至基线环境，进一步在必要的时候路由回对应标签的泳道。
泳道组：泳道的集合。泳道组的作用主要是为了区分不同团队或不同场景。
如上图，交易中心和商品中心各有两个新版本（1和2）在运行，需要对其进行灰度验证。分别创建了A泳道和B泳道，通过微服务网关将满足特定流控规则的请求流量路由到新版本，其余流量全部路由到线上（正式）版本，即基线环境。
假设某个应用只有线上基线环境，没有标签1、标签 2 的环境，则流量会打到基线环境中；若后续增加了标签1 、标签2的环境，泳道的流量会回退到对应标签的应用里。
全链路灰度常见的应用场景有如下几种：
① 日常/开发/项目/测试环境隔离：如果没有全链路灰度机制，开发环境需要进行物理隔离，需要部署整套微服务架构，无论是维护还是后续的运维、机器的成本都非常高。
② 全链路灰度发布：可以保障灰度流量在 N 个应用的灰度版本之间路由。
③ 高可用同机房优先路由。
④ 全链路压测。
全链路灰度可以让线上环境配合流量控制全链路灰度的能力，实现零机器成本、零维护成本地完成全链路压测。
MSE 微服务治理全链路灰度具有以下几个特性：
① 全链路隔离流量泳道：通过设置流量规则所需的流量进行染色，染色后的流量路由到灰度机器，灰度流量携带灰度标往下透传，形成专属环境的流量泳道。无灰度环境应用会默认选择未打标的基线环境。
② 端到端的稳定基线环境及线上的稳定环境。
③ 流量一键动态切流：可以根据需求配置流量规则，配置完规则后可以一键停启，也可以同时进行增删改查。操作实时生效，使得灰度流量可以引流，更加便捷。
④ 可观测能力：具备泳道级别的可观测能力，同时具备全链路应用的可观测能力，可以从全局视角观察到流量是否存在逃逸，对于流量是否灰到一目了然。
⑤ 通过 Java Agent 技术实现，无需修改业务代码。通过字节码增强的方式可以无缝支持市面上近五年来所有 Spring Cloud与Dubbo 版本，也无须改变业务的现有架构，可以做到随上随下、无绑定。只需开启MSE 服务治理专业版，在线配置，实时生效。
⑥ 具备无损上下线能力，发布更丝滑，无论是在大流量场景下的发布、回滚，还是扩容缩容等场景，都可以保证业务流量无损。
上图为客户来电科技的业务架构。
最上层是移动端，最右侧是移动端的用户界面，通过 Nginx 网关作为接入层，使用Spring Cloud 与 Dubbo 作为服务框架。
它的全链路灰度落地架构如下：在Nginx 层进行流量分流的配置，使其中 10% 流量进入灰度环境，其余 90% 流量进入未打标及线上的正式环境。经过灰度环境的流量会自动被MSE 染色，染上对应环境的标签颜色，从而进行全链路灰度路由，形成灰度环境的流量泳道，以此保证流量在灰度环境中闭环。如果没有灰度环境的机器，则流量会走到线上环境；而若数据中心又有了灰度环境的机器，灰度流量依然会重新回到数据中心的灰度环境中，即流量回退。
四、总结与展望
全链路灰度方面：
全链路灰度将不断覆盖生产环境所涉及到的各个场景，从前端网关到微服务，包括RPC、MQ、Redis、分布式调度、数据库Database 。
同时MSE 服务会针对各个场景来打造完整的全链路相关解决方案，比如基于Ingress-nginx 网关、基于Apache PISIX网关、基于MSE 云原生、基于 Java 网关等。通过Jenkins 构建 CI/CD 实现金丝雀发布，还有端云互联相关的微服务敏捷开发最佳实践等。
此外，我们希望能够提供完整的产品化界面，将各个场景和各种解决方案以产品化的方式呈现给用户，同时不断打磨秒级的可观测能力、应用间的流量大盘使得灰度情况一目了然。
服务治理开源方面：
服务治理是微服务改造深入到一定阶段后的必经之路。此过程也不断会出现新的问题，比如除了全链路灰度，服务治理还有哪些能力？服务治理能力有没有标准的定义？多语言场景下有无全链路灰度最佳实践或标准？微服务如何统一治理？
服务治理主要以落地和解决问题为主，目前没有形成很好的标准和规范化，对研发有一定的理解成本。对接其他微服务时，如果服务治理体系不同，会对我们造成很多困扰，同时，打通两套或多套治理体系的成本也非常高昂。
为此我们提出了 OpenSergo，主要用于解决不同框架、不同语言在微服务治理上由于概念的碎片化无法互通的问题，它致力于帮助不同的微服务框架、语言以及通信协议之间达成共识，形成云原生服务治理的规范，使框架的使用者不会因为语言的不同和框架的不同而产生割裂，让企业的架构师能够用一种统一的规范来描述内部的微服务架构。
MSE服务治理方面：
首先，持续打磨核心能力，提升性能以及用户体验，增加产品厚度，拓宽使用场景，不断打磨完善最佳实践。
其次，打造一套完整的微服务体系，以开源为基础支持开源到云上的平滑迁移。
最后，将 MSE 打造成一个阿里巴巴实践输出的阵地，将阿里开源技术不断输出，同时将阿里内部的最佳实践以及客户的实践案例以完整的方案对外输出，打造云上永不停机的业务。
