如何一步步设计前端架构？

叁歲伎倆 2021-09-20 07:54 345阅读 0赞

前端有架构吗？前端有架构模式吗？

## 架构是什么？ ##

![v2-1fc1ea0271fb2581e24d4f65b38cf175_hd.jpg][]

软件架构，是一种为了解决复杂问题的通用模式。软件架构，是关于软件系统的一系列有层次的技术决策的集合。换句话来说，当我们讨论架构的时候，不能只讨论某某架构，而是要包含其实施，以及后期的维护。

因为：

*  一个无法上线的应用架构，算不上是好的软件架构
 *  一个没有人能完成开发的软件架构，算不上是可行的软件架构
 *  一个在现有的技术上不可行的架构，算不上是合理的软件架构

诸如微服务，对于复杂的后端系统来说，是一种不错的『低耦合，高内聚』的实施。但是，它并不适合于大部分的小公司——复杂的架构不适合于简单的应用。而小公司也缺乏足够的人才，来实施一个复杂的系统，与此同时还需要有人能维护这个系统。

所以，当我们谈及软件架构的时候，说的是：有这么一些人，他/她们能按时、高质量（或者说有质量）完成这一个系统的设计——即**有能力的个人**。

PS：对于前端架构来说，这些人大概率会来自于看了本书的人，笑~

## 前端架构拆解：四层次设计 ##

![v2-5e662bbc9f5a7cdaae01139939b07d08_hd.jpg][]

从笔者的角度来看，架构设计本身是分层级的，面向不同级别的人时，所展示的内容也是不一样的。如面对的是同一级别、更高一级别的架构师、技术人员，说的便是形而上学的东西，如微前端、前后端分离，并通过各种概念，如构建系统拆份，以抽象的方式介绍如何去设计。这些概念，对于接触过的程序员来说，也是相当好理解的。而当我们面对的是，经验略微丰富的程序员的时候，说的可就不是：去实现微前端这样的东西。而是需要落实到怎样去做这样的一件事。

在不同的时期，不同的阶段，我们考虑的架构相关的因素是不同的。按照这个思想，笔者将架构的设计分为了四个层级：

系统级，即应用在整个系统内的关系，如与后台服务如何通讯，与第三方系统如何集成。 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。 代码级，即从基础设施来保障架构实施。

对应的层级与实施模式，如下图所示：

!前端四个层级

### 系统内架构 ###

![v2-942b973f9518aa183bb6cd54dafd1194_hd.jpg][]

在设计前端架构的时候，首先考虑的是应用在整个系统中的位置——它与系统中的其它子系统是怎样的。这种关系包含了架构上的关系、业务上的关系，以及它们之间的协作机制。对于前端应用来说，这一部分的子系统包含了：

*  其它前端应用。侧重于关注如何与这些应用交互，诸如交互、通讯等。
 *  对接的后台服务。关注于如何与后台服务进行通信，诸如权限、授权、API 管理等。

若是系统间的数据通信，如与后台服务之间的交互，那么只需要规定好数据通信、数据传递的机制即可。这一类的通讯机制，不仅仅包含了前后端分离架构的 API 设计，还包含了各类的数据传递，诸如 OAuth 跳转的 Token 验证。除此，对于传统的多页面应用来说，也需要关注于其中的数据传递，如 Cookie 作为用户凭据等等。

为此，对于前端开发人员来说，关于与后端间的关系，我们所要考虑的主要因素是前后端分离架构的设计。

*  **前后端分离架构**。（详见《前端架构：从入门到微前端》）
 *  **微前端架构**。（详见《前端架构：从入门到微前端》）

而后，我们还需要考虑到前端的**客户端展现形式**。在大前端的背景之下，它可能是以 PC Web 应用、移动 Web 应用、混合移动应用（结合 Cordova 构架）、混合桌面应用（结合 Electron 框架）、原生移动应用（结合 React Native）等，具体选择何一种技术，取决于我们在之前调查的利益相关者的需求。

当我们做完上述的三个核心的架构决策之后，就需要考虑一下应用的**部署架构**。不同的客户端形式，或者需要服务端渲染，会在某种程度上影响到前端应用的部署，但是总的影响并不是太大。往往只需要通过反向代理的配置，就可以完成部署的配置。若是与后台服务不在一个域，则需要考虑**支持跨域请求或者是后台做一层代码**。

在有了这些基本的架构设定，便可以往下继续设计下一层级的应用架构。

### 应用级架构 ###

![v2-2dabcd2aaa4e4f05dd244ed7ccb05b7d_hd.jpg][]

应用级架构，指的是单个应用与外部应用的关系，如微服务架构下的多个应用的协作。它可以是一个团队下的多个前端应用，又或者是一个组织内的前端应用。其在组织中所处的位置，也进一步决定了我们所需要设计的架构方案。

若是从相关的定义上来看，它与系统级应用存在一定的交集。但是，笔者将其视之为系统级架构的进一步细化。如在系统内架构的层级里，我们定义了微前端架构，而具体的实施细则会放在各个应用中实现的。而诸如应用间的数据如何交换，而不同的应用又有各自不同的实现，则会在这个层级里定义了相应的接口。

与此同时，当我们维护了多个前端应用，必然会去考虑在这些应用之间，复用代码、共享组件库、统一设计等，以减少相应的工作量。为此，在这个层级里，我们会考虑下面的一些架构相关的设计内容：

*  **脚手架**。（详见《前端架构：从入门到微前端》）
 *  **模式库**。（详见《前端架构：从入门到微前端》）
 *  **设计系统**。（详见《前端架构：从入门到微前端》）

与此同时，在这个层级里，我们决定**选择什么前端框架**，进行相关的技术选型。

### 模块级架构 ###

![v2-eff5220ba821122d6043c31533bb81dc_hd.jpg][]

模块级架构，便是深入单个应用内部，更细致的设计应用内部的架构。它所涉及的部分，便是在日常开发中，我们经常接触到的主要部分。我们所做的便是制定一些规范，又或者是更细致的架构设计。这部分的内容，会在我们开始业务编码之前进行设计，在敏捷软件开发中，它称之为 迭代 0/Sprint 0/Iteration 0。相关的内容有：

*  **模块化**。（详见《前端架构：从入门到微前端》）
 *  **组件化**。（详见《前端架构：从入门到微前端》）

除此，对于不同的框架，还涉及到一些**框架特定的模式**与架构设计，它们会在一定程度上影响单个应用的架构。对于不同的框架来说，所需要涉及的范围都有所不发。如在 Angular 框架中，不需要操心相关的模式，只需要掌握框架定义的规范即可，如使用 Service 来保存应用的状态，使用 Pipe 来处理数据等。而在 React 框架中，则需要设计**状态和数据流**的管理方式，为此便需要诸如 Flux 或者 Redux 这样的状态管理方案。

### 代码级：规范与原则 ###

![v2-b3acb6b95d4f1735725ccd55ab0b1dd4_hd.jpg][]

当我们真正编码的时候，考虑的架构因素便是更低层级的内容。这部分的架构设计，便称为代码级的架构设计，它关注于实践过程中的相关规范和原则。这部分的内容相当的多，并且繁琐。它包含了以下的内容，但是又不限于下述的部分：

*  **开发流程**。（详见《前端架构：从入门到微前端》）
 *  **代码质量及改善**。（详见《前端架构：从入门到微前端》）
 *  **规范而非默契**。（详见《前端架构：从入门到微前端》）

除此，在日常的开发中，还需要注重**代码的可维护**——简单的代码更容易读性和维护。笔者维护一个 Scala 项目的过程中，便是深有体会——越是写得越抽象的代码，越难以维护。诸如函数式编程是一个好的东西，但是好的东西也容易被烂用，导致人们不喜欢这个东西。

## 小结 ##

买， 买，买

——节选自《前端架构：从入门到微前端》

[v2-1fc1ea0271fb2581e24d4f65b38cf175_hd.jpg]: /images/20210812/937b63d2b7104bb382fab75053811d0c.png
[v2-5e662bbc9f5a7cdaae01139939b07d08_hd.jpg]: /images/20210812/70423e4fae77480fb1a24d9b047a87e5.png
[v2-942b973f9518aa183bb6cd54dafd1194_hd.jpg]: /images/20210812/d33a7157ee5249ba97e3f361dc25c5a3.png
[v2-2dabcd2aaa4e4f05dd244ed7ccb05b7d_hd.jpg]: /images/20210812/e4f1dc1ea00441fdaa000b13b13f4514.png
[v2-eff5220ba821122d6043c31533bb81dc_hd.jpg]: /images/20210812/240d1db911d7435ebf83cc4b44a4c705.png
[v2-b3acb6b95d4f1735725ccd55ab0b1dd4_hd.jpg]: /images/20210812/d27634d0bc5342c9a28378d6a5f5df42.png