常用架构模式 _架构

在做架构设计的时候，一般会采用一些架构模式，便于设计和以后需求变更时修改代码。如果设计模式选择得不正确那么很容易造成架构的混乱，代码也会变成怪物。
分层模式

文章插图
分层模式
分层模式是最常见的模式。我们熟悉的MVC模式就是分层模式的一种。在进行架构设计的时候，如果一筹莫展，那么分层模式是很好的一种尝试。在分层模式中，业务水平切分，分解到不同的层次中，每个层次要求仅相邻的两个层次之间可以进行交互，不可以跨层次进行调用。一般架构会被分成3到5层，具体视架构规模而定，大规模的架构可能会超过5层。在分层模式中，可以很好的解耦，不需要跨层次感知下层的存在。这样带来的好处就是，如果因为某些原因切换了存储，这个时候仅需要修改持久化层就好了，再上面的层次完全感知不到底层的变化。

文章插图
例外情况
但是这种模式中也会存在些例外，底层有的时候需要对上上层进行部分开放。比如新增加了一个层次，为了适配可能会对一些请求放行，即允许部分跨级调用。
【常用架构模式】分层模式需要注意的时候，层次必须要做处理，如果当前层次仅仅是对请求的转换，那么就要考虑是否层次拆分得有问题。如果仅做请求转换，那么带来的仅是性能损失和增加新请求时额外的转换代码。
事件模式

文章插图
事件模式1

文章插图
事件模式2
事件模式有两种形式：
1.带有协调器。协调器作为事件总的入口，监听到事件之后，编排调用处理器，使事件按照业务逻辑进行处理和消费，即协调器监听到事件之后，将事件写入第一个处理器，处理器处理完毕后，协调器再将下一步的业务逻辑事件写到下一个处理器，由此完成业务逻辑。
2.不带有协调器，业务流程的处理靠每个处理器走下去。一个请求到来之后，感兴趣的处理器会处理事件，并产生一个新的事件，并将事件发布到消息队列，对新消息感兴趣的处理器再继续处理新的事件，并再次产生新事件。
这种模式很好的做到了解耦，每个处理器只需要处理自己感兴趣的事件即可。但是因为这些事件都是异步消息，所以容错很难处理。
微内核模式

文章插图
微内核模式
微内核模式也是一种比较常见的模式，比如我们熟悉的eclipse、MySQL存储引擎等。在微内核中，核心的业务逻辑包含在内核中，插件提供对功能的加强。一般情况下，内核逻辑是稳定的，新的需求只需要修改某个插件或者新增插件。插件的逻辑比较专注，只需要关注插件内的逻辑即可。对于内核和插件需要规划好连接接口。一定要注意，接口要全面，不能仅局限于当前，不然业务逻辑增加时再增加接口可能会影响到已经存在的插件，使插件不得不进行升级。