西部数码网站管理助手ftp,网站二次开发多少钱,网站接入服务单位,天津关键词优化专家作者#xff1a;吕周洋
大家好#xff0c;我是来自云快充研发中心的平台架构师吕周洋#xff0c;今天我给大家分享云快充云原生稳定性之路。
点击查看#xff1a;云快充研发中心平台架构师 吕周洋#xff1a;云快充云原生稳定性治理之路
云快充成立于2016年#xff0c…作者吕周洋
大家好我是来自云快充研发中心的平台架构师吕周洋今天我给大家分享云快充云原生稳定性之路。
点击查看云快充研发中心平台架构师 吕周洋云快充云原生稳定性治理之路
云快充成立于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内部服务、权限管理等方面都加强安全防护手段。
希望阿里云的方案能够帮助我们更快地实现这两个规划也希望新能源行业的其他技术团队可以和我们一起共同探索云原生稳定性方面的技术路径。
