软件架构设计案例_透过现象看本质：常见的前端架构风格和案例

所谓软件架构风格，是指描述某个特定应用领域中系统组织方式的惯用模式。架构风格定义一个词汇表和一组约束，词汇表中包含一些组件及连接器，约束则指出系统如何将构建和连接器组合起来。软件架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将系统中的各个模块和子系统有机的结合为一个完整的系统

没多少人能记住上面的定义，需要注意的是本文不是专业讨论系统架构的文章，笔者也还没到那个水平. 所以暂时没必要纠结于什么是架构模式、什么是架构风格。在这里尚且把它们都当成一个系统架构上的套路, 所谓的套路就是一些通用的、可复用的，用于应对某类问题的方式方法. 可以理解为类似“设计模式”的东西，只是解决问题的层次不一样。

透过现象看本质，本文将带你领略前端领域一些流行技术栈背后的架构思想。直接进入正题吧

文章大纲

分层风格
Virtual DOM
Taro
管道和过滤器
中间件(Middleware)
事件驱动
MV*
家喻户晓的MVC
Redux
复制风格
微内核架构
微前端
组件化架构
其他
扩展阅读

分层风格

没有什么问题是分层解决不了，如果解决不了, 就再加一层 —— 鲁迅不不，原话是: Any problem in computer science can be solved by anther layer of indirection.

分层架构是最常见的软件架构，你要不知道用什么架构，或者不知道怎么解决问题，那就尝试加多一层。

一个分层系统是按照层次来组织的，每一层为在其之上的层提供服务，并且使用在其之下的层所提供的服务. 分层通常可以解决什么问题？

是隔离业务复杂度与技术复杂度的利器. 典型的例子是网络协议, 越高层越面向人类，越底层越面向机器。一层一层往上，很多技术的细节都被隐藏了，比如我们使用HTTP时，不需要考虑TCP层的握手和包传输细节，TCP层不需要关心IP层的寻址和路由。

分离关注点和复用。减少跨越多层的耦合, 当一层变动时不会影响到其他层。例如我们前端项目建议拆分逻辑层和视图层，一方面可以降低逻辑和视图之间的耦合，当视图层元素变动时可以尽量减少对逻辑层的影响；另外一个好处是, 当逻辑抽取出去后，可以被不同平台的视图复用。

关注点分离之后，软件的结构会变得容易理解和开发, 每一层可以被复用, 容易被测试, 其他层的接口通过模拟解决. 但是分层架构，也不是全是优点，分层的抽象可能会丢失部分效率和灵活性, 比如编程语言就有'层次'(此例可能不太严谨)，语言抽象的层次越高，一般运行效率可能会有所衰减:

分层架构在软件领域的案例实在太多太多了，咱讲讲前端的一些'分层'案例：

我自己是一名从事了多年开发的web前端老程序员，目前辞职在做自己的web前端私人定制课程，今年年初我花了一个月整理了一份最适合2019年学习的web前端学习干货，各种框架都有整理，送给每一位前端小伙伴，想要获取的可以关注我的头条号并在后台私信我：前端，即可免费获取。

Virtual DOM

前端石器时代，我们页面交互和渲染，是通过服务端渲染或者直接操作DOM实现的, 有点像C/C++这类系统编程语言手动操纵内存. 那时候JQuery很火:

后来随着软硬件性能越来越好、Web应用也越来越复杂，前端开发者的生产力也要跟上，类似JQuery这种命令式的编程方式无疑是比较低效的. 尽管手动操作 DOM 可能可以达到更高的性能和灵活性，但是这样对大部分开发者来说太低效了，我们是可以接受牺牲一点性能换取更高的开发效率的.

怎么解决，再加一层吧，后来React就搞了一层VirtualDOM。我们可以声明式、组合式地构建一颗对象树, 然后交由React将它映射到DOM：

一开始VirtualDOM和DOM的关系比较暧昧，两者是耦合在一起的。后面有人想，我们有了VirtualDOM这个抽象层，那应该能多搞点别的，比如渲染到移动端原生组件、PDF、Canvas、终端UI等等。

后来VirtualDOM进行了更彻底的分层，有着这个抽象层我们可以将VirtualDOM映射到更多类似应用场景:

所以说 VirtualDOM 更大的意义在于开发方式的转变: 声明式、数据驱动, 让开发者不需要关心 DOM 的操作细节(属性操作、事件绑定、DOM 节点变更)，换句话说应用的开发方式变成了view=f(state), 这对生产力的解放是有很大推动作用的; 另外有了VirtualDOM这一层抽象层，使得多平台渲染成为可能。

当然VirtualDOM或者React，不是唯一，也不是第一个这样的解决方案。其他前端框架，例如Vue、Angular基本都是这样一个发展历程。

上面说了，分层不是银弹。我们通过ReactNative可以开发跨平台的移动应用，但是众所周知，它运行效率或者灵活性暂时是无法与原生应用比拟的。

Taro

Taro 和React一样也采用分层架构风格，只不过他们解决的问题是相反的。React加上一个分层，可以渲染到不同的视图形态；而Taro则是为了统一多样的视图形态: 国内现如今市面上端的形态多种多样，Web、React-Native、微信小程序...... 针对不同的端去编写多套代码的成本非常高，这种需求催生了Taro这类框架的诞生. 使用 Taro，我们可以只书写一套代码, 通过编译工具可以输出到不同的端:

(图片来源: 多端统一开发框架 - Taro)

管道和过滤器

在管道/过滤器架构风格中，每个组件都有一组输入和输出，每个组件职责都很单一, 数据输入组件，经过内部处理，然后将处理过的数据输出。所以这些组件也称为过滤器，连接器按照业务需求将组件连接起来，其形状就像‘管道’一样，这种架构风格由此得名。

这里面最经典的案例是*unix Shell命令，Unix的哲学就是“只做一件事，把它做好”，所以我们常用的Unix命令功能都非常单一，但是Unix Shell还有一件法宝就是管道，通过管道我们可以将命令通过标准输入输出串联起来实现复杂的功能:

# 获取网页，并进行拼写检查。代码来源于wikicurl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | sed 's/[^a-zA-Z ]/ /g' | r 'A-Z ' 'a-z' | grep '[a-z]' | sort -u | comm -23 - /usr/share/dict/words | less

另一个和Unix管道相似的例子是ReactiveX, 例如RxJS. 很多教程将Rx比喻成河流，这个河流的开头就是一个事件源，这个事件源按照一定的频率发布事件。Rx真正强大的其实是它的操作符，有了这些操作符，你可以对这条河流做一切可以做的事情，例如分流、节流、建大坝、转换、统计、合并、产生河流的河流......

这些操作符和Unix的命令一样，职责都很单一，只干好一件事情。但我们管道将它们组合起来的时候，就迸发了无限的能力.

import { fromEvent } from 'rxjs';import { throttleTime, map, scan } from 'rxjs/operators';fromEvent(document, 'click') .pipe( throttleTime(1000), map(event => event.clientX), scan((count, clientX) => count + clientX, 0) ) .subscribe(count => console.log(count));

除了上述的RxJS，管道模式在前端领域也有很多应用，主要集中在前端工程化领域。例如'老牌'的项目构建工具Gulp, Gulp使用管道化模式来处理各种文件类型，管道中的每一个步骤称为Transpiler(转译器), 它们以 NodeJS 的Stream 作为输入输出。整个过程高效而简单。

不确定是否受到Gulp的影响，现代的Webpack打包工具，也使用同样的模式来实现对文件的处理, 即Loader, Loader 用于对模块的源代码进行转换, 通过Loader的组合，可以实现复杂的文件转译需求.

// webpack.config.jsmodule.exports = { ... module: { rules: [{ test: /.scss$/, use: [{ loader: "style-loader" // 将 JS 字符串生成为 style 节点 }, { loader: "css-loader" // 将 CSS 转化成 CommonJS 模块 }, { loader: "sass-loader" // 将 Sass 编译成 CSS }] }] }};

中间件(Middleware)

如果开发过Express、Koa或者Redux, 你可能会发现中间件模式和上述的管道模式有一定的相似性，如上图。相比管道，中间件模式可以使用一个洋葱剖面来形容。但和管道相比，一般的中间件实现有以下特点:

中间件没有显式的输入输出。这些中间件之间通常通过集中式的上下文对象来共享状态
有一个循环的过程。管道中，数据处理完毕后交给下游了，后面就不管了。而中间件还有一个回归的过程，当下游处理完毕后会进行回溯，所以有机会干预下游的处理结果。

我在谷歌上搜了老半天中间件，对于中间件都没有得到一个令我满意的定义. 暂且把它当作一个特殊形式的管道模式吧。这种模式通常用于后端，它可以干净地分离出请求的不同阶段，也就是分离关注点。比如我们可以创建这些中间件：

日志：记录开始时间 ⏸ 计算响应时间，输出请求日志
认证：验证用户是否登录
授权：验证用户是否有执行该操作的权限
缓存：是否有缓存结果，有的话就直接返回 ⏸ 当下游响应完成后，再判断一下响应是否可以被缓存
执行：执行实际的请求处理 ⏸ 响应

有了中间件之后，我们不需要在每个响应处理方法中都包含这些逻辑，关注好自己该做的事情。下面是Koa的示例代码:

const Koa = require('koa');const app = new Koa();// loggerapp.use(async (ctx, next) => { await next(); const rt = ctx.response.get('X-Response-Time'); console.log(`${ctx.method} ${ctx.url} - ${rt}`);});// x-response-timeapp.use(async (ctx, next) => { const start = Date.now(); await next(); const ms = Date.now() - start; ctx.set('X-Response-Time', `${ms}ms`);});// responseapp.use(async ctx => { ctx.body = 'Hello World';});app.listen(3000);

事件驱动

事件驱动, 或者称为发布-订阅风格，对于前端开发来说是再熟悉不过的概念了. 它定义了一种一对多的依赖关系，在事件驱动系统风格中，组件不直接调用另一个组件，而是触发或广播一个或多个事件。系统中的其他组件在一个或多个事件中注册。当一个事件被触发，系统会自动通知在这个事件中注册的所有组件.

这样就分离了关注点，订阅者依赖于事件而不是依赖于发布者，发布者也不需要关心订阅者，两者解除了耦合。

生活中也有很多发布-订阅的例子，比如微信公众号信息订阅，当新增一个订阅者的时候，发布者并不需要作出任何调整，同样发布者调整的时候也不会影响到订阅者，只要协议没有变化。我们可以发现，发布者和订阅者之间其实是一种弱化的动态的关联关系。

解除耦合目的是一方面, 另一方面也可能由基因决定的，一些事情天然就不适合或不支持用同步的方式去调用，或者这些行为是异步触发的。

JavaScript的基因决定事件驱动模式在前端领域的广泛使用. 在浏览器和Node中的JavaScript是如何工作的? 可视化解释简单介绍了Javascript的执行原理，其中提到JavaScript是单线程的编程语言，为了应对各种实际的应用场景，一个线程以压根忙不过来的，事件驱动的异步方式是JavaScript的救命稻草.

浏览器方面，浏览器就是一个GUI程序，GUI程序是一个循环(更专业的名字是事件循环)，接收用户输入，程序处理然后反馈到页面，再接收用户输入... 用户的输入是异步，将用户输入抽象为事件是最简洁、自然、灵活的方式。

需要注意的是：事件驱动和异步是不能划等号的。异步 !== 事件驱动，事件驱动 !== 异步

扩展:

响应式编程: 响应式编程本质上也是事件驱动的，下面是前端领域比较流行的两种响应式模式：
函数响应式(Functional Reactive Programming), 典型代表RxJS
透明的函数响应式编程(Transparently applying Functional Reactive Programming - TFRP), 典型代表Vue、Mobx
消息总线：指接收、发送消息的软件系统。消息基于一组已知的格式，以便系统无需知道实际接收者就能互相通信

MV*

MV*架构风格应用也非常广泛。我觉MV*本质上也是一种分层架构，一样强调职责分离。其中最为经典的是MVC架构风格，除此之外还有各种衍生风格，例如MVP、MVVM、MVI(Model View Intent). 还有有点关联Flux或者Redux模式。

家喻户晓的MVC

如其名，MVC将应用分为三层，分别是：

视图层(View) 呈现数据给用户
控制器(Controller) 模型和视图之间的纽带，起到不同层的组织作用：
处理事件并作出响应。一般事件有用户的行为(比如用户点击、客户端请求)，模型层的变更
控制程序的流程。根据请求选择适当的模型进行处理，然后选择适当的视图进行渲染，最后呈现给用户
模型(Model) 封装与应用程序的业务逻辑相关的数据以及对数据的处理方法, 通常它需要和数据持久化层进行通信

目前前端应用很少有纯粹使用MVC的，要么视图层混合了控制器层，要么就是模型和控制器混合，或者干脆就没有所谓的控制器. 但一点可以确定的是，很多应用都不约而同分离了'逻辑层'和'视图层'。

下面是典型的AngularJS代码, 视图层:

`Todo`

{{todoList.remaining()}} of {{todoList.todos.length}} remaining [ archive ] {{todo.text}}

逻辑层:

angular.module('todoApp', []) .controller('TodoListController', function() { var todoList = this; todoList.todos = [ {text:'learn AngularJS', done:true}, {text:'build an AngularJS app', done:false}]; todoList.addTodo = function() { todoList.todos.push({text:todoList.todoText, done:false}); todoList.todoText = ''; }; todoList.remaining = function() { var count = 0; angular.forEach(todoList.todos, function(todo) { count += todo.done ? 0 : 1; }); return count; }; todoList.archive = function() { var oldTodos = todoList.todos; todoList.todos = []; angular.forEach(oldTodos, function(todo) { if (!todo.done) todoList.todos.push(todo); }); }; });

至于MVP、MVVM，这些MVC模式的延展或者升级，网上都大量的资源，这里就不予赘述。

Redux

Redux是Flux架构的改进、融合了Elm语言中函数式的思想. 下面是Redux的架构图:

从上图可以看出Redux架构有以下要点:

单一的数据源.
单向的数据流.

单一数据源, 首先解决的是传统MVC架构多模型数据流混乱问题(如下图)。单一的数据源可以让应用的状态可预测和可被调试。另外单一数据源也方便做数据镜像，实现撤销/重做，数据持久化等等功能

单向数据流用于辅助单一数据源, 主要目的是阻止应用代码直接修改数据源，这样一方面简化数据流，同样也让应用状态变化变得可预测。

上面两个特点是Redux架构风格的核心，至于Redux还强调不可变数据、利用中间件封装副作用、范式化状态树，只是一种最佳实践。还有许多类Redux的框架，例如Vuex、ngrx，在架构思想层次是一致的:

复制风格

基于复制(Replication)风格的系统，会利用多个实例提供相同的服务，来改善服务的可访问性和可伸缩性，以及性能。这种架构风格可以改善用户可察觉的性能，简单服务响应的延迟。

这种风格在后端用得比较多，举前端比较熟悉的例子，NodeJS. NodeJS是单线程的，为了利用多核资源，NodeJS标准库提供了一个cluster模块，它可以根据CPU数创建多个Worker进程，这些Worker进程可以共享一个服务器端口，对外提供同质的服务, Master进程会根据一定的策略将资源分配给Worker:

const cluster = require('cluster');const http = require('http');const numCPUs = require('os').cpus().length;if (cluster.isMaster) { console.log(`Master ${process.pid} is running`); // Fork workers. for (let i = 0; i < numCPUs; i++) { cluster.fork(); } cluster.on('exit', (worker, code, signal) => { console.log(`worker ${worker.process.pid} died`); });} else { // Workers可以共享任意的TCP连接 // 比如共享HTTP服务器 http.createServer((req, res) => { res.writeHead(200); res.end('hello world'); }).listen(8000); console.log(`Worker ${process.pid} started`);}

利用多核能力可以提升应用的性能和可靠性。我们也可以利用PM2这样的进程管理工具，来简化Node集群的管理，它支持很多有用的特性，例如集群节点重启、日志归集、性能监视等。

复制风格常用于网络服务器。浏览器和Node都有Worker的概念，但是一般都只推荐在CPU密集型的场景使用它们，因为浏览器或者NodeJS内置的异步操作已经非常高效。实际上前端应用CPU密集型场景并不多，或者目前阶段不是特别实用。除此之外你还要权衡进程间通信的效率、Worker管理复杂度、异常处理等事情。

有一个典型的CPU密集型的场景，即源文件转译. 典型的例子是CodeSandbox, 它就是利用浏览器的Worker机制来提高源文件的转译性能的: