阿里云 MSE 助力开迈斯实现业务高增长背后带来的服务挑战-Toy模板网

这篇具有很好参考价值的文章主要介绍了阿里云 MSE 助力开迈斯实现业务高增长背后带来的服务挑战。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

开迈斯新能源科技有限公司于 2019 年 5 月 16 日成立，目前合资股东分别为大众汽车（中国）投资有限公司、中国第一汽车股份有限公司、一汽-大众汽车有限公司[增资扩股将在取得适当监督（包括反垄断）审批后完成]、万帮数字能源股份有限公司和安徽江淮汽车集团控股有限公司，总部位于江苏常州。开迈斯集车企与充电企业优势于一体，提供从充电基础设施的研发制造到软件的智能互联，从私人充电用户到半公共、公共以及商务用户，从电力供应的行业源头到服务平台的终端体验，实现每一个业态的前后端无缝连接。

开迈斯为中国新生代消费者而来，不仅注重私家电动车主的充电体验，还以高端的品质服务提供用户便捷无忧、智能高效的全新充电体验，开启乐享生活的旅程。同时，开迈斯致力于为电动出行提供全场景充电服务，依托强大的研发实力、先进的核心技术和高质量服务，还收获了国内新能源汽车充电领域的诸多奖项：2021 年，开迈斯荣膺“中国充电桩行业最佳运营服务创新奖”；2023 年 3 月，开迈斯一举获得“高质量充电五星级场站奖“，成为首批获得五星级评价的优秀充电运营商（五星级别是最高级别最高标准的场站）；同年 6 月，开迈斯荣获 2023 中国充换电行业十大影响力运营商品牌奖。开迈斯将持续推动充电网络建设速度和充电用户旅程的优化创新，并将聚焦高功率充电设备研发和新能源服务领域的探索，从而推动新能源与新能源汽车深度融合的绿色发展。

业务稳定性挑战大

2023 年，开迈斯将继续致力于以用户为中心的整合创新，助力智能电动化出行。截止今年7月底，开迈斯充电网络覆盖国内 192 城，建设 1,274 座充电站和 11,113 个充电终端，积累用户超 241 万。从建设滞后到“适度超前”，未来三年充电桩产业将迎来大发展，市场规模达千亿级。现在全国各地很多城市在对充电桩的增设和利用上在不断升级加码，随着新能源汽车的发展，充电用户群体的诉求飞速增长，开迈斯伴随着业务的快速增长，对其架构的稳定性以及可用性也提出了前所未有的挑战。

开迈斯采用传统的 SpringBoot 方式进行应用开发，应用间通过 Http 请求方式进行互通互联，也正是 SpringBoot 架构的简单性，有效帮助到开迈斯的业务以及微服务数量进行快速扩张。但是随着微服务规模的增大，逐渐发现应用在发布、运行等各个阶段的都存在一些稳定性与效率上的问题。开迈斯架构同学也意识到需要引入微服务治理能力对当前的微服务进行恰当的治理，从而进一步提升业务的稳定性。 同样的，业务依旧面临快速发展的诉求，如果将原先的 SpringBoot 框架升级成 Spring Cloud 并且引入各种高阶的服务治理能力，对于开迈斯研发同学来说，成本过于太大。

升级架构不改代码

是否有一种不用改代码的方式实现我们微服务的治理能力呢？比如通过实施全链路灰度发布来避免变更带来的稳定性风险；通过限流降级能力保障运行态的稳定性，解决不确定的流量带来的稳定性风险；通过鉴权能力解决微服务间调用的安全风险。这就好比，我们如何可以在飞机高速运行的过程中，通过更换引擎来提升飞机的性能？更关键的是，对于我们飞机上的乘客来说，还要是无感的。

我们将问题进一步抽象，如何可以不改代码，实现任意 Java 应用的服务治理能力，并且在这个过程中我们需要确保稳定性、问题诊断效率、架构的可持续性、性能等一系列现实的因素。

技术的探索总是为业务服务的，我们围绕着开迈斯的方案进行了一步讨论，是否可以通过 ServiceMesh 的方案解决用户无侵入服务治理的难题。

主流的分布式 Sidecar 模式在近几年受到了大家的青睐，但是在使用过程中也有问题逐渐暴露了出来，Sidecar 模式在内存消耗上比较可控，最多也是在 MB 这个量级，但是在 CPU 利用率上，随着业务吞吐量的增长，Sidecar 的 CPU 消耗基本达到了与业务消耗持平的量级，相当于在使用 Sidecar 之后，相同业务规模需要两倍的集群数来承载。总的来看，业内也逐渐意识到了这个问题，逐渐演进出了其他方案，通过集中化的方式实现无侵入的流量路由。
1. 另一方面，引入 Envoy Sidecar 对于开迈斯来说则增加了不必要的运维成本、问题诊断的效率也大幅度上升，同时引入 ServiceMesh 的技术复杂度对业务的研发同学来说也是非常高的门槛。
既然 ServiceMesh 方案对用户来说门槛比较高，那么是否可以通过 Higress 实现服务间调用的治理诉求？ 只需透出网关的操作界面即可，基于托管的 Higress 给无侵入的服务治理提供了一种新的思路，在满足用户服务治理治理需求的同时，相比Sidecar 在资源利用率、运维复杂度、性能和时延等方面具有优势。

如何实现服务间的流量转发与治理

既然思路敲定了，大家评估完了稳定性、安全与成本之后，那么就快速开始方案的实践与探索了。我们首先面临的问题是原先通过域名调用 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 企业版无论是在使用还是功能层面都有一定的优势。