使用场景_几种可直接使用的架构模式及其使用场景

写在前面

最开始做架构最好的方式都是基于模仿的&＃xff0c;我们可以找到一个类似于我们现有系统的业界解决方案&＃xff0c;阅读并分析&＃xff0c;看看究竟哪些可以抽象摘借出来为我所用。比如在软件系统重构过程中有一些现有的模式是可以直接复用的&＃xff0c;相信在平时的重构过程中有些模式你已经使用过了。

可复用的架构模式

列出以下几个自己平时习惯套用的模式&＃xff1a;

• 分层模式&＃xff1b;

• 管道模式(过滤器模式)&＃xff1b;

• 聚合网关模式&＃xff1b;

• MVC模式&＃xff1b;

• 事件驱动模式&＃xff1b;

多层模式

多层模式是我们做架构设计时最常用的一种模式&＃xff0c;我们习惯的基于三层方式对我们的整体架构进行分层&＃xff0c;比如说最上层的是展现层&＃xff0c;中间是逻辑层&＃xff0c;最下面是持久层&＃xff0c;比如这样&＃xff1a;

其实分层设计和分模块分领域设计的思路是一致的&＃xff0c;都是通过代码聚合的方式将能力收敛&＃xff0c;达到边界清晰的目的&＃xff0c;以后每个模块和分层可以独立演进&＃xff0c;互不影响&＃xff0c;提高了开发效率与扩展性。

当问你分层对于系统带来了哪些好处呢&＃xff1f;有人会说实现了更好的解耦&＃xff0c;但是分的层越多一定越好吗&＃xff1f;

答案肯定是否定的&＃xff0c;因为过度的分层反而带来了治理的无序&＃xff0c;我个人更将这种分层或分模块看成是一种能力标准化的方式&＃xff0c;因为我们目的是提供某种程度上的标准化能力&＃xff0c;而这部分能力是需要基于具体支撑的场景来抽象的&＃xff0c;也就最终影响到了分层与合并&＃xff0c;进而回答那个分层多少的问题。

每一层都是一组模块&＃xff0c;这组模块组合起来就是某种标准化能力的收敛。需要注意的是层的依赖必须是单向的&＃xff0c;也就是上层依赖于下层&＃xff0c;反过来是不行的。理想态是每层是一个完整的分区&＃xff0c;对外提供公开的接口。

比如表现层是对于展现的标准化实现&＃xff0c;这种展现可能是有用户界面的&＃xff0c;或者是通过提供某种聚合形式的api json result间接达成了某个UI上的展现&＃xff0c;比如多客户端的展示&＃xff0c;甚至是一些IOT设备上的报文、心跳信息等。

分层可以用于单实例的代码逻辑分层&＃xff0c;也就是独立部署的进程里面进行分层&＃xff0c;另一种方式的分层是物理部署节点的分层&＃xff0c;比如网关层独立部署&＃xff0c;逻辑层按读写分离独立部署&＃xff0c;持久层只做多数据源的聚合于路由&＃xff0c;几层都只干了逻辑分层的一部分能力&＃xff0c;但又是独立部署的。

分层是技术性的分区架构&＃xff0c;而不是一个领域的分区架构。分层是围绕于组件形成的&＃xff0c;而不是领域本身。

大部分场景可以依据分层方式实现&＃xff0c;属于一种通用普世的解决方案。

管道模式

还有一种常见的模式是管道模式&＃xff0c;或是过滤器模式。

说道过滤器模式&＃xff0c;大家可能最先想到的是如tomcat或filter这种实现方式&＃xff0c;任务过滤器顶多是实现大型系统里面某个组件功能的&＃xff0c;很难提升到架构设计维度吧。

其实不是的。

我们接触到的很多系统都有管道模式的影子&＃xff0c;特别是那些具有状态机驱动的场景&＃xff0c;比如订单有明确的状态机&＃xff0c;配送有明确的状态机&＃xff0c;很多都可以抽象出一个明确流转不可逆的状态机的&＃xff0c;这些具有明确状态机流转特点的系统都可以以管道模式进行设计。

他的设计特点围绕于输入、流转、输出过程中数据流的变化。

引入管道模式去解决复杂业务时&＃xff0c;可以设计成一个个的松耦合的组件&＃xff0c;组件之间有简单的通用交互机制&＃xff0c;可以灵活集合&＃xff0c;组件也更易复用&＃xff0c;你的数据流转也更清晰。

而一个重复请求的幂等处理或是路由处理&＃xff0c;可以很简单的基于状态机将其路由到某个指定的逻辑&＃xff0c;精简了链路&＃xff0c;去除了没有必要的逻辑处理。

比如以IM系统会话来说&＃xff0c;其包括会话创建&＃xff0c;会话排队&＃xff0c;会话分配&＃xff0c;会话聊天&＃xff0c;会话结束。我们只需要在会话创建时&＃xff0c;建立相关会话上下文&＃xff0c;其他后续流程就不需要对上下文信息进行过分的校验与考虑了&＃xff0c;只做”读行为“即可&＃xff0c;大大降低了编码复杂度和理解成本。

当然管道模式有他的好处&＃xff0c;其缺点也极其明显&＃xff0c;需要有明确的流转特征的系统&＃xff0c;而上下文信息的解析与泛解析成本会比较高&＃xff0c;所以我一般会将流程层独立抽象出一层&＃xff0c;降低其与领域层直接产生关系&＃xff0c;这样可以在扩展状态机时减少开发成本。

聚合网关模式

你可以认为是网关模式&＃xff0c;如果没有网关模式的话&＃xff0c;一个客户端对应一个server这样很多资源与逻辑是难以复用的&＃xff0c;所以好的方式是抽象出一个网关做资源聚合&＃xff0c;复用到多个客户端&＃xff0c;同时可以提高管控与弹性伸缩的能力。

网关中一般有两个组件&＃xff0c;”接收逻辑“与”处理逻辑“&＃xff0c;前者负责接收请求&＃xff0c;将其发送到处理器&＃xff0c;处理器处理之后异步响应回来。

这种模式适用于那些对于吞吐量有高要求&＃xff0c;但是处理周期长特点的业务系统。

其缺点也很明显&＃xff0c;就是处理逻辑会成为系统的性能瓶颈&＃xff0c;故障点。

MVC模式

MVC是我们常用的一种模式&＃xff0c;一般用于那些直接和客户端打交道的系统&＃xff0c;因为端对于UI及UI所需的格式有一定的要求&＃xff0c;而UI部分往往是一个改动频次较高的部分&＃xff0c;所以MV就是需要做好UI及UI背后的数据源支撑。

• 模型&＃xff1a;包含属性的数据模型

• 视图&＃xff1a;数据源及展示交互的组合

• 控制器&＃xff1a;承接模型与视图之间的衔接逻辑

事件驱动模式

计算机最常处理的场景就是对于事件的响应&＃xff0c;可以将特定业务抽象成事件&＃xff0c;并广播出去&＃xff0c;这样的好处是&＃xff0c;扩展能力好。

而大型系统对于事件的产生与处理使用的还是比较多的&＃xff0c;微服务架构下的事件通知往往是基于MQ实现的。

每个事件可以建立独立部署或独立处理逻辑的组件&＃xff0c;当事件进入队列后&＃xff0c;可以引入调度器根据策略进行调度&＃xff0c;或是事件处理器主动拉取事件进行事件处理。

分布式架构下&＃xff0c;常用的场景是对于状态机的事件订阅&＃xff0c;比如订单的达成、支付&＃xff0c;配送状态的变更、流转时间等&＃xff0c;其他团队基于事件监听异步跨服务的进行异步逻辑处理。

写在后面

知道了这些模式了&＃xff0c;可以在系统设计时有意识的看看是否可以适用&＃xff0c;一步步找到不同模式所特有的场景&＃xff0c;这种实现可大可小&＃xff0c;可以用作模块设计&＃xff0c;也可以用作微服务系统的组合搭建。