知识 - 软件架构模式
参考资料
架构模式
根据维基百科中的架构模式定义：
An architecture pattern is a general，reusable solution to a commonly occurring problem in software architecture within a given context.
在软件研发领域，最经典的两种架构设计模式，即微内核架构模式和 Pipe-Filter 架构模式。
Pipe-Filter 架构模式
Pipe-Filter 模式，即管道过滤器模式, 这种模式与工业制造生产流水线非常类似，每个环节都是独立的，但是又环环相扣，相互影响。
对应 Pipe-Filter 管道过滤器模式，管道就像生产流水线上的传送带，过滤器就像每一道工序上的机器。
- 管道负责数据的传递。
- 原始数据通过管道传送给第一个过滤器，第一个过滤器处理完成之后，再通过管道把处理结果传送给下一个过滤器。
- 重复这个过程直到处理结束。
- 最终得到需要的结果数据。
用一幅图来形象描述这个过程，如下图所示：
适用场景：
Web框架：Http请求到后端后，处理过程以及响应。(除了 Web 系统，其他像大数据数据处理与分析系统、编译器、Linux 管道命令等等，也大量使用了 Pipe-Filter 架构模式)
Filter 和组合模式
当 Pipe-Filter 遇上组合模式时，多个 Filter 又可以再组合成一个新的 Filter，如下图所示:
Serverless 和 FaaS
serveless 无服务架构可以显著降低企业中中长尾应用的成本，中长尾应用指那些每天大部分时间都没有流量或者有很少流量的应用。要实现这样的无服务架构，FaaS(Function as a Service)便是其中一个非常核心的组件 ，FaaS 中有一个核心组件叫 Fn Actuator，负责 Fn 函数的加载（可以是热加载，也可以是冷启动）、调度、执行。如下图所示：
Fn 执行方式有哪些？
- Fn 串行：多个 Fn 可以串行执行，每个 Fn 的执行结果会传递给下一个 Fn，作为下一个 Fn 的输入数据；
- Fn 并行：多个 Fn 可并行执行，当所有的 Fn 都执行完成之后，将这多个 Fn 的执行结果封装成一个数组传递给下一个 Fn；
- Fn 串行组合：多个 Fn 串行执行，并对外封装成一个新的 Fn，新的 Fn 入参与第一个 Fn 保持一致，返回值与最后一个 Fn 保持一致。这样封装有个好处，新的 Fn - 对使用的人来说，就是一个 Fn，只需关注入参和返回值，而无需关注内部的实现；
- Fn 并行组合：多个 Fn 并行执行，并对外封装成一个新的 Fn，新的 Fn 可重新定义入参和返回值；
- Fn 复杂组合：上述方式的自由组合；
Fn 可以是哪些类型?
- 纯函数：就是一个最简单的函数
- 远程服务调用：可以将一个 HTTP 或 RPC 调用封装成一个函数
- 脚本：可以将一个 SQL 或 shell 语句封装成一个函数
在封装一个 Fn 的时候，需要注意以下几点：
- 每个 Fn 只处理一件事情；
- 每个 Fn 的入参和返回值都必须显示声明；
- 每个 Fn 内部不能直接读取或修改外部的全局变量；
微内核架构模式
概念：微内核架构（Microkernel Architecture），也被称为插件化架构（Plugin-in Architecture），是一种面向功能进行拆分的可扩展架构。例如 VS Code、Eclipse 这一类 IDE 软件、UNIX 操作系统等等，都是参照微内核架构设计实现的。
微内核架构的两个核心组件
- 核心系统（Core System）
- 负责与具体功能无关的通用功能，例如，应用生命周期的管理、插件模块的管理（包括：插件模块的注册、载入、卸载等）
- 插件模块（Plug-in modules）
- 负责实现具体的功能，例如，一个 Web 框架基本上会按照功能模块拆分成如下的插件模块：路由模块、安全模块、HTTP 编解码模块等，每个模块都通过插件实现，每一个插件都只做一件事情。
架构示意图如下所示：
核心系统设计的关键点
- 插件管理
插件安装：各种编程语言的生态都有提供类似 maven、npm 这样的包管理工具，所以一般无需自己再造轮子，例如 Node 通过 npm install 命令即可。
启用插件：安装了一个插件仅代表这个系统依赖了这个插件的功能，但要想插件真正生效，还需要启用插件。启用插件一般是通过配置文件来进行声明。注意，在实现该功能模块的时候，需要考虑多环境（开发环境、测试环境、预发环境、生产环境等），插件可动态调整的配置一般也放到插件的配置文件里面；
插件通信：虽然设计时插件之间是完全解耦的，但实际运行过程中，必然会出现多个插件需要协作完成某个功能。这时就需要支持插件间的通信了，因此核心系统需要提供一套插件通信机制。注意: 插件与插件之间最好不要直接通信，应该通过核心系统来完成；
禁用插件：通过插件的配置文件，将插件状态从 enable 改成 false 即可；
卸载插件：卸载插件也很简单，一般各个包管理工具都有提供类似命令，例如：npm uninstall
- 应用管理
不管开发的是一个客户端 APP 软件，还是一个服务端的 Web 系统，在应用启动的时候，肯定会有一个主进程。
主进程设计的时候一般都比较轻量，这样更不容易出 bug，插件一般是通过子进程来实现，这样即使子进程挂了，也不会影响主进程。
像早期浏览器都是单进程的，浏览器的各种插件诸如 Web 播放器都是运行在浏览器同一个主进程之上的，所以经常会碰到一个插件奔溃了导致整个浏览器奔溃。
- 现代的浏览器早已改变了这种实现方式，最新的 Chrome 浏览器就会将进程拆分成 Browser Process、Render Process、GPU Process、Network Process、Plugin Process 五类进程，其中 Browser Process 浏览器进程就是负责各个子进程的管理。
插件模块设计的关键点
插件元数据定义
- 包括插件的名称、描述、版本号等等，插件的命名从一开始就要制定好规范，这样方便后期管理。像 Spring Boot 很多插件都是以 spring-boot-starter- 开头命名的。
插件要可插拔、可配置
- 插件应该是灵活可插拔的，当不需要一个插件的时候，可随时将这个插件卸载掉。插件中可配置的属性需要暴露到外界使用环境，实现业务可定制。（通常意义上的软件开发包sdk可以看做插件的集合）
每个插件都应该保持职责单一性
- 系统复杂度上升很多时候是因为模块拆分不合理导致的，一个插件其实就是实现了某一个功能模块，所以每个插件都要尽量保持职责单一性。
微内核架构应用案例:
- VS Code：VS code 内核是非常轻量的，只提供最基础的能力，其他功能都是通过一个个插件来扩展；
- 规则引擎：规则引擎也属于微内核架构的一种实现，其中执行引擎可以看做是微内核，执行引擎通过解析、执行配置规则，来达到业务的灵活多变
- Koa Web 框架：框架本身只提供最基础的能力，其他都是通过一个个中间件来扩展，中间件既是一个插件，也是一个 Filter，可以说是微内核架构与 Pipe-Filter 架构的完美融合。
总结
其实不管是什么类型的架构模式，都是围绕着下面的这些问题来解决的：
- 如何降低系统的复杂度
- 如何提高系统的可维护性、可扩展性、可配置性
但最终还是为了解决现实中的问题，把一个大的问题拆分成一个个小的问题，再通过某种方式把这些功能聚合在一起，进而达到解决这个大问题的目的。就像 MapReduce 算法模型，其实也是这样一个思路，当一个大的计算任务没办法通过一台计算机计算得到结果，那就先把这个大的计算任务拆分成一个个小的计算任务，然后把这些小的计算任务交给一个个独立的计算节点，最终再把每个子任务计算得到的结果汇总起来，然后得到一个最终的结果，正所谓“分久必合合久必分”。