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