스크립트
00:00:00欢迎收听 Better Stack 播客，在这里我们探讨软件开发、
00:00:04人工智能以及各种前沿技术。我是你们的主持人之一 Andrus，今天做客我们节目的是
00:00:10James 和 Alex。嘿，Alex，欢迎来到节目。谢谢邀请，伙计们。那么我们先从
00:00:16你经营的公司聊起吧。它叫 Hookdeck。对于不太熟悉的朋友，
00:00:22Hookdeck 是什么？它是做什么的？跟我们详细说说吧。好的，我喜欢把它看作是
00:00:27一家致力于终结 Webhook 的 Webhook 公司。这背后的故事我们待会儿可以聊聊。
00:00:32但我们目前主要开发两款产品。一款是 Event Gateway（事件网关）。Event Gateway 充当的是
00:00:37一种针对所有外部基础设施传入事件的专用事件总线。
00:00:41Webhook 是最典型的场景，但我们也处理很多物联网和基于 SDK 的用例等等。
00:00:47基本上，我们提供的是一种所谓的不可信端点。你可以向其发送任何事件。
00:00:51并提供管理这些事件的所有功能。这涵盖了过滤、
00:00:55转换、路由、排队、警报，以及问题管理和重放，基本上就是这些全套功能。
00:01:01所以实际上，它涵盖了互操作性，即我需要接收
00:01:05来自我所有合作供应商的事件和 Webhook，对吧？比如 Stripe、Shopify、Twilio、
00:01:10WhatsApp、TikTok 等等，应有尽有。它们各有各的标准、怪癖
00:01:16和特定的要求。而我们则能将所有这些标准化，并将其统一为
00:01:20单一契约。此外，还有从排队角度出发的功能。比如
00:01:27Shopify 商店正在进行限时抢购，你可能会被
00:01:31汹涌而来的事件潮淹没。通过事件网关，你可以对吞吐量进行标准化控制，
00:01:38以及处理所有相关事务。这是其中很大一部分。它有点像消费端。
00:01:42这正是 Hookdeck 故事开始的地方。最近，我们还发布了 Outpost。Outpost 是完全
00:01:49开源的，采用 Apache 2.0 协议。我们现在也提供了托管服务。它是用来发送
00:01:55事件的。所以这是等式的另一边，对吧？也就是你作为发布者，作为一个
00:01:59平台或开发者工具方。实际上，每个人现在都在发送事件，这让我每天都很惊讶。
00:02:05Outpost 既可以是托管服务也可以是自托管服务，你可以用它来
00:02:12声明你的租户是谁，目的地在哪里，它们注册了什么端点，配置
00:02:17主题并将事件发布给它们。它处理从可见性、指标、交付
00:02:23保证、重试到围绕签名、签名轮换等所有常见问题。
00:02:28关于终结 Webhook 的那个小玩笑，其实是因为 Outpost 虽然
00:02:35允许你发送 Webhook，但也允许你直接向用户的消息
00:02:39总线发布事件。因此，Outpost 原生支持现在被称为“事件目的地”的功能。Webhooks 被视为
00:02:46传输路由器。你基本上是通过 Webhooks 发送事件，
00:02:53Webhook 是标准的传输机制，对吧？你可以选择新的传输协议，比如 MQ
00:02:59或者是 RabbitMQ 或 Kafka。我们也支持直接向所有常见的 Pub/Sub 目的地发布，比如
00:03:05SQS、AWS EventBridge，当然还有 Hookdeck Event Gateway，对吧？所以我把它看作是
00:03:12更好的目的地，但这取决于人们是否相信。你说你想终结 Webhook，所以我
00:03:18猜这个想法的诞生是因为大家都厌倦了 Webhook 或者是因为它
00:03:25太难管理了。跟我们说说你是怎么想到这个点子的。是的，我前几天刚跟别人讲过
00:03:31这个故事。大概五六年前，我在 Medium 上发布了一篇文章。
00:03:37快六年了。文章的标题呼应了刚才你说的，
00:03:42“Webhook 很烂，但你可以为此做点什么。” 那时我正待在
00:03:48地下室里折腾，构建了 Hookdeck 的 V1 原型。
00:03:54这确实源于那种挫败感。我当时在做电子商务，我们构建了
00:03:59做了很多定制化的软件来支持电子商务，从定制订阅管理到
00:04:05仓储和配送等等。而你们遇到的许多问题
00:04:10都归结于 Webhook。这几乎成了个反复出现的笑话，因为一方面，
00:04:15我是在经营女性时尚生意，对吧？我在卖
00:04:18内衣和尼龙袜之类的。而另一方面，却在纳闷那该死的
00:04:23Webhook 跑哪去了？这感觉就像是关注点完全不匹配。
00:04:28所以，它确实来源于此，作为一个 Webhook 的使用者，我对这种
00:04:33缺乏“内置电池”般的处理方案感到非常沮丧。
00:04:38如果你上网搜索建议，虽然 Webhook 本身不是新东西，
00:04:43归根结底就是 HTTP 请求。这里显然有一些处理它的成熟模式。
00:04:46但你很快就会掉进兔子洞里。好的，你需要能够自动扩容的
00:04:50摄入消费者，然后你需要排队进入像 SQS 这样的队列。然后你需要部署一组
00:04:55消费者来从 SQS 中消费。如果出错了，它会进入
00:05:00处理来自 SQS 等队列的消费者。如果过程中出错了，它最终会进入
00:05:05死信队列。然后你需要一些脚本来处理死信队列的恢复工作，并
00:05:09随着复杂性的增加，你还希望能够重放你已经接收到的历史事件。
00:05:14你想查看 Webhook 的具体负载。
00:05:18然后你还要面对不同的供应商，因为可能 Stripe 会给你一个 UI，而 Intercom 不会。
00:05:22你不得不处理各种不同的怪癖。
00:05:26所以，它真的是源于那种挫败感，为什么没有现成的解决方案呢？
00:05:31起初，我仅从可观测性的角度看待这个问题，但这行不通。
00:05:35但我漏掉的部分是，可观测性只是其中一部分。最终我有了个说法，称 Webhook 为
00:05:41通往事件驱动架构的入门毒品。原因是——我也喜欢坚持用“事件”而不是 Webhook 这个词——
00:05:47是因为在每个 Webhook 背后都有一个事件，而且现在
00:05:51伴随 Webhook 而来的还有事件驱动架构的范式，对吧？
00:05:56所以每次当你为了某种规模或关键用例接收 Webhook 时，你现在必须考虑
00:06:01随之而来的还有事件驱动架构的范式，就像是 Webhook 的配套功能，对吧？所以每当
00:06:07你在任何严谨的规模或关键用例下接收 Webhook 时，现在都必须
00:06:14所以我们构建的很多东西最终演变成了构建一个完整的队列。
00:06:19因此，虽然存在互操作性，确保我们在处理事件，
00:06:25但所有的语义更多是关于处理事件和发布订阅系统等等的。
00:06:29而我们最初并非想重新发明队列。我们只是碰巧发现了一些相当不错的真知灼见。
00:06:33我们现在看到人们正在转而使用 Hookdeck 来替换他们堆栈中的 Pub/Sub 或 SQS，
00:06:38这对我来说简直难以置信，因为我们并不运行你们的 VPC 之类的东西。
00:06:43我想这背后可能有很多问题，也许以后会列入路线图。重点是，
00:06:48人们已经习惯了围绕事件驱动架构的许多语义，并且没人会去质疑。
00:06:53这就好比，为什么我们又要折腾死信队列了？到底哪里出了问题？
00:06:57因为我不知道有谁会觉得死信队列是处理队列错误的一种方便的语义，对吧？所以，我很乐意
00:07:05聊聊其中一些观点，因为里面有几个非常强烈的看法。
00:07:09我不确定你们对 Pub/Sub 和事件驱动架构有多大兴趣，我不想把你们带得太深。
00:07:13我觉得，是的，我对死信队列之类东西的了解非常、非常基础。
00:07:19今天听到的一些东西，还是第一次听说。
00:07:25是的，我本来也想说我的理解也比较肤浅，但我处理过 Webhook，
00:07:29也应对过你提到的一些问题。而且，你们关于 Webhook 是通往事件驱动架构的入门毒品的观点，
00:07:35非常有道理。因为我敢打赌，对于你们这种背景的开发者来说，Webhook 很可能是
00:07:40你们第一次接触到：“等等，这是异步的？我该怎么处理？”
00:07:48我觉得这有一个完整的学习曲线，就像经典的冰山理论一样，
00:07:53噢，你有一个传入的 HTTP 请求，然后，你知道，剩下的冰山
00:07:57都在水面之下。我正在尝试做的事情之一就是
00:08:01带来一种在这个领域尚未实现过的开发体验 (DX)，这样
00:08:06你实际上不需要去搞懂冰山的其余部分，对吧？有些事情是
00:08:12有点不可避免的，我不想歪曲它。我觉得一旦你开始
00:08:17处理这类问题，你确实需要对幂等性有很好的理解，
00:08:21也需要对顺序保证有很好的理解。所以并不是说
00:08:26你能解决所有问题。归根结底你还在处理事件。但我认为很多
00:08:32你其实不需要去弄懂冰山水下的那部分，对吧？有些东西是
00:08:37多少有些不可避免的，我不想歪曲事实。我觉得一旦你开始
00:08:40处理这类问题，你就需要对幂等性有很好的理解，
00:08:45非常深入了解问题的客户，他们会围绕现有的 Kafka 设置
00:08:49所以，这并不是说所有问题都能解决。我认为你最终还是在处理事件。
00:08:53但我觉得，很多语义和复杂性主要是源于工具考虑得不够周全，而非
00:08:58我不想去学习任何这些东西，只想绕过整个问题。所以，我们确实看到了这两种画像。
00:09:05这是否也是你将工具 Outpost 开源的原因，为了让开发者
00:09:13上手更容易？在某些方面是的。另一个原因是，我们不需要 Outpost
00:09:18来赚钱。好的，所以我们想，那我们就开源它吧。这很简单。
00:09:23我知道我们的 YouTube 观众真的很喜欢了解新的开源工具。
00:09:28这就是我问这个问题的原因。但首先，我有点后悔
00:09:31在早期阶段没有采取开源优先的方法。我觉得你在构建软件时，
00:09:36构建闭源与开源的思考方式非常不同。但在开源决定方面，
00:09:41你在获得风险投资的初创公司中看到的那种东西，最终通常是
00:09:47伪开源，对吧？说是开源，但要么是核心开源，要么是，是的，它是开源的，
00:09:53但他们真的不想让你用开源版本，或者最终不得不重新许可
00:10:01我知道很多YouTube观众都很喜欢了解新的开源工具，所以
00:10:07有机会拥有正确的激励机制。我们可能会深入探讨我们对业务的想法，但
00:10:13在我看来，需要接收 Webhook 的消费端人数至少比需要发送 Webhook 的人多出两到三个数量级，
00:10:18因为想想看，如果我发送 Webhook，我是发送给我所有的客户，
00:10:21而我的客户可能是 10 个（如果你刚起步），或者 100 个、1000 个，甚至 200 万个。所以，必然地，
00:10:26消费端的人数要多得多。所以当我从企业家的角度思考时，
00:10:30我更看好消费端的业务。但我认为我们意识到的是，显然，没有好的生产者就没有消费者。
00:10:34我认为人们对 Webhook 的需求在一般应用开发中越来越大。
00:10:39所以，更多人想提供它，但又不想经历技术债和开销等。但从我的角度来看，
00:10:44首先，发送 Webhook 是个更简单的问题，因为你可以控制参数，而接收端，vendor 是决定参数的人。
00:10:49所以，我不说它简单，但生产端的问题空间 definitely 更有限。其次，
00:10:54我们的工作是鼓励事件的生产。这是我们最终关心的，
00:10:59因为我们希望更多人消费这些 Webhook，并最终成为我们的客户。所以，我觉得这让我们
00:11:03处于一个可以真正这样说的位置：不管你是使用 Outpost 开源版，还是部署
00:11:09Hookdeck 的托管版，对我们来说通常是一样的。无论哪种方式，我们都达到了商业目标。
00:11:13这种一致的激励让我很兴奋。我们做的一件事是，我们先发布了开源，
00:11:17起步阶段是100人，可能1000人，甚至200万。没错，所以归根结底，消费端的人数确实要多得多。
00:11:24开源项目大概是两年前发布的。所以我们花了差不多两年时间才等到有足够多的人请求托管版本，
00:11:28我们才最终构建了它。另一部分是，托管版本的 Outpost 运行的是
00:11:33和发布在 Docker Hub 上的开源版本完全相同的 Docker 构建。
00:11:37这意味着我们没有私有分支，没有在开源之外打包功能。我们运行的是完全相同的 Docker 构建。
00:11:42所以问题对你来说不是版本间的功能差异，而是你是否想自己部署、承担与之相关的
00:11:46运营负担？还是你想付钱给别人代劳？没有对错之分，这取决于每个业务的水平、
00:11:51合规要求等等。因为这样，我觉得我们可以作为一个项目贡献者为开源社区做出贡献。
00:11:57我很高兴能致力于此，因为它是我参与的第一个大型开源项目，作为核心维护者。
00:12:02你觉得现在有了 Claude Code 等工具后，开源世界怎么样？PR 很多吗？有虚假的漏洞报告吗？
00:12:06看起来还没那么糟？听着，我觉得我们的规模还没到能谈论其他人正在经历什么的程度。
00:12:10我绝对不想歪曲情况，因为对于很多人来说情况确实糟糕。不过我确实对我们收到的质量和
00:12:15贡献感到惊讶。但我们肯定也遇到过那种，比如有一个特定的 PR，我想现在还在仓库里挂着，
00:12:19它是要把 Cloudflare 队列作为目的地添加进去。从表面上看，描述听起来很不错，
00:12:23但当你实际挖掘代码时，它用了一堆完全虚构的 Cloudflare API。
00:12:29显而易见，提交 PR 的人根本没试着去运行它。现在负担就落在了我们身上，
00:12:35因为我确实担心被视为不想支持我们可能与之竞争的人。
00:12:40所以我认为我们应该支持 Cloudflare 队列，但它并不在路线图上，没人问过。
00:12:44它现在处于一种尴尬状态。如果关闭它，你看起来像是不想支持潜在竞争对手的用户。但你
00:12:48真的要投入资源、修改路线图并确保实现正确吗？这是一个两难的境地。
00:12:52但我目前感觉这是一次很好的经历，特别是因为我们使用相同的构建。
00:12:57我们采取的一种做法是，当客户联系我们寻求反馈或谈论特定功能时，我们在 GitHub 上打开问题，
00:13:03或者指向现有的 PR 和问题。我们确保让人们知道仓库在那儿，你们可以去贡献。
00:13:08事实上，确实有几位托管用户做出了贡献，并实现了他们自己的功能。
00:13:13这大大降低了此类真实贡献的准入门槛。因为从历史上看，项目是用 Go 写的，
00:13:19大部分用户最初并不是 Go 开发者。我们看到很多 Python、TypeScript，当然还有 Node.js 用户，
00:13:23所以对于 Go 来说有准入门槛，学习一个新项目来贡献也是非同小可的。
00:13:29所以我认为这确实大幅降低了准入门槛，这非常好。
00:13:34如果用户遇到了麻烦，作为维护者，这是一个强烈的信号，表明该功能值得构建。
00:13:38有人花精力去实现它，这表明它确实很重要。关于积压工作的重要性排序，
00:13:44这非常有价值。如果你能设法处理垃圾邮件等问题，那将会有很多积极因素。
00:13:51在落地页上，有一个引起我注意的地方，是来自 Vercel CEO 的推荐语。
00:13:55所以 Vercel 实际上也在使用 Hookdeck 作为产品。
00:14:01还有这类工作，不过是作为核心维护者。所以，嗯，感觉挺好的。
00:14:05现在的开源世界有了 Claude Code 和类似工具，你的体验如何？
00:14:09你是否收到过很多无效的 PR 或安全漏洞报告，还是说其实还好管理？
00:14:14嗯，你看，我不认为我们的规模能代表其他人的经历。
00:14:20所以我绝对不想曲解现在的情况，因为对很多人来说，那里的环境确实很糟糕。
00:14:25不过我要说，贡献的质量确实让我感到惊讶。但我们也确实遇到过一些贡献，比如
00:14:30有一个特定的 PR，我想现在还在仓库里挂着，是关于将 Cloudflare 队列作为
00:14:34目标端。就像在表面上支持的事件目标之一，对吧？
00:14:40PR 里的描述听起来很不错，诸如此类。但当你真正深入研究代码时，
00:14:44会发现它用了一堆完全是编造出来的 Cloudflare API。
00:14:48而且他们根本没去复核。意思是，很明显提交 PR 的人甚至根本没尝试运行过。
00:14:52对，所以现在负担就落在我们身上了，就像是，好吧，既然现在有这个开启的 PR，
00:14:56我当然有点担心被外界认为我们不想鼓励那些可能被视为竞争对手的人。
00:15:02所以，我的确认为我们应该添加 Cloudflare 队列支持等等，但同时，
00:15:08它并没有在开发计划里，除了这个人以外，没人要求过这个功能。
00:15:12所以我确实认为我们应该加入 Cloudflare 队列之类的功能，但与此同时
00:15:15这本来是在待定路线图里的，除了这个人之外根本没人提过这类需求
00:15:19但你真的要投入资源去提前开发计划吗？确保实现得正确？
00:15:24所以，在这种情况下，这简直成了一个两难困境。
00:15:28嗯，但到目前为止，我觉得这依然是一次非常好的体验，
00:15:33尤其是因为我们使用同样的构建方式。有一件事我们已经开始做了，就是每当
00:15:37客户联系我们寻求反馈，或者和我们讨论具体功能时，
00:15:43我们会直接在 GitHub 上开启 issue，或者指引他们去参考已有的 PR 和 issue。
00:15:48我们尽量确保让大家知道：嘿，仓库就在那儿，你可以去参与贡献。
00:15:53说真的，针对这一点，我们已经有几位托管版用户进行了贡献，
00:15:58基本上就是直接去实现了他们想要的功能。
00:16:03我觉得这极大地降低了那些真实使用场景的准入门槛。
00:16:07因为你知道，从历史上看，这些 Go 语言项目，
00:16:13我们大部分用户可能根本不是 Go 开发者。对吧，我们看到很多
00:16:18Python、TypeScript 开发者，当然还有 Node.js 的，所以这存在着一道 Go 语言的门槛。
00:16:24而且要学习一个新项目去进行贡献，本身也并不简单。
00:16:28所以我觉得这确实大幅降低了准入门槛，这真的非常好。
00:16:35因为现在如果作为用户，你遇到了“这个东西真的让我很困扰”的问题，
00:16:39而且加上作为维护者，这本身就是一个极其强烈的信号，表明这个功能值得开发。
00:16:42如果有人愿意投入时间去实现它，
00:16:48那这就是一个信号，说明这事确实很重要。在排优先级时，
00:16:53了解什么才是最重要的。所以我认为，降低准入门槛真的很好。
00:16:58这说明它确实很重要。在确定优先级方面，什么最重要，
00:17:02知道什么才是最重要的。所以我认为降低准入门槛真的很棒。
00:17:07所以我觉得，如果你能设法避开垃圾信息和那些干扰因素的冲击，
00:17:12这会带来很多积极的影响。
00:17:14在着陆页上，令我印象深刻的一点是 Vercel 首席执行官的推荐语。
00:17:21所以 Vercel 实际上也在使用 Hookdeck 作为产品。
00:17:25如果你读了那句具体的引用，它也在推荐它。
00:17:29哦，好的。
00:17:29就像 Vercel 的用户之类的那种情况。
00:17:32嗯，但其实这背后有个有趣的故事。
00:17:35因为 Guillermo 在一个周六晚上发了关于它的推文。
00:17:39我完全没想到会发生这种事。
00:17:40我和 Guillermo 之间之前并没有什么联系之类的事情。
00:17:45这也能体现出社区中某些人士的影响力。
00:17:48因为那次之后我们获得的注册量和关注度简直
00:17:53简直疯狂。
00:17:54嗯，从那时起，Guillermo 和我有过一些交流。
00:17:57我们也一直聊得很投机。
00:17:59这很有意思。
00:18:00因为，呃，实际上如果你看像 Vercel 这样的公司，Guillermo 曾告诉过我一件事，
00:18:04他说现在确实看到有更多的人在使用 WebEx。
00:18:07他的理解是，这主要是由 LLM 的选择驱动的。
00:18:12这正在为数据创造新的用例。
00:18:15这些用例通常是你以前不会关心的。
00:18:18比如想想你的客户支持系统。
00:18:20例如，你有代理商和人类在那里工作。
00:18:23几乎没有什么理由要对这些新工单事件做任何处理。
00:18:29诸如此类的事情。
00:18:30因为反正最后都是由人类去回答那个消息。
00:18:34但现在我们显然处于一个一切都在改变的世界。
00:18:37当你从人类触发代理转变为通过事件触发代理时，
00:18:42对吧。
00:18:42突然之间，你开始关心来自客户支持系统、
00:18:46营销工具以及其他各种工具的事件。
00:18:48对。
00:18:48所以，这绝对是我认为作为平台他们正在观察到的东西。
00:18:54这对我们来说显然一直是个有趣的讨论点。
00:18:57但确实，Vercel 并不是直接的用户。
00:19:01我的意思是，我相信 Vercel 有很多开发者在使用你们的本地 CLI 等工具，
00:19:05但确实如此。
00:19:06那么 Hookdeck 的典型客户是谁呢？
00:19:10如果我有一个小型 T 恤电商商店之类的东西，我该如何使用 Hookdeck？
00:19:15这种情况下使用它合理吗？
00:19:17这种情况下使用它有意义吗？
00:19:19可能没有。
00:19:21好的。
00:19:22你问我的算是价值百万美元的问题，因为我认为我们一直很纠结，
00:19:26因为使用 Webhooks 或依赖 Webhooks 的原因极其广泛。
00:19:32使用 WebEx 或依赖 WebEx 的原因简直多得惊人。
00:19:35比如我们从像 Stripe 和 Shopify 这种通常的怀疑对象那里得到 WebEx，但我们也有
00:19:40来自所有澳大利亚电信运营商和英国票据交换所的 WebEx。
00:19:47甚至还有很多来自《EVE Online》游戏。
00:19:50似乎还有一个社区的人还在玩 15 年前左右的《野蛮人柯南》游戏。
00:19:55他们也非常依赖 Webhooks。
00:19:58而且他们也大量使用WebEx。
00:20:00别问我为什么。
00:20:00好的。
00:20:01但关键在于，用户的广度非常大，很难去定义说：
00:20:06这就是我们的客户群体。
00:20:08对。
00:20:09所以当我们看用户时，并没有单一的用例或群体占比超过 10%。
00:20:13无论是什么。
00:20:14可能超过百分之十。
00:20:16但说到你提到的电子商务用例或示例。
00:20:19首先，一家小型 T 恤商店可能还没构建过依赖于此的自定义应用程序。
00:20:25诸如此类的事情。
00:20:27但他们几乎肯定安装过应用程序。
00:20:30比如，收集评价的应用、到货通知应用、库存管理应用以及与第三方物流集成的应用。
00:20:35这些人几乎都在完全依赖 Webhooks。
00:20:39这些服务几乎完全依赖 Webhooks。
00:20:43没错。
00:20:43所以如果我想发送“到货提醒”，我的操作就是监听所有库存
00:20:48通过 Shopify 商店的 Webhooks 进行更新。
00:20:50一旦之前缺货的产品现在有货了，
00:20:53我就会想，好，得发邮件了。
00:20:54没错。
00:20:55所以基本上，他们安装或添加的每一项功能，最终
00:20:59都要在后台依赖 Webhooks。
00:21:00其中很多也是我们的客户。
00:21:02我们看到的另一类是大商店。
00:21:07想想 Gymshark、Good American、Rogue 这种规模的商店，
00:21:09他们有自己的技术团队在构建自定义应用。
00:21:11他们为系统集成构建自定义应用，
00:21:14通常在操作层面，比如订单同步至第三方物流的排序，以及添加备注等。
00:21:19有时需要在数据到达第三方物流之前添加特定于客户的偏好。
00:21:22他们正在为自己的系统集成构建自定义应用程序，通常在操作层面非常具体
00:21:28例如订单排序、何时需要与第三方物流系统同步，以及需要添加备注。
00:21:34或者当某人购买礼品卡并想发送给朋友时发送特定电子邮件等。
00:21:39这些是我们往往会看到的情况。
00:21:41小型 Shopify 商店是你刚才选的例子，我们没怎么看到他们使用 Hookdeck，
00:21:41但实际上在那个细分领域中的几乎每个地方，
00:21:46你最终都会接触到使用 Webhooks 的公司。
00:21:51比如有人买了礼品卡想送给朋友，诸如此类的事情。
00:21:55所以我们通常看到的，小型Shopify店铺可能就是你提到的
00:21:59挑选的例子，虽然我们不太常看到有人用WebEx，但你知道，在几乎其他所有
00:22:04你所瞄准的那个细分领域里，你最终都会接触到一家
00:22:08使用WebEx的公司。
00:22:09嗯，显然我们都知道 AWS，我的意思是 AWS 几乎在做同样的事情，对吧？
00:22:10是的。
00:22:11它与 AWS EventBridge 之类的服务相比如何？
00:22:14也是通用的。
00:22:17这更多是关于开发者体验的论点，对吧？
00:22:19即合适的 API、漂亮的 UI 以及稳如磐石的可观测性等等。
00:22:24没错。
00:22:25当然还有集成问题。我认为 AWS 的问题一直在于
00:22:26你最终会拥有 20 个服务，其中大多数你可能已经忘了名字。
00:22:31CloudWatch、亚马逊云服务以及诸如此类的东西，其实同样适用。
00:22:37所以，这很大程度上就像是关于开发体验的论点，对吧？
00:22:40但更广泛的一点是，AWS EventBridge 实际上并没有与所有人集成。
00:22:46供应商需要主动与 AWS EventBridge 集成。
00:22:47虽然可以通过 API 网关等方法解决，但这主要还是为 AWS 生态构建的。
00:22:47大多数用例实际上是 AWS 内部事件，比如 S3 文档上传之类的事情。
00:22:51而在与第三方互操作性方面，虽然他们确实支持 40 多种供应商，
00:22:56（现在可能更新了，但肯定没有上千个）。
00:22:59你总是会陷入这种情况：Shopify 支持 EventBridge，但 Twilio 不支持。
00:23:01对。
00:23:01所以当你需要一个可以通用且立即可用的方案时，
00:23:02Hookdeck 就能解决这些问题。
00:23:07这就是我们想做的事情。
00:23:08也就是说，厂商必须先与 AWS EventBridge 完成集成。
00:23:11在这个点上，我们构建 Hookdeck 的方式相当新颖，因为它纯粹基于 HTTP 工作。
00:23:16我们为你提供一个 URL，你可以用它替换现有的 Webhook URL。
00:23:23而在 Hookdeck 中，你的目标就是原本的 URL。
00:23:31我们像是一个基于推送的队列。
00:23:31我们通过 HTTP 获取 Webhook，并按你指定的速率推送到你的终端。
00:23:36那些厂商，啊，现在可能已经更新了，别引我这句话，但你知道的，绝不是成千上万个。
00:23:40你总会遇到这种情况：好吧，Shopify 支持 EventBridge，但像
00:23:45Twilio 却不支持。
00:23:47因为唯一的条件只是更新那个 URL。
00:23:47这与 AWS EventBridge 那种终极供应商锁定、需要特定兼容性、
00:23:51且只能在 AWS 生态中工作的情况有很大区别。
00:23:52是的。
00:23:54通常我会把 AWS EventBridge 看作是另一个大型事件网关。
00:23:59我们也看到了 Azure Event Grid，它也是一个获得了一些份额的竞争对手。
00:24:02所以我认为这是我们最直接的竞争对手，或者说在某些方面是我们的灵感来源。
00:24:08但我们的愿景要大得多。
00:24:10这对某些人来说是好事，对其他人来说则不然。
00:24:15有些人完全沉浸在 AWS 生态中，
00:24:17他们使用 CloudFormation，熟悉所有服务，这完全没问题。
00:24:22我们并不打算占领 100% 的市场份额。
00:24:25占领几个百分点就足够了。
00:24:28所以，对于独立公司和开发者来说，
00:24:31这就是正确的解决方案。
00:24:34对于其他人，AWS EventBridge 可能更合适，这也没关系。
00:24:39我注意到在过去一年里，大公司的宕机次数似乎增加了。
00:24:40比如 GitHub 宕机的各种梗。
00:24:44两年前，如果 P99 降到 99.5% 以下，团队会进行严肃的对话。
00:24:48但现在这似乎成了常态。
00:24:53是的。
00:24:53大家似乎都已经习惯了 GitHub 长时间的宕机。
00:24:58那么从 Hookdeck 的角度来看，今年是否感觉宕机次数更多？你们如何应对这些挑战？
00:25:04这很有趣，因为如果你要使用 Webhooks，这绝对是个考量点。
00:25:10特别是 GitHub 的 Webhooks 尤其成问题。
00:25:13在 Railway 或 Vercel 上登录时，有一半的几率会看到一个小横幅，
00:25:17提示部署失败，因为 GitHub Webhooks 无法工作。
00:25:18GitHub CTO 曾针对基础设施稳定性写过一篇博文，
00:25:20试图平息舆论，但这并不起作用。
00:25:22文中明确提到了 Webhook 的稳定性以及它对 MySQL 等服务的依赖。
00:25:24没错。
00:25:26平心而论，我并不怀疑他们面临的基础设施挑战是极其疯狂的，
00:25:27特别是在 AI 智能体兴起的背景下。
00:25:30这和开源维护者被淹没的情况一样，基础设施也被淹没。
00:25:31我觉得我们不可能拥有百分之百的市场份额。
00:25:34所以实际上在美国，我认为只要占据几个百分点可能就够了。
00:25:38所以是的，我认为我们正在试图证明，对于那些美学公司和
00:25:45开发人员等等，这将是正确的解决方案。
00:25:48而且对于其他人来说，AWS EventBridge 将会是（首选），那也很好。
00:25:51所以我注意到过去一年里，大型企业的停机时间
00:25:59一直在增加。
00:26:00就像网上到处都是关于 GitHub 宕机的梗图。
00:26:02我记得两年前我工作的时候，如果 P99 指标
00:26:07如果跌到了 99.5% 左右或更低，你就会和你的团队进行一次严肃的谈话。
00:26:13问这怎么可能发生？
00:26:14而现在，这似乎成了家常便饭。
00:26:15是啊，现在已经习以为常了。
00:26:17确实。
00:26:17人们好像已经习惯了 GitHub 长时间宕机这种情况。
00:26:23所以我想问，从你在 Hook 的角度来看，你是否觉得
00:26:28今年比往年有更多的宕机情况？你们是如何应对这些挑战的？
00:26:33这很有趣，因为如果你打算使用 Webhooks，这显然是你必须考虑的问题。
00:26:37如果你打算使用 Webhook，尤其是 GitHub 的 Webhook，那确实是个挺麻烦的问题。
00:26:42你知道的，如果你在 Railway 或 Vercel 之类的平台上部署，大概有一半的几率会遇到这种情况，
00:26:46那就是会弹出一个横幅提醒。
00:26:47上面会写着，由于 GitHub Webhook 无法正常工作，部署暂时中断之类的。
00:26:51实际上，GitHub 的 CTO 曾专门写过一篇关于他们基础设施稳定性的博文，
00:26:58当时正处于各种玩梗和舆论的焦点中，
00:27:02他们试图平息大家的怒火。
00:27:03我觉得效果并不怎么好，但当时确实是个大问题。
00:27:05在那篇文章中，他们明确提到的原因之一就是 Webhook 的稳定性，
00:27:09以及它是如何依赖 MySQL 等等服务的。
00:27:12明白了。
00:27:13说句公道话，我认为文章的措辞方式或许有点轻描淡写了。
00:27:17我完全不怀疑他们面临的基础设施挑战有多么疯狂，
00:27:21特别是在智能体兴起的情况下。
00:27:23就像我们刚才提到开源维护者被请求淹没一样，
00:27:26他们的基础设施也同样面临这种被淹没的状况。
00:27:30所以，抱歉，我相信这绝对是个极具挑战性的难题。
00:27:33但我想表达的重点，或者说我正要引出的结论是，没错，我们确实能看到这一点。
00:27:38不仅如此，对于某些供应商，我们实际上也在进行监控。
00:27:41例如，我们有一个自研工具，我们称之为“Deck雷达”。
00:27:44这个想法是，我们可以查看所有客户以及通过Deck接收到的所有WebHook的汇总统计数据，
00:27:49通过 WebEx 获取的聚合数据，进而计算出诸如投递延迟等指标
00:27:53某个供应商的P99交付延迟是多少、他们的正常运行时间是多少等等指标。
00:27:58所以，举个例子，我们为Shopify提供的雷达监控就非常受欢迎。
00:28:01我已经有几百个订阅者了。
00:28:04我们的想法是，如果延迟超出了基准延迟的一定标准差，我们就会发送警报。
00:28:09基本就是这样。
00:28:12对。
00:28:12我认为就Shopify而言，基准交付延迟大约在四到五秒左右。
00:28:17交付延迟。
00:28:17我认为如果超过10秒，
00:28:19对。
00:28:20我们就发送警报。
00:28:22但核心理念是，你可以像查看时间序列数据一样监控这些指标，并观察
00:28:26他们的正常运行时间，不仅是原始正常运行时间，还有他们的延迟概况
00:28:31随时间的变化情况。
00:28:32这也是你肯定能观察到的。
00:28:33我的意思是，Shopify团队也充分意识到了这一点。
00:28:36但你可以看到交付时间存在很大的差异。
00:28:41所以大概每两个月左右，就会出现一次诸如此类的情况，
00:28:46也就是出现相当明显的延迟故障。
00:28:49我认为这是你通常看不出来的。
00:28:51对。
00:28:52因为显然，停机检测要容易得多。
00:28:54你打开Datadog或Better Stack。
00:28:57你们把这种产品又称为什么来着？
00:29:01可观测性。
00:29:02对，可观测性。
00:29:03所以当你打开Better Stack，显然是在构建这类东西。
00:29:05对。
00:29:06如果你看到指向WebHook端点的HTTP调用停止了，那就很明显。
00:29:11没错。
00:29:11就像你知道的那样，问题很明显，处理起来也很直接。
00:29:14但如果延迟增加到60秒，这在你的实际指标中就很难看出来了。
00:29:19因为那是处理延迟，这可能是你
00:29:22对。
00:29:23那是因为这是你在处理时所花费的延迟，这大概是你
00:29:27会去进行追踪之类操作的部分。
00:29:28这是供应商那边的延迟。
00:29:31如果你在代码和业务操作中做出了新的假设，
00:29:34认为这些事件是实时的，如果它们现在延迟60秒才到达，
00:29:39这就会引入一系列微妙的问题、漏洞以及对代码的错误假设。
00:29:44所以我认为这是我们这类产品独特的切入点，
00:29:46能够提供良好的数据支撑。
00:29:50让你清楚到底是自己出问题了，
00:29:52还是供应商出了问题。
00:29:55对。
00:29:56那就是问题所在。
00:29:57我不确定能否凭经验说明这类问题发生的频率是上升了还是下降了。
00:30:03虽然有些“惯犯”是大家容易指责的对象。
00:30:06指责他们确实很容易。
00:30:08我不知道这是否是一个我们时刻都在看到的普遍性的分布式问题。
00:30:13我觉得这更集中在特定的供应商身上。
00:30:16而且我觉得大家最容易栽跟头的地方就是交付延迟。
00:30:23另一件事是，我觉得人们假设大多数供应商的交付延迟比实际情况要短，
00:30:27因为在大多数情况下我们确实是在谈论几秒钟的延迟，
00:30:31这取决于你怎么看，可能算是很长，也可能不算。
00:30:34但我向一群Shopify开发者展示这个延迟图表时，
00:30:40他们的第一反应往往是“我没想到会这样”。
00:30:43对。
00:30:43这种对预期的打破时有发生。
00:30:46我以前为一家相当大的电商公司工作过，我们也有同样的问题。
00:30:53延迟很严重，但每个人都在玩“蜘蛛侠对指”的梗，
00:30:58互相推诿到底是谁的责任。
00:30:59因为就像你说的，通常基本上是第三方供应商的问题。
00:31:05有时候你确实无能为力。
00:31:07只能想办法绕过去。
00:31:08所以很酷。
00:31:09指责供应商时也要小心。
00:31:11对。
00:31:11这显然是你们业务背景下经常遇到的问题。
00:31:16你知道，这总是一个常见问题。
00:31:18每当我们遇到事故，就会问：“我们要把多少责任推给供应商？”
00:31:22但在某个时刻，也要分清什么是合理的，什么是不合理的。
00:31:27什么是偶然事故，什么不是。
00:31:29比如前几天，Railway，我们的一些部署是运行在Railway上的，
00:31:34因为他们的定价结构。
00:31:36因为我们必须运行与开源版本相同的版本，我们没有构建……
00:31:40多租户架构，这在开源领域也不适用。
00:31:44所以基本上我们为每个客户进行单独部署。
00:31:48对。
00:31:49对于免费计划用户，我们会在Railway上为他们部署一个实例，
00:31:52总体来说，运行得相当不错。
00:31:54但前几天，他们的GCP账户被关停了，导致他们宕机了大约六个小时。
00:31:59之类的。
00:31:59对。
00:31:59所以当时就觉得，好吧，你知道，能不能别在你的频道里提起这件事？
00:32:06有一点是肯定的，就是关于推卸责任的问题。
00:32:09我当然认为你必须对你的供应商负责。
00:32:11但重点是，我认为这条界限很难把握。
00:32:14我确实观察到人们有一种天生的倾向，就是想要
00:32:18通过指责他人，来减轻自己的责任感。
00:32:20所以你必须努力去克服这种倾向。
00:32:23对。
00:32:24但在你能确定是供应商的问题的情况下，
00:32:28能够识别出这一点，并拥有相关数据就很重要，
00:32:31而这往往是供应商问题的难点所在。
00:32:35对。
00:32:35你看不到他们那边的原始数据。
00:32:37因此很难确凿地或拿出实证说这完全是他们的错。
00:32:42你只能从自己的数据中推断，
00:32:43这可能对，也可能错。
00:32:46对。
00:32:47所以我很好奇，当Shopify或Stripe出现宕机时，
00:32:51事件是如何进行追赶处理的？这会给你们的服务器造成很大的负担吗？
00:32:57是的，基本上这就是所谓的“重试积压”效应。
00:33:00因为在那些场景下，我们总是说，
00:33:05你不应该假设某个特定的WebHook容量。
00:33:09嗯。
00:33:09我们有一个特性，即每个供应商都会强制执行超时限制。
00:33:14没错。
00:33:14它们通常会给你大约三秒钟的时间，
00:33:15五秒的时间，取决于具体的平台。
00:33:18这意味着你实际上无法进行大量有意义的工作，
00:33:21尤其是当你考虑到网络延迟和类似的因素时。
00:33:25对。
00:33:25这就是为什么，不仅是为什么，
00:33:28但这是人们普遍认为你需要排队的原因之一。
00:33:31你不能同步处理这些请求。
00:33:33但我刚才忘了要说什么了。
00:33:39你能重复一下你的问题吗？
00:33:42我是在问当Stripe和Shopify这样的公司出现宕机时的情况。
00:33:45哦，对。
00:33:45关于赶工处理的问题。
00:33:47是的。
00:33:47对。
00:33:47没错。
00:33:47总之，说了这么多关于延迟的问题，绕了个大弯，其实就是你需要有自动扩容的能力。
00:33:52而且你需要在很短的时间内完成扩容。
00:33:53这些高峰出现的原因多种多样。
00:33:56可能只是自然发生的，比如客户进行了批量导入。
00:33:58可能只是自然发生的，比如当你的客户进行批量导入时，
00:34:03或者类似的情况。
00:34:03是的。
00:34:03造成流量激增的原因还有很多。
00:34:05但服务宕机确实是其中之一。
00:34:07没错。
00:34:07会有这样一刻：如果Shopify宕机了半小时，等他们恢复时，
00:34:11他们会直接冲进积压的队列里，试图减少队列积压带来的压力。
00:34:16也就是处理掉停机期间堆积的所有任务。
00:34:17基本上就是处理掉所有堆积任务。
00:34:22所以，你会看到他们甚至会以超过平时的容量进行处理，
00:34:26因为他们试图赶进度。
00:34:28对。
00:34:28结果就是向终端门店发送了大量请求。
00:34:32所以是的，你会有那些不规律的流量，但其中一些不规律和吞吐量激增
00:34:37并不是由你造成的。
00:34:38那是100%由供应商造成的，因为他们正在经历自己的基础设施挑战。
00:34:42等等所有那些问题。
00:34:44显然，Shopify发送WebHook的能力要远高于你接收WebHook的能力。
00:34:49大部分情况下是这样。
00:34:52是的。
00:34:52有趣的是，我们的一位投资者曾是Twilio的CPO。
00:34:56我认为这也是他感兴趣的原因。
00:34:59因为他曾说，基本上Twilio会定期对客户进行DDoS攻击，
00:35:04从任何目的上来看都是如此。
00:35:07这在某种程度上是不可避免的，也是处理供应商驱动事件时不可避免的问题。
00:35:14所以，这在供应商中是一个非常众所周知的问题。
00:35:17他们也知道这一点，因为这也是你可以追踪服务器响应延迟的指标，对吧？
00:35:21如果你对客户进行DDoS，服务器的响应延迟就会上升。
00:35:24而且在某个节点，他们会开始超时。
00:35:26问题就会加剧，因为如果超时时间变长，就更难获得高吞吐量。
00:35:29基本上你维持HTTP连接的时间越长，
00:35:31你的工作进程能处理的请求数就越少。
00:35:34所以现在你必须扩容，然后你发送得更多，因为你已经扩容了，你对吧。
00:35:38这些东西都堆积在一起了，对吧？
00:35:40这往往是一个自我强化的过程，因为基本上你处理WebHook的能力越差，
00:35:45延迟就会退化得越快，对吧？
00:35:46当你触及服务器的处理极限时，延迟会变得非常严重。
00:35:52但那些请求会持续堆积。
00:35:57很多供应商的做法是在某个时刻直接禁用你的端点，
00:36:01否则问题会持续恶化，对吧？
00:36:04因为如果你的服务器响应缓慢，他们不想维持成千上万个HTTP连接。
00:36:07但一旦他们禁用了，你就丢失数据了。
00:36:10这也是关键所在，对吧？
00:36:14因此，应对那些超出你控制范围的延迟波动，是这个挑战的重要组成部分。
00:36:15这是处理过程中的难题。
00:36:19我还想问，随着AI的发展，它是如何改变WebHook这个领域的？
00:36:21我知道你说过大模型现在正在发送和处理更多的WebHook。
00:36:25但在内部，你们是如何在Hookdeck中使用AI的？
00:36:29我还想问一下，随着人工智能的出现，网络钩子（web hooks）的整个领域发生了怎样的变化？
00:36:37我知道你说过大语言模型（LLMs）现在正在发送更多的网络钩子，或许还在处理它们。
00:36:43作为一个软件开发店，我们显然也在经历挑战。
00:36:48我感觉你们也面临同样的挑战，
00:36:51围绕着工作流每周都在变化，Token成本，
00:36:54如何评估Token成本是否合理等等问题。
00:36:57我觉得你们可能也正经历着同样的挑战，
00:37:02比如每周都在变的工作流程，还有 Token 成本问题，
00:37:05以及究竟多少 Token 成本才算合理，诸如此类的事情。
00:37:10是啊，我们没必要搞什么排行榜。
00:37:15我对排行榜这个想法感到非常担忧。
00:37:18这看起来绝对会摧毁你们的利润率。
00:37:24所以我有几个想法。
00:37:25首先，回到我之前提到的，由这些代理用例驱动的事件需求在增长，
00:37:29因为代理正在从人类触发转向事件触发，你们可以看到各种云代理产品层出不穷。
00:37:35比如GitHub PR，或者你在GitHub上的提交、评论，所有这些都是Web驱动的。
00:37:41但显然，它会扩展到远不止于此，
00:37:42涉及客户支持、Slack等等，甚至可能是真实世界中发生的实时传感数据，对吧？
00:37:46我想很多代理也需要触发其他代理的事件，基本上，代理的输出本身就是一个事件，
00:37:49GitHub 的 PR，或者是你在 GitHub 上提交代码或评论时，这些都是基于 Web 的。
00:37:56但很明显，它将会扩展到远不止于此，比如客户支持、
00:38:00Slack 等等，甚至可能还包括现实世界中发生的实时事件，
00:38:04比如来自传感器的数据等等，对吧？
00:38:08我认为很多智能体也需要触发与其他智能体之间的事件，基本上，
00:38:12智能体的输出将成为一个事件，这很可能会触发
00:38:17另一个智能体、另一家公司等等，是的，你可以将其
00:38:21可以归类为 Webhook 用例，确实也算得上是。
00:38:23但我觉得目前围绕 Webhook 的一些语义在安全性、协议以及效率等方面还有些欠缺。
00:38:28协议和效率等方面还存在缺陷。
00:38:33这就是为什么我们一直在推动将事件目标作为一种更好的模式，
00:38:36这也是针对此场景一种更优化的模式。另外，如果你执行
00:38:40的响应事件的操作是智能工作流，它们是不确定的，可能会运行很长时间，
00:38:47这使得你很难根据接收到的事件来真正调整容量和规模。
00:38:51所以我认为吞吐量管理和容量管理会变得更加困难。
00:38:55因为云端超时，以及评估未通过等原因，你的失败率将会更高。
00:39:00所以，从应用程序构建的角度来看，以及你想要使用的核心原语，
00:39:07所以我认为从应用程序构建的角度，以及你想要使用的核心原语来看
00:39:12还有它们的运行位置、运行时长，以及你如何处理背压之类的问题
00:39:16都会带来许多新的挑战。至于我们内部的情况，
00:39:21完全被容量所震撼。我并没有让任何人感到惊讶，我不觉得我带来
00:39:25彻底被算力所震撼。我这话并不让人意外，也不认为自己带来了
00:39:29什么独到的见解。但我唯一想说的是，从
00:39:34高质量、有品位的产品之间，门槛依然存在。我认为在所有的模因和
00:39:41曝光中，这种细微差别正在丧失。我怀疑你是否真的能花费
00:39:45这么多 token，最终还能产出对世界真正有价值的东西。
00:39:50至少根据我们目前的经验，显然这其中很多是围绕安全的，
00:39:55这是一个巨大的赋能，比如代码审查等等。但我认为当涉及到
00:40:01确实是巨大的推动力，比如代码审查之类的工作。但我觉得谈到
00:40:06这些东西，它们只能算是基础门槛。它们并非是那种真正
00:40:11能带来最终价值的东西，对吧？比如在真正去构建一些
00:40:14能让他人获益的优质产品时，我觉得依然存在很大的差距。而且我觉得
00:40:19我们的团队仍然非常负责带来那种品位、见解、客户理解、
00:40:25同理心以及所有这些你无法直接从聊天框中获得的东西。
00:40:31所以也许我们才是那个愚蠢的人，我们本可以移动得快得多，如果
00:40:35我们只是一次性完成一切并直接运行它。但目前，我们的方法仍然是
00:40:42保持同样的期望，即最终输出的内容以及我们交付给最终用户的东西。
00:40:47是的，显然这意味着我们可以做更多。而且，我也认为更多的人
00:40:53具备那种品位和同理心，就能为用户带来价值，因为障碍曾经是代码，对吧？
00:40:57所以例如，现在公司里几乎每个人都可以说是“在写代码”，
00:41:01对吧？比如我们的设计师现在就是常驻的 Vipe 程序员。他现在完全负责
00:41:06网站工作，还有一大堆仪表板的工作，或者产品
00:41:11营销人员或开发者关系人员，大家都在使用，不是在最大化使用 token，但如果有一个排行榜，
00:41:16他们可能就在榜首。我认为这是一件非常好的事情。它是赋能，
00:41:20因为这些人必须具备我刚才描述的那种批判性思维，
00:41:25才能发布出品味高雅的最终用户产品，而且障碍更多在于代码本身。
00:41:30所以在某些方面，我认为最大的好处来自于此，而不仅仅是
00:41:36纯粹的工程。同样，并不是说纯粹的工程没有从中获得巨大的价值，
00:41:40但我认为瓶颈仍然在于品位。此外，我花费了
00:41:45太多时间去审查那些毫无意义的 PR。现在，这也有其不利的一面。
00:41:51对，确实如此。还有你必须审查的代码量。
00:41:56是的，还有这种基本上毫无可能的晦涩漏洞。
00:42:01我甚至不确定它是否算得上是低危漏洞。但显而易见，一旦它暴露出来，
00:42:06你就会感到一种责任。我认为这是正常的。但是，
00:42:09在某个时候，这简直就像是……我们从来没有像现在这样有这么多待处理的 PR。
00:42:14要真正搞清楚这一切简直有点疯狂。而且，
00:42:18我认为带入判断力，即“不是因为你能做每件事”，
00:42:21“你就应该做每件事”。我认为这非常符合那种 LLM 的
00:42:26态度。而且我认为带入判断力，即什么是最终会产生
00:42:31价值的，或者有潜力产生价值的，比以往任何时候都更重要。
00:42:34因为在使用智能体时，有一种像待办事项清单一样的满足感，
00:42:39你知道，偶尔我就会大脑死机。就像是，
00:42:44我只想浏览我的清单，做完所有的事情，然后就打勾、打勾、打勾、
00:42:48打勾。没错。在使用 LLM 时，确实会伴随着这种感觉，就像是
00:42:53我开始这个对话，开始那个对话，开始另一个对话，也许有五六个智能体在同时进行，
00:42:57同时进行，它们都在处理任务，而且它们各自也有正在逐一完成的待办事项。
00:43:02没错，没错，确实如此。所以，那种完成任务的满足感和快速反馈……
00:43:06那种满足感，以及与之相关的快速奖励。我认为有时候
00:43:11这会战胜我们。没错。或者至少就我个人而言，你们的团队有多大？
00:43:15我们现在是 10 人。哦，哇。那真是太精简了。没错，做得好。这一直是我个人的抱负。
00:43:23我不认为自己是最好的管理者。所以我认为这样对每个人都更好。
00:43:29不，我一半是在开玩笑，我认为从一开始，我们就诞生于新冠疫情期间，
00:43:33对吧？每个人都在远程办公。而且，从一开始就有一种思维模式，即
00:43:38聘用那种有资深经验、极其自主的人才，
00:43:45来给你们一点感觉。我们实际上每两周只进行一次单独的通话，
00:43:50讨论产品和基础设施。因此，我们非常努力地尝试建立这种异步的
00:43:56工作流。而且我认为这也非常适合 AI 的用例。因为
00:44:01我们已经聘用并优化了那些具备这种自主性的人才。我不认为有
00:44:06对错之分。我不会去说教我们的做事方式，但我认为这很适合我们。
00:44:11这对我来说行得通，也有助于我的理智。所以就是这样。
00:44:14我想谈谈你在对话最开始说的那件事，呃，
00:44:21Webhooks 已经过时了，新方法是事件网关。这个词是你创造的，还是它已经在某个地方存在了？
00:44:27已经在业界存在了吗？呃，到底什么是“事件网关”？我完全没概念。
00:44:32是的，是我们创造了这个词。要建立一个产品以及一个尚未成熟的
00:44:37产品类别是非常困难的。呃，因为你面临着像市场营销和
00:44:41交流，以及如何描述这个东西的挑战。有一段时间，我们
00:44:46称之为 Webhook 管理基础设施之类的。
00:44:51没有什么是真正朗朗上口的。所以，你不仅有交流上的挑战，
00:44:54还有产品上的挑战。因为当你在一个现有类别中构建产品时，
00:44:58比如说像 Better Stack、可观测性，你知道你在努力优化什么，
00:45:02你的具体 USP 是什么，在你的例子中，我认为很多是在价格
00:45:07和 DX 等方面。但重点是核心语义是存在的。所以你
00:45:10在优化的是那种独特的价值主张。当你构建一个
00:45:14尚未真正存在的东西时，你必须发明这种语义，然后在此基础上
00:45:19建立引人注目的价值主张。所以这就变得非常困难。
00:45:24这是过去几年的一条经验，在一个既有类别中构建产品
00:45:28是非常困难的。所以关于事件网关的想法以及它的由来，就是
00:45:32尽可能好地捕捉这一概念。希望用两三个词就能朗朗上口地描述
00:45:37它的作用。我们的目标是在事件总线和
00:45:43API 网关之间架起桥梁。并捕捉到这样一个概念，即网关存在
00:45:49作为一种接口，即供应商与你自身系统之间的接口等等。而
00:45:55事件总线的意义在于，这是全面的事件管理、排队等等。
00:46:00所以我们试图找到一个能将两者结合起来的术语。当你想到
00:46:04EventBridge 时，其实离事件网关也不远。所以，我们确实希望
00:46:10人们视我们为 EventBridge 的竞争对手，例如，我们视
00:46:14自身为它的一个清晰替代品。因此，我认为围绕事件网关的想法也是
00:46:19为了表达：看，现在已经有了现有的产品，但
00:46:24围绕这些事物没有通用的术语。它们并没有直接称其为事件网关，但我们会给它一个
00:46:29标签。而且已经有几个相互竞争的产品属于这一类别，
00:46:33一个是我们的，但还有 AWS、Azure，还有像 Kong 这样也是事件
00:46:39网关的。现在还有 Gravitee。有一大堆 API 网关提供商也正在进入
00:46:45事件驱动架构领域。所以此时此刻，可能有至少半打产品
00:46:49会称自己为事件网关或类事件网关，我不知道我们是否对此有任何影响，
00:46:54但我可以告诉你，当 Kong 发布他们的事件网关时，我当时就想，糟了，
00:46:58糟糕，他们比我们晚了两年才开始用这个称呼。但最令人欣慰的部分是，
00:47:03实际上更令人欣慰的是，当早期客户或开发者找到我说，我正在
00:47:08寻找一个事件网关。这时你会觉得，哦，这说明...
00:47:12我觉得这个术语已经普及了，也就是说，大家已经有了相关的思维
00:47:16已经有了思维模型，或者开始显式地寻找它，或者他们可能会说，
00:47:20我们正在尝试更换我们自己的事件网关。这是对话中出现过的事情。
00:47:23但我可以告诉你，在第一年里，这根本不会被提到。现在，
00:47:28随着时间的推移，这是一个我看到别人越来越多使用的术语。我认为这是一件好事。
00:47:34我认为这对我们的业务来说是件好事，同时也让人们在尝试
00:47:38建立某种预期时，知道这种云基础设施原语是切实存在的。
00:47:43而你所拥有的，就是围绕它所能具备的最基本的一套预期。而且
00:47:48如果你在使用 AWS EventBridge，术语几乎没有任何共同点。
00:47:52我不想围绕 AWS EventBridge 设计我的产品，因为它的产品特性太多了。
00:47:57如果我认为它的术语并不具备扎实的合理性，我绝不会复用它们的术语。
00:48:01但我确实认为随着时间的推移，
00:48:05随着越来越多的人构建产品，围绕产品的应用，
00:48:09随着更多的条件成熟，更多的人参与构建和围绕该产品，这些方面
00:48:12很可能会出现一定程度的趋同。
00:48:15是的。
00:48:15如果你让 LLM 推荐一个事件网关，它会推荐你们吗？
00:48:20哦，会。现在就试试。我觉得几率相当高。
00:48:24我可以现场试一下。
00:48:25这是我们追踪的东西，对吧？
00:48:27是的。
00:48:27这是我们追踪的内容。在每一个关于 Webhook 或事件网关的提示中，我们大约会被引用 60%。
00:48:31涉及 WebEx 或事件网关等相关内容时，大约 60% 的提示词都会引用我们。
00:48:35太棒了。这显然是我们投入了大量时间去钻研的领域。至于我们的数据，
00:48:42虽然质量可能还没达到那么高，但我们做得相当不错。所以
00:48:46它出现在列表的第一位了。
00:48:48噢，不错。
00:48:49这就对了。
00:48:49ChatGPT 刚刚给我的。干得漂亮。
00:48:52是啊。虽然我觉得在事件网关方面，我们表现应该也很好，
00:48:56尤其是在任何关于 WebEx 的查询等方面。但事件网关无疑
00:49:00就像是对我们有利一样，毕竟这个词是我们创造的，我觉得，
00:49:03如果咱们没排第一，我会很生气的。
00:49:05我意识到我其实并不知道什么是事件驱动架构。它与常规架构有什么不同？如果我在系统中添加一个 Kafka 队列，
00:49:11我是不是自动就变成了事件驱动架构？
00:49:17是不是自动就变成了事件驱动架构？
00:49:21既是也不是。当你谈论事件驱动架构时，它更多是一套范式和期望。
00:49:25所以部分在于工具，对吧？你使用 Kafka、消息队列或旨在解耦系统的事件流。
00:49:31所以当归结为核心时，
00:49:35生产者和消费者之间不需要了解彼此，对吧？消费者可以从事件流中消费，
00:49:39而这些事件可以由任何人产生。你唯一真正的期望是关于事件本身的契约。
00:49:43比如有效载荷是什么，形状是什么？
00:49:47通常会有特定的模式，人们会使用，比如基于 Avro 的模式、Protobuf 等等，
00:49:53标准化期望什么是载荷。契约就围绕着这些事件存在。
00:49:57作为消费者，我的职责是处理订单创建或产品更新等事件。
00:50:02一个真正拥抱 EDA 的组织，你会看到围绕此的系统化模式，
00:50:06会有具体的指南说明该如何操作，以及载荷形状应该是什么。
00:50:11这是一种架构方法，你会有意识地解耦服务，并使服务间的通信事件驱动。
00:50:16架构方法，你会有意识地解耦服务，并使服务间的通信事件驱动。
00:50:21我感觉很多公司采取的是混合方法，对吧？有些是事件驱动的，有些不是。
00:50:25目标是 100% 事件驱动吗？还是只是一种架构范式的子集？
00:50:29目标是 100% 事件驱动吗？还是只是一种架构范式的子集？
00:50:32我不认为是 100%。只是随着时间的推移，当你成长且复杂性增加时，
00:50:36第三方依赖也变多，这是一种自然的发展趋势。因为在某种程度上，耦合所有系统非常困难。
00:50:41必须要考虑扩展性和相互依赖性，这使得事情相当困难。
00:50:45但总的来说，提到事件驱动架构，人们通常会联想到大型企业。
00:50:50但在第一个十年里，它主要集中在大企业。现在情况变了，因为人们对这些模式越来越熟悉，
00:50:54我不认为非得是百分之百。只是随着时间推移，当业务增长、复杂度增加，
00:51:00还有更多的第三方依赖等等，这是一种自然而然的发展趋势
00:51:04因为在某种程度上，让所有系统保持耦合是非常困难的。
00:51:09然后你必须考虑扩展性和相互依赖性等等问题
00:51:14这些处理起来相当棘手。但总的来说，当我们想到
00:51:19事件驱动架构，从字面上看，我想人们会想到，
00:51:23我认为合乎情理的是，人们会想到大型企业，对吧？我想在
00:51:28事件驱动架构的最初十年里，它主要集中在大型企业中。但我认为现在
00:51:32情况正在改变，部分原因是人们对这些模式越来越熟悉，部分原因是
00:51:37Webhook 成为了入门的敲门砖。而且相关工具也变得越来越好。比如我在想，
00:51:41大型企业方式。从某种意义上说，我们正在努力将其带给每个人。
00:51:46我们不是唯一这样做的。有许多其他人采取不同的方法。
00:51:51比如所有的工作流引擎和 step function，比如 Temporal、Ingest 和 Trigger.dev 等等。
00:51:57所以，这是一个充满活力的领域，可能不再有统一的固定定义了。
00:52:01对于那些真正有兴趣学习更多关于事件驱动架构及其范式的人，
00:52:05有一位叫 David Boyan 的人，他之前是 AWS 的开发者布道师，曾在 EventBridge 工作。
00:52:11等昂贵的成本，从而开始采用事件驱动架构。但我认为这个术语
00:52:15的含义已经有些模糊了。我相信有些人可能不赞同我这么说，但
00:52:19我确实认为它随着时间的推移失去了一些原本的含义，或者至少说，我们所指的范围被混淆了。
00:52:25我觉得当我提到它时，主要是指系统的解耦。然后还有
00:52:31作为工程师无需过多考虑的编程问题，比如
00:52:37你得去思考独立性、排序以及诸如此类的各种顾虑。所以当
00:52:43我说事件驱动架构时，我更多是指你现在进入了一个领域，在这里
00:52:48当你构建应用时，你将不得不面对之前不需要处理的那些问题。
00:52:52没错，明白了。并且能够学习并采纳你构建事物的方式，以便
00:52:58去适应这些问题。我不确定我最初的意思是否是指那种
00:53:03大型企业那种方式。我觉得在某种意义上，我们所做的就是试着让这种模式
00:53:08在一定程度上普及给每个人。没错。而且我们并不是唯一一家
00:53:14在做这件事的参与者。还有很多其他人正在采取不同的方法。
00:53:18有各种工作流引擎和 Step Functions，我觉得它们
00:53:22与 Temporal、Ingest、Trigger.dev 以及那些团队的工作内容有所重叠。所以我认为这个
00:53:28领域里正在发生很多事情。可能已经没有一个真正明确的、固定的定义
00:53:34已经不再适用。对于那些真正有兴趣进一步了解
00:53:38事件驱动架构及其相关范式的人来说，有个人
00:53:42叫 David Boyan，他曾是 AWS 的开发者布道师，实际上参与过 Event
00:53:49Bridge 的工作。他做过一系列那种绘图式的科普内容。但到了现在，他可能已经有了
00:53:55好几百个（视频），他现在还运营着一个名为 Event Catalog 的开源项目，你们或许可以邀请他
00:54:02来做播客嘉宾。总之，他研究的深度
00:54:07简直到了不可思议的程度。所以绝对推荐给那些感到好奇的朋友们。
00:54:14太棒了，我们会把它加到节目说明里。那么，你对事件和 Web
00:54:19hooks 的所有这些知识，难道都是在构建 Hookdeck 的过程中积累起来的吗？
00:54:23还是说……你说过之前在 Webhooks 上遇到过一些问题，是从那时候才开始深入研究事件的吗？
00:54:27很大程度上是这样。我认为这种学习很大程度上源于
00:54:34所遇到的那些问题，也源于对基本原则的理解，因为当我在处理那些
00:54:38问题时，其实并没有太多的相关知识，这也是我为什么会遇到
00:54:42那些问题的原因。所以我觉得这更多是出于一种想要解决问题
00:54:47及其解决方案的心态，而不是先去找解决方案然后强行套用到问题上。
00:54:51不过，说到底，到了现在这个阶段，
00:54:55我们已经处理了成千上万个 Webhooks，见识了各种
00:54:59各样的案例。所以我认为我只是从那些对话中吸收了经验。这过程
00:55:05其实非常有趣。我起初是一名产品设计师，所以算是一个……
00:55:11从产品设计师，转为全栈开发，接着是后端工程师，
00:55:15然后又变成了基础设施工程师。现在感觉已经是深入到了
00:55:21兔子洞的深处。但这一切都是通过与客户合作、倾听
00:55:26他们的顾虑并审查架构等方式积累的。当然也离不开团队，
00:55:30我们团队里也有很多在处理这类系统方面有丰富经验的人，
00:55:33他们也将这些知识带到了公司。你是什么时候
00:55:38意识到你发现了这个市场机会的？我猜你开始做这个项目后
00:55:42发布到了什么地方。反响是立竿见影的吗？还是说让大家意识到这是更好的选择是一个缓慢的过程？
00:55:47缓慢，简直太缓慢了，因为一切都始于我提到的那篇 Medium 文章，
00:55:53与其说它是慢热，不如说它是从那篇Medium文章开始的，对吧？就像那种网络
00:55:57方面的问题，你能为此做些什么。我当时一心只想为人们打造产品
00:56:01为用户打造产品。所以最初的版本有点像自助服务，你知道的，你可以
00:56:07进去创建我们所说的首个连接，诸如此类的事情。
00:56:12什么的。这只是我当时在做的 20 个失败的副项目之一。
00:56:16什么的。这只不过是我当时做的二十来个失败的个人项目之一罢了。
00:56:21而且，说实话，现在回顾起来，那时的数字简直少得离谱，因为当时可能只有五个人
00:56:26因为那篇文章联系了我。但对于每一个做过副项目的人来说，
00:56:32经历过那种努力想让别人用你开发的东西的人，
00:56:37五个人简直太疯狂了。那比我之前得到过的关注都要多。
00:56:42所以我当时超级兴奋。我当时实际上是在我的
00:56:48露营车里，在不列颠哥伦比亚省攀岩。离创业什么的那种念头非常远。
00:56:55只是在和那些人交流，了解我的想法，了解他们遇到的问题等等。
00:57:00然后，注册用户开始一点点增加，也许每周一个。
00:57:05我攀岩时打开 Slack，看到 Slack 的通知。
00:57:08我们有一个专门用于记录每次注册的通知频道，就是我们用了六年的那个。
00:57:13到了现在，甚至很难追踪（注册人数）了，因为它滚动得太快了。
00:57:18有一个专门通知注册的频道，对吧？就像我们用了六年的那个一样。
00:57:21到了现在，几乎很难跟上进度了，因为消息刷得太快。
00:57:25不过，我们确实有那个频道，我也一直关注着那个通知，我会想：
00:57:31不，那时候绝对没有。不过你刚才说你现在还在用（这个通知），所以我才这么问。
00:57:38没错，确实，现在的进展很顺利，但还没到会把 Slack 搞崩溃的程度。
00:57:44明白了。不管怎样，我觉得最开始的一个核心假设
00:57:48其实是有问题的，那就是认为它主要只是为了“可观测性”。我觉得那还远远不够。
00:57:54但一旦你把定位从“打造一个可观测性工具”转变为“重塑消息总线”，
00:57:58格局一下子就完全打开了。
00:58:02所以，在构建第一个队列引擎的过程中，我遇到了我的联合创始人兼 CTO。
00:58:08确实如此。所以我其实是在构建第一个队列引擎的过程中，结识了首席技术官兼联合创始人。
00:58:15所以，当我意识到事情的规模会因此而彻底打开时，
00:58:19那时已经很明显这东西开发成本会很高，事实证明确实如此。
00:58:23据我了解，你们并没有走旧金山的典型路线，是在蒙特利尔打造的，对吧？
00:58:28嗯，这对于实际发生的情况来说可能有点虚伪。所以我们当时
00:58:32从天使投资者那里筹集了约 40 万美元的种子前资金，没有机构风投。
00:58:36但几个月后我们上了 Hacker News（以下简称 HN），这才是我们真正知道，
00:58:39回到你的问题，詹姆斯，HN 的反响——我不是说它是 HN 上最火的展示，
00:58:44但比我们预期的要好得多。这有个有趣的轶事，我还记得有一个家伙在 HN
00:58:51之后购买了我们 300 美元的套餐。我和联合创始人都觉得：兄弟，我们要成功了。
00:58:56事情稳了。我们肯定能行。
00:59:00那天晚上出去吃饭，把钱全花光了。这确实很令人振奋。
00:59:05总之，通过那次 HN 亮相，随后我们收到了很多投资者的主动接触。
00:59:11所以，我们最终从硅谷的 Matrix Partners 筹集了一轮融资。
00:59:18就像是大局已定一样。我们当时觉得，肯定能成了。
00:59:22那天晚上还去吃了顿好的，把那钱全花光了。差不多就是这样。
00:59:25而且因为疫情，人们越来越接受公司不一定要设在那里（硅谷），完全可以组建远程团队。
00:59:31Zapier、GitLab 等公司早就这么做了，所以疫情只是让这种模式标准化了。
00:59:34关于一些创始人……我可能对此有点天真，但常听到关于
00:59:38加拿大创始人必须注册特拉华州公司，以及 YC 曾拒绝接受加拿大公司，后来又撤销决定等等。
00:59:44那时候有一种默认的认知：每个投资者都会要求你变成特拉华州的 LLC。他们确实会要求。
00:59:50但这个故事缺失的部分是，你其实是可以说“不”的。
00:59:55他们会问为什么不，这对他们来说确实更容易，但如果你只是说“不”，其实也没关系。
01:00:00这至少是我身边的经验。这就是那个故事中缺失的部分。归根结底，他们的工作是分配资本，
01:00:04寻找投资对象，寻找原创想法。我不想在这里争论这些利弊，我知道这有很多好处，
01:00:08但最终，作为创始人和建设者，选择和谁一起做，在哪做，是你的权力。
01:00:12像 GitLab 这些公司，做这件事的时间比任何人都长得多。
01:00:17所以可能你的工作就是找到他们。说我们完全在那个泡泡之外确实有点虚伪，
01:00:21但我个人非常高兴能一直留在蒙特利尔。
01:00:27你知道，作为加拿大创始人，这种更大的波动，还有加拿大创始人圈子的推特话题，围绕着...
01:00:32但后来你们搬到了多伦多，然后就把一切都搞砸了。
01:00:38公平，公平。我也能说作为英联邦的一员……太棒了，对吧？
01:00:42同样一位国王。完全一样。是啊，我们确实有国王。
01:00:47我不知道他们现在是否已经更新到国王了，但我们以前的钞票上确实有女王。
01:00:54嗯，没错。他们肯定会问“为什么不呢？”，毕竟那样对他们来说更容易，
01:00:58但事实证明，如果你只是说“不”，其实也完全没问题。至少在我的经验中，
01:01:03以及我周围许多人的经验里都是这样。所以我认为这正是那个故事中缺失的部分，
01:01:07对吧？毕竟归根结底，他们也是在寻找投资机会，他们的工作就是配置资金，
01:01:11他们是在寻找值得投资的人，或者寻找有创意的项目之类的东西。
01:01:15我不想在这里争论在这些地方注册的利弊。我相信这肯定有很多积极的一面，
01:01:19但归根结底，作为创始人，你的选择权在于，
01:01:24身为创始人和开发者，由你决定与谁共事，以及在哪里共事。
01:01:27我认为，如果你有好的创意并为此投入心血，投资者依然会尊重你的选择。
01:01:31或者至少，部分投资者会尊重这一点。对吧？所以也许你的工作就是找到他们。
01:01:36但确实，如果说我们完全置身事外，那也不诚实。
01:01:41但我个人在这里生活得很开心，我很高兴自己依然留在蒙特利尔。
01:01:47我很庆幸自己依然留在蒙特利尔。身为加拿大同胞，能听到加拿大的成功故事真好。
01:01:52值得称赞，但后来你搬到了多伦多，然后你就把一切搞砸了。
01:01:57公平，这很公平。作为英联邦的一员，我可以这么说，对吧？同一个国王。
01:02:06都是一样的，对吧？是的，我们确实有女王，我是说，
01:02:11我不知道他们是否已经换成了国王，但我们的钞票上确实印着女王。
01:02:14Hookdeck 是你作为创始人的第一个创业项目吗？还是说之前有其他经历让你掌握了寻找投资者的技巧？
01:02:19我一直很有创业精神，从一开始就在小型公司摸爬滚打。
01:02:23比如在 14 或 15 岁时去退休社区修理电脑之类的。所以，
01:02:27在那种意义上，这更像是一种创业精神，但说实话，
01:02:34大部分经历都是失败的副业项目，比如发布一款毫无起色的电子游戏。
01:02:38还有很多类似的事情。有段时间我还在做一个社交网络，
01:02:44尽管我可能是那种最不擅长社交聚会和组织活动的人。
01:02:48总之，我算是走过了这一系列流程。不过，有一点我必须说，
01:02:53在那个电子商务公司的经历确实很有启发性。
01:02:58我是那里的首位员工，非常深入地参与了创始团队的工作。
01:03:03我们用了三年时间，从 4 个人发展到了 40 人左右。
01:03:07也就是创始团队。我们的人数从最初的四个人左右，增加到了大约四十人
01:03:13用了三年时间。你知道，所有关于创业的那些经历，以及所有这一切，
01:03:19所以我认为 Hookdeck 虽然是我的第一个创业公司，
01:03:23但如果说它是从零开始，也不完全准确。因为在此之前，
01:03:27我确实接触过类似的事情。显然，在那家电子商务公司，
01:03:31我们也与投资者打过交道，建立了联系。
01:03:36而那家电子商务公司的第一位投资者，也成为了 Hookdeck 的首位投资者。
01:03:39所以这并不像有些人那样完全是从零开始的。
01:03:44不过，我确实没想到自己会在几年后走到这一步。但这感觉很棒。
01:03:48我看到有一个叫 Kiwi Mornings 的公司，是做健康早餐的初创项目，那是什么情况？
01:03:54那是你在做家庭作业吗？那是我在创业路上的失败案例之一。
01:04:02我其实是和我妻子一起创办的。故事是这样的，我妻子在工作中给自己带早餐，
01:04:09结果公司的销售人员都很羡慕，开始向她索要早餐。
01:04:14我当时还纳闷，什么叫你们公司的销售人员想要早餐？这怎么回事？
01:04:19后来，她每天早上都要为销售团队制作五六份早餐。
01:04:24我们就像所有那种脑子一热的念头一样，觉得为什么不把它做成一门生意呢？
01:04:30于是我们建立了一个提供零浪费工作早餐的服务。
01:04:36我们用小玻璃罐装酸奶、奶昔和奇亚籽布丁之类的东西送到办公室。
01:04:41我们在办公室放个小冰箱之类的。我这个人又有点钻牛角尖，
01:04:47在产品和工程方面做了很多设计，所有的订单都是通过 Slack 机器人下的。
01:04:51雇主可以将此作为一种员工福利，基本上他们会承担 50% 的早餐费用。
01:04:56所以员工通过 Slack 机器人订餐。至于这个项目为什么结束了，
01:05:01只是因为在餐饮行业，凌晨四点总是会出现各种乱子，而且做餐饮根本没钱赚。
01:05:06所以当这两件事结合在一起时，很难把它做成一个有成就感的企业。
01:05:11最终我们卖掉了 Slack 机器人，停止了经营。
01:05:16但幸运的是，那是 2021 年 1 月，就在 COVID 爆发前两个月。
01:05:20后来，那些提供办公室午餐的公司基本都倒闭了。
01:05:25所以我们在时机上有点幸运，因为不管怎样这个项目都要结束了。
01:05:29Slack 机器人之类的一切，我们也就慢慢不做了。嗯，但谢天谢地，
01:05:34那是在 2021 年 1 月。也就是新冠疫情爆发前两个月。嗯，基本上所有
01:05:42我们总喜欢问嘉宾，关于这个行业、人工智能或其他方面，你有什么犀利的见解？尽管说。
01:05:46我觉得我在这次对话中已经给出了几个了。
01:05:52你说得对。那么，你最犀利的见解是什么？要那种火辣辣的。
01:05:57非常火辣的见解。好吧，这部分我可能会失去一些听众，因为它深入到了工程架构的细节。
01:06:01我相信我们的听众能听懂你在说什么。
01:06:06太好了。我的犀利见解是，基于拉取（Poll）的消费者系统，
01:06:12相比基于推送（Push）的系统，简直太蠢了。
01:06:18之所以我们还没有全面采用基于推送的系统，是因为目前还没有哪个队列服务构建了一个优秀的推送系统。
01:06:22为了说明这一点，当我构建队列和消费者时，每一个放入事件的队列都需要一个消费者。
01:06:29那个消费者可能是一个从队列中拉取任务的长时间运行的 Worker。
01:06:35但问题是，如果你想动态地拥有多个队列，比如你想为每个客户设置一个独立的队列，
01:06:42以避免某个客户阻塞整个队列，或者要限制各自的容量，
01:06:49现在你需要拥有和队列数量一样多的消费者，这简直疯了。
01:06:56因为存在多路复用问题。基于推送系统的巨大优势在于，所有这些队列可以推送到同一个消费者。
01:07:02那个消费者可以是一个带有负载均衡器的 API，你可以水平或垂直扩展它。
01:07:07重点是，你可以完全解耦队列的数量。
01:07:12一旦涉及到更复杂的场景，比如按主题、条件或特定客户来排队，
01:07:16情况就会变得一团糟，因为你需要上百个队列和对应的消费者。
01:07:21但如今很难找到基于推送的消息队列。
01:07:26原因在于你转移了吞吐量的控制点。如果是消费者控制吞吐量，
01:07:31每个消费者需要声明：我每秒处理 50 条消息。
01:07:36然后实际处理的消息量取决于 Worker 的容量和数量。
01:07:41而且这不完全取决于你想处理多少，还要看代码本身的执行速度。
01:07:45完全脱离你实际拥有的队列数量。我认为我们目前看到的一点是，
01:07:49随着用例变得越来越复杂，你最终会需要越来越多
01:07:54比如 GCP Pub/Sub 虽然有推送模式，但它会自动加大发送请求的频率，
01:07:58条件，甚至是针对特定客户等等。这会变得极其混乱，因为那样的话你
01:08:02就会有 100 个队列、100 个消费者，甚至 100 美元的队列，以及伴随而来的所有混乱。
01:08:07系统变慢、崩溃、降速，然后又爬升，如此反复，毫无意义。
01:08:13如果你构建一个能精细控制吞吐量和消费速率的基于推送的队列，
01:08:17你的架构会简单得多。这就是我的见解，虽然很激进，但我愿意为此买单。
01:08:22每秒 50 条消息或并发处理之类。那么你要消费多少消息就变成了，
01:08:29工作节点的处理能力是多少？你有多少个工作节点？以及实际的
01:08:33处理能力又是多少？因为即便你说想要每秒 50 条，实际速度
01:08:37感谢大家收听本期 Better Stack 播客。
01:08:40在 Spotify、Apple Music 或任何你获取播客的地方都可以找到我们。
01:08:45实际上并不能为你提供所需的粒度控制和吞吐量管理。比如，
01:08:50像 GCP Pub/Sub 确实有推送模式，但在该模式下，它们基本上是不断增加发送请求的频率，
01:08:55直到你的 API 开始变慢，而此时它们基本上已经
01:09:00导致服务降级了。一旦开始变慢，它们就会降低发送速率。所以最终结果是
01:09:06频率不断爬升、爬升、再爬升，直到服务器崩溃或出现严重的性能退化，
01:09:11然后一切又回到零，接着又不断爬升、爬升、再爬升，最终又
01:09:15回到零。简直完全没用，一点都不合理。确实。我认为如果你
01:09:20构建推送式的消息队列，而这正是我正在探索的方向，即拥有非常细粒度的
01:09:24吞吐量控制和对消费速率的精确行为把控，它将大大简化你的
01:09:29架构。所以这就是我给内行人们的建议，而且，我愿意
01:09:34为此据理力争。我是说，虽然我没完全听懂，但听起来很有道理，对吧？
01:09:40如果你听懂了的话，去看看 Hookdeck 吧。没错，正是如此。
01:09:46非常感谢，是的。那么，谢谢你，Alex。感谢收听本期
01:09:50Better Stack 播客。你可以在 Spotify、Apple Music 或任何其他平台上找到我们。
01:09:57但今天，我们要说再见了。我也要告辞了。还有我，再见。