分布式系统「伸缩性」大招之——「弹性架构」详解

如果第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~  >

本文长度为3633字，建议阅读10分钟。

坚持原创，每一篇都是用心之作～

 

 

如果我们的开发工作真的就如搭积木一般就好了，轮廓分明，个个分开，坏了哪块积木换掉哪块就好了。

 

但是，实际我们的工作中所面临的可能只有一块积木，而且还是一大块，要换得一起换，要修得一起修。

 

Z哥在之前《分布式系统关注点（13）——「高内聚低耦合」详解》中提到的分层架构它可以让我们有意识的去做一些切分，但是换和修的难度还是根据切分的粒度大小来决定的。

 

有更好的方式吗？这是显然的。

 

 

事件驱动架构

我们来换一个思维看待这个问题。

 

不管是平时的系统升级也好、修复bug也好、扩容也好，其实就是一场“手术”。通过这场“手术”来解决当前面临的一些问题。

 

那么分层架构好比只是将一个人的手、脚、嘴、鼻等分的清清楚楚，但是整体还是紧密的耦合在一起。

 

怎么耦合的呢？我们人是靠“血液”的流动连接起来的。这就好比在分布式系统中通过rpc框架连接起不同的节点一样。

 

 

但是软件与人不同，有2种不同的连接方式，除了「同步」的方式之外还有「异步」的方式。因为有些时候你不需要知道其他系统的执行结果，只要确保自己将其需要的数据传递给它了即可。

 

恰巧有一种架构是这种模式的典型——事件驱动架构（简称EDA，Event Driven Architecture）。

 

平时常见的MQ、本地消息表等运用于数据传递的中转环节，就是事件驱动架构的思想体现。

 

 

事件驱动架构又细分为两种典型的实现方式，与Z哥之前在《分布式系统关注点（3）——「共识」的兄弟「事务」》中提到的Saga模式的2种实现方式类似，一种是中心化的、一种是去中心化的。

 

下面Z哥来举个例子，让你看起来更容易理解一些。（例子仅为了阐述是怎么工作的，真正的实施中还需要考虑如何保证数据一致性等问题，这部分可以参考之前发表的系列文章，文末带传送门）

 

传统的电商场景中，用户从购物车中点击“提交”按钮后，至少需要做这几件事：生成一笔订单、生成一笔支付记录、给订单匹配发货的快递公司。

 

在这个场景下，中心化和去中心化有什么不同呢？

 

 

中心化

这种模式拥有一个“上帝”。