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