前端架构设计：层次设计

我们在开发的不同阶段，构成的架构因素是不同的，基于这个思路，架构可以分为：

系统级架构

应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。在设计前端的时候，首先应该考虑的，是前端系统与其他系统之间是怎样的关系。

这种关系包含，业务关系和协作机制，比如与其他前端应用之间，如何进行交互和通信。如何与后台对接实现权限，授权，api管理等功能。

如果与后台通信，只需要规定与后台数据传递的机制即可，包括api设计规则，访问授权的一个开放标准（OAuth）跳转token的验证，数据传递cookie等。对于前端与后端的关系，我们所考虑的主要因素是前后端分离的架构设计。

前后端分离架构其实是如何实施技术决策，用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF(服务于前端的后端，nodejs)，是否需要服务端渲染等。所有以上决策，都需要不同团队，比如前端与后端，与产品需求分析师，与测试的不断沟通，才能一起设计出整个系统方案。

而微前端很微妙，在一个系统内微前端是应用间的架构方案；在多个应用之间，微前端则是一种系统间等架构方案。微前端是将多个前端应用以某种形式结合在一起进行应用。下面我们来深入了解一下，微前端。

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。

这类问题在企业级 Web 应用中尤其常见，比如淘宝。阿里这么大的体系，淘宝，天猫，支付宝，一淘，淘票票，阿里云，都可以用同一个账号登陆，他们前端部分就是用的微前端，登陆这块就是一个微前端模块。

还比如，之前我负责开发大屏系统，里面的角色权限控制模块可以独立成一个微前端，通过路由连接主系统；我们在孔雀屏系统配置好大屏页面，获得一个URL地址，将地址用类似iframe的方式放到系统页面里面展现。这其实就是一个比较简单的微前端解决方案。

这块架构的难点，在于主系统与各个子应用的连接方式，模块导入，子应用暴露钩子，路由配置，应用和样式隔离，js隔离，跨域等问题的解决方案。

应用级架构可以看作是系统级架构的细化，比如单个应用与其他外部应用的关系，微服务架构下多个应用的协作，数据交换等。由于各个应用之间，需要通过复用代码，共享组件库，统一设计等减少工作量，因此，微妙要考虑以下几个方面内容：

脚手架。我另一篇文章前端脚手架CLI生成模版命令工具（包括，npm包的发布，脚手架的搭建，注意事项，优化等）作为一个基础等模块应用，脚手架用于快速生成搭建前端应用。它除了包含一个前端项目所需等要素，还包含组织内部相关等规范和模式，如部署模版，构建系统等。一个CLI应用可以支持多个应用等开发，能根本的提高团队整体的工作效率。
模式库。它是一系列可复用代码合集，如前端组件，通用工具函数等，带业务或不带业务的组件。作用是多个应用之间共享代码，降低修改成本。模式库，有的只涉及UI层面，比如antd；有的涉及业务，有的可以封装通用接口，有的包含多个应用通信数据库，这个就需要多方统一协作沟通，最终目的就是提高工作效率，降低开发和维护成本。
设计系统。这个主要偏向设计人员模式，而非开发人员视角。需要UI有更高的视野，才能设计出有高度统一标准的UI规范。

这部分内容是我们开始业务编码之前进行设计，我们称为迭代0，相关内容有两方面：

模块化。包含css,js,html的模块化。js受框架的影响比较大（vue还是react）；css我们需要设计一个合理的方式进行管理，比如全局样式的复用（antd global样式），局部样式用于隔离，通用变量方便修改（主题色）；还需要定义js，css，html代码的组织方式。
组件化主要考虑，如何对组件进行封装，以及组件拆分原则和粒度（考虑复用性）。

真正实际操作写代码的时候，主要考虑以下几个问题：

此外，在开发中，还要注意可维护性，简单的代码可维护性高，更容易读懂和维护。越是写的抽象的代码越难维护。比如前端的hook，有的人滥用，没用好很难维护。

以上就是根据开发的不同阶段，需要思考的四个不同层级的架构。