文章概覽

應用程式通訊的 API 與訊息傳遞之間的差異

Phil Wilkins | Oracle 雲端開發人員技術傳播者 | 2022 年 12 月

各個軟體之間都需要對話。有時，應用程式中的軟體需要請求服務，或與應用程式的其他部分交換資料。或者，某個應用程式必須請求服務，或與另一個完全不同的應用程式交換資料。

這些類型的通訊使用了兩種典型機制：應用程式設計介面 (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：Service Bus 的作用就像是不同程序之間的粘合劑，並且在這些程序之間執行協調處理，例如在上述提到的複雜交易中。Service Bus 系統通常包含加值功能，例如將有效負載從一種格式轉譯為另一種格式 (在簡訊類比中將英文轉譯為法文)、根據訊息內容遞送訊息，甚至根據複雜交易的狀態做出決策。例如，工作 A 和 B 可以並行完成；如果工作 B 順利完成，則執行工作 C；如果工作 B 失敗，則執行工作 D；如果工作 D 失敗，則進行人工介入。

Service bus 型訊息傳遞有時被稱為使用智慧管道，因為在提供者與用戶之間的「管道」中新增了訊息傳遞路線和排程的智慧功能。也稱為協調處理。

訊息提供者會呼叫 Service Bus 來傳遞訊息。Service Bus 會接受訊息，並將其遞送給用戶。在路由期間，訊息可能會受到轉換邏輯與篩選約束。

Service Bus 的同義詞是 Message Bus。這些技術當初發展成為服務導向架構 (SOA) 解決方案時，Message Bus 和 Service Bus 之間會有些許差異。如今，兩者之間沒有什麽差異。事實上，其名稱只是縮短為 bus。
Web 服務：從廣義上講，Web 服務代表兩個處理序之間的直接同步通訊，通常使用 TCP 和 HTTP 通訊協定 (或其他變化，例如 HTTPS 和 HTTP/2)。用戶與用戶端透過點對點連線來實現 (雖然提供者端支援多個並行用戶端連線是很常見的)。這兩個程序之間可能會有代理 (從網路防火牆到 API 閘道以及 Web 快取) 和網路 (交換器與路由器) 中介，但提供者和用戶都不會意識到它們。
訊息提供者會直接與用戶溝通。傳輸程序取決於雙方目前是否可用。
訊息中介：訊息中介是訊息提供者與訊息取用者之間的中介，且與服務匯流排和 Web 服務具有共通性。

中介常駐於訊息的寄件者與收件者之間，中介將收到通訊的訊息並加以儲存，直到收件者使用它為止。這表示可以在無須擔心收件者是否立即可用的情況下完成訊息的傳輸。因此，這種通訊通常被稱為非同步或「即發即棄」，因為只要中介仍然可操作，就可以確保訊息會在某個時間點傳遞。

與 Web 服務的相似之處在於從屬端和中介之間的連線表示為點對點連線；訊息中介在功能上是不可見的。

與 Service Bus 的相似之處則在於代理會提供加值服務，因為它可以保留收到的訊息，直到收件者可用。與更強大的 Service Bus 不同，訊息中介除了理解簡單的事情外幾乎沒有智慧功能，例如瞭解哪些目的地可能想要收到特定訊息，以及如果目的地沒有及時使用訊息該怎麼處理。

中介通訊樣式被稱為「笨水管」。由於中介只有很少的智慧功能，而且它需要端點瞭解在傳遞或接收訊息時所需的內容。此樣式被稱為編排 (與 Service Bus 的智慧型協調流程相反)。

訊息提供者會將訊息提供給中介。然後，中介會保留訊息，直到用戶要求獲得訊息，或用戶能夠接收訊息。提供者不相依於用戶。

串流在企業訊息傳遞中的作用

在本次討論中，雖然某些串流技術可支援資料處理元素，但串流還是可以被視為一種相當特殊的訊息傳遞形式。在此環境中，串流被視爲透過 IPC 技術將連續事件流傳遞至相同目的地的行為，不論通訊是由 Web 服務還是訊息中介來實現的。(很少涉及 Service Bus，因為資料太多，流動太快，需要 Service Bus 的額外智慧功能。)

除了串流中的連續資料流之外，串流通常還需要近乎即時或低延遲的連線。像是 Netflix 等傳統上被稱為影音串流的服務，就是很好的範例。您當然不希望在提供者發送新的影音位元，或在訊息中介將影音從一種格式轉換為另一種格式時，出現停止並重新開始影音內容的狀況。

Web 服務串流的常用技術有 WebSocket、gRPC 串流和 GraphQL 訂閱。在中介訊息傳遞串流時 (使用 Kafka 之類的技術)，您有時可以運用中介來查看傳輸事件的「片段」。這有助於您收集寶貴的洞察分析，包括串流本身的資訊，也成爲串流分析。

雖然串流分析中套用的邏輯可能很複雜，但訊息中介不會執行決策或操控訊息，這就是中介仍被視為「笨」的原因。這些類型的串流分析功能通常都會使用 Kafka 串流等技術導入。

API 和訊息傳遞的業界標準

API 和訊息傳遞系統聽起來很簡單，但其細節和技術特性卻非常複雜，絕不能有歧義，因此需要準確的產業標準和文件，以及理想地應用這些標準。

十多年來，這個領域持續發展，尤其是 API。業界已採用適用於以 REST 為基礎的 API 的 OpenAPI 規格 (一種 Web 服務形式)，可能是現代企業軟體中最常用的 API 類型。

對於 API (和串流)，有許多額外的標準用於定義和描述訊息及其傳輸的各個方面。其中包括通訊協定緩衝區 (也稱為 Protobuf，並搭配 gRPC 使用)，以及近期的 GraphQL、JSON Schema 及 YAML。

在非同步訊息網域中，過去幾年來已成功對 AsyncAPI 進行定義。這項定義藉鑒了 OpenAPI 和其他不斷發展的標準，以滿足衆多訊息傳遞需求。

現代分散式應用軟體作為獨立軟體的服務集合來實現，有時在同一台伺服器上執行，有時則是不同的伺服器。API 為這些軟體提供了一種相互對話的方式，以要求服務或交換資訊。訊息傳遞系統提供基礎架構，以促進非同步通訊，並為 API 呼叫提供智慧型媒介，這可能非常簡單 (智慧型手機簡訊運作的方式)，也可能極為複雜 (例如適用於複雜多階業務交易的協調)，更不用說使用 API 直接相互溝通的分散式服務了。幸運的是，不斷發展的技術和標准讓用戶能夠在所有層面使用 API，從資料庫呼叫到串流媒體。這些 API 和消息傳遞標準持續發展和進步，讓移轉至現代分散式軟體架構更快、更容易且更安全。