作者：开迈斯新能源
开迈斯新能源科技有限公司于 2019 年 5 月 16 日成立，目前合资股东分别为大众汽车（中国）投资有限公司、中国第一汽车股份有限公司、一汽-大众汽车有限公司[增资扩股将在取得适当监督（包括反垄断）审批后完成]、万帮数字能源股份有限公司和安徽江淮汽车集团控股有限公司，总部位于江苏常州。开迈斯集车企与充电企业优势于一体，提供从充电基础设施的研发制造到软件的智能互联，从私人充电用户到半公共、公共以及商务用户，从电力供应的行业源头到服务平台的终端体验，实现每一个业态的前后端无缝连接。开迈斯为中国新生代消费者而来，不仅注重私家电动车主的充电体验，还以高端的品质服务提供用户便捷无忧、智能高效的全新充电体验，开启乐享生活的旅程。同时，开迈斯致力于为电动出行提供全场景充电服务，依托强大的研发实力、先进的核心技术和高质量服务，还收获了国内新能源汽车充电领域的诸多奖项：2021 年，开迈斯荣膺“中国充电桩行业最佳运营服务创新奖”；2023 年 3 月，开迈斯一举获得“高质量充电五星级场站奖“，成为首批获得五星级评价的优秀充电运营商（五星级别是最高级别最高标准的场站）；同年 6 月，开迈斯荣获 2023 中国充换电行业十大影响力运营商品牌奖。开迈斯将持续推动充电网络建设速度和充电用户旅程的优化创新，并将聚焦高功率充电设备研发和新能源服务领域的探索，从而推动新能源与新能源汽车深度融合的绿色发展。
业务稳定性挑战大
2023 年，开迈斯将继续致力于以用户为中心的整合创新，致力打造智能电动出行。截止今年 5 月底，开迈斯充电网络覆盖国内 180 城，建设 1,198 座充电站和 10,490 个充电终端，积累用户超 196 万。从建设滞后到“适度超前”，未来三年充电桩产业将迎来大发展，市场规模达千亿级。现在全国各地很多城市在对充电桩的增设和利用上在不断升级加码，随着新能源汽车的发展，充电用户群体的诉求飞速增长，开迈斯伴随着业务的快速增长，对其架构的稳定性以及可用性也提出了前所未有的挑战。
开迈斯采用传统的 SpringBoot 方式进行应用开发，应用间通过 Http 请求方式进行互通互联，也正是 SpringBoot 架构的简单性，有效帮助到开迈斯的业务以及微服务数量进行快速扩张。但是随着微服务规模的增大，逐渐发现应用在发布、运行等各个阶段的都存在一些稳定性与效率上的问题。随着用户与的增多，相应的需求也越来越多，业务场景也越来越复杂。在这个时候仅依靠内部测试很难保证可以覆盖到所有的场景，每次应用的发布都需要进行充分的测试与足够的灰度验证。为了满足快速迭代的业务诉求，如何可以做到低成本地进行多个迭代在开发环境并行，并且保证每次业务发版的稳定，成了提效的关键。
在大规模之下，再小的问题都会牵一发而动全身。一方面，我们面对的流量是随机的、无法预测的，当激增流量超出服务承载上限时，可能会使服务变慢、负载飙高，导致服务崩溃。另一方面，分布式微服务架构是复杂的网状架构，调用链路错综复杂，这时候任何一个服务（包括依赖的外部服务）出现不稳定因素（如慢调用或异常）时，都有可能把上游调用方拖垮，进而形成级联影响。因此，在微服务治理中，我们需要一些手段来预防这些不稳定的情况。
面对持续演进增长的微服务架构，开迈斯架构同学也意识到需要引入微服务治理能力对当前的微服务进行恰当的治理，从而进一步提升微服务的稳定性与效率。同样的，业务依旧面临快速发展的诉求，如果将原先的 Spring Boot 框架升级成 Spring Cloud 并且引入各种高阶的服务治理能力，对于目前面对业务快速发展的开迈斯研发同学来说，需要投入成本过于太大。
无感实现微服务架构升级
是否有一种不用改代码的方式实现我们微服务的治理能力呢？比如通过实施全链路灰度发布来避免变更带来的稳定性风险；通过限流降级能力保障运行态的稳定性，解决不确定的流量带来的稳定性风险；通过鉴权能力解决微服务间调用的安全风险。这就好比，我们如何可以在飞机高速运行的过程中，通过更换引擎来提升飞机的性能？更关键的是，对于我们飞机上的乘客来说，还要是无感的。
我们将问题进一步抽象，如何可以不改代码，实现任意 Java 应用的服务治理能力，并且在这个过程中我们需要确保稳定性、问题诊断效率、架构的可持续性、性能等一系列现实的因素。技术的探索总是为业务服务的，我们围绕着开迈斯的方案进行了一步讨论，是否可以通过统一南北和东西向流量治理的方案来解决用户无侵入服务治理的难题？1. MSE云原生网关是兼容 K8s Ingress 标准的下一代网关产品，将流量网关、微服务网关 和 WAF 安全网关三合一，具备高集成、易使用、易扩展、热更新的特点。它打通了 K8s/Nacos 等多种服务来源，通过无损上下线、全链路灰度、过载保护、故障自愈、限流降级等手段，提升整个链路的应用稳定性。2. MSE 云原生网关采用了全托管的模式，用户在选择云原生网关之后，只需要关心网关的具体使用，无需关心云原生网关本身的运维、稳定性、监控、报警 等功能， 开箱即用，使用门槛低。考虑到云原生网关可以通过路由规则统一流量以及流控，那么是否能够通过 Higress 实现服务间调用流量的治理诉求？
服务间的流量转发与治理
既然思路敲定了，大家评估完了稳定性、安全与成本之后，那么就快速开始方案的实践与探索了。我们首先面临的问题是原先通过域名调用 K8s Service 的方式，我们如何将流量转发至 Higress 并且通过 Higress 再转发给真实对应的 Pod 呢？并且在这个过程中我们需要考虑方案的稳定性。
- 直接想到的方式就是修改 K8s 中的 Service 跟 Endpoints 配置，利用 coreDNS 能力将流量转发至 Higress。
apiVersion: v1 kind: Service metadata: name: provider spec: type: ClusterIP clusterIP: None --- apiVersion: v1 kind: Endpoints metadata: name: provider spec: subsetS: ip: ${higress-slb} port: 80
- 出于商业化稳定性的考虑 CoreDNS，可以使用同类型产品 privatelinkZone DNS 进行替代，同时可以配置 CNAME 类型的 DNS 记录批量将服务间访问的域名 *.camsnet.com 切换至云原生网关上。
到目前为止我们完成了 Order 的流量被先转发至内部网关 Higress 上，接下来我们需要配置 Higress 路由规则，将流量转发至真实的目标服务中。
- 我们在 MSE 云原生网关（Higress 商业版）中同步容器服务的 Service 至网关，并且配置对应的路由规则，实现流量转发。
流量经过 MSE 云原生网关转发之后，我们就可以做更多的治理能力了。
- 这个过程中我们直接可以配置标签路由实现灰度发布的能力，再结合链路追踪实现全链路灰度的能力。
- 这个过程中我们可以在路由上配置 JWT 鉴权规则，从而达到服务间的安全调用。
可观测与全链路追踪
开迈斯通过接入应用实时监控服务 ARMS -应用监控，无需修改一行代码就可以实现应用的监控诊断能力，可以快速了解应用最关键的响应时间，吞吐量，错误率这黄金三指标，同时根据指标的异常利用调用链能力对整个微服务进行快速跟踪。
同时链路追踪能力也为应用实现全链路灰度提供了一个技术底座支持。
全链路流量标签透传
借助 Tracing Baggage 机制在全链路中传递对应染色标识，因为大部分 Tracing 框架都支持 Baggage 概念及能力，如：OpenTelemetry、Skywalking、Jaeger 等等。当然 ARMS Tracing 能力也是符合这个标准的，我们通过实现 Higress WASM 插件，在 Higress outbound Filter 中将指定的透传 key 如 x-mse-tag 从 Tracing 协议指定位置的 Baggage 中读出 x-mse-tag 对应的值，并塞入到 Http 的 Header 中，供 Higress 进行路由。从而实现自定标签全链路透传的能力。
具备自定标签全链路透传的能力之后，我们就可以构建完整的全链路灰度能力了。什么是全链路灰度呢？
在微服务架构下，有一些需求开发，涉及到微服务调用链路上的多个微服务同时发生了改动，通常每个微服务都会有灰度环境或分组来接受灰度流量，我们希望通过进入上游灰度环境的流量，也能进入下游灰度的环境中，确保 1 个请求始终在灰度环境中传递，即使这个调用链路上有一些微服务没有灰度环境，这些应用请求下游的时候依然能够回到灰度环境中。如果一次发布涉及到链路中的多个微服务，我们可以顺滑地进行全链路灰度发布，并且不用担心灰度流量乱窜的风险。
当我们实现全链路透传 x-mse-tag 标签后，我们可以在 Higress 路由上，配置基于 x-mse-tag 的标签路由规则，实现带有特定标签的流量在应用特定版本的节点内流量闭环，从而实现“流量泳道”的全链路灰度能力。
流量防护能力
如何可以不用修改代码，实现流量防护能力？以常见的流量控制与熔断降级为例，下面我们先来介绍一下流量防护能力。
- 流量控制
流量是非常随机性的、不可预测的。前一秒可能还风平浪静，后一秒可能就出现流量洪峰了（例如双十一零点的场景）。每个系统、服务都有其能承载的容量上限，如果突然而来的流量超过了系统的承受能力，就可能会导致请求处理不过来，堆积的请求处理缓慢，CPU/Load 飙高，最后导致系统崩溃。因此，我们需要针对这种突发的流量来进行限制，在尽可能处理请求的同时来保障服务不被打垮，这就是流量控制。
- 熔断降级
现代微服务架构都是分布式的，由非常多的服务组成。不同服务之间相互调用，组成复杂的调用链路。以上的问题在链路调用中会产生放大的效果。复杂链路上的某一环不稳定，就可能会层层级联，最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。开迈斯通过接入 MSE 服务治理流量防护能力（Sentinel 企业版），无缝实现流量防护能力。相比社区版本，Sentinel 企业版无论是在使用还是功能层面都有一定的优势。
更多的探索与实践
不需要改代码，我们也能快速具备完整、体系化的微服务治理能力。目前开迈斯基于 Higress 实现了全链路灰度、全链路追踪与可观测、流量防护等一系列能力，使得开迈斯当前的架构可以更加从容地面对快速增长业务带来的挑战。
另一方面，对于 Higress 来说，开迈斯方案的落地为 Higress 生态的发展注入了新鲜的思路，我们也在持续地提升 Higress 的易用性与稳定性，希望可以给更多企业带来更大的价值。
