研发中心平台架构师谈稳定性建设之路

JQ_Ling

云快充成立于2016年，以充电服务和能源管理为核心，业务涵盖九个方向。截止到2022年11月，业务覆盖370个城市，接入电桩运营商 7400人，接入充电终端31万家，与640个桩企达成合作。目前，新能源行业发展情况除了大力满足业务的快速发展，服务更多客户外，云快充一直非常重视线上服务的稳定性建设，以提升用户的充电体验。
业务系统容器化
' M( }$ F! \/ L1 P% `" ]
; |2 m7 y: O5 v5 N. X4 G为了确保业务的稳定运行，云快充从 2019年 就确定了业务系统百分之百容器化的技术路线。在当时虽然容器平台还有其他的一些方案可以选择，但基本已经可以明确的感受到K8s 成为云原生时代的基础设施底座的技术趋势。K8s 能够带来的价值是多方面的，包括研发运营与效率的提升，降低资源成本等。

9 J2 h% H# v1 Y: H
% c6 t3 Z. g; i: m, {" j
基于自身业务，云快充最看重的是 K8s 对于业务稳定性的提升。在大型分布式 IT 架构中，任何一个环节都有可能发生故障。比如云上的 ECS 不是百分之百能够保持正常运行，每一个应用进程都有可能在长时间运行后遇到宕机的情况。我们需要确保的是，当这些故障发生的时候，业务不要受到任何的影响。K8s 的调度机制以及健康检查机制为IT 架构提供了自愈能力，出现故障的时候，能够自动把业务 Pod 重新调度到正常的节点上。这个过程完全不需要人工介入。通过 K8s 集群的跨可用区部署，配合上同可用区优先的微服务访问策略，甚至可以做到机房级别故障的罕见场景下，业务系统依然正常提供服务。

这一点我们在实战中也验证过。在业务高峰期，通过 K8s 的弹性伸缩能力，可以实现基于业务负载的自动弹性扩容。 这个弹性能力涉及到工作负载的水平伸缩以及计算资源的水平伸缩。在全面使用 K8s 之前，我们考虑过类似的方案，但因为担心影响业务稳定性，并没有真正投入大规模使用。全面容器化之前，我们的团队也尝试自己搭建 K8s 集群，验证 K8s 的各项能力，通过一段时间的实战，还是遇到了不少的挑战。
6 _  N6 p; D( V9 T0 _  K3 v: `
; J1 q1 k7 j" W: _, C+ T
  k' h$ n$ e# N5 s( O
" _) h* i6 I0 `0 D8 p! d( dK8s 是一个大型复杂的分布式系统，涉及十多个核心组件，这些组件和云上的 IaaS 层产生集成的时候就更为复杂了，光是搞定网络插件就需要投入不少的精力，我们也没有专业的技术人员能够快速解决节点异常、Pod 异常、网络不通等问题。特别是有时候遇到 K8s 本身的 bug，就更无能为力。开源 K8s 本身的bug其实还是很多的。当前社区处于 open 状态的 issue 就有1600多个。集群规模比较大的时候，系统的各个组件均出现相应的性能问题的机会也就变高了。如果遇到 etcd 的性能瓶颈，会导致集群一系列的问题发生，体现在业务侧，就是用户充不上电。

K8s 版本以及 K8s 组织的升级是另一个难题。 社区版本更新的很快，升级有影响业务的可能性。但我们也担心，太久不升级，老版本因为漏洞会造成更严重的问题。所以我们除了在测试环境，保留自建K8s作为学习和研究之外，生产环境的系统都全面向容器服务 ACK 迁移。结合我们自身的业务场景与技术架构，ACK 在这些方面体现出来的价值让我们最认可。

首先在 API 和标准上完全兼容开源K8s，确保我们的技术架构遵循开源开放的技术体系。 其次是计算、存储、网络等云产品进行了深度集成，而且这些集成本身也是基于K8s 标准，特别是在网络方面，实现了VPC内容器网络与虚拟机网络的打通。这对我们渐进式地将应用从 ECS 迁移到 K8s 起到了非常大的帮助。整个迁移的过程是非常顺利。由于网络是打通的，可以在保持原有架构的基础上一个一个应用的验证，只是应用的底层承载，从虚拟机转向了容器。这也确保了我们在容器迁移过程中的业务稳定性。

+ Z3 Y  o; U( `1 Q" g最后在集群自身的稳定性方面，ACK 也做了大量的工作，如 master节点托管、智能巡检诊断，跨可用区的高可用等等。这些都经过阿里双十一大规模场景，以及阿里云的大型客户实战验证。对云快充而言，最重要的一点在于集群和组件的版本升级变得更简单了，直接在控制台一键操作，对于业务是无感，极大的降低了维护成本，也为业务稳定性的提升提供了基础保障。



ACK 还集成了一个非常好用的集群诊断工具，它是基于eBPF技术实现的，对我们来说提供了一个开箱即用的能力，一键开启就可以。这个工具提供了全局视角的应用拓扑，遵循了从整体到个体的原则，先从全局视图入手，从请求数、错误数、延误三个黄金指标出发，发现异常的服务个体，如某个应用服务，定位到这个应用后，可以获取日志，关联分析。在一个页面展示分层下钻，不需要多个系统来回跳转，方便快速定位拓扑中的服务调用，这些有价值的数据都导入到了云上的 Prometheus 服务。大家也知道在云原生时代，Prometheus 在可观测领域的地位就相当于 K8s 在云原生底座的地位。
! h# R0 @4 ?* D% P$ c! W
- ?/ \" m* M/ \/ D/ l. e; V通过云上的 Prometheus 和 Grafana ，我们将 eBPF 指标与云产品的指标结合在一起，做了一个业务监控大盘，通过这个大盘就能了解到当前业务的进展情况。对于重要的接口，我们也基于服务质量配了告警规则，通过 ARMS 告警平台，通知到运维群，保证核心服务的SLA，这对于提升我们的业务稳定性起到了很大的帮助。
) d- t! r& ~4 ]' A

2 _/ \2 {' g% E# F' Q4 L构建业务稳定性

7 B- Q) R& }2 L+ @在微服务稳定性方面，我们的团队也做了大量探索。根据之前的经验，80% 以上的线上业务故障都跟版本发布有关，这和应用上下线不够优雅，以及缺少精细化、灰度策略有关。

$ k) O+ g  n! w9 O2 x* T在阿里云 MSE 微服务治理方案的帮助下，我们对微服务系统的稳定性进行了一系列提升。由于 MSE 所提供的微服务治理能力是基于 Java-Agent 字节码增强的技术实现，和我们使用的 Spring Cloud 微服务框架可以完美匹配。这些提升完全没有代码侵入，所以建立这些能力是很简单的。

* r+ E2 G1 Z3 K4 c

首先解决的是无损上下线问题。 做过大规模微服务架构的朋友都知道，无损上下线问题是一个困扰了很多开发者的老大难问题。MSE的微服务治理 Agent做了两件事情，一是动态感知应用上下线的行为，二是动态调整服务消费者的负载均衡策略。通过这两个事情很轻松的实现了应用无损上下线。现在我们不管是做应用的扩缩容，还是版本发布，都可以做到对最终用户无感。

: D2 S. S: c6 c3 a在全链路灰度方面，MSE也提供了完整的解决方案。 生产环境只需要一套环境，就可以基于泳道模型定义多个逻辑的灰度版本，再通过路由规则的配置，让特定的流量在对应的泳道中流转。这样就可以在发布新版本的时候，严格控制新版本影响的请求量，通过充分的验证后，再决定到底是加大新版本的覆盖度，还是回滚到上一个版本，从而将版本发布对正常业务的影响降到最低。

& x, N. ]# X" R  F4 j: X4 w由于全链路灰度对于整个研发以及运维的流程提出了更高的要求。我们目前只在一条业务线上进行了推广，得到的收益是很明显的，因为应用变更导致的生产事故降低了70%以上。 后续我们会再接再厉，将全链路灰度推广到整个企业。

& S+ r) U3 K, A# M& Y此外，全链路流量防护也是我们基于MSE构建的提升业务稳定性的重要手段。从网关到微服务应用，到第三方依赖，每一层我们都配置了流量防护规则，确保在业务高峰期不会有任何系统被用户流量所压垮。

这是云快充当前的技术架构。为了保障充电桩连接的稳定性，我们搭建了专门的集群，双服务通过TCP强连接与双通信提供基础能力。伴随着云快充的全面容器化与稳定性建设，云快充接入的电桩数量完成了20万到30万的增长，平均需求迭代周期从7人日降低到4人日，极大地促进了业务的快速迭代。
/ J4 L9 d  E0 o- d7 j; u$ s
# I: r! b1 F; c: a  a+ F
展望

除了继续提升全链路灰度覆盖度之外，我们在将来还有两大规划：一是通过边缘容器方案提升我们的服务质量，这和云快充的业务特点是有关系的。在网络中断等极端场景下，基于边缘节点的能力，也能让部分业务可以正常对外服务，不至于用户在这种情况下完全无法充电。二是增强端到端的安全治理。在防攻击、登录认证、涉及网关的双线TLS内部服务、权限管理等方面，都加强安全防护手段。
2 o* U" Q5 u+ t# U
希望阿里云的方案能够帮助我们更快地实现这两个规划，也希望新能源行业的其他技术团队可以和我们一起共同探索云原生稳定性方面的技术路径。
) S7 k+ T- G; |4 V5 e# ^

521li

可以同时多少人进行线上开会