聊聊软件架构与前端架构-一一网

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

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

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

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

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

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

我理解的软件架构

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

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

对于我个人的理解来说：

系统与子系统：

比如说前端，后端，它们是有关联的个体，各自根据自己的框架规则范式，共同完成独特的功能。

系统：一个整体的完整的事物，比方说，前端目前情况能脱离后端独立运行吗？后端不使用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后可以预选在服务端的环境中完成大量前端逻辑计算，提升前端的访问性能。

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