不管是平时的系统升级也好、修复bug也好、扩容也好，其实就是一场“手术”。通过这场“手术”来解决当前面临的一些问题。
那么分层架构好比只是将一个人的手、脚、嘴、鼻等分的清清楚楚，但是整体还是紧密的耦合在一起。我们人是靠“血液”的流动连接起来的。这就好比在分布式系统中通过rpc框架连接起不同的节点一样。但是软件与人不同，有2种不同的连接方式，除了同步的方式之外还有异步的方式。因为有些时候你不需要知道其他系统的执行结果，只要确保自己将其需要的数据传递给它了即可。恰巧有一种架构是这种模式的典型——事件驱动架构。平时常见的MQ、本地消息表等运用于数据传递的中转环节，就是事件驱动架构的思想体现。
事件驱动架构又细分为两种典型的实现方式，一种是中心化的、一种是去中心化的。中心化这种模式中存在3种类型的主体：事件生产者、“上帝”（调停者）、事件处理者。然后中间夹着两层队列，以此结构就能解耦。就像这样：事件生产者 --> 队列 --> “上帝”（调停者） --> 队列 --> 事件处理者。事件转换和事件发送是你在实现“上帝”（调停者）功能的时候需要满足的最基本的两个功能.
中心化最大的优势是让流程更加的“可见”了，同时也更容易去做一些监控类的东西，系统规模越大，这个优势产生的效果越明显。但是一个最基本的“上帝”（调停者）实现起来还需要考虑数据一致性问题，所以，会大大增加它的实现复杂度。因此，如果你面对的场景，业务没有特别庞大，并且是比较稳定的，或许用去中心化的方式也是不错的选择。
改造成事件驱动架构之后，通过队列的解耦和异步的事件流转，系统的运转的确会更顺畅。但是有时候你可能想进行更细粒度的控制，因为一般情况下，一个service中会处理很多业务环节，不太会只存在一个对外接口、一条业务逻辑。微内核架构（插件架构）就适合来解决这个问题。顾名思义，微内核架构的关键是内核。微内核架构整体上由两部分组成：核心系统和插件模块。核心系统内又包含了微内核、插件模块，以及内置的一些同样以插件形式提供的默认功能。其中，微内核主要负责插件的生命周期管理和控制插件模块。插件模块则负责插件的加载、替换和卸载。外部的插件如果要能够接入进来并顺利运行，前提先要有一个满足标准接口规范的实现。最后，插件之间彼此独立，但核心系统知道哪里可以找到它们以及如何运行它们。 那么事件驱动架构以及微内核架构的适用场景都是什么呢?结合其优缺点来说，事件驱动架构适用于对实时性要求不高的场景、系统中存在大量的跨平台、多语言的异构环境、以尽可能提高程序复用度为目的的场景、业务灵活多变的场景、需要经常扩容缩容的场景。微内核架构的适用场景是可以嵌入或者作为其它架构模式的一部分。例如事件驱动架构中，“上帝”的事件转换就可以使用微内核架构实现、业务逻辑虽然不同，但是运行逻辑相同的场景。比如，定期任务和作业调度类应用、具有清晰的增量开发预期的场景。