弹性架构

如果我们的开发工作真的就如搭积木一般就好了，轮廓分明，个个分开，坏了哪块积木换掉哪块就好了。但是，实际我们的工作中所面临的可能只有一块积木，而且还是一大块，要换得一起换，要修得一起修。

事件驱动架构

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

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

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

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

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

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

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

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

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

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

微内核架构

顾名思义，微内核架构的关键是内核。所以需要先找到并明确内核是什么？然后将其它部分都视作“可拆卸”的部件。 

好比我们一个人，大脑就是内核，其它的什么都可以换，换完之后你还是你，但是大脑换了就不是你了。

最佳实践

知道了这两种具有“弹性”的架构模式，你该如何判断什么情况下需要搬出来用呢？

事件驱动架构

它的优点是：

1. 通过「队列」进行解耦，使得面对快速变化的需求可以即时上线，而不影响上游系统。

2. 由于「事件」是一个独立存在的“标准化”沟通载体，可以利用这个特点衔接各种跨平台、多语言的程序。如果再进行额外的持久化，还能便于后续的问题排查。同时也可以对「事件」进行反复的「重放」，对处理者的吞吐量进行更真实的压力测试。

3. 更“动态”、容错性好。可以很容易，低成本地集成、再集成、再配置新的和已经存在的事件处理者，也可以很容易的移除事件处理者。轻松的做扩容和缩容。

4. 在“上帝”模式下，对业务能有一个“可见”的掌控，更容易发现流程不合理或者被忽略的问题。同时能标准化一些技术细节，如「数据一致性」的实现方式等。

它的缺点是：

1. 面对不稳定的网络问题、各种异常，想要处理好这些以确保一致性，需要比同步调用花费很大的精力和成本。

2. 无法像同步调用一般，操作成功后即代表可以看到最新的数据，需要容忍延迟或者对延迟做一些用户体验上的额外处理。

那么，它所适用的场景就是：

• 对实时性要求不高的场景。

• 系统中存在大量的跨平台、多语言的异构环境。

• 以尽可能提高程序复用度为目的的场景。

• 业务灵活多变的场景。

• 需要经常扩容缩容的场景。

原文链接：https://mp.weixin.qq.com/s/-GqDM6ll7zxXDIv73pl-wA