共计 3246 个字符，预计需要花费 9 分钟才能阅读完成。
作者：吕周洋
大家好，我是来自云快充研发核心的平台架构师吕周洋，明天我给大家分享云快充云原生稳定性之路。
点击查看：云快充研发核心平台架构师 吕周洋：云快充云原生稳定性治理之路
云快充成立于 2016 年，以充电服务和能源管理为外围，业务涵盖九个方向。截止到 2022 年 11 月，业务笼罩 370 个城市，接入电桩运营商 7400 人，接入充电终端 31 万家，与 640 个桩企达成单干。目前，新能源行业倒退状况除了鼎力满足业务的疾速倒退，服务更多客户外，云快充始终非常重视线上服务的稳定性建设，以晋升用户的充电体验。
业务零碎容器化
为了确保业务的稳固运行，云快充从 2019 年 就确定了 业务零碎百分之百容器化 的技术路线。在过后尽管容器平台还有其余的一些计划能够抉择，但根本曾经能够明确的感触到 K8s 成为云原生时代的基础设施底座的技术趋势。K8s 可能带来的价值是多方面的，包含研发经营与效率的晋升，升高资源老本等。
基于本身业务，云快充最看重的是 K8s 对于业务稳定性的晋升。在大型分布式 IT 架构中，任何一个环节都有可能产生故障。比方云上的 ECS 不是百分之百可能放弃失常运行，每一个利用过程都有可能在长时间运行后遇到宕机的状况。咱们须要确保的是，当这些故障产生的时候，业务不要受到任何的影响。K8s 的调度机制以及健康检查机制为 IT 架构提供了自愈能力，呈现故障的时候，可能主动把业务 Pod 从新调度到失常的节点上。这个过程齐全不须要人工染指。通过 K8s 集群的跨可用区部署，配合上同可用区优先的微服务拜访策略，甚至能够做到机房级别故障的常见场景下，业务零碎仍然失常提供服务。
这一点咱们在实战中也验证过。在业务高峰期，通过 K8s 的弹性伸缩能力，能够实现基于业务负载的主动弹性扩容。 这个弹性能力波及到工作负载的程度伸缩以及计算资源的程度伸缩。在全面应用 K8s 之前，咱们思考过相似的计划，但因为放心影响业务稳定性，并没有真正投入大规模应用。全面容器化之前，咱们的团队也尝试本人搭建 K8s 集群，验证 K8s 的各项能力，通过一段时间的实战，还是遇到了不少的挑战。
K8s 是一个大型简单的分布式系统，波及十多个外围组件，这些组件和云上的 IaaS 层产生集成的时候就更为简单了，光是搞定网络插件就须要投入不少的精力，咱们也没有业余的技术人员可能疾速解决节点异样、Pod 异样、网络不通等问题。特地是有时候遇到 K8s 自身的 bug，就更无能为力。开源 K8s 自身的 bug 其实还是很多的。以后社区处于 open 状态的 issue 就有 1600 多个。集群规模比拟大的时候，零碎的各个组件均呈现相应的性能问题的机会也就变高了。如果遇到 etcd 的性能瓶颈，会导致集群一系列的问题产生，体现在业务侧，就是用户充不上电。
K8s 版本以及 K8s 组织的降级是另一个难题。 社区版本更新的很快，降级有影响业务的可能性。但咱们也放心，太久不降级，老版本因为破绽会造成更重大的问题。所以咱们除了在测试环境，保留自建 K8s 作为学习和钻研之外，生产环境的零碎都全面向容器服务 ACK 迁徙。联合咱们本身的业务场景与技术架构，ACK 在这些方面体现进去的价值让咱们最认可。
首先在 API 和规范上齐全兼容开源 K8s，确保咱们的技术架构遵循开源凋谢的技术体系。 其次是计算、存储、网络等云产品进行了深度集成，而且这些集成自身也是基于 K8s 规范，特地是在网络方面，实现了 VPC 内容器网络与虚拟机网络的买通。这对咱们渐进式地将利用从 ECS 迁徙到 K8s 起到了十分大的帮忙。整个迁徙的过程是十分顺利。因为网络是买通的，能够在放弃原有架构的根底上一个一个利用的验证，只是利用的底层承载，从虚拟机转向了容器。这也确保了咱们在容器迁徙过程中的业务稳定性。
最初在集群本身的稳定性方面，ACK 也做了大量的工作，如 master 节点托管、智能巡检诊断，跨可用区的高可用等等。这些都通过阿里双十一大规模场景，以及阿里云的大型客户实战验证。对云快充而言，最重要的一点在于集群和组件的版本升级变得更简略了，间接在控制台一键操作，对于业务是无感，极大的升高了保护老本，也为业务稳定性的晋升提供了根底保障。
ACK 还集成了一个十分好用的集群诊断工具，它是基于 eBPF 技术实现的，对咱们来说提供了一个开箱即用的能力，一键开启就能够。这个工具提供了全局视角的利用拓扑，遵循了从整体到个体的准则，先从全局视图动手，从申请数、谬误数、延误三个黄金指标登程，发现异常的服务个体，如某个应用服务，定位到这个利用后，能够获取日志，关联剖析。在一个页面展现分层下钻，不须要多个零碎来回跳转，不便疾速定位拓扑中的服务调用，这些有价值的数据都导入到了云上的 Prometheus 服务。大家也晓得在云原生时代，Prometheus 在可观测畛域的位置就相当于 K8s 在云原生底座的位置。
通过云上的 Prometheus 和 Grafana，咱们将 eBPF 指标与云产品的指标联合在一起，做了一个业务监控大盘，通过这个大盘就能理解到以后业务的停顿状况。对于重要的接口，咱们也基于服务质量配了告警规定，通过 ARMS 告警平台，告诉到运维群，保障外围服务的 SLA，这对于晋升咱们的业务稳定性起到了很大的帮忙。
构建业务稳定性
在微服务稳定性方面，咱们的团队也做了大量摸索。依据之前的教训，80% 以上的线上业务故障都跟版本公布无关，这和利用高低线不够优雅，以及短少精细化、灰度策略无关。
在阿里云 MSE 微服务治理计划的帮忙下，咱们对微服务零碎的稳定性进行了一系列晋升。因为 MSE 所提供的微服务治理能力是基于 Java-Agent 字节码加强的技术实现，和咱们应用的 Spring Cloud 微服务框架能够完满匹配。这些晋升齐全没有代码侵入，所以建设这些能力是很简略的。
首先解决的是无损高低线问题。 做过大规模微服务架构的敌人都晓得，无损高低线问题是一个困扰了很多开发者的老大难问题。MSE 的微服务治理 Agent 做了两件事件，一是动静感知利用高低线的行为，二是动静调整服务消费者的负载平衡策略。通过这两个事件很轻松的实现了利用无损高低线。当初咱们不论是做利用的扩缩容，还是版本公布，都能够做到对最终用户无感。
在全链路灰度方面，MSE 也提供了残缺的解决方案。 生产环境只须要一套环境，就能够基于泳道模型定义多个逻辑的灰度版本，再通过路由规定的配置，让特定的流量在对应的泳道中流转。这样就能够在公布新版本的时候，严格控制新版本影响的申请量，通过充沛的验证后，再决定到底是加大新版本的覆盖度，还是回滚到上一个版本，从而将版本公布对失常业务的影响降到最低。
因为全链路灰度对于整个研发以及运维的流程提出了更高的要求。咱们目前只在一条业务线上进行了推广，失去的收益是很显著的，因为利用变更导致的生产事变升高了 70% 以上。 后续咱们会再接再厉，将全链路灰度推广到整个企业。
此外，全链路流量防护也是咱们基于 MSE 构建的晋升业务稳定性的重要伎俩。从网关到微服务利用，到第三方依赖，每一层咱们都配置了流量防护规定，确保在业务高峰期不会有任何零碎被用户流量所压垮。
这是云快充当前的技术架构。为了保障充电桩连贯的稳定性，咱们搭建了专门的集群，双服务通过 TCP 强连贯与双通信提供根底能力。随同着云快充的全面容器化与稳定性建设，云快充接入的电桩数量实现了 20 万到 30 万的增长，均匀需要迭代周期从 7 人日升高到 4 人日，极大地促成了业务的疾速迭代。
瞻望
除了持续晋升全链路灰度覆盖度之外，咱们在未来还有两大布局：一是通过边缘容器计划晋升咱们的服务质量，这和云快充的业务特点是有关系的。在网络中断等极其场景下，基于边缘节点的能力，也能让局部业务能够失常对外服务，不至于用户在这种状况下齐全无奈充电。二是加强端到端的平安治理。在防攻打、登录认证、波及网关的双线 TLS 外部服务、权限治理等方面，都增强平安防护伎俩。
心愿阿里云的计划可能帮忙咱们更快地实现这两个布局，也心愿新能源行业的其余技术团队能够和咱们一起独特摸索云原生稳定性方面的技术门路。
