法学硕士正在打破 20 年前的系统设计

过去十年的“云原生”架构建立在 20 年前的假设之上：状态存在于数据库中，而计算是无状态的。如果您想扩展，您可以垂直扩展数据库（获取更大的机器）[1] [1]，或者围绕数据分区设计数据库架构，然后水平扩展应用程序服务器（添加更多框）。任何请求都可以到达任何服务器，负载均衡器并不关心，数据库是唯一的事实来源。法学硕士和代理人正在悄然违反这一假设，并使这种架构越来越难以使用。不是一次性完成，而是通过三种微妙的方式： 长时间运行的工作：执行 10 分钟任务的代理不是“请求”，而是一个长时间运行的异步流程。有状态计算：代理可能会运行多次对话，可能会处理多个工具调用，并依赖于累积的上下文。该状态并不是真正的“数据库状态”，而是代理的内存。双向交互：用户想要观察代理的思考、打断它并重定向它。这是与进程的对话，而不是对无状态 API 和数据库的查询。持久执行解决了部分问题持久执行（Temporal、Inngest、Restate）是业界目前对执行部分的答案。它使该过程持久且有弹性。但我们仍然假装它在底层是无状态的。这适用于执行，但不能解决交互问题。路由问题 HTTP + 负载均衡器 + 无状态服务器无法路由到特定进程。它只能路由到数据库。因此，当客户端想要与在持久执行框架中运行的进程进行对话时，您就会遇到同样的路由问题。所以每个人都会恢复投票。轮询查询端点以获取持久执行进程写入数据库的最新更新。这是一种通用的解决方法，但它仍然很糟糕，原因与民意调查很糟糕一样。关于轮询频率、数据库负载、浪费的请求、糟糕的流媒体用户体验的延迟选择。最终，轮询将您的数据库视为消息总线。这就是人们在实际的消息总线存在之前所做的事情。当您不知道如何解决您想要交谈的问题时，您可以进行轮询。这是解决路由问题的方法。缺少路由原语 关于我们如何构建 Web 服务的基本假设正在被打破。我们使用这种架构进行设计已经很长时间了，以至于我们忘记了它甚至是一种选择。但我们缺少 HTTP、负载均衡器和无状态服务器设计无法解决的基本路由原语。路由原语 可路由的传输名称，不是服务器。我们希望能够说； “将此消息传递给为工作流程 X 生成输出的任何人”。无需知道哪个盒子、哪个服务器副本、哪个进程。也许是 WebSocket？从上图可以看出，WebSockets 似乎可以很容易地放入标记为“路由原语”的框中。它们是支持长时间运行的双向连接的传输，并将服务器进程连接到客户端。但 WebSocket 有一个问题：它们是连接，而不是地址。他们通过在客户端和服务器之间创建直接连接来一次性解决路由问题。但如果该连接断开，“地址”就会丢失。您无法重新连接到同一进程，因为您没有可路由到的地址。这是发布/订阅频道 发布/订阅频道反转了所有权。服务器进程和客户端都不可寻址。传输是可寻址的。客户端和服务器都通过名称连接到发布/订阅通道，并获得双向、有状态的通信。通道是地址，与 WebSocket 不同，它不是连接。这是一个持久的通道，您可以断开连接并重新连接，而不会丢失数据或路由到同一进程的能力。用于持久执行的持久传输 回到临时示例，持久工作流活动（或步骤）将连接到以工作流 ID 命名的发布/订阅通道。客户端将连接到同一通道以获取更新，并发送中断或转向消息。工作流将是持久的，通道也是持久的，因此即使工作流进程或客户端连接断开，它们也可以重新连接到同一通道并继续相互通信。您不必通过数据库线程化数据，不必轮询，也不必担心无法处理实际正在执行工作的持久进程。这与法学硕士无关，尽管法学硕士只是让这个问题更加明显。以前，如果连接断开，请求的成本足够低，可以重试，并且您可能会得到确定性响应。当您可以期望对同一请求获得相同的响应时，重试会更简单。但对于法学硕士来说，情况并非如此。 LLM 的回答不是确定性的，而且并不便宜。如果您支付代币费用，则无需