转载

前端架构与系统稳定性 – 之我见

#### 1. 前言

在说系统之前，我们先来说说关于系统架构的东西，什么是架构：架构可以认为是一个产品的骨架，设计图；不同的产品需要不同的架构，就好比摩天大楼的架构与一栋平房的架构，肯定是不同的；

但是也有一句话说：麻雀虽小五脏俱全；对应到产品系统架构中，也是一样的概念，不管什么样的产品，基本的架构思路其实是差不多的；

因为作者的工作是前端开发，所以接下来就以前端的角度，来说说前端的架构，大概包含哪些方面（经验有限，以后会持续更新添加）。

#### 2. 总体把控

前端的架构，我这里会分为三个部分来说，

1. 线上node服务

2. 前端代码架构

3. 发布、回滚与监测

#### 3. 线上node服务

现在大部分web开发，都已经流行前后端分离，后端专注于数据，只需要提供接口，保证接口性能即可，以往的一部分后端工作，变成了前端的工作，比如这里，对于需要服务端渲染的项目，就需要有一个node服务来完成；

那么对于一个node服务，它需要完成的工作是：当接到一个请求，会去路由列表里，找出这个路由对于的view和cgi（后端接口）地址，然后node服务会发一个page请求到后端服务器，后端服务器返回数据之后，node服务把view和data进行模板数据化，返回html代码给前端；

node服务的好处有哪些：

1. 直出数据，SEO较好

2. page请求为服务器与服务器之间的通信，网络相对稳定

3. 无JS时，也可以展示页面；

node服务应该具备的基本能力：

1. 配置后端服务器信息，信息配置，环境变量等；

2. 配置路由信息，文件更新时的路由重启机制；

3. 需要把浏览器请求的header信息，完全中转给服务器；

4. 请求cgi，并且渲染模板的能力（核心能力）；

5. 错误处理能力，不能因为简单的错误，导致导致服务挂机；

除了node服务的基本能力之外，它还要具备哪些能力：

1. 异常自动重启机制（毕竟真实的线上环境），并邮寄通知负责人；

2. 异常日志系统（重启日志，错误日志等）；

3. 提供node能力，比如项目中想要使用node的能力；

如果具备了以上的能力，那么我可以认为，这至少是一个还不错的node服务，我可以尝试去使用它；

#### 4. 前端项目架构

前端的项目架构，大致可以按照以下三个角度来说：

1. 代码目录分割

2. 开发规范

3. 工具工程化

##### 4.1 代码目录分割

绝大部分前端项目，都可以以下面的方式进行架构分割前端代码：

1. 基本依赖类库，公用CSS样式；

2. Utils工具库（该部分，最好有单元测试）；

3. 第三方依赖统一配置，项目枚举类数据统一配置；

4. 一级组件库，公用组件；

5. 业务组件 / 页面

##### 1 基本依赖，公用CSS样式

因为不常变动，所以可以单独把这部分存放在lib的文件下，如果是合并打包的话，那么就可以打包到一起，使用统一的版本号控制；

##### 2 Utils工具库

在项目中，经常使用到一些纯工具类的，它不依赖与任何第三方库，纯逻辑的处理；

Utils库，因为是属于自己开发与维护的，又是整个项目的底层依赖，所以如果一个稳定的系统，那么Utils库必须要有对应的单元测试，以保证整个项目底层的稳定性；

##### 3 第三方依赖，项目枚举数据依赖

该部分存放一些第三方的依赖，何为第三方的依赖：

1. 书封链接，头像等图片链接地址；

2. jssdk（自家APP，微信，QQ等客户端的jssdk的url地址）；

3. url跳转链接（自家分平台的跳转，客户端，M站，PC的跳转地址）；

4. 与后端约定的接口的枚举数据（比如：活动状态，平台、设备枚举，通用的错误码等枚举数据）；

它们有一个特点，就是如果你直接去使用，对于开发期间，是没有问题，但是维护成本太高，尤其是，当依赖的项目因为升级，这些依赖的使用方式出现变化时，如果你不是要统一配置，一个文件一个文件的修改，简直就是一个要死人的状态了；

而这里进行统一配置的好处就在于：当它们变化之后，我可以只改这些依赖文件，只要我保证能够向前兼容即可，我无需关心什么地方，引入或者使用了这个功能，只要我把这个文件改动了，那么所有引入的地方，都会使用最新的代码，即便向前兼容会花不少时间，也总比去每个使用的地方修改来的方便吧。

> 而且，修改的文件过多，你上线发布时，会不会有战战兢兢的感觉？

##### 4 一级组件库（公用的UI组件）

该层会依赖于前面的三层，会使用前面三层所提供的能力，所以虽然是公用的组件库，但是如果你想要把这些组件拿到其他的项目里，还是要进行大的修改，这一层却是在当前项目的通用UI组件；

它有以下的特点：

1. 不包含特定的业务；

2. 组件展示和功能配置化；

3. 可被复用和扩展；

4. 内部有自己指定的交互和逻辑，很难修改；

很多做组件库的团队，做出来的组件库，都是属于这一层次的，比如：Bootstrap，Element UI，Ant Design等，他们所完成就是这部分的功能；

##### 5 业务组件 / page 页面

这已经属于最上层的了，这部分UI展示，其实已经面向了用户，也是很难被封装的一部分，大部分前端开发的工作，都是集中在这一层次的；

单纯目录、功能上的架构，上述的分类已经足够覆盖绝大部分场景了，但这个也只是文件按功能分类的架构；

好的架构，不止于只是文本架构结束了，那么开发规范呢，开发工具呢，所以接下来，我们继续说一下，关于开发规范和开发工具的部分；

##### 4.2 开发规则

开发规范按照合作对接方的不同，可以简单区分如下：

1. 设计规范

2. 代码规范

3. 接口规范

4. jssdk调用规范

5. 产品规范（不属于架构，顺便一说）

##### 1. 设计规范

作为前端开发，你最看重的设计规范是什么，可以自己想想，顺便看看我列举的这几条：

1. 没有按照设计元素分图层（图层混乱，切图很难）

2. 尺寸混乱（边距，字体大小，间距等）

3. 设计源图特别高清（切图出来，压缩之后几百KB）

4. 字号和颜色特别多（可能有5、6中字号和5、6中颜色）

没有规范的设计稿，会让前端的重构工作变得特别艰难，而且还原度也会一度受到挑战；

但是完全按照规范来设计，对于设计师来说，也是一个很大的工作量，就拿图层来说，我个人认为，如果设计师是懂得前端开发的，TA需要知道，前端开发拿到这个设计稿要怎么分离图层，才能实现这个设计，这样的图层才是前端开发喜欢的；然而事实是，设计师很少会懂得前端，甚至懂得前端重构布局的，这也就导致了，绝大部分设计师的图层划分，是需要前端开发再次处理的；

这个最好的方式就在于：反推动设计师，建立一定的规范，一点点的建立，那作为前端来说，就慢慢轻松下来了。

对于这个，我自己的做法是：只要有机会跟设计的负责人一起合作，只要是她的设计稿，出了什么问题，我就会叫她到我这边工位，然后吐槽一下，这个设计风格，对我来说有多难（以事实说话），然后说一下，怎么样对我们来说，是更友好的；（现在间距基本都是不需要测量的，基本都是16px，32px两者，一眼就可以看出来）

如此，慢慢的反推一下设计的规范，以适合我们前端的开发；

##### 2. 代码规范

前端的代码规范，就与设计的规范一致，每个人都有每个人的风格；我个人觉得完全同意代码规范，是不人性的，而且也不应该设置太多的代码规范；

`eslint`的设置非常多，我的建议就是，使用基本的规范即可；

为了强制这些基本规范的顺利执行，可以加入`precommit`的限制即可；

##### 3. 数据接口规范

数据接口规范，对于前后端分离的开发，是至关重要的，目前一般公司的后端，都会有一定的规范，所以这个问题基本不大；

比如统一一些接口的返回数据，可以让前端做一些公用的处理逻辑；

就比如一些常用的异常code，就可以统一处理，开发只需要关心正常调用时的处理逻辑，减少异常处理的工作量；

数据接口可以与后端开发共同约定；