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

#### 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,就可以统一处理,开发只需要关心正常调用时的处理逻辑,减少异常处理的工作量;

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

##### 4 jssdk调用规范
对于项目来说,jssdk的调用,应该算是第三方依赖了,这里可以不做专门的说明;

##### 5. 产品规范
这里的产品规范,也可以认为是需求文档的规范。

大部分开发,与产品的关系,都不会相处的很好,因为产品经理会经常改动需求,你没有发现么?

为了自己,尽量的要求产品出需求文档,越详细越好,出了文档之后,所有的改动都要更新同步;

> 产品规范不属于架构,但是属于规范,所有这里顺便一说,可以略过;

##### 4.3 工具工程化
关于工程化这一点,我的态度是:简洁、简洁、简洁;

如果一个项目的架构里,有几十个工程化命令,那我认为这不是一个好的架构,不说其他的开发者,作为这些工具的创造者,你真的能记住每一个工程命令的功能吗?如果有新人接入,又能理解你这么多命令的功能吗?

没有人理解,就没有人使用,那么大部分就是浪费的,而且,他们加大了整个系统的复杂度;

所以如果是我来做这个,那么我会把命令尽量控制在5个以内;理论上最常用的也只两三个(init , dev, build);

#### 5. 发布、回滚、监测

这里就到了上线了,发布和回滚,在我看来是非常重要的,他们必须包含的两个功能就是:无损发布和无损回滚;

相信做过开发的人,都无需我来解释为什么;

上线之后就结束了么,不,生产环境永远比你想象的复杂;监测线上代码的异常,也是非常重要的一个环节;

监测异常平台,性能监测平台,现在有不少已经开源,或者商业化,可以选择一些合适的进行接入;

目前我能接触到的几种监测工具包含:Sentry异常日志,elk日志分析,rrweb回放;

##### 6. 系统架构稳定性

前面说了很多,都是关于架构的,这里准备使用一小节来说明一下,系统的稳定性,系统的稳定性就来源于架构的稳定性,一个稳定的架构,那么其系统稳定性也必定是很不错的;

综合前面的文章,你觉得,哪些关键点,可以影响整个系统的文档性呢?

可以留言参与讨论。

外加一张简单的脑图:

##### 7. 总结
这是我的第一篇架构类文章,有些概念并不一定写的正确,也可能有些重要的点,是我没有注意到的,如果您有更多这方便的意见,请指正;

架构来源于业务,配合业务特性的架构,才是一个最优秀的架构,可以总结为一句话:抛开业务谈架构,就是耍流氓;

感谢阅读,本文地址:http://www.zhangyunling.com/?p=909

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>