创业公司的容器化之路

正文

请到「今天看啥」查看全文

这时 Scala 最大的问题开始体现出来了，那就是编译速度的问题。那时候我们的应用部署方式也很原始，必须登陆服务器运行一个 Shell 脚本，它会拉取代码，然后编译、打包、运行，整个过程需要耗费5～10分钟。而我们 API 应用的节点后来增加到 5、6 台，即使两台同时发布，也需要 20 分钟才能全部发布完成。如果发布后出了问题，那就吐血了，因为回滚也是一样的流程，又需要 20 分钟。

有一次我们做了一个送 Apple Watch 的活动，半夜 12 点开始。我们出了个很低级的 BUG，活动一开始就蹭蹭蹭的一分钟送好几个 Apple Watch。我们创业公司也没多少钱，每一个都是白花花的银子，心痛啊。修复很简单，但发布或者回滚都得先编译，太慢了，于是我们一狠心把服务器给停了，几分钟后才部署上了新的代码。

这是我们觉得必须要有一个自动化的发布系统了。其实在几年以前，发布都是需要运维执行的，研发提交给运维，运维手动部署。那自然发布不可能很频繁，并且对开发和运维都是很大的负担。但渐渐的敏捷和 Devops 的文化成为主流，持续集成和发布（CI/CD）成为一项基础设施。

我们第一版 CI/CD 很简单，是基于 Jenkins 的，通过脚本进行编译、打包，然后拷贝到服务器上发布。因为只要打包一次即可，缓解了部署慢的问题。但还是存在几个问题。

• 首先，没有应用仓库。打包是一次性的，部署的时候会备份当前应用目录，用于回滚，所以只能回滚到上一个版本。

• 其次，健康检比较简单，只能检测应用是否启动。我们遇到过应用启动了，测活也没问题，但服务还是有严重问题、基本不可用的情况。

• 最后，不支持灰度发布，出问题只能回滚。

期间我们有一次较大的故障，也是因为这几个因素，花了很长时间才恢复。痛定思痛，于是我们又开发了 Frigate 发布系统，它的架构大致如下图。

• Frigate 有一个应用仓库，即 App Repository。应用仓库会保存发布的应用版本，回滚的时候可以指定版本。

  
  

• Watcher 组建实现了比较强大的应用检测功能。除了一般的 HTTP 检测，还可以从日志、监控里获取数据，可以根据异常数、错误率等进行进一步的健康检测。

  
  

• Frigate 支持分组和分阶段发布。例如现发布2台机器，然后健康检查，或者中间可以有一些人工检查，然后再发布剩余的机器。

后来回头看，Frigate 虽然没有使用容器，但其实是实现了容器编排的很多功能。Frigate 发布的截图如下，这是基于 Jenkins Pipeline 的。

4. 微服务化

系统多了，依赖复杂、数据没有隔离、逻辑重复，接下来一个必然的方向就是微服务。关于微服务，我们公众号有两篇文章（乐高式微服务化改造（上）、乐高式微服务化改造（下））对此有比较详细的分析说明，这里就简单介绍一下。

我们的服务注册和发现是基于 Consul 的，负载平衡是通过 Nginx 实现的。下图是整个服务注册和发现的过程：

请到「今天看啥」查看全文