淘宝前端团队谈前端工程化的云构建

最开始的时候 client 与 worker 都是通过 HTTP 进行通信，这样实现起来的确是很简单，系统也能正常运行。而且对于绝大多数构建任务来说是没有问题的。但是遇到一些比较大的项目，构建时间比较长的项目，问题就暴露出来了。由于构建时间比较长 HTTP 连接经常可能会被重置，既有可能因为 nginx 代理的问题导致，也有可能因为网络问题导致。

随着云构建系统越来越复杂，服务器的返回值，需要经过多层嵌套才能够返回给客户端，这对于系统的调试和错误处理带来了很多的不变，而且大大降低了代码的可读性。错误处理变得很复杂，可能会存在没有发现的 bug。

为了彻底解决这个问题，我们使用了 socket 来代替 HTTP，使用了 socket 的特性，构建时间即使再久也不会发生构建过程中通信中断的问题。而且只要构建发生错误，通过 socket 的事件机制立马就能够通知客户端。

2，文件上传

在最初的系统中，项目文件的上传是通过 client 直接把项目文件压缩打包上传到 worker，项目文件很大打包压缩上传的时间需要很久，而且文件过大，nginx 会返回 413 错误。当并发任务数量过多的时候，worker 负载过大，经常会因为上传下载占用过多的资源影响构建服务的正常进行。

通过把文件上传服务独立出来，建立单独文件中转服务，worker 只需要关注构建相关的问题，不再接收处理上传的文件，client 传递给 worker 的只是一个 URL 地址。构建完成后，worker 把构建好的代码打包压缩上传到文件中转服务，然后返回相应的地址给 client，client 通过地址拿到构建好的内容。所有文件处理都通过第三方去处理，文件部分的处理和构建过程完全独立。减少了系统的耦合程度。

3，负载均衡

随着云构建系统被使用的越来越多，构建任务经常需要等待，为了避免构建等待，加快构建速度，我们增加了构建服务器的数量。

多台构建服务器就需要有相应的任务分发机制，对任务进行分发保证构建任务不需要等待。因此增加了云构建路由服务（router）。云构建路由对任务进行分发，构建服务器有多台，在分发的时候要根据构建服务器上面正在运行任务的数量进行分发，确保任务能够以最快的速度运行。

同时还需要设定心跳机制，定时去检测构建服务器的情况，如果构建服务器出现异常能够及时报警，同时自动下线相应的构建服务器。最大程度的保证构建能够正常的运行，不会因为一台构建服务器出现故障而影响整个构建系统的正常运行。

展望

1，为了提高测试平台的稳定性和安全性，我们设想为每个构建器提供单独的沙盒运行环境，使用 docker 技术把构建器的运行环境和构建系统本身隔离开来，保证构建器运行过程的问题不会影响构建系统本身，使两者独立起来。这样做对于系统的安全性也会有很大的提高，限制了构建器本身的运行环境，即使构建器中存在一些危害构建系统的行为也不会影响到构建系统，这样极大的提高了安全性和稳定性。

2，目前云构建还只是拥有对代码进行构建的能力，完全可以把云构建平台进行通用化，成为一个通用 Node.js 任务运行平台，目前我们正在做这方面的尝试。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!