写点什么

银行业中的弹性系统

  • 2018-10-19
  • 本文字数:4355 字

    阅读完需:约 14 分钟

本文要点

  • 冗余和隔离是同一枚硬币的两面。
  • 防范自己的 Bug,而不仅仅是环境因素。
  • 减速比崩溃更容易跨越服务边界。
  • 同步 API 为故障传播提供了充足的机会——务必避免!
  • 已建立的云模式是有效的,即使没有调度程序和网格——第一天的架构应该简单到极点。

弹性是容忍失败,而不是消除它。

你不能把所有的时间都花在避免失败上。如果你这样做了,你将构建出一个脆弱到无可救药的系统。如果你真希望建立一个弹性系统,就必须构建一个能够吸收冲击并继续或恢复的系统。

在“斯塔林银行(Starling Bank)”,在现有银行公共服务大量中断的背景下,我们在一年的时间里从零开始创建了一家银行;我们知道,我们需要可靠的弹性方法。我们需要来自混沌工程的保障,以及使最好的创业公司得以茁壮成长的对简单性和严格优先级的执着追求。

以下是我们的弹性方法背后的原则和信念。

顺便说一下,我们的方法有一些特性,我在这里不做介绍,但它们仍然是必不可少的:

  • 混沌工程——因为弹性必须测试;
  • 监控——因为弹性需要可支持性;
  • 事件响应——因为弹性适用于系统和运行它的组织。

相反,我们关注的是从基础设施往上的弹性架构。

弹性架构

为客户提供弹性服务意味着,要确保在故障发生时,受错误影响的系统部分与系统整体相比很小。

有两种方法可以确保这一点。冗余是指确保系统作为一个整体扩展到故障范围之外。不管有多少受损,我们都有其他备用的。隔离是指确保故障局限在一个很小的范围内,而不能扩展到我们系统的边界。

无论你如何设计系统,都必须对这两个问题有很好的答案。有鉴于此,你必须针对你能想象到的每一个错误在脑海中测试你的设计。

请考虑以下方面的失败,希望对你有所帮助:

  • 基础设施层故障(如网络故障)以及应用程序层的故障(如未捕获的异常或终止);
  • 我们构建的软件的内部故障(由我们即 Bug 导致)以及外部故障(由其他人如非法消息导致)

仅仅假定通过测试可以消除内部故障是不够的。保护自己不受外界干扰和保护自己不受自己干扰一样重要。

设计的简单性是影响失败归因难易程度的最重要因素,所以总是选择满足你需求的最简单设计。

冗余

基础设施冗余在云中很容易实现。基础架构即代码使我们在创建多个时可以和创建一个一样容易。

云提供商,如 AWS 和 GCP,提供了 IaaS 原语,如负载均衡器缩放组,并在文档中清楚记录了它们的使用模式。像 Kubernetes 这样的执行环境提供了部署复制控制器等资源,其中,复制控制器持续保证服务的多个副本正在运行并可用。无服务器技术将在不进行任何配置的情况下为你扩展服务。

但也有一些限制。

状态是老敌人了。当实例假设本地状态准确时,扩展服务的难度就大许多。要么通过一个高可用的数据存储和外部共享状态,要么引入集群协调机制来保证每个实例的本地状况与对等实例的一致,总之,将服务器转化为分布式缓存。

我的建议是,至少对于创业公司来说,在第一天要保持非常简单。数据库用于共享状态。用它共享所有状态,直到达到其极限。本地内存仅用于瞬态状态。这为你提供了一个简洁的“不可变的”计算层和一个具有明确操作需求的数据库。你知道,你需要在某个时候改进这个基础设施,同步修改架构并监控指标。到那一天,你就从简单的扩展和冗余受益了。

无服务器环境通常提供一个无状态函数服务,并针对状态提供单独的数据库服务,这实际上是默认提供了简单巧妙的分离。

共享资源限制可能是另外一个问题。当后端数据存储仅支持接受 3 个连接时,将服务扩展到 10 个实例是没有意义的。事实上,当服务公开其他组件以加载它们无法支持的组件时,扩展服务可能是危险的。增加系统某一部分的性能会降低系统的整体性能。实际上,如果没有高强度的测试,你就无法了解所有这些限制。

隔离

在云基础设施层,AWS 在每个区域内提供单独的可用区,在基础设施组件之间提供强隔离。负载均衡器和伸缩组可以跨越多个可用区。

在 AWS 中已建立的构建模式可以确保你做好基础工作。其他云也有类似的功能。

在应用程序层,微服务自包含系统、甚至传统的 SOA 都是可以在服务之间引入强隔离带的设计方法,允许这些组件独立失败,而不影响整体的服务能力。

如果服务的单个实例崩溃,则服务不会中断。如果服务的每个实例都崩溃,客户体验可能会在某种程度上受到影响,但其他服务必须继续运行。

使用这种模式,系统分割得越细,单个服务故障影响的半径就越小。但还是那句话,魔鬼是在细节当中。服务之间可以通过许多微妙的方式相互依赖,这些方式跨越服务边界,使得错误会在系统中扩散。当服务密切相关时,通常可以简单地将它们视为单个服务,并将它们构建为单个服务。

有些方式可能不太明显,比如隐藏协议;服务实例可能通过负责 Master 选举的集群协议进行连接,或者通过针对每个事务(如果你参与了这类事务)进行网络投票的两阶段提交协议。工程师们常常会完全脱离这些网络交互,但它们用错误可以传播的方式将服务连接在一起。

就像在生活中一样,同居是一个不可掉以轻心的决定。如果你在同一个实例上运行多个服务,无论是经过深思熟虑的静态分组,还是使用像 Kubernetes 这样的调度器,这些服务的隔离程度都要比在单独的机器上低。它们都受许多相同故障条件的影响——尤其是硬件故障。

如果服务 X、Y 和 Z 的实例总是在同一台主机上一起运行,那么如果 X 可以任意运行并“毒害”主机,那么不管有多少个实例,X 的邻居都是 Y 和 Z。把它们分到一组,就侵蚀了服务 X、Y、Z 之间的隔离——即使你的技术应该保证这种“中毒”情况不会发生。

调度程序可以通过避免在任何地方部署相同的服务集来缓解这一问题。因此,如果一个有 Bug 的服务毒害了它的主机,你不会看到任何其他服务的完全失败,而是在更广泛的服务范围内产生较为分散的局部影响,而这可能根本不会影响客户体验。

在我们推出的架构中,斯塔林银行选择了一个简单的单服务 EC2 实例模型。这是一种权衡,特别注重简单性而不是经济性,但也提供了非常强的隔离。失去一个实例是很难察觉的。即使我们部署了一个流氓服务,对它的主机做了一些有害的事情,它也不容易影响到其他服务。

在应用层代码中传播错误的方法也很多。

也许最有害的因素是时间本身

在任何事务型系统中,时间都是最有价值的资源。即使你没有在处理器上进行主动调度,你也可能在完成工作的时间内持有重要的资源:连接、锁、文件、套接字。如果你磨磨蹭蹭,就会让别人挨饿。如果另一个线程无法继续,它可能不会释放它所持有的资源。它可能迫使其他服务进入等待状态,在整个系统中传播不良影响。

虽然死锁经常被描述为并发编程中的邪恶反派,但在现实中,由于事务运行缓慢而导致的资源匮乏可能是一个更常见而又同样严重的问题。

这一点太容易忽视了。工程师的第一直觉是安全而正确的:获取锁,进入一个事务,也许简单考虑了下超时设置然后就跳过了它——(工程师讨厌任何看起来随意的东西,对于如何处理超时,会有尴尬的选择)……日常开发中的这些简单诱惑能给生产环境造成严重伤害。

不能允许等待和延迟在服务之间传播。但是,除非你对这种不当行为有一些全局的预防措施,否则不难想象,你的系统容易受到攻击。你有固定大小的数据库连接池吗?或者线程池?你确定在进行 REST 调用时从不持有数据库连接吗?如果这样做了,当网络通信降级时,是否会耗尽连接池?其他还有什么会耗费时间?那些你几乎看不到的东西呢,比如日志调用?或者,你可能有一些需要反复收集的指标需要数据库访问,但由于池中的连接被用光了,所以数据库访问开始失败,导致大量的垃圾被写到日志中?然后,你也许会突破日志架构的限制,从而失去对正在发生的一切的可见性。构建一个噩梦般的场景是一件很有趣的事情,而这个场景是以一点点的拖延开始的。

预防措施有很多:断路器、“隔板(bulkheads)”、重试设置、最后传播期限……还有一些库可以帮助你在软件( hystrix resilience4j )中实现这些模式,也有一些服务网格或中间件( istio conduit linkerd )在底层提供了其中部分模式。但如果不投入时间和精力,它们都不会做正确的事情。和往常一样,任何代码的性能和故障模式都将反馈给工程师。

同步调用借用了别人的时间。而且,作为一个同步 API,按照合理的设计原则,你通常不知道这段时间对调用者有多么宝贵,也不知道它们多么容易受你的拖延或失败影响。你把他们扣为了人质。因此,我们更喜欢在服务之间使用异步 API,并且只在绝对必要或者是非常简单的只读调用中使用同步 API。

前端可以进行“乐观”的 UI 更新,而不是等待确认,并在离线时显示过时的信息。在大多数情况下,根据过时的信息进行决策需要付出一定的代价,但这种代价不一定很高。Pat Helland 曾经写道:计算由记忆、猜测和道歉组成。当系统表示偏离现实时总是有代价的,当现实在你背后发生变化时,它总会在某个时候偏离现实。在分布式系统中没有真正的“现在”。在决定需要完美的事务语义或同步响应之前,评估下“错误”的代价。

对于银行系统来说,容忍失败意味着容忍失败而不丢失信息。因此,虽然实现异步系统不一定需要队列,但你可能希望系统作为一个整体表现出一些类似队列的属性——至少一次最多一次交付,即使存在错误。通过这种方式,你可以确保某些服务始终拥有数据或命令的所有权。

你可以通过在服务中同时使用幂等性和追踪处理来达到这两个目的(如斯塔林的“DITTO”架构——有很多自治服务不断尝试做互相幂等的事情),或使用队列保证至少一次,使用幂等载荷保证至多一次(如 Nubank 的 Kafka 基础设施)、或设法把它们都委托给“企业服务总线”(如许多传统银行的架构)。

使用这些技术,完全有可能在异步交互服务的基础上创建响应性应用程序。

总结

编写弹性系统比以往任何时候都容易。在前 12 个月的运营中,斯塔林银行经历了许多局部故障和系统部分退化——从来没有出现过整个系统不可用。这主要是因为我们在每个层面上都强调冗余和隔离。

我们设计了一个能够容忍服务中断的架构,并特别重视这样一种观点,即慢服务对最终用户的威胁可能比死服务更大。

如果一开始我们对于上面列出的各项——混沌工程、监控和事件响应——没有可靠的方法,那也没有关系。但这得再一天介绍了。

关于作者

Greg Hawkins 是技术、金融科技、云计算和 DevOps 等领域的一名独立顾问。他在 2016 年至 2018 年期间担任斯塔林银行的首席技术官,这是英国一家仅限移动端的挑战者银行。在此期间,这家金融科技初创企业获得了银行牌照,两大移动平台上的下载量都突破 10 万次。现在,他仍然是斯塔林银行的高级顾问。斯塔林从零开始构建了全栈银行系统,成为英国第一个完全部署在云上、普通公众可以使用的经常账户,并满足了适用于零售银行的所有监管、安全和可用性预期。

查看英文原文: Resilient Systems in Banking

2018-10-19 16:102180
用户头像

发布了 1008 篇内容, 共 390.9 次阅读, 收获喜欢 344 次。

关注

评论 1 条评论

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

Scrum Master是什么?Scrum Master的职责是什么?和PM又有哪些区别?

爱吃小舅的鱼

敏捷开发 PM Scrum Master

企业如何选择合适的低代码平台?这6点不得不考虑!

J2PaaS低代码平台

低代码 低代码开发 低代码平台 企业数字化

我是一个程序员,总想引导亲朋好友走上编程的伟大航路......

图灵教育

程序员 App Inventor

不要再重复造轮子了,Hutool这款开源工具类库贼好使

沉默王二

Java

手把手教你学Dapr - 2. 必须知道的概念

MASA技术团队

C# .net 微软 后端 dapr

项目管理常见问题系列(1)—资源不足

一叶而不知秋

项目管理

拥抱智能,AI 视频编码技术的新探索

阿里云视频云

阿里云 视频编码 机器视觉 视频编解码 视频云

浅谈 RDMA 与无损网络

青云技术社区

云计算 云原生 存储

彻底搞懂Spring状态机原理,实现订单与物流解耦

Tom弹架构

Nebula Graph 源码解读系列 | Vol.04 基于 RBO 的 Optimizer 实现

NebulaGraph

图数据库 源码解读

我所理解的社群—社群本质

sec01张云龙

社群 11月日更 社群运营

短视频个性化Push工程精进之路

百度Geek说

后端 软件架构

Python代码阅读(第58篇):压缩列表

Felix

Python 编程 列表 阅读代码 Python初学者

CSS布局之display:flex(二)

Augus

CSS 11月日更

月薪3万的大厂测试工程师裸辞3个月,送外卖谋生背后的真实感悟

六十七点五

程序员 程序人生 软件测试 软件自动化测试 测试工程师

速来!开源中国首届飞算SoFlu组件开发悬赏赛来袭

SoFlu软件机器人

Java

混合云的概念以及优势劣势简单介绍-行云管家

行云管家

云计算 混合云 多云 云管平台

一招教你通过焱融 SaaS 数据服务平台+ELK 让日志帮你做决策

焱融科技

云计算 分布式 SaaS 公有云 文件存储

首次!统一调度系统规模化落地,全面支撑阿里巴巴双 11 全业务

阿里巴巴中间件

阿里云 云原生 中间件 双十一 统一调度

第一本 Compose 图书上市,联想大咖教你学会 Android 全新 UI 编程

图灵教育

Compose AndroidUI

手把手教你学Dapr - 1. .Net开发者的大时代

MASA技术团队

C# .net 微软 后端 dapr

极光笔记丨关于数据大屏一比一还原设计稿这件事

极光JIGUANG

大前端 数据可视化

就是简单,全球100多万读者,一起跑通前端HTML5与CSS3知识!

图灵教育

大前端 HTML5, CSS3

模块三作业——外包学生管理系统架构设计

覃飞

Vue项目优化打包——前端加分项

CRMEB

千万级学生管理系统的考试试卷存储方案

Steven

架构实战营

河南等保测评公司都有哪几家?都在哪里?

行云管家

网络安全 信息安全 数据安全 等级保护

前端的状态管理与时间旅行:San实践篇

百度开发者中心

大前端 san san-store 技术实践

【高并发】通过ThreadPoolExecutor类的源码深度解析线程池执行任务的核心流程

冰河

Java 并发编程 多线程 高并发 异步编程

LevelDB Java&Go实践

FunTester

Java 自学 Go 语言 leveldb FunTester

Nginx中间件渗透总结

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

银行业中的弹性系统_服务革新_Greg Hawkins_InfoQ精选文章