云快充研发中心平台架构师谈云原生稳定性建设之路

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 云快充云原生稳定性之路

来自云快充研发中心的平台架构师吕周洋,给大家分享云快充云原生稳定性之路。https://www.bilibili.com/video/BV16P4y1e7jA/


云快充成立于2016年,以充电服务和能源管理为核心,业务涵盖九个方向。截止到2022年11月,业务覆盖370个城市,接入电桩运营商 7400人,接入充电终端31万家,与640个桩企达成合作。目前,新能源行业发展情况除了大力满足业务的快速发展,服务更多客户外,云快充一直非常重视线上服务的稳定性建设,以提升用户的充电体验。


业务系统容器化


为了确保业务的稳定运行,云快充从 2019年 就确定了业务系统百分之百容器化的技术路线。在当时虽然容器平台还有其他的一些方案可以选择,但基本已经可以明确的感受到K8s 成为云原生时代的基础设施底座的技术趋势。K8s 能够带来的价值是多方面的,包括研发运营与效率的提升,降低资源成本等。

image.png

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


这一点我们在实战中也验证过。在业务高峰期,通过 K8s 的弹性伸缩能力,可以实现基于业务负载的自动弹性扩容。这个弹性能力涉及到工作负载的水平伸缩以及计算资源的水平伸缩。在全面使用 K8s 之前,我们考虑过类似的方案,但因为担心影响业务稳定性,并没有真正投入大规模使用。全面容器化之前,我们的团队也尝试自己搭建 K8s 集群,验证 K8s 的各项能力,通过一段时间的实战,还是遇到了不少的挑战。

image.png

K8s 是一个大型复杂的分布式系统,涉及十多个核心组件,这些组件和云上的 IaaS 层产生集成的时候就更为复杂了,光是搞定网络插件就需要投入不少的精力,我们也没有专业的技术人员能够快速解决节点异常、Pod 异常、网络不通等问题。特别是有时候遇到 K8s 本身的 bug,就更无能为力。开源 K8s 本身的bug其实还是很多的。当前社区处于 open 状态的 issue 就有1600多个。集群规模比较大的时候,系统的各个组件均出现相应的性能问题的机会也就变高了。如果遇到 etcd 的性能瓶颈,会导致集群一系列的问题发生,体现在业务侧,就是用户充不上电。


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


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


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

image.png

ACK 还集成了一个非常好用的集群诊断工具,它是基于eBPF技术实现的,对我们来说提供了一个开箱即用的能力,一键开启就可以。这个工具提供了全局视角的应用拓扑,遵循了从整体到个体的原则,先从全局视图入手,从请求数、错误数、延误三个黄金指标出发,发现异常的服务个体,如某个应用服务,定位到这个应用后,可以获取日志,关联分析。在一个页面展示分层下钻,不需要多个系统来回跳转,方便快速定位拓扑中的服务调用,这些有价值的数据都导入到了云上的 Prometheus 服务。大家也知道在云原生时代,Prometheus 在可观测领域的地位就相当于 K8s 在云原生底座的地位。


通过云上的 Prometheus 和 Grafana ,我们将 eBPF 指标与云产品的指标结合在一起,做了一个业务监控大盘,通过这个大盘就能了解到当前业务的进展情况。对于重要的接口,我们也基于服务质量配了告警规则,通过 ARMS 告警平台,通知到运维群,保证核心服务的SLA,这对于提升我们的业务稳定性起到了很大的帮助。

image.png


构建业务稳定性


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


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

image.png

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


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


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


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


这是云快充当前的技术架构。为了保障充电桩连接的稳定性,我们搭建了专门的集群,双服务通过TCP强连接与双通信提供基础能力。伴随着云快充的全面容器化与稳定性建设,云快充接入的电桩数量完成了20万到30万的增长,平均需求迭代周期从7人日降低到4人日,极大地促进了业务的快速迭代。

image.png


展望


除了继续提升全链路灰度覆盖度之外,我们在将来还有两大规划:一是通过边缘容器方案提升我们的服务质量,这和云快充的业务特点是有关系的。在网络中断等极端场景下,基于边缘节点的能力,也能让部分业务可以正常对外服务,不至于用户在这种情况下完全无法充电。二是增强端到端的安全治理。在防攻击、登录认证、涉及网关的双线TLS内部服务、权限管理等方面,都加强安全防护手段。


希望阿里云的方案能够帮助我们更快地实现这两个规划,也希望新能源行业的其他技术团队可以和我们一起共同探索云原生稳定性方面的技术路径。





相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
26天前
|
Cloud Native Java 编译器
将基于x86架构平台的应用迁移到阿里云倚天实例云服务器参考
随着云计算技术的不断发展,云服务商们不断推出高性能、高可用的云服务器实例,以满足企业日益增长的计算需求。阿里云推出的倚天实例,凭借其基于ARM架构的倚天710处理器,提供了卓越的计算能力和能效比,特别适用于云原生、高性能计算等场景。然而,有的用户需要将传统基于x86平台的应用迁移到倚天实例上,本文将介绍如何将基于x86架构平台的应用迁移到阿里云倚天实例的服务器上,帮助开发者和企业用户顺利完成迁移工作,享受更高效、更经济的云服务。
将基于x86架构平台的应用迁移到阿里云倚天实例云服务器参考
|
11天前
|
缓存 物联网 数据库
如何帮助我们改造升级原有架构——基于TDengine 平台
一、简介 TDengine 核心是一款高性能、集群开源、云原生的时序数据库(Time Series Database,TSDB),专为物联网IoT平台、工业互联网、电力、IT 运维等场景设计并优化,具有极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一个高性能、分布式的物联网IoT、工业大数据平台。 二、TDengine 功能与组件 TDengine 社区版是一开源版本,采用的是 AGPL 许可证,它具备高效处理时序数据所需要的所有功能,包括: SQL 写入、无模式写入和通过第三方工具写入 S标准 SQL 查
43 13
|
13天前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
|
1月前
|
Kubernetes 监控 Cloud Native
Cluster Optimizer:一款云原生集群优化平台
**Cluster Optimizer** 是一款云原生集群优化平台,旨在通过自动化和智能化工具帮助企业降低云成本,解决云原生架构中的成本管理难题。面对资源闲置、配置不当和缺乏自动化优化机制等挑战,Cluster Optimizer能够深入分析云资源、应用和用户行为,精准识别优化机会,并给出具体建议,涵盖节点组、节点、GPU 节点、磁盘、持久卷和应用等多个维度。通过优化实例类型、自动扩缩容和资源分配,帮助企业降低成本、提升性能和效率。[点击此处](https://www.wiseinf.com.cn/docs/setup/) 免费安装和试用 **Cluster Optimizer 社区版**。
81 9
|
12天前
|
编解码 Linux 开发工具
Linux平台x86_64|aarch64架构RTMP推送|轻量级RTSP服务模块集成说明
支持x64_64架构、aarch64架构(需要glibc-2.21及以上版本的Linux系统, 需要libX11.so.6, 需要GLib–2.0, 需安装 libstdc++.so.6.0.21、GLIBCXX_3.4.21、 CXXABI_1.3.9)。
|
2月前
|
存储 边缘计算 Kubernetes
边缘计算问题之边缘计算平台建设中业务应用践行云原生体系如何解决
边缘计算问题之边缘计算平台建设中业务应用践行云原生体系如何解决
50 1
|
2月前
|
编解码 Linux 数据安全/隐私保护
Linux平台x86_64|aarch64架构如何实现轻量级RTSP服务
为满足在Linux平台(x86_64与aarch64架构)上实现轻量级RTSP服务的需求,我们开发了一套解决方案。该方案通过调用`start_rtsp_server()`函数启动RTSP服务,并设置端口号及认证信息。支持AAC音频和H.264视频编码,可推送纯音频、纯视频或音视频流。此外,还支持X11屏幕采集、部分V4L2摄像头采集、帧率/GOP/码率调整、摄像头设备选择与预览等功能。对于音频采集,支持alsa-lib和libpulse接口。整体设计旨在提供150-400ms的低延迟体验,适用于多种应用场景。
|
2月前
|
缓存 架构师 数据库
缓存系统稳定性 - 架构师峰会演讲实录
缓存系统稳定性 - 架构师峰会演讲实录
|
3月前
|
消息中间件 负载均衡 数据管理
微服务架构在电商平台中的应用与实践
在现代电商平台的开发和运维中,微服务架构成为了提升系统灵活性和可扩展性的关键技术。本篇文章从实践出发,深入探讨了微服务架构在电商平台中的具体应用,包括服务拆分策略、通信机制、数据管理、以及常见的挑战和解决方案。通过真实的案例分析和代码示例,帮助读者全面了解微服务架构的优势和实施方法,提供在实际项目中的实践指导。
|
3月前
业务系统架构实践问题之在财务信息化研发中为何选择将事务控制放在biz层
业务系统架构实践问题之在财务信息化研发中为何选择将事务控制放在biz层
下一篇
无影云桌面