在做架构设计的时候,一般会采用一些架构模式,便于设计和以后需求变更时修改代码。如果设计模式选择得不正确那么很容易造成架构的混乱,代码也会变成怪物。
分层模式
分层模式是最常见的模式。我们熟悉的MVC模式就是分层模式的一种。在进行架构设计的时候,如果一筹莫展,那么分层模式是很好的一种尝试。在分层模式中,业务水平切分,分解到不同的层次中,每个层次要求仅相邻的两个层次之间可以进行交互,不可以跨层次进行调用。一般架构会被分成3到5层,具体视架构规模而定,大规模的架构可能会超过5层。在分层模式中,可以很好的解耦,不需要跨层次感知下层的存在。这样带来的好处就是,如果因为某些原因切换了存储,这个时候仅需要修改持久化层就好了,再上面的层次完全感知不到底层的变化。
例外情况
但是这种模式中也会存在些例外,底层有的时候需要对上上层进行部分开放。比如新增加了一个层次,为了适配可能会对一些请求放行,即允许部分跨级调用。
分层模式需要注意的时候,层次必须要做处理,如果当前层次仅仅是对请求的转换,那么就要考虑是否层次拆分得有问题。如果仅做请求转换,那么带来的仅是性能损失和增加新请求时额外的转换代码。
事件模式1
事件模式2
事件模式有两种形式:
1.带有协调器。协调器作为事件总的入口,监听到事件之后,编排调用处理器,使事件按照业务逻辑进行处理和消费,即协调器监听到事件之后,将事件写入第一个处理器,处理器处理完毕后,协调器再将下一步的业务逻辑事件写到下一个处理器,由此完成业务逻辑。
2.不带有协调器,业务流程的处理靠每个处理器走下去。一个请求到来之后,感兴趣的处理器会处理事件,并产生一个新的事件,并将事件发布到消息队列,对新消息感兴趣的处理器再继续处理新的事件,并再次产生新事件。
这种模式很好的做到了解耦,每个处理器只需要处理自己感兴趣的事件即可。但是因为这些事件都是异步消息,所以容错很难处理。
微内核模式
微内核模式也是一种比较常见的模式,比如我们熟悉的eclipse、MySql存储引擎等。在微内核中,核心的业务逻辑包含在内核中,插件提供对功能的加强。一般情况下,内核逻辑是稳定的,新的需求只需要修改某个插件或者新增插件。插件的逻辑比较专注,只需要关注插件内的逻辑即可。对于内核和插件需要规划好连接接口。一定要注意,接口要全面,不能仅局限于当前,不然业务逻辑增加时再增加接口可能会影响到已经存在的插件,使插件不得不进行升级。
联系客服