极客视点
极客时间编辑部
极客时间编辑部
113241 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:15
登录|注册

如何将代码部署时间减少95%?

讲述:初明明大小:4.80M时长:05:15
Plaid 是一家金融科技公司,该公司搭建了一个技术平台,使应用程序能够与用户的银行账户建立联系。随着公司的发展,基础设施规模在不断扩大。目前,这家公司运行着 20 多个内部服务,每天在核心服务上部署 50 多个代码提交。因此,最小化部署时间对于最大化迭代速度至关重要,一个快速的部署过程能够迅速进行 Bug 修复并运行平稳的连续部署系统
为此,Plaid 实践了自定义“快速部署”机制,该公司的工程师埃文·利曼托(Evan Limanto)发文介绍了具体过程,如下。
我们的银行集成服务由 4000 个 Node.js 进程组成,这些进程运行在专用的 Docker 容器上,这些容器托管并部署在 Amazon 的容器编排服务 ECS 上。在分析了我们的部署过程之后,我们将增加的部署延迟归结到三个不同的组件上。
第一,启动任务会导致延迟。除了应用程序启动时间之外,ECS 健康检查也会导致延迟,它决定容器何时准备好开始处理流量。控制这个过程的三个参数是 interval、retry 和 startPeriod。如果没有对健康检查进行仔细调优,容器可能会卡在“启动”状态,即使它们已经准备好为流量服务。第二,关闭任务会导致延迟。第三,启动任务的速度限制了部署的并行性。
为了逐步实现总体目标,我们考虑并试验了一些不同的潜在解决方案。
其一,减少生产中运行的容器总数。这当然是可行的,但它涉及到对服务架构进行重大修改,使其能够处理相同的请求吞吐量,因此在进行这样的修改之前,我们还需要进行更多研究,这在短期来看并不现实。
其二,通过修改健康检查参数来调整 ECS 配置。我们尝试通过减少 interval 和 startPeriod 的值来加强健康检查,但是 ECS 在启动时将健康的容器错误地标记为不健康,导致我们的服务永远无法完全稳定在 100% 健康状态。由于 ECS 部署缓慢这个根本问题依然存在,对这些参数进行迭代是一个缓慢而费力的过程。
其三,在 ECS 集群中启动更多实例,以便可以在部署期间同时启动更多任务。这样做可以减少部署时间,但不会减少太多。从长远来看,这也不划算。
其四,通过重构初始化和关机逻辑优化服务重启时间。只需要做一些小小的修改,我们就能够在每个容器中节省大约 5 秒的时间。
尽管这些更改将总体部署时间减少了几分钟,但是我们仍然需要将时间提高至少一个数量级,才能认为问题已解决。这将需要一个从根本上就不同的解决方案。
初步解决方案是利用 Node Require Cache“热重载”应用程序代码,虽然能够消除 ECS 部署中存在的大部分延迟,优化整个部署过程,但是出于一些其他原因,可能会导致应用程序意外失败。由于我们不愿意在银行集成服务的可靠性上妥协,所以这种方案并不适合。
因此,最终解决方案就是重新加载进程。
在过去,为了在所有服务中运行一系列统一的初始化任务,我们编写了自己的进程封装器,它的名称叫做 Bootloader。其核心包含设置日志管道、转发信号和读取 ECS 元数据的逻辑。每个服务都是通过将应用程序可执行文件的路径以及一系列标志传递给 Bootloader 来启动的,这些文件在执行初始化步骤之后会作为子进程执行。
我们在 Bootloader 中实现了自定义逻辑,以触发使用此代码退出的任何子进程的进程重载。这使我们能够绕过 ECS 部署的成本并快速引导新代码,同时避免“热重载”的陷阱。此外,Bootloader 层的这种“快速部署”逻辑允许我们将其推广到在 Plaid 运行的任何其他服务。
下面是最终解决方案的步骤:
Jenkins 部署管道向银行集成服务的所有实例发送 RPC 请求,指示它们“快速部署”特定的提交散列。
应用程序接收 gRPC 请求进行快速部署,并根据接收到的提交散列从 Amazon S3 下载构建好的压缩包。然后,它替换文件系统上的现有构建,并使用 Bootloader 识别的特殊退出代码退出。
Bootloader 看到应用程序使用这个特殊的“Reload”退出代码退出,然后重新启动应用程序。
服务运行新的代码。
总之,我们能够在 3 周内交付这个“快速部署”项目,并将 90% 生产容器的部署时间从 30 多分钟降低到了 1.5 分钟,部署时间减少了 95%。这个项目极大提高了 Plaid 集成工作的速度,允许我们更快地发布特性及进行 Bug 修复,并将浪费在上下文切换和监视仪表板上的工程时间最小化。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
49
沉浸
阅读
分享
手机端
快捷键
回顶部