ITPub博客

首页 > 架构设计 > 基础设施 > 兔展雷宗民:小团队的基础设施建设之路

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

原创 基础设施 作者:胡孟依 时间:2018-12-10 15:15:59 0 删除 编辑

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

讲师简介:

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

摘要:

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

分享大纲:

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

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

3. 私有NPM仓库踩坑记

4. 高并发WebSocket项目实践

正文:

  1. 自研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模块手写测试代码,不仅仅对链接做测试,也加入了整个业务的流程,测试的客户端它会连接上去,会自动去答题,答完了下一题还会继续的答。

在经历了一年的开发和部署的改进,从最开始的很原始方式到现在,团队开发效率提高了,代码也更加规范了,生产质量也有所提升。今天的分享就到这里,谢谢大家!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31545806/viewspace-2284724/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-09-19

  • 博文量
    16
  • 访问量
    21243