別再管你的 API 叫微服務了：容器、微服務和API之間是什麼關係？

做者 | Lukas Rosenstock譯者 | 無明最近我對 API 世界的觀察彷佛證實了「命名」確實是個大難題：人們對「API」和「微服務」這兩個術語存在混淆，有些人彷佛已經把它們混爲一談了。

你有沒有聽過這句名言：「計算機科學領域只有兩個難題，緩存失效和命名」？聽說這句話是 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