我们如何使用Cloudflare和Stripe在2小时内处理500万欧元的捐赠
深入探讨Late Late Toy Show捐赠平台背后的无服务器架构，以及我们在短短几周内将其整合在一起时所面临的挑战。
有关RTÉ的Late Late Toy Show的无服务器平台的简介，请参阅本文。
在本文中，我们将为您提供当晚的实况转播，并深入探究支撑一切的技术。并非所有事情都按计划进行（是吗？），但是RTÉToy Show Appeal取得了巨大的成功。
我们机构有史以来第一个商业项目“我们无服务器”的简介如下：
为爱尔兰最受欢迎的电视节目RTE的Late Late Toy Show建立捐赠平台，并准备在四个星期内进行。
由于这是第一次在玩具展上提出捐赠要求，所以我们不知道会筹集多少资金，也不知道会有多少观众转化为捐赠者。我们只知道以下内容：
估计爱尔兰有150万观众，还有来自全球130多个国家的爱尔兰侨民
我们应该毫不费力地扩展，从几乎零活动到每秒数千个请求
使其精简；应用程序本身具有的代码和复杂性越多，构建所需的时间就越长，而大规模操作的难度就越大。
对于我们的第一个挑战，我们必须决定平台的基础架构，我们决定使用CloudFlare Workers。
就无服务器平台而言，CloudFlare Workers可能不如AWS Lambda知名。但是，它们将允许我们的代码在CloudFlare的全球边缘网络上运行，而不是在区域实例上运行。与其他任何云计算服务不同，CloudFlare不使用容器或虚拟机，而是使用V8隔离技术，该技术是Google Chrome小组创建的在浏览器中运行JavaScript的技术。实际上，对于我们来说，这意味着代码将更接近最终用户发出的请求，并且调用不会引起任何冷启动，这种启动可能会持续100毫秒。
我们使用无服务器大炮，Grafana和InfluxDB进行的负载测试的结果令人鼓舞。我们模拟了用几分钟的时间最多进行300次捐赠活动来猛击该站点的情况，发现10个请求中有9个请求的延迟时间不超过416毫秒，平均只有77毫秒。
尽管出于明显的原因，我们无法在事件本身期间衡量延迟，但CloudFlare衡量的晚上结果更为令人印象深刻：99％的请求使用的时间少于6.6 ms，而整个晚上和第二天。仅在第99.9个百分位，我们看到了一个小小的颠簸，与捐款高峰在晚上11.34左右重合。借助AWS Lambda，我们习惯于在预热阶段看到功能运行100毫秒（毫秒），几秒钟，因此使功能持续运行不到10毫秒而又不会不可避免地受到损失是显而易见的！
第二个挑战是使用可以每秒处理数百笔交易而又不费吹灰之力的支付平台：为此，我们很快就选择了Stripe。考虑到RTÉ之前的慈善呼吁节目“RTÉDids Comic Relief”的表演，我们对Stripe的现有限制感到满意，并且RTÉ的慈善合作伙伴爱尔兰社区基金会已将Stripe告知该活动。那时我们几乎不知道“玩具晚会秀”会打破所有记录，而我们很快就突破了这个极限。
由于我们希望使堆栈尽可能地精简，因此我们严重依赖Stripe元数据和相关的Stripe Sigma（基本上是Presto）来存储和查询卡交易不需要的少量额外数据，例如用户选择大笔捐款的退税。这使我们能够提供总计的实时报告，并对Stripe持有的数据执行SQL查询，从而消除了许多必须考虑数据存储和相关可伸缩性的压力。
节目在晚上9.35开始。 Twitter上颇有一些期待，并且第一条官方推文发布了要求捐款的消息。我们的捐款额约为1万欧元，以为我们度过了一个宁静的夜晚。
我们开始看到访问量激增，尤其是在节目主持人Ryan于晚上10.30左右首次提出捐赠要求时，就在Saoirse分享了她勇敢而鼓舞人心的故事后不久。
突然之间，事情正在发生，交通流量激增，我们看到捐款总额每秒猛增数万欧元。
然后活动开始了，图表开始了，我们看到了先兆警告，来自Sentry和Stripe仪表板的Stripe API返回速率限制错误，随后用户在Twitter上报告了同样的错误。尽管平台本身正在快速响应，但由于Stripe的速率限制，一定比例的用户无法通过。我们与RTÉ的团队和Stripe的客户经理通电话。所有参与的团队反应迅速，不到半小时，Stripe的限制提高了5倍。同时，我们收到了Stripe CTO的电话，后者向我们保证我们不会再遇到任何问题。 Twitter现在着火了（#latelatetoyshow在世界范围内正在流行），很多人（理所当然地！）感谢Stripe。他们的反应绝对出色。
捐款不断涌入。我们在23:13:54记录了每秒151笔捐款的峰值。我们还在23:35看到了更长的高峰分钟，即每分钟6988次捐赠-在整个分钟中每秒超过110次捐赠。到午夜，该平台已筹集了超过500万欧元，其中大部分捐款（超过400万欧元）在从晚上11点到午夜的一小时内完成。
几个小时后我们结束了。这是一个漫长而激动人心的夜晚，我们需要为周六下午的节目重播做好准备。总共筹集了超过650万欧元（在撰写本文时，该站点一直开放到2020年12月14日），我们的CloudFlare员工收到了超过400万个请求。
我们有意地将平台逻辑保持在最低限度。核心是，我们有一个工作站点，该站点负责两件事：它为静态ReactJS前端提供服务并响应后端路由。后端路线是处理付款的核心，它使用用户提交的数据为Stripe的API创建付款意向并返回任何反馈。
我们通过Cypress.io对平台进行了自动化测试，该平台使用Stripe的测试模式在过渡环境中模拟了完整的付款过程，并使用Github Actions对我们主分支的每次提交都运行了该过程。然后，我们再次使用Github Actions和Wrangler将其部署到RTÉ的CloudFlare帐户。测试和部署管道的简单性意味着我们可以在整个团队中快速迭代，同时确保我们的核心功能保持稳定。
所有警告都记录在Sentry中，并发送到我们的Slack。晚上，我们记录了许多Sentry事件，其中许多事件与特定的浏览器行为和依赖项带来的控制台警告有关（例如我们与RTÉ的官方页眉和页脚的集成）。对我们来说幸运的是，并且证明了我们提前使用Browserstack进行了广泛的跨浏览器测试，没有报告的错误和警告被认为对用户使用至关重要。我们现在正在筛选这些事件，并使用知识来改进其下一个化身的平台。
我们的平台可轻松扩展。使用传统的基础架构方法，充其量我们最多会大规模超支，从而导致超额支付，最糟糕的是该平台将超负荷且不可用。
在边缘运行时（通过CloudFlare Workers或AWS Lambda @ Edge），无服务器速度更快。此外，CloudFlare Workers不会遭受典型的“冷启动”，随着流量的增加，整个活动期间的请求时间保持不变。
当他们的服务有可能成为您的应用程序的限制因素时，请始终与您的依赖项制定直接的沟通计划。
