【后端教程】最经典的两种软件架构模式

1.1 适用的场景

那么，Pipe-Filter 管道过滤器模式有哪些适用的场景呢个就是 Web 框架，像 Koa 洋葱模型其实就是参照 Pipe-Filter 架构模式设计的。在软件研发领域，Web 系统可以说是最常见的一类系统了，生活中我们每天都在使用这样的系统，从 交工具微信、QQ，到购物 站淘宝、京东，生活中我们无时无刻不在使用这样的系统。那么，设计这样的一个系统，Pipe-Filter 模式又有哪些应用案例呢赞商家管理后台为例（流程已精简），当一个用户访问我们的商家后台时，会经过如下的处理环节。

1.3 Serverless 和 FaaS

Filter 和组合模式又有哪些应用案例呢下，有个非常火的系统架构叫 serverless 架构（即无服务架构），serveless 无服务架构可以显著降低企业中中长尾应用的成本，中长尾应用指那些每天大部分时间都没有流量或者有很少流量的应用。要实现这样的无服务架构，FaaS 便是其中一个非常核心的组件，FaaS 是 Function as a Service 的简称，FaaS 中有一个核心组件叫 Fn Actuator，负责 Fn 函数的加载（可以是热加载，也可以是冷启动）、调度、执行。如下图所示：

核心系统功能尽量保持稳定，不要因为插件模块的扩展而不断修改，插件模块可以根据功能需求进行不断扩展。

2.3 核心系统设计的几个关键点

插件管理

• 插件安装：各种编程语言的生态都有提供类似 maven、npm 这样的包管理工具，所以一般无需自己再造轮子，例如 Node 通过 npm install 命令即可，例如：npm install [<@scope>/]@；

• 启用插件：安装了一个插件仅代表这个系统依赖了这个插件的功能，但要想插件真正生效，还需要启用插件，启用插件一般是通过配置文件来进行声明。注意，在实现该功能模块的时候，需要考虑多环境（一般分：开发环境、测试环境、预发环境、生产环境等），插件可动态调整的配置一般也放到插件的配置文件里面；

• 插件通信：插件通信指的是指插件之间的通信，虽然设计插件的时候插件之间是完全解耦的，但实际运行的过程中，必然会出现多个插件需要协作完成某个功能，这时候就需要支持插件间的通信了，因此核心系统需要提供一套插件通信机制。有一个需要注意的地方，插件与插件之间最好不要直接通信，插件通信都通过核心系统来完成；

• 禁用插件：禁用插件就很简单了，一般通过插件的配置文件，将插件 enable 状态设置成 false 即可；

• 卸载插件：卸载插件也很简单，一般各个包管理工具都有提供类似命令，例如：npm uninstall [<@scope>/][@]

应用管理

不管你开发的是一个客户端 APP 软件，还是一个服务端的 Web 系统，在应用启动的时候，肯定会有一个主进程，主进程设计的时候一般都比较轻量，这样更不容易出 bug，插件一般是通过子进程来实现，这样即使子进程挂了，也不会影响主进程。像早期浏览器都是单进程的，浏览器的各种插件诸如 Web 播放器都是运行在浏览器同一个主进程之上的，所以经常会碰到一个插件奔溃了导致整个浏览器奔溃。现代的浏览器早已改变了这种实现方式，最新的 Chrome 浏览器就会将进程拆分成 Browser Process、Render Process、GPU Process、Network Process、Plugin Process 五类进程，其中 Browser Process 浏览器进程就是负责各个子进程的管理。

总结下，核心系统在实现应用管理模块功能的时候，其实就主要实现下面两块功能：

• 应用本身的生命周期管理

• 插件生命周期的管理

2.4 插件模块设计的几个关键点

插件元数据定义

包括插件的名称、描述、版本 等等，插件的命名从一开始就要制定好规范，这样方便后期管理。像 Spring Boot 很多插件都是以 spring-boot-starter- 开头命名的。

插件要可插拔、可配置

插件应该是灵活可插拔的，当不需要一个插件的时候，可随时将这个插件卸载掉。插件中可配置的属性需要暴露到外界使用环境，实现业务可定制。

每个插件都应该保持职责单一性

系统复杂度上升很多时候是因为模块拆分不合理导致的，一个插件其实就是实现了某一个功能模块，所以每个插件都要尽量保持职责单一性。

2.5 微内核架构应用案例

• VS Code：VS code 内核是非常轻量的，只提供最基础的能力，其他功能都是通过一个个插件来扩展；
• 规则引擎：规则引擎也属于微内核架构的一种实现，其中执行引擎可以看做是微内核，执行引擎通过解析、执行配置规则，来达到业务的灵活多变
• Koa Web 框架：框架本身只提供最基础的能力，其他都是通过一个个中间件来扩展，中间件既是一个插件，也是一个 Filter，可以说是微内核架构与 Pipe-Filter 架构的完美融合。

其他还有很多应用案例，因篇幅所限，就不再详细介绍，有兴趣的小伙伴可自行研究。最后，这两种架构模式到这里就讲完了，其实不管是什么类型的架构模式，都是围绕着下面的这些问题来解决的：

• 如何降低系统的复杂度
• 如何提高系统的可维护性
• 如何提高系统的可扩展性
• 如何提高系统的可配置性

但最终还是为了解决现实中的问题，把一个大的问题拆分成一个个小的问题，再通过某种方式把这些功能聚合在一起，进而达到解决这个大问题的目的。
就像 MapReduce 算法模型，其实也是这样一个思路，当一个大的计算任务没办法通过一台计算机计算得到结果，那就先把这个大的计算任务拆分成一个个小的计算任务，然后把这些小的计算任务交给一个个独立的计算节点，最终再把每个子任务计算得到的结果汇总起来，然后得到一个最终的结果，正所谓“分久必合合久必分”。

服务推荐

• 蜻蜓代理
• ip代理服务器
• 企业级代理ip
• 微信域名检测
• 微信域名拦截检测

文章知识点与官方知识档案匹配，可进一步学习相关知识CS入门技能树Linux入门初识Linux25349 人正在系统学习中