我们的开发工作开始的时候是简单的，结束的时候是复杂的，我们无法做到说哪里的开发出了问题，直接将它换掉，改成新的，这样修改的代价会很大，而且带来的并发问题会更多，所以如何处理项目的出错修改，这值得我们仔细想想。
不管是平时的系统升级也好、修复bug也好、扩容也好，其实就是一场“手术”。通过这场“手术”来解决当前面临的一些问题。那么分层架构好比只是将一个人的手、脚、嘴、鼻等分的清清楚楚，但是整体还是紧密的耦合在一起。人类依靠血液耦合；连接，分布式紫铜通过rpc框架连接不同的节点。但是软件与人不同，除了「同步」的方式之外还有「异步」的方式。有时候，不需要知道其他系统的执行结果，我们只需要将其需要的数据传递给系统即可。
事件驱动架构：
平时常见的MQ（消息队列）、本地消息表等运用于数据传递的中转环节，由一系列相关组件构成的应用，而组件之间通过事件机制完成一定的业务功能。由于在一个EDA系统中各个组件都只专注于处理输入的消息与发布输出的消息，因而EDA系统能够更有加效地对管道化（pipelined）的、由多 软件模块链接而成的并发事件流（concurrent processing of events）进行处理。
它的实现方式：1.去中心化的，2.中心化的。
下面举例说明：
传统的电商场景中，用户从购物车中点击“提交”按钮后，至少需要做这几件事：生成一笔订单、生成一笔支付记录、给订单匹配发货的快递公司。那在这个场景下，中心化和去中心化有什么不同呢？
中心化：这种模式拥有一个“上帝”。但是它不会处理也并不知道任何业务逻辑，它只负责编排事件。它存在着3种主体：事件生产者、“上帝”（调停者）、事件处理者。依赖事件生产者 --> 队列 --> “上帝”（调停者） --> 队列 --> 事件处理者的形式解耦。
如上图，事件生产者CartService发出了一个“订单创建”事件，通过队列传递给调停者。然后调停者根据事先制定好的编排规则对事件进行相应的转换，也通过队列做二次分发，传递给事件处理者。
具体的编排到底是什么？应该如何做？
编排就是事件转换和事件发送，事件转换实质就是将要发送的事件对象的参数进行赋值，使用什么赋值，就是事件产生的源头带入的参数，还有持续累积的上下文，我们可以通过通过一个全局唯一的标识即可，每次向“上帝”发送事件的时候把这个全局唯一标识传送过去，使用同一个标识标识多个事件，即对应同一个上下文。事件发送就是负责事件流转的逻辑控制，然后发送给事件处理者去处理。它主要决定我们使用的是顺序进行还是分支进行，串行，还是并行。中心化最大的优势是让流程更加的“可见”，更容易去做一些监控类的东西。
去中心化中没有“上帝”，事件处理者开发人员编写的业务代码中存放着每个事件处理者需要知道自己的下一个事件处理器，参数和所用队列，队列」的解耦和异步的事件流，系统的运转会更顺畅。
它所适用的场景就是：
对实时性要求不高的场景。
系统中存在大量的跨平台、多语言的异构环境。
以尽可能提高程序复用度为目的的场景。
业务灵活多变的场景。
需要经常扩容缩容的场景。