写点什么

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

  • 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:102179

评论

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

Python Qt GUI设计:5种事件处理机制(提升篇—3)

不脱发的程序猿

Python qt PyQt GUI设计 事件处理机制

5.《重学JAVA》--编码规范

杨鹏Geek

Java 25 周年 28天写作 12月日更

共享

mtfelix

28天写作

模块一学习总结

Only

「架构实战营」

架构实战营 - 微信业务架构 & 学生管理系统

阿门阿前一颗葡萄树๑

架构实战营 #架构实战营 「架构实战营」

【技术分享】DOSM Web项目优化分析 & 解决方案

云智慧AIOps社区

Hoo虎符研究院 | 币圈后浪——KBOX

区块链前沿News

虎符 Hoo虎符 Hoo 虎符交易所

全员客户成功

boshi

随笔杂谈

TypeScript 之映射类型

冴羽

JavaScript typescript 翻译 大前端

Python Qt GUI设计:QTabWidget、QStackedWidget和QDockWidget容器控件类(提升篇—2)

不脱发的程序猿

Python qt PyQt GUI设计 容器控件类

从航海贸易到元宇宙,从公司制到DAO

CECBC

2021年度人工智能最佳产品TOP10!百度飞桨EasyDL再获业界认可

百度大脑

人工智能

模块一作业

撿破爛ぃ

「架构实战营」

创业团队组织建设-跨部门沟通

wood

创业 沟通 28天写作

Hoo虎符研究院 | 区块链简报 20211206 期

区块链前沿News

虎符 Hoo虎符

被寄予厚望的区块链在数据交易中能发挥的作用是什么?

CECBC

如何“对抗”听众的短时记忆

将军-技术演讲力教练

星环科技分布式文件系统TDFS大揭秘(上)

星环科技

大数据 计算与存储

实用机器学习笔记五:探索性数据分析

打工人!

机器学习 学习笔记 12月日更 李沐 实用机器学习

vue单页面和多页面的区别?

CRMEB

区块链电子签章平台搭建,区块链电子合同系统

电微13828808271

数研所已实现在数字人民币中积极探索区块链应用

CECBC

IT 好文&好课分享

hackstoic

架构实战营4期-第1周作业

周念

「架构实战营」

【AI最前线】精准优质-资讯|分享|热议第43期

百度大脑

人工智能

非专业的系统安全规范

张老蔫

28天写作

AI安全领域的“雨山机车大赛”,改变了什么?

脑极体

流上机器学习,星环科技Sophon Base助力海洋石油富岛工艺监测智能化

星环科技

数字人民币生态体系进一步完善 试点场景加速拓展

CECBC

同程旅行 IAST 落地实践

火线安全

DevOps DevSecOps 漏洞扫描 漏洞分析

xxxx

guangbao

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