发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

在建立优步大型支付系统过程中学到的分布式架构概念

                   
2018-04-18 20:27
赞助商链接

这是优步Uber员工Gergely Orosz自己的经验分享:

两年前我加入了优步,担任移动软件工程师,有一些后端经验,我构建了带有支付功能的应用程序 - 并在后来重写了它。之后,我就晋升工程管理并领导了一个团队。这意味着需要接触更多的后端,因为我的团队负责支持支付的许多后端系统。

在优步工作之前,我几乎没有分布式系统经验。我的背景是传统的计算机科学学位和十年的全面软件开发。然而,虽然我能够画图并谈论权衡,但我对分布式概念(如一致性,可用性或幂等性)没有太多的了解或理解。

在这篇文章中,我总结一些在构建大规模,高可用性的分布式系统时应该学习的基本概念。我们的优步支付系统是一个负载高达每秒数千次请求的系统,即使部分系统停机,关键支付功能也需要正常工作。这里讨论的基本概念是一个完整的清单吗?可能不会。但是,如果我早点知道他们的话,那会让我的生活变得更轻松。因此,让我们深入了解SLA、一致性、数据持久性、消息持久性、幂等性以及我在工作中需要学习的其他一些内容。

SLA
对于每天处理数百万事件的大型系统,有些事情肯定会出错。在深入规划系统之前,我发现决定“健康”系统最重要的因素是什么。“健康”应该是实际可衡量的。衡量“健康”的常见方式是SLA:服务级别协议。我见过的一些最常见的SLA是:

可用性:服务运行时间的百分比。虽然拥有100%可用性的系统很诱人,但实现起来可能非常困难,而且很昂贵。即使是像VISA卡网络,Gmail或互联网提供商这样的大型和关键系统也没有100%的可用性 - 多年来,它们也会宕机数秒,数分钟或数小时。对于许多系统而言,四个九个可用性(99.99%,或每年约50分钟的停机时间)被视为高可用性。刚刚达到这个水平通常需要相当辛苦的工作付出。

准确性:系统中的某些数据不准确或丢失可以吗?如果是这样,可以接受多少百分比?对于我所从事的支付系统,准确度需要达到100%,这意味着不允许丢失任何数据。

容量:系统能够支持的预期负载是多少?这通常以每秒请求数来表示。

延迟:系统在多长时间内响应?95%的请求在多长时间到达,99%的请求在多长时间内到达?系统通常有很多嘈杂的请求,因此.p95和p99延迟在现实世界中更实用。

为什么建立大型支付系统时SLA很重要?我们需要整合了一个新系统,取代了现有旧系统。为了确保我们构建的是正确的事情,是一个“更好”的系统,我们使用SLA来定义期望值。可用性是我们的最高要求之一。一旦确定了目标,我们就需要考虑通过架构的折衷才能达到这个目的。

水平与垂直缩放
假设新建系统的使用业务量增长,负载就会增加。在某些情况下,现有设置将无法支持更多负载并需要添加更多容量。两种最常见的缩放策略是垂直或水平缩放扩展。

水平缩放扩展是增加更多的机器(或节点)到系统,以增加容量。水平缩放是扩展分布式系统最流行的方式,特别是,向集群添加(虚拟)机器通常与单击按钮一样容易。

垂直缩放基本上是“购买更大/更强的机器” - 或者是具有更多内核的(虚拟)机器、更多处理器、更多内存。对于分布式系统,垂直缩放通常不太流行,因为它可能比水平缩放更昂贵。但是,一些主要站点,如Stack Overflow已经成功地通过垂直扩展满足了需求。

为什么在构建大型支付系统时扩展策略很重要?我们很早就决定建立一个横向水平扩展的系统。尽管在某些情况下可以实现垂直扩展,单个超级昂贵的大型机在今天也可以满足需要。 我们团队的工程师也曾在大型支付服务提供商那里工作过,当时他们试图购买的最大机器上进行垂直纵向扩展,但是未能成功。

一致性
任何系统的可用性都很重要。分布式系统通常建立在具有较低可用性的机器之上。假设我们的目标是构建一个具有99.999%可用性(每年约宕机5分钟)的系统。我们使用的机器/节点平均具有99.9%的可用性(它们每年约宕机8小时)。一个直接获得我们的可用性数值的方法是将一堆机器/节点添加到群集中。即使某些节点停机,其他节点也会启动,系统的整体可用性将高于单个组件的可用性。

一致性是高度可用系统中的关键问题。如果所有节点同时查看并返回相同的数据,则系统是一致的。回到之前的模型,我们添加了一堆节点以实现更高的可用性,确保系统保持一致不是微不足道的。为了确保每个节点具有相同的信息,他们需要互相发送消息,以保持自己的同步。但是,发送给对方的消息可能无法传递,它们可能会丢失,并且某些节点可能不可用。

一致性是我花最多时间理解和欣赏的概念。有几种一致性模型,分布式系统中最常用的模型是强一致性、弱一致性和最终一致性。关于最终vs强一致性,Hackernoon的文章给出了在这些模型之间的进行折衷选择的实用概述。通常,所需的一致性越弱,系统的速度越快,但返回的就可能不是最新的数据集。

为什么建立大型支付系统时一致性很重要?系统中的数据需要保持一致。但是如何保持一致?对于系统的某些部分,只有强一致的数据才能做到。例如,了解付款是否已经开始需要以强一致的方式进行存储。对于其他部分而言,如果不是关键任务,最终的一致性可以被认为是合理的权衡。一个很好的例子就是列出最近的交易:这些交易可以通过最终的一致性来实现(也就是说,最近的交易可能会在一段时间后才会显示在系统的一部分中),作为回报,操作将以较低的延迟返回,或者资源密集度较低)。

数据持久性
持久性意味着一旦数据成功添加到数据存储中,它就可以继续使用。即使系统中的节点脱机,崩溃或数据损坏,情况也会如此。

不同的分布式数据库具有不同级别的持久性 有些数据库支持机器/节点级别的持久性,有些支持集群级别的,有些则不提供开箱即用。通常使用某种形式的复制来提高持久性 - 如果数据存储在多个节点上,并且一个或多个节点脱机,但是数据仍然是可用。这里有一篇很好的文章,说明为什么在分布式系统中实现耐久性可能会有挑战.

为什么建立支付系统时数据的持久性很重要?因为不会丢失任何数据这是很重要的,比如付款就不能丢失付款数据。我们构建的分布式数据存储需要支持集群级数据持久性 - 所以即使个别实例会崩溃,已完成的交易也会持续存在。现在,大多数分布式数据存储服务(如Cassandra,MongoDB,HDFS或Dynamodb)都支持各种级别的持久性,并且都可以配置为提供群集级别的持久性。

消息持久性和耐久性
分布式系统中的节点执行计算,存储数据并将消息发送给对方。发送消息的关键特征是这些消息到达的可靠程度。对于任务关键型系统,通常只能丢失零个消息。

对于分布式系统,消息传递通常由一些分布式消息服务完成,例如RabbitMQ,Kafka或其他。这些消息传递服务可以支持(或被配置为支持)传递消息的不同级别的可靠性。

消息持久性意味着当处理消息的节点发生某些故障时,消息仍然会在故障解决后进行处理。消息持久性通常用于消息队列级别。使用持久的消息队列时,如果队列(或节点)在发送消息时脱机,则消息恢复联机时仍会收到消息。阅读关于这个主题的更好的文章就是这个


为什么建立大型支付系统时信息的持久性和耐用性很重要?我们不能承受消息的丢失,比如一个人已经开始支付乘坐费用的消息就不能丢失。这意味着我们使用的消息传递系统必须是无损的:每条消息都需要传递一次。但是,构建一个系统可以将每条消息准确传递一次,或者至少传送一次消息的系统的复杂程度不同。我们决定实现一个持久的消息传递系统,至少一次传递,并选择了一个消息总线,我们将在此之上构建这个消息总线(我们最终使用Kafka设计了一个无损集群系统)。

幂等
对于分布式系统,任何事情都可能会出错,例如连接可能中途中断或请求超时。客户经常会重试这些请求。幂等系统确保无论执行特定请求多少次,对此请求的实际执行只发生一次。一个很好的例子就是付款。如果客户发出支付请求,请求成功,但客户端超时,客户端可能会重试同样的请求。用幂等系统,支付的人不会被收取两次费用。

为幂等而设计的分布式系统需要某种分布式锁策略。这是早期分布式系统概念的一部分。假设我们打算通过实施乐观锁定来实现幂等性,以避免并发更新。为了进行乐观锁定,系统需要保持强一致性 - 以便在操作时,我们可以使用某种版本控制来检查是否已启动另一个操作。

取决于系统的限制和操作类型,有许多方法可以实现幂等性。设计幂等方法是一个很好的挑战 - Ben Nadel写了他使用的不同策略,包括分布式锁或数据库约束。在设计分布式系统时,幂等性可能是容易被忽视的部分之一。我遇到过各种情况,我的团队因为没有确保某些关键操作的正确幂能力而被烧毁。

为什么建立大型支付系统时幂等性很重要?最重要的是:避免双倍收费或双倍退款。鉴于我们的消息传递系统至少有一次无损传递,我们需要假设所有消息可能会多次传递,系统需要确保幂等性。我们选择使用版本控制和乐观锁定来处理这个问题,让实现幂等行为的系统使用强一致的存储作为其数据源。

分片和法定人数
分布式系统通常必须存储更多数据,单个节点通常做不到这点。那么,如何在一定数量的机器上存储大量数据呢?最常见的技术是使用分片。数据使用某种散列进行水平分区以分配给分区。尽管许多分布式数据库在底层实现分片,但分片是一个有趣的领域,可以更多地进行了解,特别是重新分片。由于Foursquare在2010年发生了一个分裂的边缘案例,因此Foursquare在2010年有17个小时的停机时间,在这个案例中,这篇文章分享了一个很好的事后分析。

许多分布式系统在多个节点上复制数据或计算。为了确保操作以一致的方式执行,定义了基于投票的方法,其中一定数量的节点需要获得相同的结果,最后才能使得整个操作成功。这被称为法定人数Quorum。

在优步建立支付系统时,为什么法定人数和分片是重要的?这些都是很常用的基本概念。当我看看我们如何设置Cassandra复制时,我个人遇到了这个概念。Cassandra(和其他分布式系统)使用法定人数和本地法定人数来确保跨集群的一致性。作为一个有趣的副作用,在我们的一些会议上,当有足够多的人在会议室时,有人会问:“我们可以开始吗?我们有法定人数吗?”

演员Actor模型
描述编程实践的常用术语是 变量、接口、调用方法等 - 这些假定前提都为单机系统。在谈到分布式系统时,我们需要使用一套不同的方法。描述这些系统的常见方式是遵循Actor模型,我们在通信方面考虑代码。这种模式很受欢迎,因为它与我们想到的心智模式相匹配,例如,在组织中的人们是如何进行沟通的场景类似。另一种描述分布式系统的流行方式是CSP--传递顺序过程。

演员模型基于演员互相发送消息并对其作出反应。每个角色都可以做一些有限的事情 比如- 创建其他角色,向他人发送消息或决​​定如何处理下一条消息。通过一些简单的规则,可以很好地实现一个复杂的分布式系统,这些系统也可以在演员崩溃后自行修复。我推荐Brian Storti 文章在10分钟内了解演员模型。许多语言都实现了actor库或框架。例如,在Uber,我们使用Akka工具包。

为什么在建立大型支付系统时,这个演员模型很重要?我们正在建立一个拥有许多工程师的系统,其中很多人都拥有分布式的经验。我们决定遵循标准的分布式模型,自己提出分布式概念,可能是重新发明轮子。

响应式架构
在构建大型分布式系统时,其目标通常是使其具有韧性、弹性和可扩展性。对于一个支付系统或一个高负载系统,都需要类似这样模式。业内人士一直在发现并分享在这些情况下运行良好的最佳实践 - 而响应式/反应式架构是这一领域中流行和广泛使用的模式。

要开始使用Reactive Architecture,我建议阅读Reactive Manifesto并观看关于该主题的12分钟视频

为什么建立大型支付系统时Reactive Architecture很重要? 我们使用工具包 Akka来构建新的支付系统,这个工具包就受到了响应式架构的影响。我们许多工程师构建新系统时也同时熟悉了响应式编程的最佳实践。遵循响应原则 - 建立一个响应灵活、弹性好、有韧性和消息驱动系统变得非常自然。

总结
我很幸运能够参与重建一个高规模,分布式的关键任务系统:优步的支付系统。通过在这种环境中工作,我选择了许多我以前不必使用的分布式概念。我总结了这些内容,希望对其他人开始或继续学习分布式系统有所帮助。



Distributed architecture concepts I learned while

3
扩展性      分布式系统      消息队列      actor模型     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com