兔展雷宗民：小团队的基础设施建设之路

最新推荐文章于 2024-06-20 15:06:48 发布

cipinpai1032

最新推荐文章于 2024-06-20 15:06:48 发布

阅读量180

点赞数

文章标签：前端后端测试 ViewUI

本文根据雷宗民在2018年10月19日【第十届中国系统架构师大会(SACC)】现场演讲内容整理而成。

讲师简介：

雷宗民： 现任兔展前端架构师，从零构建兔展一视的技术架构，并参与兔展整站重构。专注于Node.js开发，热衷于开源，发布过多款NPM模块，如xss和@leizm/web，GitHub：leizongmin

摘要：

对于大多数初创公司的小团队而言，面临的问题包括初级技术水平的成员占比较高，基础设施不完善，但是却要求用更短的时间和更少的资源来完成任务。为了解决代码、文档统一的问题;实现自动生成Mock数据和测试代码功能使得前后端更顺畅地并行开发;为了解决团队项目部署权限混乱的问题，以及使用Sinopia作为私有NPM仓库时，由于某段时间服务不稳定导致构建失败率剧增等问题。

分享大纲：

1. 自研Web框架实现代码+文档+Mock+测试同步

2. 前端项目的构建和部署工具实践

3. 私有NPM仓库踩坑记

4. 高并发WebSocket项目实践

正文：

自研Web框架实现代码+文档+Mock+测试同步

上图是项目开发的一般流程，先对项目进行需求分析，根据需求设计数据模型、设计并编写文档，之后前后端一起开发。项目多数是比较典型前后端分离的模式，后端提供前端接口，前端作为界面调用后端接口，接口联调成功再发布上线。我们做的项目大部分是数字营销相关的，比如朋友圈转发的H5活动页面，有抽奖、集赞和各种热点内容，项目开发时间一般是比较短的，从设计稿成型到开发完成的周期短时间是三五天，长时间也就一周两周。

基于开发团队的很多成员是一年左右的工作经验，每个成员在代码规范上的习惯也不一样，这就很容易导致团队开发效率不高。另一方面，在完成需求开发后就直接进入前后端的运行开发，在接口方面的约定单纯依靠前后端的口头交流和约定，导致代码质量和运行效果都不是那么好。在理想情况下是需要做单元测试的，但由于开发时间太紧就省略了测试环节，在验收时发现问题就进行调节，没有发现问题这个项目就算完成了。项目上线周期也是比较短的，也不会有长期的运营时间去发现存在的问题。

但随着公司业务的发展，做的项目越来越复杂，运行的时间越长，项目难度也随之增加了，在这个过程中团队发现之前的方式已经不可行了。所以开始思考在不减轻开发的工作量的情况下，把编写文档和设计完成，验收阶段加上测试部分，会不会比现在的情况好? 考虑到这个因素，后端团队设计模型和注册接口的时候，尝试用代码描述这个接口来生成接口文档，后端开发采用Nodejs，写完部分代码就可以生成参数检查，将单元测试和接口文档交给前端开发，后端就可以进入真正业务代码的编写过程。

上图是代码描述接口的具体细节：要设计一个接口，首先定义构思方法，通过什么路径、命名这个接口、有什么参数、返回的是什么类型的东西，从而形成一个具体业务逻辑。

在业务代码没完成的情况下，先通过代码定义好接口，并生成接口文档，文档里面就能够显示我们通过什么样的参数去调用这个接口，这个接口会返回什么样的信息，这时候前端就可以按照这份接口文档进行开发。

为项目编写单元测试也变得十分方便，只需要自动把接口按一定的规则映射成一个函数，单元测试时只需要并调用对应接口的函数，构造相应的参数然后检查返回结果就可以了。

前端需要手动调试的情况很常见，这时候可以根据接口生成一个用于Swagger调试的配置文件进行调试，另外前端使用typescript编写代码，还可以根据接口描述生成对应的typings定义文件，所以在编写代码的时候，除了编写比较方便、写得比较少之外，还可以利用编辑器的代码提示。

2. 前端项目的构建和部署工具实践

下面是具体实施过程，首先是定一个标杆项目，根据项目的特点做模版，通过Yeoman工具生成代码，另外项目包括前面定义的框架，我们不是通过NPM模块的方式去引用的，而直接就把它放在项目代码里面。在第一个版本的时候加了一些功能，随后的测试中发现问题再逐渐的修改，慢慢开发成下一个版本，因为项目数量比较多，这个项目改变了点，把代码直接放到项目，下一个项目直接把它拿出来再改改，再放到里面也不影响。比如说版本升级，前面项目已经做好了，尽管它是有点不完善的，但是大多数时候不需要后期去维护的。另外为了跟业务代码做一个隔离，这个项目自动生成的代码，需要单独的放到一个目录里。

通过前面的框架，解决了开发效率和规范质量的问题。通过改革后的前端的发布流程如上图所示，首先通过Webpack做构建，之后将静态资源上传到CDN上，通过FTP将静态文件上传。

数字营销相关的项目大多数规模都是比较小的，都是一个前端一个后端的组合，可能同时有好几个项目在运行，每个项目的前端做完了就把文件打包发布上去，另外一个项目做完了也打包发上去，这个时候会涉及到权限管理的问题，所有人都要在服务器上面做一个发布，如果中间有人操作错了怎么办?所有人都拿同一个账号的操作，也没有记录查询，这个时候开始考虑优化前端发布的流程。

上图是改革后的流程：首先完成Webpack构建，通过zip把前端的代码打包起来，提交到发布管理平台，由管理平台上传到对应的服务器上，通过平台就可以通过账号查询对应的项目关系，因为不是直接去操作服务器的，可以避免文件被更改的后果。

上图左边是之前的分布式管理，分布式就是所有人都可以操作，经过改造后变成集中式管理，直接把文件提交前端发布系统，再由前端发布系统上传到对应的地方。实际上在前端发布系统还做了些扩展，在新建一个项目时可以在界面上手动操作，在里面配置项目用的域名是什么、放在哪个路径下、CDN对应的是哪里，后面把构建跟上传结合在一起，相当于做了一个小的云平台。

3. 私有NPM仓库踩坑记

一般项目都会有搭建NPM库的需求，团队最开始用的是简单的Sinopia，公司还有另外一个前端团队，他们在前端的构建不是按照改革后方式来去做一个发布的，是直接把前端跟后端的构建打包在一个文件里，之前已经做好了整个构建的脚本，突然发现构建失败了，查询失败原因是安装NPM包出错，当构建流程定下来之后，怎么单独的跳过NPM的安装把它构建出来呢? Sinopia是我搭建出来的，自然就把这个问题转到我这里来了，但是当时我用的是第三方工具搭建的私有NPM，它出问题了，我这边也顶多只能重启。

基于这件事我对NPM的实现原理做了一个研究， NPM在安装的时候，为什么会出错?主要是因为网络的问题， Sinopia实现方式是直接做反向代理，在安装模块的时候，有一部分是私有模块，但是大部分是NPM上原有的模块，如果是NPM上原有的模块可以通过302重定向来减少网络出错导致的故障。另外新版本的NPM命令上面可以配置自己私有的scope的源地址，除了这个特定scope之外的模块不会请求到私有NPM源，也就减少了这个问题。

实现一个私有NPM库主要是三部分，第一部分是登录授权，登录授权有固定接口，提交密码返回一个token，拿token上去就可以了。另外是发布模块，将把整个模块打包，再加一个接口就搞定了。另外是查询模块，它有固定的URL地址格式，通过请求下载这个文件， NPM的安装就完成了，所以不一定要自己开发私有NPM，只需要一个静态的文件服务，按照格式把包传上去就可以了。

4. 高并发WebSocket项目实践

下面的是项目的经历，今年上半年有个直播答题活动，产品经理要求它要有5万并发，就是同时在线有5万人的直播答题。团队之前从来没有做过这样的项目，要在短短的半个月内完成，首先第一是服务器怎么去支持大量的并发，在做并发的时候， Nodejs性能怎么样?Nodejs是单进程的，如果通过多进程去部署的话，如何实现共享?WebSocket怎么测试?怎么知道项目它就能够支持5万的并发呢?

团队研究发现要使得系统支持大量并发，只要调一下Linux系统的参数就可以支持大的连接数，另外是进程状态的共享，最简单是通过Redis的发布订阅模式去共享多进程的状态，另外一个是数据序列化，测试第一版的时候，就能够达到5万的并发的连接了，但当项目完成真正去跑的时候，实际上在1万的时候就挂掉了。排查原因发现是测试方法有问题。服务端支持这么大的并发连接是没问题的，但是只是保持这么多个连接，它并不包含活动中的发消息的操作，直播答题中每5秒钟这5万人不断地要去给服务端发信息，服务端还得返回结果，在操作的时候卡了一两秒再给他返回信息就达不到直播的效果了。

首先对发消息的数据序列化做了一个改进，最开始是通过JSON去做一个序列化，直接返回一个对象，把各种信息统统都塞进去，这个对象里面的key都很长的，之后需要优化这个发送数据的长度，让前端后端的通讯数据格式上就尽可能的精简了。

在完成优化后，如何测试呢?现有工具对WebSocket的测试基本上只是发连接，然后测试这个并发连接的性能。所以手动通过uws模块手写测试代码，不仅仅对链接做测试，也加入了整个业务的流程，测试的客户端它会连接上去，会自动去答题，答完了下一题还会继续的答。