分布式系统韧性架构压舱石OpenChaos

转载 收藏 评论
举报 2022-05-09

上层应用带来的诸如可靠、安全、弹性等一系列韧性架构的挑战。

混沌工程思想给我们带来了一定程度的启发。Netflix 最初为了搬迁基础设施上云创建了 Chaos Monkey,由此拉开了混沌工程学的序幕。再到后来,CNCF 成立了专门的兴趣小组,希望能够推动这一领域的标准诞生。OpenChaos 创始团队早期也和这些社区的先行者进行过多轮交流。可惜的是,2019 年该兴趣组并入 App Delivery SIG 后再无太大动静。这几年国家政策大力引导下,企业的数字化升级不断加快,越来越多的 CIO、CTO 甚至包括 CEO 开始重视并投入到混沌工程实践中。国内由中国信通院牵头的混沌工程实验室也在积极推动该领域标准的制定,从全链路压测、混沌故障引入到催生未来架构变革的多云多活参考架构,这些无不昭示着这一产业在飞速发展。根据国内外科技媒体调研统计,到 2025 年,80% 的组织将实施混沌工程实践。通过全链路压测、混沌故障,以及多云多活架构等策略的整体导入,可以将意外停机时间减少 50%,实现真正意义上的秒级 RTO/RPO,让应用、业务创新更加专注。

良药虽好,但也有局限

混沌工程的最基本流程是在生产环境小规模定期自动化执行试验,为系统随机注入故障,来观察 “系统边界”。它主要关注系统面对故障所展现出的容错能力和可靠性。目前市面上绝大部分混沌工程工具,倾向于构造以黑盒随机为主的故障类型,对底层基础设施(硬件、操作系统、数据库与中间件)理解与洞察较少。缺少统一的框架标准、成熟的 specific 度量指标。同时,分析反馈较弱,无法给出全面彻底的诊断建议,尤其通过强化学习,生成式 AI 等能力可以进一步解决目前随机故障注入,进行自愈风险分析与优化建议。

面向有更多复杂特性的分布式系统,仅通过观察系统应对故障的表现是有局限的,并且依赖于观察是极其主观的,很难形成统一的评测标准,也较难针对表现分析系统缺陷。系统的可观测性,不仅需要模型的全面覆盖,还需要完备的监测系统,并提供全面的结果报告,甚至智能预测,来指导架构提升自身的韧性能力。分布式领域资深技术专家、开源顶级项目 Apache RocketMQ、OpenMessaging 最初的创始人冯嘉曾表示“云原生分布式架构的演进正在朝着组装式架构、韧性架构进一步发展”。在这样的背景下,他提出并带领团队创造了 OpenChaos 这一新兴项目。

OpenChaos 需要解决的本质问题

韧性架构,覆盖高靠性、安全、弹性、不可变基础设施等特性。实现真正的韧性架构毫无疑问是现代分布式系统的演进方向。针对分布式系统韧性能力,OpenChaos 借助混沌工程思想,对其定义进行延伸扩展。针对一些分布式系统特有属性,如 Pub/Sub 系统的投递语义与推送效率,调度编排系统的精准调度、弹性伸缩与冷启效率,streaming 系统的流批实时性、反压效率,检索系统的查全率与查准率,分布式系统共识组件的一致性等,设置专用的检测模型。OpenChaos 内置可扩展的模型支持,以便验证在大规模数据请求以及各种故障冲击下的韧性表现,并为架构演进提供进一步优化建议。


本文系作者授权数英发表,内容为作者独立观点,不代表数英立场。
转载请在文章开头和结尾显眼处标注:作者、出处和链接。不按规范转载侵权必究。
本文系作者授权数英发表,内容为作者独立观点,不代表数英立场。
未经授权严禁转载,授权事宜请联系作者本人,侵权必究。
本内容为作者独立观点,不代表数英立场。
本文禁止转载,侵权必究。
本文系数英原创,未经允许不得转载。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权,侵权必究。

    评论

    文明发言,无意义评论将很快被删除,异常行为可能被禁言
    DIGITALING
    登录后参与评论

    评论

    文明发言,无意义评论将很快被删除,异常行为可能被禁言
    800

    推荐评论

    暂无评论哦,快来评论一下吧!

    全部评论(0条)