聊聊软件架构与前端架构

在软件开发行业中，我们经常能够听到架构，架构师。前端架构师, 听起来就是个很高大上的 Title, 每个初入行的前端工程师在面试时, 被问到你未来的方向是什么? 我们或许都会很顺口的回答, "嗯, 朝着架构方向走吧..."。

在我们前端工程师的视角中，前端架构师可能是一个：

1. 技术很赞, 编写代码的能力较强
2. 对当前正在运行的业务有着较高的把握
3. 工作时不经常写代码，更多的时间是在画架构图PPT等
4. 对项目运行来说，看的更加长远能够考虑到后续维护

前端架构师主要搞的就是整体的项目架构，对整体项目有一个把控。

那么软件架构到底是什么？前端架构又是什么？

在下面让我给大家一一道来我对软件架构和前端架构上的一些理解。

我理解的软件架构

在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。

而软件架构有如下几个概念：系统与子系统，模块与组件，框架与架构。

对于我个人的理解来说：

系统与子系统：

系统：一个整体的完整的事物，比方说，前端目前情况能脱离后端独立运行吗？后端不使用View层的情况下能脱离前端运行吗? 很显然不能。那么他们单独拎出来就不能说是一个大系统。当然，你如果对前端后端内部进行细分，其实还是可以分出来很多很多系统。类似比如登录系统，登陆系统内会有很多小系统来支撑登录的功能运行。而你将前端和后端之间打通一个桥梁，前端作为展示数据，后端作为传输数据，操作数据。他俩组合起来才能够运行，这我称之为一个系统。

子系统：子系统与系统的定义其实是一致的，只不过是观察的角度有差异，一个系统可能是另一个更大系统的子系统。类似于在前端系统中，有登录系统，用户管理系统。而在登录系统中，包含了账号密码登录，第三方账号登陆，手机号登录等等子系统。

模块与组件：

模块：比如说后端开发中的模块，我们分为了controllers(控制器）models(数据模型) config（配置）等等诸多模块，再比如说前端中，小到一个登录函数，大到我们的翻译适用，都能称之为是一个模块。

组件：又比如说前端开发中的视图组件，我们分为了基础组件库（iview/element),全局基础组件，二次封装组件，领域特定组件，业务相关组件，页面级组件，而我们也可以将函数作为一个组件，因为组件是独立并且可替换，在多个维度都可以使用的。

框架与架构：

框架：比如说我们前端开发的（Vue,React,Angular)，又比如我们后端开发的（Python的Django,php的CodeIgniter)等等更多.这些框架除了提供一些基础功能之外，它还对我们的后续的代码编写有控制，你需要按照这些框架的一定的约定来编写代码。例如： Vue的Options API,要求你按它的约定来编写代码。

架构：架构是我们这些框架，模块组件，系统子系统的顶层结构，比如说利用文件夹将逻辑分层，等等...。又或是我们使用的框架，它的内部是有调度和渲染的，这就是框架的架构。

划定软件架构层次（分层架构）

设计架构的层次要素（架构金字塔）

为此，我们划定了架构的四个层级 + 基础设施层：

系统级；即应用在整个系统内的关系，如与后台服务如何通讯，与第三方系统如何集成。（传统MVC架构，前后端分离）

应用级；即单个应用的整体架构，及其与系统内单个应用的关系等。(单页应用程序，多页应用程序，微前端）

模块级；即应用内部的模块架构，如代码的模块化、数据和状态的管理等。（WebPack，ESModule, 双向数据绑定（v-model 语法糖)，单向数据流（Vuex，Redux) ）

代码级；即从代码级别的基础设施保障架构。（Eslint，Prettier，husky，lint-staged)

我对前端四层架构理解

前后端未分离阶段/前后端未完全分离阶段/前后端分离阶段（系统级）

前后端未分离阶段：

在前后端未分离阶段，页面逻辑处理以及页面渲染全部由后端完成。比如最具代表性的MVC三层框架。用户发起请求致服务端控制层（controller)，控制层通过调用模型处理器（model）以及渲染视图（view）并将最终页面返回给客户端。 在这个阶段，前端几乎没有什么话语权，也就是说，当时是以后端为主的开发情况，而且这种架构需要后端关注前端的html、css代码。并且前端无法独立的去调试，也不可能单独开发前端应用。无法并行开发，开发效率极其低，后期维护成本较高。

前后端未完全分离阶段：

在前后端未完全分离阶段，后端根据restful风格的API接口（通俗的讲，即传输json数据的http api接口）。前端通过AJAX请求调用后端Http API接口，并完成页面数据的绑定，最终由客户端浏览器完成页面的渲染。这种架构看起来是已经做到了前后端分完全分离。其实不然，后端接口仍需要关注前端的UI展示，后端需要为前端做接口定制化。而对于多终端的场景来说，后端就需要实现多套API接口，前后端数据以及业务耦合比较紧密。

这个阶段的架构使得前后端代码分离开来，并且可以独立部署上线，开发效率相比前后端未分离时有了显著的提升。

但是这种架构的缺点是，前端并没有掌握数据的控制逻辑，数据的控制逻辑仍然是在后端代码中实现的，致使后端代码需要过多的关注于前端业务逻辑定制API接口。客户端也需要根据接口的数据返回做大量的js处理。

前后端完全分离阶段：

在前后端完全分离阶段，前端引入了NodeJs作为服务桥接层（BFF中间层），NodeJs由前端工程师负责搭建完成。通过NodeJs服务器在服务器端运行JS脚本，可以让前端人员快速入门搭建自己的服务器。引入了NodeJs后可以预选在服务端的环境中完成大量前端逻辑计算，提升前端的访问性能。

这种架构使得前端可以承接部分后端的逻辑处理，在前端NodeJs部分可以做接口的聚合、适配、裁剪，以便适应多端的需求。因，后台服务现有的接口从设计到实现都是与PC端桌面UI展示需求强关联，无法适应移动端等等其他端的展示需求，需要的接口字段也都不是相同的。这时就需要在BFF层，对每个端的数据进行重新的聚合适配。

缺点就是

• 前端开发工程师需要同时维护前端应用与他对应的BFF层，开发成本增加。
• 需要维护各种BFF应用，以往前端也不需要关心并发等，现在并发压力集中在了BFF中。
• 链路复杂了，BFF引入后，要同时走前端、服务端的开发流程，流程更繁琐

前端多页面架构（应用级）

在我们前端应用级，目前我司前端后台管理系统使用了Vue多页面应用程序的方案。因为每个应用其实都是互相没有太大的关联性，所以这时候利用Vue多页面+良好的文件夹管理，即可划分出一个非常易读的项目结构。

同时，每个应用都是独立的一个Vue实例，也都有自身的接口文件，路由文件。这使得维护的难易度下降了一个量级。

并且每个应用内部挂载的插件可能是不一样的，这样可以准确的区分出每个应用的作用，按需引用应用所需要的插件。

前端组件化架构（模块级）

通过利用文件夹区分多页面多层架构，可以来明显的划分我们前端不同作用下的组件。

可以通过目录，来将我们的组件分为。

1. 全局基础组件（即为Src之外的目录内的组件，例如：node_modules，xxx-design)
2. 全局应用组件（Src目录内的component，例如：面包屑组件）
3. 应用组件（项目应用目录内的component，每个业务独立的组件）

通过目录的划分，我们可以很明显的看到所定义的组件的作用域。（即为可能使用它的地方）

前端代码规范架构（代码级）

在我们前端代码级架构中，我们在内部的wiki中制定了开发流程，代码规范。

但是可能有人不会完美的去执行我们指定的代码规范，这时候就需要一个强制性的约定，在我们的开发工具上。

对于团队而言，eslint/prettier/husky/lint-staged,这些工具都是至关重要的，对于强制约定规则，来保证代码的严谨性。

可以在如下三个阶段中，利用上诉工具来限制不严谨的代码产生。

编码阶段：需要统一IDE配置以及插件安装

其次可以在保存代码文件时自动的用prettier来格式化书写有误的代码，部分不可自动修复的代码需要你手动改进。通过使用eslint限制代码书写规范，如果你在开发过程中书写了错误的代码，那么应用它有可能不能正常构建成功。

代码提交阶段：必须安装项目依赖才可以生效

通过husky监听git操作，比如commit，push。首先commit阶段可以利用commitizen来检测commit规范如正确通过，使用lint-staged在当前暂存区中，检查暂存区内文件代码是否符合规范，如果有某个文件不符合某条规则，弹出git操作需要改正后才可正常提交。

CI持续集成阶段：需要熟悉并可使用CI相关应用

在这个阶段中，当代码被push或合并请求被提交时，可以在这个阶段运行代码的质量规范检查。因为husky是可以被跳过的，而在CI阶段中，这时候代码错误就无法被合并到测试分支/线上分支。

写在最后

第一次发文章，文章内容如有不正确不准确，欢迎在评论区指正。 如果这篇文章帮到了你，欢迎点赞和关注? 谢谢

参考文章

前后端分离技术体系 如何深度理解整体架构设计？