写点什么

如何处理分布式系统中的紧急情况?

  • 2021-05-01
  • 本文字数:2116 字

    阅读完需:约 7 分钟

如何处理分布式系统中的紧急情况?

本文最初发表于 gitconnected 博客,经原作者 Gregory Pabian 授权,InfoQ 中文站翻译并分享。


由于发生意外或遭受攻击,任何分布式系统都可能会遇到紧急情况。即便是像执行脚本这样看似无害的操作,也可能会对整个平台造成严重破坏,最终导致用户无法使用。本文作者分享了软件开发者在紧急情况发生之前为系统做好准备的一些方法。

 

免责声明:我不是软件安全专家,而是一名全栈软件开发者,本文中的所有信息都源于我的开发经验。我希望讨论主要的可能性以准备和处理紧急情况,但我不打算就正确和错误的做法提出看法。至于如何设计一个安全的分布式系统,这可能需要用到资深安全工程师的专业知识。

应急预案

 

我相信系统设计者可能会考虑准备一个应急预案,至少要知道如何保护一个分布式系统不受内外威胁。我从各种 OWASP(即 Open Web Application Security Project,开放式 Web 应用程序安全项目,是一个在线社区,在 Web 应用安全领域提供免费的文章、方法、文档、工具和技术。)资源中学到了很多关于网络应用安全的知识。

 

在我看来,应急预案至少应该包括对下列问题的回答:

 

  • 谁可以启动应急预案,以及有哪些权利;

  • 应急预案实施期间将发生什么情况,在哪里发生;

  • 如何才能有人启动应急预案,将会持续多久。

 

本文假定系统管理员可以使用 CLI 以系统上的最高权限启动应急预案,该措施的调用将无限限制多个后台的某些功能。

时间框架

 

这个应急预案可在这两个时间框架下生效:

 

  • 过去和未来:系统会根据指定的过去和所有未来事件改变其行为;

  • 未来:系统会根据所有未来事件改变其行为。

 

当然,并非所有的分布式系统都支持逆行性行为变更。在使用长时间运行事务的系统中,遵守这样的转换要求执行补偿性事务,这样才能明显消除原始过去事务的影响。

解决方案

 

我将所有可能的解决方案分为三组:无状态协议(如 HTTP)中阻止访问的方案、基于消息的系统(如 Kafka)中阻止访问的方案,以及回滚事务的方案。只要它们在所设计的系统中实际发挥作用,系统架构师就可以选择应用这些解决方案中的一些,甚至是并行的。

无状态协议中阻止访问

 

阻止特定的访问令牌(例如 JWT)可以说是通过限制特定用户对资源的访问来解决紧急情况的最精确的方法。若攻击者已获得访问令牌,并且可能将其用于非法用途,则系统可应用此解决方案。根据暴露程度的不同,此解决方案可以影响到一个或多个后端。

 

系统也可以组织访问特定的访问方法(例如 HTTP 端点或 RPC)。如果系统管理员不知道特定攻击者的访问令牌,或者由于最新的部署,端点无法正常工作,那么他们可能会选择此解决方案。在选择用这种方法解决问题之前,我认为人们应该考虑一下锁定整个功能的后果,以及如何与最终用户沟通这个选择。

 

在阻止某些服务中的某些访问方法无效的情况下,可以考虑关闭该服务。在分布式系统中,这相当于禁止在相关服务实例中向负载均衡器转发请求,或者终止所有以上实例。不管选择哪种解决方案,都会对系统造成严重的影响,因为很多功能已经不能工作了。

 

最后,系统管理员可以决定关闭整个系统(或者至少所有后端)。关闭分布式系统的精确算法在很大程度上取决于其基础设施和使用的冗余。若有人考虑到这一可能性,则应考虑到后果,因为除了某些可能在离线模式下工作的前端功能外,系统将会停止工作。

基于消息的系统中阻止访问


系统管理员可以禁止在基于消息的系统内共享特定的消息。有些情况下,消息代理可以应用此类策略,而有些情况下,这一工作属于后端。这样的规则,读者可以将其视为判定函数,它接受一个参数、一条消息,然后返回一个布尔值。

 

另外,人们可以选择阻止特定的主题或通道分发消息。它会间接地影响依赖这种通信方式的后端。此外,人们也可以禁止某种服务通过某一主题或通道收发消息。

 

最后,有人可能会决定阻止整个消息管道。与关闭整个系统一样,这种解决方案对系统内的通信产生巨大影响,并可能导致多个功能失效。软件开发者在出现这种情况之前,应该弄清楚哪些功能可能会崩溃。

回滚事务


在后端向关系数据库提交某些事务之前,系统可能会回滚它们。这类规则的应用要求对后端架构进行有效性检查,并确保后端能够及时接收策略变更信息。此解决方案可以作为取消已启动事务的示例。

 

对于使用依赖注入的后端,一个基于紧急情况的限制列表可以驻留在所有请求或消息处理程序重用的组件中。人们可以使用全局变量实现类似的结果,但是我不赞成这种方法。


处理程序可以运行一个检查函数,以验证对于当前评估的请求是否存在某些限制。当系统使用紧急编排时,接受紧急通告的后端需要与系统的其他部分通过无状态请求或消息管道共享信息。若后端无法执行此操作,则将阻止应急响应的传播。系统设计者应该找到避免这个障碍的方法,例如,让前一个服务等待下一个服务确认信息处理,然后继续进行处理。

总结

 

在本文的开头,我已经指出,由于不同的系统使用不同的模式进行后端到后端的通信,所以在分布式系统中处理紧急情况的方法多种多样。我认为,尝试将危机应对措施融入开发中的系统中,或许可以为系统设计提供许多参考。

 

作者介绍:

 

Gregory Pabian,全栈软件开发者,热爱构建产品。

 

原文链接:

 

https://levelup.gitconnected.com/emergencies-in-distributed-systems-9f93c6d75600

2021-05-01 10:102199

评论

发布
暂无评论
发现更多内容

【Vue2】文本无缝滚动

德育处主任

Vue 大前端 28天写作

Reactive Spring实战 -- 响应式Redis交互

binecy

redis Reactive Spring

LeetCode题解:433. 最小基因变化,BFS+生成所有可能新基因再匹配,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

年关将至

luojiahu

小产品、连接和生态

孙苏勇

产品 产品定位

如何做到超预期供应

熊斌

28天写作

怀着期待开启美好的一天「幻想短篇 23/28」

道伟

28天写作

【计算机内功修炼】八:函数运行时在内存中是什么样子?

码农的荒岛求生

高并发 内存 高性能 内存管理 运行时栈帧

mPaas上线应用检测

阿里云金融线TAM SRE专家服务团队

ios android RPC

产品训练营-第六课笔记

Geek_娴子

GameStop: 究竟发生了什么?

lidaobing

28天写作 逼空

架构师训练营第10周课后作业

万有引力

week10-homework

J

VS2019 + Qt Creator 4.11.1 导入Qt源码进行调试记录

Creep

c++ qt

我的电脑嘲讽我!

IT蜗壳-Tango

七日更

机器学习笔记之:虽然还没明白到底是在干嘛,但竟然还觉得挺有意思的!

Nydia

创业失败启示录|茶之玄学

阿萌

28天写作 创业失败启示录 青城

管事情的过程,如何聚焦并决策高价值的事?

一笑

管理 优先级队列 28天写作

还不清楚Lambda的底层原理?一文帮你搞懂

后台技术汇

28天写作

外企时代已经过去?

李忠良

28天写作

同城快递架构设计

Mars

28天瞎写的第二百三十三天:唯工具论的错误

树上

28天写作

浅谈JavaScript常见的循环方式

devpoint

foreach for for...of

《学会写作》学习笔记之如何选题

JiangX

28天写作

碎碎念之「创造力可能是新的生产力」

Justin

创意 28天写作 创造性思维

week10-总结

J

NullPointerException 的处理新方式,Java14 真的太香了!

xcbeyond

Java java 14 新特性 28天写作

管理笔记[2]:独裁者X与民主统治者Y

L3C老司机

发布 Go Modules

Rayjun

go modules Go 语言

开发质量提升系列:表字段名称引发的血案

罗小龙

代码规范 28天写作

项目管理知识标准体系

Ian哥

28天写作

如何处理分布式系统中的紧急情况?_文化 & 方法_Gregory Pabian_InfoQ精选文章