写点什么

我们为什么从 Lambda 迁移到了 ECS?

  • 2021-05-23
  • 本文字数:3209 字

    阅读完需:约 11 分钟

我们为什么从 Lambda 迁移到了 ECS?

在本文中,我将深入探讨 Lambda 的成功之处,我们面临的挑战,以及为什么我们最终会决定将一些服务从 Lambda 迁移到 AWS 弹性容器服务(Elastic Container Service,ECS)。


我们要解决的问题是什么?


简单介绍一下背景,我们的产品是 B2B 软件公司的一个集成平台,我们帮助软件公司构建集成,并将这些集成部署给他们的客户。一次简单的集成可能如下所示:


  • 步骤一:在 Dropbox 中下拉 XML 文档。

  • 步骤二:使用一些自定义的 JavaScript 代码处理 XML。

  • 步骤三:使用一些存储的凭证,向第三方 API 发布经过处理的数据。


用户可以按计划配置集成以运行,也可以通过 webhook 触发集成,而平台则负责运行、记录和监控集成(以及一大堆其他内容)。

早期情况


Prismatic 的第一个实现使用 LocalStack。我们希望最终把 Prismatic 托管在 AWS 上(根据需要可能会迁移到 Azure、GCP 等),所以需要在本地启动我们的平台来模拟 AWS。类似 AWS Lambda 的 LocalStack 服务易于迭代,并且在运行中不会出现大问题。这为我们提供了一个非常好的开发反馈回路,我们很快进行了原型设计和测试。


在使用 Lambda 执行集成的每一个步骤时,步骤利用 SQS 传递数据并触发下一个步骤。所以,集成的执行情况如下所示:


  • 执行 Dropbox 的“获取文件”动作以抓取 XML 文件。

  • 在 SQS 中保存 XML 文件的内容,触发下一步骤。

  • 运行客户自定义 JavaScript 代码以处理 XML。

  • 在 SQS 中保存生成的转换数据,并触发下一步骤。

  • 执行一个动作,将处理后的数据发布到第三方 API。

  • 保存上一步骤的结果,触发集成结束。


这对于 LocalStack 来说是一个非常快速的过程。我们可以定义一个 6 步集成,运行它,然后在几秒内就能看到结果。

向实际的 AWS Lambda 迁移


当我们的概念被证明可行之后,我们就将 Prismatic 转到实际生产环境中,使用实际的 Lambda、队列、数据库等等。我们还只是一个小团队,不想花太多的时间来解决 DevOps-y 的基础设施问题。我们希望花更多的时间在核心商品上,而 Lambda 能让我们做到这一点。


此外,Lambda 在很多方面都比较有优势。比如,我们无需担心 CPU 或内存分配、服务器监控或自动扩展,因为这些都是内置的。还可以将包含 JavaScript 代码的 .zip 文件放到 Lambda 上,AWS 负责剩下的工作。Lambda 让我们将代码分成一系列服务(一个用于日志记录、一个用于 OAuth 密钥更新、一个用于集成出错时短信 / 邮件提醒等),这样我们就能很好地理解由哪些代码负责哪些任务。成本也很合理:你只需支付计算时间的费用。我们无需全天候运行服务器,只需在我们的原型执行某些任务时付费。


Terraform 上运行几天之后,我们在 AWS 上有了 Prismatic 的第二个实现。集成运行器运行在实际的 Lambda 上,并且被 SQS 触发。此时,我们就要面对集成运行器的性能问题了。

为何 Lambda 无法工作


在 Lambda 中,我们遇到了速度、SQS 大小的限制以及缺少进程隔离等问题。这让我们重新考虑它作为集成运行器的有效性。下面我们依次对这些问题进行讨论:


速度。我在前文提到过,在 LocalStack 内运行 6 步集成只需几秒。但是在实际的 Lambda 和 AWS 中,这花了整整一分钟。实际上,Lambda 调用非常快,通常为几毫秒。但是,在向 SQS 写入步骤结果的过程中,以及在接下来执行下一步骤的过程中,每一步骤都需要几秒钟。对于更为复杂的集成来说,比如那些循环了 500 多个文件的集成,这就成为一个障碍:谁想要花上几分钟(几小时)来完成他们的集成?


为了加快 Lambda 调用的速度,我们尝试了许多方法。根据指导原则,我们为一些 Lambda 实例保留了“热度”,并将驱动 Lambda 的虚拟 CPU 数量增加到了当时能够达到的最高水平(6 个虚拟 CPU/10 GB 内存),但这只会降低我们集成运行时间的个位数百分比。


SQS 的大小限制。SQS 限制消息大小为 256 KB。在集成的各步骤之间传递的数据量通常会超过这个大小(毕竟,集成开发人员现在一个数兆的 JSON 文件进行处理是完全合理的)。要想绕过这个大小限制,推荐的解决方案是向 S3 写入有效载荷,然后通过 SQS 传递对 S3 对象的引用——但是这个对 S3 的 API 调用只会使速度更慢。


结果表明,如果客户在其集成中编写了像 global.XMLHttpRequest = null; 这样不好的代码,依赖 XMLHttpRequest 库的集成随后将在同一个 Lambda 上运行,这将导致错误。这个问题很大,因为一个客户可能会破坏其他客户的 axios。有些客户甚至可能会恶意执行 global.console.log = (msg) => { nefariousCode(); } 之类的操作,同时,当调用 console.log() 时,同一 Lambda 上执行的其他集成将运行 nefariousCode()。


为了解决共享执行空间的问题,我们做了一些尝试。我们曾强迫 Lambda 每次都冷启动(这是一个坏主意,原因显而易见),也曾试过在 chroot jail 中启动不同的 Node 进程。这两种方法都不起作用:在 Lambda 中启动子 Node 进程需要 3~5 秒的时间,并且在一定程度上与 Lambda 的初衷背道而驰。

向 ECS 迁移


在开发方面,Lambda 为我们提供了很好的服务:我们可以快速迭代,并获得一个原型,但是由于 Lambda 面临的各种问题,我们决定咬紧牙关,花一些开发时间在云基础设施上。


为了扩展已有的 Terraform 脚本,并将集成运行器迁移到 AWS 弹性容器服务(ECS),我们的团队已经开始了工作。使用 ECS 容器,我们可以轻松地、快速地使用 chroot,并将 Node 进程彼此隔离,从而解决了 Lambda 中出现的进程隔离问题。为解决 SQS 的大小限制问题,我们改用了 Redis 支持的队列服务。虽然我们重新发明一些 Lambda 免费提供的“轮子”,比如日志、自动扩展和健康检查,但是最终,我们的 6 步测试集成将在 2 秒内恢复运行。


但是,ECS 也并不完美,有些东西需要进行取舍。比如,ECS 的自动扩展似乎没有 Lambda 快。“扩展”似乎要花费一分钟时间,从 API 调用到 AWS Fargate 获取并初始化一个准备好接受工作的容器。我们不得不让一名开发者从产品开发中抽调出来,参与云基础设施的工作,同时在 CPU 和内存使用、自动扩展规则和监控方面也有许多问题需要解决,但在产品开发的这一阶段,这种痛苦是值得的,因为它能让我们为客户提供一个快速的集成运行器。

Lambda 还有什么?


在 Lambda 中,我们并没有移出所有的微服务:许多微服务仍然保留在无服务器的生态系统中,并且在可预见的将来也是如此。集成运行器并不适用于 Lambda,但是对于其他任务,它似乎是一个明确的选择。在 Lambda 中,我们保留了所有重要的集成服务,而这些服务对 Lambda 的实际执行并不重要。其中包括:


  • 从 ECS 中提取日志并将其发送到 DataDog 的记录器服务。

  • 向 PostgreSQL 数据库写入关于集成执行的元数据的服务。

  • 跟踪和排队调度的集成服务。

  • 如果用户的集成出错,就会向用户发送短信或电子邮件通知的警报服务。

  • 针对第三方服务的 OAuth 2.0 密钥更新授权服务。


我们不希望让这些服务妨碍集成的运行,如果它们需要更多的一两秒钟来运行也没有问题,因为对于 Lambda 来说,这样做是很合适的。

总结


当然,随着时间的流逝,我们的基础设施肯定会发生变化,但是我认为我们一直在做正确的决定。通过 LocalStack 的“Lambda”服务,我们可以进行快速地开发和迭代,我们的 AWS 首次部署非常简单,我们的小型开发团队可以更改我们的基础设施,而无需花费大量的开发时间。


Lambda 看起来是一个很有吸引力的解决方案,可以用于托管和扩展我们的微服务,而且对于许多这样的服务,尤其是那些可能需要一到两秒才能运行的一步服务,仍然是正确的选择。但是,对于我们的集成运行器,我们了解到 Lambda 的规模、速度和进程隔离限制使得 ECS 成为更好的选择,并且值得为这个特定服务创建 ECS 部署所需的开发时间。


Lambda 让我们在早期关注产品开发,当时机成熟时,向 ECS 迁移将会非常顺利。尽管我们在 Lambda 遇到了很多困难,但我很高兴我们走上了正规。


作者介绍:


Taylor Reece,Prismatic 开发技术推广工程师,具有 DevOps/ 云的背景。


原文链接:


https://dzone.com/articles/why-we-moved-from-lambda-to-ecs

2021-05-23 18:463174

评论

发布
暂无评论
发现更多内容

商品计划管理系统助力企业实现高效决策与资源配置

第七在线

观测云:开放透明与知识共享的引领者

可观测技术

文档 开放生态

Waves 混音插件 完美破解版 for mac/win 安装包

Rose

Waves 混音插件 Waves破解版

简析网络安全中的伦理困境与道德守则

我再BUG界嘎嘎乱杀

黑客 网络安全 信息安全 WEB安全 网安

Luminar Neo:不只是修图,更是创意的孵化器

Rose

动态之美:Motion 5特效,让视频栩栩如生 mac版

Rose

mac视频后期特效处理 Motion 5破解版 Motion中文版

苹果电脑防火墙Radio Silence for mac v3.2激活版 附安装教程

Rose

苹果电脑 mac防火墙 Radio Silence下载 Radio Silence破解版

京东小程序数据中心架构设计与最佳实践

京东科技开发者

AI入门之深度学习:基本概念篇

京东科技开发者

无缝集成,全域监控:观测云引领企业运维新纪元

可观测技术

运维

Pushgateway:观测云中的实时数据监控解决方案

可观测技术

云原生

macOS Big Sur(macos11 正式版)v11.2.3 高速下载版

Rose

7月新特性 | 软件开发生产线CodeArts发布多项新特性等你体验!

华为云开发者联盟

测试计划 代码检查 企业号 8 月 PK 榜 CodeArts 2024企业号8月pk

实际上手体验maven面对冲突Jar包的加载规则

京东科技开发者

并发性能提升 4 倍!云帐房用 Serverless 轻松应对瞬时业务洪峰

阿里巴巴云原生

阿里云 Serverless 云原生

AI在商品计划领域的应用

第七在线

拼多多API接口:通过商品ID获取拼多多商品详情数据接口

tbapi

拼多多商品详情接口 拼多多API 拼多多商品数据采集

智能监控:超越传统阈值的监控

可观测技术

智能监控

AE 2019中文版 after effects破解资源 mac/win

Rose

AE 2019中文版 AE 2019 mac破解版 AE2019安装包 After Effects安装教程

如何构建高效的 CRUD 应用程序?

NocoBase

软件开发 crud crudapi

怎么用云手机进行TikTok矩阵运营

Ogcloud

云手机 海外云手机 tiktok云手机 云手机海外版 tiktok矩阵

pdf reader pro mac破解版 v3.2.1.0中文激活版 好用的pdf编辑阅读器

Rose

OmniGraffle Pro mac破解版(流程图、组织结构图、网络拓扑图、电路图等)

Rose

思维导图 流程图 OmniGraffle Pro破解 OmniGraffle Pro下载

课件ppt怎么做?3个在线网站轻松制作教学ppt!

职场工具箱

效率 职场 PPT 办公软件 AI生成PPT

跨越边界:京东商品详情API的全球拓展之旅

代码忍者

实时洞察,精准掌控:观测云在企业监控中的核心优势

可观测技术

监控

苹果电脑装机必备防休眠工具:InsomniaX for Mac中文版

Rose

MacBook防睡眠软件 InsomniaX for Mac

如何在 K8s 中实现 Pod 原地更新?

小猿姐

数据库 云计算 Kubernetes 云原生

我们为什么从 Lambda 迁移到了 ECS?_文化 & 方法_Taylor Reece_InfoQ精选文章