超越 HTTP API：Web Assembly 和系统集成的未来

25 年多来，我们一直在为系统集成构建 HTTP API。Roy Fielding 在 2000 年提出了 REST，虽然我们的架构更加多样化，但有一个共同点：网络。

这些通过互联网将人、软件和设备连接起来的网络是真正的技术奇迹。我们已经设计出令人难以置信的方法来使用它们。我们使用流媒体播放内容、购买杂货、叫车，并促使功能越来越强大的人工智能系统回答我们的问题，然后人工智能系统会提出更多的网络请求，以满足我们的需求。

在集成或扩展软件系统时，网络允许完全解耦的对等系统交换数据并协同工作，来回传递信息。系统 A 通知系统 B，系统 B 在分析新数据并决定下一步行动后，需要更新系统 A 中的数据，并调用一些额外的应用程序接口。这两个系统的维护者只需选择一种传输编码（REST、GraphQL、gRPC 或其他），并就该编码定义的接口达成一致即可。

如果您正在阅读这篇文章，您可能已经构建了类似的系统，或者肯定使用过类似的系统！这是一种久经考验的应用程序接口架构模式，对我们非常有用。

但是，如果没有呢？

当系统 A 和系统 B 之间的网络延迟开始增加时怎么办？从 A 到 B 在互联网上发出十几个请求并不是免费的，即使是光速也比不上跨越美国的 ~40ms。再加上授权时间、数据传输时间、连接重置时重新协商 TLS 的时间、线路阻塞时间和重新连接时间：这些时间都不算系统 A 或系统 B 计算工作的实际时间！

图 1.基于 HTTP API 的复杂集成，需要多个跨系统请求。

当法规影响数据去向时怎么办？如果系统 A 在欧盟，系统 B 在美国，数据能否从 A 转移到 B？我的系统如何跨越这些界限进行整合？即使在同一法律管辖范围内，金融机构也要考虑敏感数据的管理和外流问题。集成商真正感兴趣的数据不太可能通过 HTTP API 流出。

但是，为什么我们可以承受这种成本呢？现在，这种分离可以帮助我们在多个小型工程师团队之间扩展大型系统的构建。它通过减少工程师对其他团队的信任度，来缩小他们必须达成的协议范围。安全、隔离和冗余问题可以在网络层面解决。

我们之所以付出代价，是因为我们没有更好的工具来构建系统。

进入 Web Assembly

WebAssembly (Wasm) 诞生于浏览器，是万维网联盟（W3C）的一项标准，它使在网络上运行用其他语言编写的代码和 JavaScript 成为可能。现在，网络应用程序可以以接近原生的速度执行紧凑、高效的二进制模块，从而使 Photoshop 和 AutoCAD 等复杂的桌面软件能够在浏览器中运行。Wasm 成功的关键在于它的安全模型，默认情况下，它不允许任何代码进行网络请求、读写文件或掌握周围主机环境的任何信息。Wasm 在完全隔离的沙盒虚拟机中运行，只能在主机允许的范围内运行。

这对应用程序接口和系统集成意味着什么？

几年前，Wasm 摆脱了浏览器的束缚，并多次作为独立虚拟机实现。这意味着 Wasm 模块可以在虚拟机能够运行的任何地方运行：台式机、游戏机、服务器、物联网设备、边缘平台，甚至电视和智能手表。在服务器应用程序中嵌入式运行 Wasm 意味着任意、不受信任的代码可以在我们的软件中安全执行，在进程中运行动态代码。

事实证明，Wasm 并不是要将其他语言的功能带到浏览器中，它真正的优势在于将浏览器的功能带到您的语言中。

让我们重温一下上面的场景，系统 A 和系统 B 通过 HTTP API 集成。如果系统 A 可以运行系统 B 的代码，但只运行处理集成所需的部分，而不需要在互联网上跳来跳去，会怎么样呢？这里有一个简单的理论想法来说明这一点：

1. Stripe 收到 Acme Corp. 客户的信用卡收费请求。
2. Stripe 加载 Acme Corp. 的 Wasm 插件来调用该before_charge_action函数，该函数返回有关购买的一些数据。
3. Acme Corp. 的插件必须首先在 Stripe 的 API 上查找客户的过去购买记录。由于插件仍在 Stripe 中，因此这是一个本地函数调用 — 无需互联网！这只需5-7 纳秒即可完成！（作为参考，40 毫秒的洲内跳跃是 40,000,000 纳秒。）
4. 通过购买数据，插件继续运行并检测到过去 30 天内已经进行了 10 次类似的购买。
5. 因此，该插件被编码为在客户下次购买时发送一封包含忠诚度折扣的电子邮件，因此它会对 Stripe 进行另一个函数调用以获取电子邮件地址和客户姓名（在 Stripe 的数据库中管理）来填写电子邮件模板。
6. Stripe 已经send email为插件提供了功能，因此它可以传递电子邮件内容并直接从 Stripe 的高可靠性电子邮件服务发送。
7. 插件将数据返回给 Stripe，扣款成功。紧接着，客户在收件箱中看到一封友好的折扣电子邮件。

图 2.复杂的 Wasm 插件集成，类似于图 1（上）中系统 A 和系统 B 之间的流程，但所有逻辑都是事件发起方（如 Stripe）的本地逻辑。

我们无需在两个系统之间通过互联网调用任何应用程序接口（API）就能完成所有这些工作。在支付交易过程中执行可能需要很长时间的本地函数调用只需几纳秒。此外，所有交易信息和客户数据都保留在 Stripe 的服务器上，没有外泄或 PII 意外泄露的风险。

真实世界的 WebAssembly 集成

事实上，如今很多这样的系统都是这样工作的，使用 WebAssembly 支持安全的客户代码执行。Figma 是一款广受欢迎的设计工具，用于创建高保真网络和移动应用程序模型。Figma 在 Wasm 运行时内运行第三方插件代码，使客户能够自由扩展软件的新特性和功能，而无需 Figma 介入和处理功能请求。Figma 同时拥有网络和桌面应用程序，那么插件开发人员是否必须为每个平台实施一个插件？不会！Wasm 在这些平台上的运行方式完全相同，因此无论 Figma 在哪里运行，相同的插件都能正常工作。

Shopify 是这种集成模式的另一个杰出实施者。这家电子商务市场的领导者多年来一直在生产中运行 Wasm，为其下一代应用程序市场提供支持：Shopify Functions。开发人员可以构建插件，商家将其安装到自己的商店中，直接在 Shopify 的基础设施中运行。这为平台提供了更深层次的集成访问，而且由于没有网络延迟，集成运行速度很快，即使在结账路径中也能注入自定义行为，而在结账路径中，每一个微小的延迟都可能意味着销售损失。

好处不仅限于集成速度和深度。与通过 HTTP API 相比，Shopify 还可以直接在平台上提供更多定制服务，从而保护客户的利益。最近，一家 Shopify 应用程序开发商承认发生了一起严重的数据泄露事件，暴露了从使用其应用程序的商家那里收集到的 Shopify 客户数据。由于这些应用程序调用 HTTP API 并将客户数据存储在第三方服务器上，Shopify 无法控制该开发商的安全态势。使用 WebAssembly 插件将所有第三方代码保存在 Shopify 上，意味着他们对类似情况的控制能力大大增强，从而避免了这次不幸的泄漏事件。

HTTP API 将数据转移到计算环境中使用，而 Wasm 则实现了革命性的转变，将逻辑转移到数据环境中。将数据静止和逻辑移动的关系颠倒过来，可以实现新的集成，而我们才刚刚开始利用这种关系。

期待

HTTP API 不会消失，也不会很快消失。但是，新技术和新的系统集成方法的出现，意味着是时候考虑一些替代方案，或研究如何逐步改善现状了。将 Wasm 的安全性和速度引入您的集成架构有很多好处，我们看到其采用率正在迅速上升。

当您考虑创建更安全的集成 API 时，请考虑 WebAssembly。您的客户将非常欣赏 WebAssembly 为您的平台带来的灵活性和易集成性。可以说，Wasm 在应用程序接口和系统集成领域还处于起步阶段，但它已经在大大小小的公司中证明了自己的价值。

原文链接：Beyond the HTTP API: WebAssembly and the Future of Systems Integration