转载

前端架构，有什么能做的？

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

架构是什么？

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

因为：

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

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

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

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

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

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

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

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

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

系统内架构

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

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

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

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

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

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

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

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

应用级架构

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

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

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

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

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

模块级架构

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

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

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