如果我们的开发工作真的就如搭积木一般就好了，轮廓分明，个个分开，坏了哪块积木换掉哪块就好了。但是，实际我们的工作中所面临的可能只有一块积木，而且还是一大块，要换得一起换，要修得一起修。Z哥在之前《分布式系统关注点：高内聚低耦合》中提到的分层架构它可以让我们有意识的去做一些切分，但是换和修的难度还是根据切分的粒度大小来决定的。有更好的方式吗？这是显然的。
事件驱动架构
我们来换一个思维看待这个问题。
不管是平时的系统升级也好、修复bug也好、扩容也好，其实就是一场“手术”。通过这场“手术”来解决当前面临的一些问题。
那么分层架构好比只是将一个人的手、脚、嘴、鼻等分的清清楚楚，但是整体还是紧密的耦合在一起。
怎么耦合的呢？我们人是靠“血液”的流动连接起来的。这就好比在分布式系统中通过rpc框架连接起不同的节点一样。
但是软件与人不同，有2种不同的连接方式，除了「同步」的方式之外还有「异步」的方式。因为有些时候你不需要知道其他系统的执行结果，只要确保自己将其需要的数据传递给它了即可。
恰巧有一种架构是这种模式的典型——事件驱动架构（简称EDA，Event Driven Architecture）。
平时常见的MQ、本地消息表等运用于数据传递的中转环节，就是事件驱动架构的思想体现。
事件驱动架构又细分为两种典型的实现方式，与Z哥之前在《分布式系统关注点——「共识」的兄弟「事务」》中提到的Saga模式的2种实现方式类似，一种是中心化的、一种是去中心化的。
下面Z哥来举个例子，让你看起来更容易理解一些。（例子仅为了阐述是怎么工作的，真正的实施中还需要考虑如何保证数据一致性等问题，这部分可以参考之前发表的系列文章，文末带传送门）
传统的电商场景中，用户从购物车中点击“提交”按钮后，至少需要做这几件事：生成一笔订单、生成一笔支付记录、给订单匹配发货的快递公司。
在这个场景下，中心化和去中心化有什么不同呢？
中心化
这种模式拥有一个“上帝”。
但是“上帝”不会处理也不知道任何业务逻辑，它只编排事件。
除了中心化之外，它还有什么特点呢？Z哥给它的定义是“3+2结构”。
这种模式中存在3种类型的主体：事件生产者、“上帝”（调停者）、事件处理者。然后中间夹着两层队列，以此结构就能解耦。
就像这样：事件生产者 --> 队列 --> “上帝”（调停者） --> 队列 --> 事件处理者。
那么回上面的这个例子中，事件生产者CartService发出了一个“订单创建”事件，通过队列传递给调停者。然后调停者根据事先制定好的编排规则对事件进行相应的转换，也通过队列做二次分发，传递给事件处理者。
可能你会问，这些好理解。但是，我之前也经常看到什么编排编排的，到底编排该怎么做呢？
其实编排主要做两件事：「事件转换」和「事件发送」（对应「服务编排」类框架的「调用」）。
「事件转换」实质就是给将要发送的事件对象的参数进行赋值。赋值的数据来源于哪呢？
除了事件产生的源头带入的参数，还有持续累积的「上下文」，就如下图中这样的一个共享存储空间
可能你又会问，我怎么将多个事件处理者之间组合成一个上下文呢？
通过一个全局唯一的标识即可，每次向“上帝”丢事件的时候把这个全局唯一标识带过去。
题外话：一般来说，还会在一个全局唯一标识之下带一个内部唯一的「子流水号」，为了配合做接下去要讲到的「事件发送」。
一是为了后续排查问题的时候清晰的知道这次调用产生的异常是从哪个上游系统来的。
二是为了便于观测整个调用的逻辑是否符合编排时的预期。
怎么做呢？通过一个x.x.x.x格式的序号。比如，串行就是1，2，3。分支和并行就是2.1，2.2。分支+串行的结合就是1，2，2.1，2.2，3。
「事件发送」实质就是负责事件流转的逻辑控制，然后发往「事件处理者」去处理。它决定了是按顺序还是分支进行？是串行还是并行？
到这就不再展开了，要不然就跑题了，我们下次再细聊这部分内容。
再强调一下，「事件转换」和「事件发送」是你在实现“上帝”（调停者）功能的时候需要满足的最基本的两个功能。
中心化最大的优势是让流程更加的“可见”了，同时也更容易去做一些监控类的东西，系统规模越大，这个优势产生的效果越明显。
但是一个最基本的“上帝”（调停者）实现起来还需要考虑数据一致性问题，所以，会大大增加它的实现复杂度。
因此，如果你面对的场景，业务没有特别庞大，并且是比较稳定的，或许用去中心化的方式也是不错的选择。
去中心化
这个模式由于没有了“上帝”，因此每个事件处理者需要知道自己的下一个事件处理器是什么？需要哪些参数？以及队列是哪个之类的东西。
但是整体结构会变得简单很多，从“3+2结构”变成了“2+1结构”。
结构简化背后的复杂度都跑到事件处理者开发人员编写的业务代码中去了。因为他需要自己去负责「事件转换」和「事件发送」这两个事情。
嗯，改造成事件驱动架构之后，通过「队列」的解耦和异步的事件流转，系统的运转的确会更顺畅。
但是有时候你可能想进行更细粒度的控制，因为一般情况下，一个service中会处理很多业务环节，不太会只存在一个对外接口、一条业务逻辑。
在这样的情况下，很多时候你可能需要修改的地方仅仅是其中的一个接口。能不能只修改其中的一部分代码并且进行「热更新」呢？
微内核架构（插件架构）就适合来解决这个问题。
微内核架构
顾名思义，微内核架构的关键是内核。所以需要先找到并明确内核是什么？然后将其它部分都视作“可拆卸”的部件。
好比我们一个人，大脑就是内核，其它的什么都可以换，换完之后你还是你，但是大脑换了就不是你了。
微内核架构整体上由两部分组成：核心系统和插件模块。
核心系统内又包含了微内核、插件模块，以及内置的一些同样以插件形式提供的默认功能。
其中，微内核主要负责插件的生命周期管理和控制插件模块。
插件模块则负责插件的加载、替换和卸载。
外部的插件如果要能够接入进来并顺利运行，前提先要有一个满足标准接口规范的实现。一个插件的标准接口至少会有这样的2个方法需要具体的插件来实现：
public interface IPlugin{ /// <summary> /// 初始化配置 /// </summary> void InitializeConfig(Dictionary<string,string> configs); /// <summary> /// 运行 /// </summary> void Run(); ... }
最后，插件之间彼此独立，但核心系统知道哪里可以找到它们以及如何运行它们。
最佳实践
知道了这两种具有“弹性”的架构模式，你该如何判断什么情况下需要搬出来用呢？
Z哥带你来分析一下每一种架构的优缺点，就能发现它适用的场景。
事件驱动架构
它的优点是：
- 通过「队列」进行解耦，使得面对快速变化的需求可以即时上线，而不影响上游系统。
- 由于「事件」是一个独立存在的“标准化”沟通载体，可以利用这个特点衔接各种跨平台、多语言的程序。如果再进行额外的持久化，还能便于后续的问题排查。同时也可以对「事件」进行反复的「重放」，对处理者的吞吐量进行更真实的压力测试。
- 更“动态”、容错性好。可以很容易，低成本地集成、再集成、再配置新的和已经存在的事件处理者，也可以很容易的移除事件处理者。轻松的做扩容和缩容。
- 在“上帝”模式下，对业务能有一个“可见”的掌控，更容易发现流程不合理或者被忽略的问题。同时能标准化一些技术细节，如「数据一致性」的实现方式等。
它的缺点是：
- 面对不稳定的网络问题、各种异常，想要处理好这些以确保一致性，需要比同步调用花费很大的精力和成本。
- 无法像同步调用一般，操作成功后即代表可以看到最新的数据，需要容忍延迟或者对延迟做一些用户体验上的额外处理。
那么，它所适用的场景就是：
- 对实时性要求不高的场景。
- 系统中存在大量的跨平台、多语言的异构环境。
- 以尽可能提高程序复用度为目的的场景。
- 业务灵活多变的场景。
- 需要经常扩容缩容的场景。
微内核架构
它的优点是：
- 为递进设计和增量开发提供了方便。可以先实现一个稳固的核心系统，然后逐渐地增加功能和特性。
- 和事件驱动架构一样，也可避免单一组件失效，而造成整个系统崩溃，容错性好。内核只需要重新启动这个组件，不致于影响其他功能。
它的缺点是：
- 由于主要的微内核很小，所以无法对整体进行优化。每个插件都各自管各自的，甚至可能是由不同团队负责维护。
- 一般来说，为了避免在单个应用程序中的复杂度爆炸，很少会启用插件嵌套插件的模式，所以插件中的代码复用度会差一些。
那么，它所适用的场景就是：
-
- 可以嵌入或者作为其它架构模式的一部分。例如事件驱动架构中，“上帝”的「事件转换」就可以使用微内核架构实现。
- 业务逻辑虽然不同，但是运行逻辑相同的场景。比如，定期任务和作业调度类应用。
- 具有清晰的增量开发预期的场景。