別再管你的 API 叫微服務了

作者 | Lukas Rosenstock

譯者 | 無明

你有沒有聽過這句名言：「計算機科學領域只有兩個難題，緩存失效和命名」？據說這句話是 Phil Karlton 在 1996 年或 1997 年左右說的。圍繞這句格言確實出現了很多帶有喜劇色彩的說法，它們也提到了其他的一些問題，但最近我對 API 世界的觀察似乎證明了「命名」確實是個大難題：人們對「API」和「微服務」這兩個術語存在混淆，有些人似乎已經把它們混為一談了。

計算世界在不斷發生變化。開發人員使用各種概念和技術，並以不同的方式將它們連接在一起。因此，我們使用不一致的術語，用多個術語來描述大致相同的概念，或者用同一個術語表示不同的事物，這些情況並不罕見。

關於 API 和微服務：是的，它們是相關的概念，它們之間存在相互作用，但它們並不是同一種東西。所以，我想直截了當地說出我的看法！

什麼是 API？

API 是應用程序編程介面（Application Programming Interface）的縮寫。維基百科指出，「總的來說，它是各種組件之間的一組明確定義的通信方法」。它可以是軟體框架或庫的介面，也可以是操作系統為原生系統軟體（如 POSIX）開發人員公開的底層介面。

這也是 API 能夠如此令人感到興奮的一個方面，因為各種開發人員可以利用其他人構建和公開的基礎設施來增強其應用程序的附加功能。

現如今，當人們談論 API 時，他們通常指的是通過 HTTP 端點公開的遠程介面。為了區分這些遠程 API 和上面提到的本地系統 API，我將用術語「Web API」指代遠程 API。（雖然有些人將這個術語用來指代瀏覽器的本地 API——有點令人困惑，對吧？）

我們通過底層設計範式（如查詢、RPC 或 RESTful）或協議（如 SOAP、gRPC 或 GraphQL）進一步對遠程 API（或 Web API）進行分類。除此之外，我們還通過目標受眾來區分 API，將它們分為公共、合作夥伴或私有 / 內部 API。

API 的兩面性

嚴格來說，API 僅用來描述介面，也就是客戶端和伺服器、API 消費者和 API 提供者之間用於交換信息的語言。對於 API 消費者來說，API 只不過是對介面和端點 URL 或 URL 集的描述。URL 是 Web 的基本構建塊之一，客戶端可以在不知道伺服器性質或位置的情況下訪問信息或服務。只要客戶能夠收到響應，它根本不管 URL 是指向隱藏在某個地下室的 Raspberry Pi 還是位於某個大陸數據中心的全球交付網路。這也是 API 能夠如此令人感到興奮的一個方面，因為各種開發人員可以利用其他人構建和公開的基礎設施來增強其應用程序的附加功能。

但是，API 提供者不僅要設計、實現和文檔化 API，還要考慮它背後的基礎設施。在雲計算時代，可能不需要購買硬體和租用數據中心。相反，API 提供者可以選擇各種「XX 即服務」產品——從虛擬機或容器的託管集群到完全無伺服器的代碼託管環境。無論選擇了什麼樣的基礎設施，他們都需要部署 API。

我這裡說的部署 API 是指部署暴露 API 所必需的代碼和基礎設施。從提供者的角度來看，API 並不是一個神奇的大門，而是需要在某個地方運行的有形資產。而且，隨著公司轉向微服務架構，這種資產就會變成微服務或一組微服務。

什麼是微服務？

微服務是系統或應用程序中的自包含獨立組件。每個微服務都應該有明確的作用域和責任，理想情況下，一個微服務只做一件事。它應該是無狀態的或有狀態的，如果它是有狀態的，它應該帶有自己的持久層（即資料庫），不與其他服務共享。軟體開發團隊基於微服務架構以更分散的方式開發可重用的獨立組件。他們可以為每個微服務使用自定義框架、依賴關係集，甚至是完全不同的編程語言。微服務也有助於實現可擴展性，因為它們本質上是分散式的，並且每個微服務都可以獨立增長或複製。

容器和微服務

容器是在操作系統中建立隔離上下文的一種方法。實際上，這意味著它們中的每一個都有一個單獨的包含了一組已安裝的軟體和相關配置的虛擬文件系統。由於它們是相互隔離的，因此任何容器都不能直接訪問或影響其他容器或底層宿主操作系統。

創建容器的能力已經成為 Linux 操作系統的一部分，這種能力已經存在了很長一段時間，但直到 2013 年 Docker 的推出，容器才成為一種流行的技術。

當我們在談論定義時，需要注意的是微服務和容器其實是不一樣的東西，但這兩個概念經常被放在一起談論，就像 API 和微服務一樣。如果沒有容器，要麼把伺服器配置成可以運行多個微服務，讓這些微服務不可避免地相互產生負面干擾，要麼每個微服務都需要一個單獨的伺服器或自己的虛擬機，導致不必要的開銷。因此，微服務通常被部署在一組由容器集群軟體（如 Kubernetes）管理的一組容器中。可以肯定地說，容器和微服務的崛起其實是相互影響、相互促進的結果。

微服務之間的通信

基於微服務架構構建的應用程序或 API 不僅要把自己完全暴露出來，還需要在內部組件（微服務）之間建立連接。由於每個微服務都可以使用不同的編程語言實現，我們需要依賴標準協議（如 HTTP）來建立微服務之間的連接。這個時候我們就回到了 API 上。

最基本的形式是每個微服務都公開一個 API，讓其他服務可以向這個 API 發出請求並獲取數據。也可以使用其他不同的方法，比如消息隊列。微服務 API 是私有 API，僅限用在單個應用程序中。它通常不提供公共 URL，而是使用組織內部專用網路的私有 IP 或主機名，甚至是單個伺服器集群內的 IP 或主機名。不過，這些 API 可以遵循類似公共 API 那樣的設計範式或協議。而且，儘管它們的消費者數量有限，也應該遵循開發者體驗的基本規則。也就是說，它們應該擁有相關的、一致的、可演化的 API 設計和文檔，讓其他團隊（甚至是你自己）知道如何使用這些微服務。因此，你可以而且應該使用類似的工具來創建你的微服務 API。

當然，與更面向外部的 API 相比，在設計微服務 API 時有不同的側重點。

微服務和 API 是不同的東西，就像微服務和容器也不是同一種東西一樣。不過，這兩個概念以兩種不同的方式協同工作：首先，微服務可以作為部署內部、合作夥伴或公共 API 後端的一種方法。其次，微服務通常依賴 API 作為與語言無關的通信手段，以便在內部網路中相互通信。開發團隊可以使用相似的方法和工具來創建公開 API 和微服務 API。

英文原文：

https://blog.stoplight.io/stop-calling-your-apis-microservices-e165a80eba9d

點個好看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！