弹性架构（云时代架构文章读后感05）

事件驱动架构

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

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

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

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

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

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

事件驱动架构又细分为两种典型的实现方式，Saga模式的2种实现方式类似，一种是中心化的、一种是去中心化的。

中心化：这种模式拥有一个“上帝”。但是“上帝”不会处理也不知道任何业务逻辑，它只编排事件。这种模式中存在3种类型的主体：事件生产者、“上帝”（调停者）、事件处理者。然后中间夹着两层队列，以此结构就能解耦。

其实编排主要做两件事：「事件转换」和「事件发送」（对应「服务编排」类框架的「调用」）。

「事件转换」实质就是给将要发送的事件对象的参数进行赋值。

「事件发送」实质就是负责事件流转的逻辑控制，然后发往「事件处理者」去处理

中心化最大的优势是让流程更加的“可见”了，同时也更容易去做一些监控类的东西，系统规模越大，这个优势产生的效果越明显。

但是一个最基本的“上帝”（调停者）实现起来还需要考虑数据一致性问题，所以，会大大增加它的实现复杂度。

因此，如果你面对的场景，业务没有特别庞大，并且是比较稳定的，或许用去中心化的方式也是不错的选择。

去中心化

这个模式由于没有了“上帝”，因此每个事件处理者需要知道自己的下一个事件处理器是什么？需要哪些参数？以及队列是哪个之类的东西。

但是整体结构会变得简单很多，从“3+2结构”变成了“2+1结构”。

结构简化背后的复杂度都跑到事件处理者开发人员编写的业务代码中去了。因为他需要自己去负责「事件转换」和「事件发送」这两个事情。

嗯，改造成事件驱动架构之后，通过「队列」的解耦和异步的事件流转，系统的运转的确会更顺畅。

但是有时候你可能想进行更细粒度的控制，因为一般情况下，一个service中会处理很多业务环节，不太会只存在一个对外接口、一条业务逻辑。

微内核架构

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

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

微内核架构整体上由两部分组成：核心系统和插件模块。

核心系统内又包含了微内核、插件模块，以及内置的一些同样以插件形式提供的默认功能。

其中，微内核主要负责插件的生命周期管理和控制插件模块。

插件模块则负责插件的加载、替换和卸载。

外部的插件如果要能够接入进来并顺利运行，前提先要有一个满足标准接口规范的实现。

一个插件的标准接口至少会有这样的2个方法需要具体的插件来实现：

public interface IPlugin{

    /// <summary>
    /// 初始化配置
    /// </summary>
    void InitializeConfig(Dictionary<string,string> configs);
    
    /// <summary>
    /// 运行
    /// </summary>
    void Run();
    
    ...
}

最后，插件之间彼此独立，但核心系统知道哪里可以找到它们以及如何运行它们。

事件驱动架构

 

它的优点是：

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

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

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

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

它的缺点是：

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

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

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

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

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

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

• 业务灵活多变的场景。

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

微内核架构

它的优点是：

1. 为递进设计和增量开发提供了方便。可以先实现一个稳固的核心系统，然后逐渐地增加功能和特性。

2. 和事件驱动架构一样，也可避免单一组件失效，而造成整个系统崩溃，容错性好。内核只需要重新启动这个组件，不致于影响其他功能。

它的缺点是：

1. 由于主要的微内核很小，所以无法对整体进行优化。每个插件都各自管各自的，甚至可能是由不同团队负责维护。

2. 一般来说，为了避免在单个应用程序中的复杂度爆炸，很少会启用插件嵌套插件的模式，所以插件中的代码复用度会差一些。

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

• 可以嵌入或者作为其它架构模式的一部分。例如事件驱动架构中，“上帝”的「事件转换」就可以使用微内核架构实现。

• 业务逻辑虽然不同，但是运行逻辑相同的场景。比如，定期任务和作业调度类应用。

• 具有清晰的增量开发预期的场景。