面向应用通信的 API 与消息传送的区别

Phil Wilkins | 甲骨文公司云技术开发人员倡导者 | 2022 年 12 月

软件需要与其他软件沟通。有时,在一个应用中,其中一部分的软件需要向另一部分的软件请求服务或与其交换数据。或者,一个应用必须向另一个完全不同的应用请求服务或与其交换数据。

这类通信使用两种典型机制:应用编程接口 (API) 和消息传送。

人们有时会混淆 API 与消息传送。这是因为这两个术语经常被混用。API 这个缩写本身具有外显含义,但由于种种原因,该术语已经衍生出几种不同的含义,我们将在稍后深入讨论。消息传送则是一个经常使用的广义术语,几乎涵盖了任何系统与系统之间的通信。接下来,让我们清楚认识 API 和消息传送的真正含义。

API 的详细定义

从广义上讲,API 是定义软件如何接收和响应服务请求的合约。该合约由软件的开发者设置。

听起来很简单,对吧?这只是一个层面。在实践中,API 的内隐含义会根据主题和语境而改变。如果我们将这个缩写拆开来看,API 指的是软件与软件之间互动所使用的接口或“合约”。有时,API 表示其高层次架构的定义;有时,API 的含义非常细化,用于详细说明开发者实施 API 的具体方式。

某些关于 API 的书籍和文章将 API 比作一扇门,并用 API 的特性来描述这扇门。例如,API 可以是一扇杂货店的自动门,也可以是一扇非常安全的银行金库门。应用的合约就相当于是这扇门的特征,具有以下几个考量因素:

  • API 在高层次上可以做什么?如果把 API 比作一扇门,它是否会为客户开门,无需客户停下来触控操作(杂货店的门)?还是用于控制访问,保护门后的东西(银行金库的门)?
  • API 需要支持哪些有效负载(传输的数据),以便软件能够顺利运行?例如,软件可能会收到一个银行账号和安全授权,并返回该银行账户的余额。
  • 执行服务需要交换哪些数据?例如,您需要准确地定义有效账号、安全授权和响应内容。这里的细节很重要;如果定义不清楚,就可能导致错误。
  • 这扇门的地址是什么?一般上,这意味着请求的通用资源标识符 (URI) 是如何形成的。也就是说,请求方实际上是如何与 API 通信的?
  • 哪些协议将用于通信?这些协议包括从常见协议(如 HTTP 和 FTP)到特殊协议(如 STOMP 和 QUIC)。
  • API 用户必须遵守哪些条款和条件?这些条款和条件包括加密细节、API 调用频率限制或商业服务的计费机制。
  • API 有哪些承诺?该承诺可能包括 API 在服务层面的保证,例如在特定时间段内确认或执行请求。

定义应用开发中的消息传送

API 定义软件如何发送和接收服务请求,而消息传送则是将信息从一个系统发送到另一个系统的进程。这里的关键词是“进程”。

您可以这么思考:

  • 消息传送指的是将一些信息碎片从服务请求方传送到服务提供方(通常使用被称为代理的第三方)的进程。

    如果用现实世界作比喻,消息传送就像是企业向客户发送短信。服务提供方必须知道接收方的电话号码,以便移动运营商能够发送该消息。然而,从运营商的角度来看,有效负载可以是任何东西。运营商不需要知道您的短信写的是英语、西班牙语、日语还是一个表情符号。

  • 消息传送指的是将消息从发送方发送给客户的所有幕后操作。

    您和您的客户不需要了解消息传送进程是如何运作的;您只需要相信运营商和智能手机制造商会正确完成他们的工作。同样的,运营商也不需要了解有效负载;他们只需要确保将其发送给正确的人,并且不出现乱码或失真的问题。

值得再次强调的是,只要有效负载符合技术要求,大多数消息传送平台并不关心有效负载。用我们的比喻,就是智能手机和移动运营商并不关心您的短信中是英文还是表情符号。

详细了解有关 API、API 平台和 API 管理的组成部分。

API 和消息传送如何在企业系统中协同工作

企业软件系统是由多个独立的可执行进程构建而成,因此需要进程间通信 (IPC)。这里的通信可能很复杂,需要通过许多 API 调用来回执行大量经过严格格式化的数据,以完成事务处理。这些事务处理必须经过仔细编制,并按正确的顺序完成,以满足业务需求。

例如,您可以想象客户的采购订单。这个进程需要访问客户数据库;查询库存数据库、会计系统、发票生成系统和信用卡收费系统;调整库存和客户账户;创建仓库请求;以及发起运输请求 — 所有这些都必须按照正确的顺序完成。

以前,这些互动需要通过某种形式的共享存储来完成,例如文件系统或数据库。然而,在更现代的企业系统中,这些进程可以直接相互通信,加快了进程并排除了问题(例如您的订单的库存已经被之前的订单所占用)。

同步和异步行为

我们可以根据通信的性质将其分为同步或异步两大类别。同步通信意味着通信所涉及的各方都必须在场,并且能够重新发送。在我们的订购示例中,电子支付所涉及的系统必须可以进行实时交互。在其他情况下,通信可以是异步的,需要进行通信的系统各方不一定要同时在场。这就和我们互相发送电子邮件一样。对于异步通信,我们需要通过中介来回传递信息。

复杂的企业消息传送系统具有不同的种类或模式:

  • 服务总线:服务总线 (service bus) 充当不同进程之间的粘合剂,并在这些流程之间进行编制工作,例如前面提到的复杂事务处理。服务总线系统一般包含增值功能,例如将有效负载从一种格式转换为另一种格式的功能(用短信做比喻,就是将英语转换为法语),根据消息内容传送消息,甚至是基于复杂事务的状态做出决策。例如,任务 A 和任务 B 可以并行完成;如果任务 B 已完成,则执行任务 C;如果任务 B 失败,则执行任务 D;如果任务 D 失败,则进行人工干预。

    服务总线式的消息传送有时也称为使用智能管道 (smart pipe),因为其在提供方和消费方之间的“管道”中的消息传送路由和调度方面添加了智能。这也称为编制 (orchestration)。

    以下是服务总线示意图和说明消息提供方调用提供消息的服务总线。然后,服务总线将获取消息并将其传送给消费方。在传送的过程中,消息可能会受到转换逻辑和筛选的影响。

    服务总线的同义词是消息总线 (message bus)。当这些技术刚刚发展成为面向服务的架构 (SOA) 解决方案时,消息总线和服务总线还有些许区别。今天,两者并无实质性的不同。实际上,它的名称正逐渐缩短成总线 (bus)。

  • Web 服务:在广泛的意义上来说,Web 服务代表着两个进程之间的直接同步通信,通常使用 TCP 和 HTTP 协议(或变体,如 HTTPS 和 HTTP/2)。消费方和客户端以点对点的方式连接在一起(尽管提供方端通常需要支持多个并发的客户连接)。两个进程之间可能会有代理(包括从网络防火墙到 API 网关和网络缓存)和网络(如交换机和路由器)中介,但提供方和消费方都不会察觉到它们的存在。

    以下是 Web 服务示意图和说明消息提供方直接与消费方进行通信。传输进程取决于双方是否可用。
  • 消息代理:消息代理 (message broker) 是消息提供方与消息使用方之间的中介,与服务总线和 Web 服务均有共同点。

    代理位于消息的发送方和接收方之间,能够接收消息并进行存储,直到接收方消费该消息。这意味着消息传输可以顺利完成,而无需担心接收方的即时可用性。因此,这种通信方式常常又称异步的或“发后即忘”(fire and forget) 的方式,因为您可以保证,只要代理持续运行,消息就一定能够在某个时候传递到位。

    与 Web 服务相似的是,客户端和代理之间是一个点对点的连接;消息代理在功能上是隐藏的。

    与服务总线的相似之处在于,代理提供增值服务,因为它可以在收件人可用之前保存收到的消息。与更强大的服务总线不同,消息代理的智能水平较低,只能理解简单的事情,例如哪些目标可能希望接收特定消息、目标无法及时消费消息时应该采取什么措施。

    经过代理的通信样式也称为具有哑管道 (dumb pipe)。由于代理所具备的智能水平较低,因此需要通过端点来了解发送或接收消息时需要哪些条件。此样式也称为编排 (choreography)(与服务总线更智能的编制恰恰相反)。

    以下是代理示意图和说明消息提供方将消息提供给代理。然后,代理将保存消息,直到使用方请求获取消息或能够收到消息。提供方不依赖于使用方。

流处理在企业消息传送中的作用

在此讨论中,流处理可以被视为一种专门的消息传送形式,尽管某些流处理技术可以支持数据处理的元素。流处理在此处指的的是通过 IPC 技术向相同目标发送连续事件流的行为,无论 Web 服务或消息代理是否实施通信。(此处很少涉及服务总线,因为数据过多,流量过快,不需要服务总线的额外智能。)

除了数据流的连续流动,流处理通常也需要具备接近实时或低延迟的连接。想一想那些传统的视频流服务(例如 Netflix),这一点也就不奇怪了。在提供方发送新的视频片段时,或者在消息代理将视频从一种格式转换为另一种格式时,您当然不希望视频播放断断续续。

Web 服务流处理的常见技术是 WebSockets、gRPC 流和 GraphQL 订阅。当涉及到经过代理的消息传送流(使用技术,如 Kafka)时,您有时可以利用代理的工作方式来查看传输事件的“分片”。这有助于您收集宝贵的洞察,包括有关流本身的信息 — 这就是流分析 (streaming analytics)。

虽然流分析的逻辑可能很复杂,但消息代理并不进行决策或消息操作;这就是为什么代理仍被视为是“哑巴”的原因。这类流分析功能一般通过技术来实现,例如 Kafka Streams。

API 和消息传送行业标准

API 和消息传送系统简单易懂,但在其细节上和技术特性方面却非常复杂。这两者不能被混淆,因此需要准确的行业标准和文档,并良好地应用这些标准。

十多年来,这一直是个不断发展的领域,特别是对 API 而言。业界已经采用了面向基于 REST 的 API 的 OpenAPI 规范,这是一种 Web 服务的形式,也是现代企业软件中很常见的 API 类型。

在使用 API(和流处理)时,您可以使用一些额外的标准来定义和描述消息及其传输的各个方面。这些标准包括协议缓冲区(也称为 Protobuf,与 gRPC 一起使用)以及最近的 GraphQL、JSON Schema 和 YAML。

这几年来,在异步消息传送领域中,AsyncAPI 深受关注,并取得了突破性进展。AsynAPI 结合 OpenAPI 的构思和其他不断发展的标准,旨在满足各种消息传送要求。

现代分布式应用作为一个服务集合来实现,这些服务是单独的软件片段,有时运行于相同的服务器上,有时运行于不同的服务器上。API 为这些软件片段提供了一种相互通信的方式来请求服务或交换信息。消息传送系统提供基础设施来促进异步通信,并为 API 调用提供智能中介,这可能非常简单(例如智能手机中短信的工作原理),也可能非常复杂(例如编制复杂的多步骤业务事务处理)。更不用说使用 API 直接通信的分布式服务了。值得庆幸的是,不断发展的技术和标准让我们能够在从数据库调用到流媒体的一切中使用 API。这些 API 和消息传送标准将持续发展和进步,以更快、更容易、更安全地完成现代分布式软件架构的过渡。

注:为免疑义,本网页所用以下术语专指以下含义:

  1. Oracle专指Oracle境外公司而非甲骨文中国。
  2. 相关Cloud或云术语均指代Oracle境外公司提供的云技术或其解决方案。