什么是微服務？

從根本上講，微服務只是一個運行在服務器或虛擬計算實例上并響應網絡請求的計算機程序。

這與典型的 Rails/Django/Node.js 應用程序有何不同？它根本上沒有什么不同。事實上，您可能會發現您的組織中已經部署了十幾個微服務。沒有任何新的神奇技術使您的應用程序有資格稱為微服務。微服務不是由它的構建方式來定義的，而是由它如何變成更通用的系統或解決方案來定義的。

那么是如何使服務成為微服務呢？一般來說，微服務的范圍更窄，專注于做好較小的任務。讓我們通過看一個例子來進一步探索。

微服務示例：亞馬遜產品列表

讓我們檢查在 Amazon 上為您提供此產品頁面的系統。它包含幾個信息塊，可能是從不同的數據庫中檢索到的：

• 產品描述，包括價格、標題、照片等。
• 推薦項目，即其他人購買的類似書籍。
• 與此項目相關的贊助商列表。
• 關于本書作者的信息。
• 顧客評論。
• 您自己在亞馬遜商店中瀏覽其他商品的歷史記錄。

如果您要快速編寫用于此列表的代碼，那么簡單的方法將如下所示：

當用戶的請求來自瀏覽器時，它將由 Web 應用程序（Linux 或 Windows 進程）提供服務。通常，被調用的應用程序代碼片段稱為請求處理程序。處理程序內部的邏輯將依次多次調用數據庫，獲取呈現頁面所需的信息并將其拼接在一起，然后呈現返回給用戶的網頁。很簡單吧？事實上，許多 Ruby on Rails 書籍都有類似這樣的教程和示例。那么，你可能會問，為什么要把事情復雜化？

想象一下隨著應用程序的增長和越來越多的工程師參與其中會發生什么。上面例子中的推薦引擎是由一小群程序員和數據科學家維護的。有幾十個不同的團隊負責渲染該頁面的某些組件。這些團隊中的每一個通常都希望獲得以下自由：

• 更改他們的數據庫架構。
• 快速且頻繁地將他們的代碼發布到生產環境中。
• 使用他們選擇的編程語言或數據存儲等開發工具。
• 在計算資源和開發人員生產力之間做出自己的權衡。
• 偏好維護/監控其功能。

可以想象，隨著時間的推移，讓團隊就發布 Web 商店應用程序的新版本的所有內容達成一致將變得更加困難。

解決方案是將組件拆分為更小的、獨立的服務（也就是微服務）。

升級流程變得更小、更笨。它基本上是一個代理，它簡單地將傳入的頁面請求分解為幾個專門的請求，并將它們轉發給相應的微服務，這些微服務現在是他們自己的進程并在其他地方運行。“應用微服務”基本上是專門服務返回的數據的聚合器。您甚至可以完全擺脫它并將該工作卸載到用戶的設備上，讓此代碼在瀏覽器中作為單頁 JavaScript 應用程序運行。

其他微服務現在被分離出來，每個開發微服務的開發團隊都可以：

• 隨心所欲地部署他們的服務，而不會干擾其他團隊。
• 以他們認為合適的方式擴展他們的服務。例如，使用他們選擇的 AWS 實例類型，或者可能在專用硬件上運行。
• 擁有自己特定于其服務的監控、備份和災難恢復。

什么是容器？

從技術上講，容器只是一個從可執行文件產生的進程，運行在 Linux 機器上，它有一些限制，例如：

• 容器不允許“看到”所有文件系統，它只能訪問其中的指定部分。
• 一個容器不允許使用所有的 CPU 或 RAM。
• 容器在如何使用網絡方面受到限制。

從歷史上看，現代操作系統總是對進程施加限制，例如每個 Linux 進程都以系統用戶的權限運行，但是容器化技術引入了更多可能的限制并使其更加靈活。

基本上，任何 Linux 可執行文件都可以受到限制，即可以“容器化”。

大多數情況下，當人們說“容器”時，他們不僅僅指的是 Linux 進程，還指的是可執行文件的打包和存儲方式。

類似的工具Docker允許開發人員獲取他們的可執行文件及其依賴項，以及他們想要的任何其他文件，并將它們全部打包成一個文件。這項技術與 tarball 之類的存檔沒有太大區別。Docker 還允許包含一些額外的指令和配置來運行這個打包的可執行文件。通常這些文件，通常稱為“容器鏡像”，也稱為容器。

但為了簡單起見，請記住：

• 一個容器就是一個運行受限制的linux進程
• 容器鏡像是可執行進程的依賴和配置打包

容器鏡像是自給自足的。它們將在任何 Linux 機器上運行，因此容器化使得將代碼從開發人員的機器復制（部署）到任何環境變得更加容易。

微服務和容器有什么區別？

我們剛剛了解到，容器只是一種打包、部署和運行 Linux 程序/進程的方法。您可以將一個巨大的單體應用程序作為容器，也可以擁有一群完全不使用容器的微服務。

容器是一種有用的資源分配和共享技術。這是 DevOps 人們感到興奮的事情。微服務是一種軟件設計架構。這是開發人員感到興奮的事情。

它們是相關的，但不需要彼此。您可以將單體應用部署為容器，也可以擁有不受限制的、非容器化的微服務。

什么時候使用微服務？

微服務背后的想法并不新鮮。幾十年來，軟件架構師一直致力于將單體應用程序分解為可重用的組件。

微服務的好處

微服務的好處很多，包括：

• 更簡單的自動化測試；
• 快速靈活的部署模式；
• 更強彈性擴縮容。

采用微服務的另一個好處是能夠為工作選擇最佳工具。應用程序的某些部分可以從 C++ 的速度中受益，而其他部分可以從更高級別語言（例如 Python 或 JavaScript）的生產力提高中受益。

微服務的缺點

微服務的缺點包括：

• 需要更仔細的規劃；
• 更高的研發投入；
• 過度設計的誘惑。

如果應用程序和開發團隊足夠小并且工作量不具有挑戰性，則通常無需投入額外的工程資源來解決您尚未解決的問題并使用微服務。但是，如果您開始看到微服務的利大于弊，這里有一些具體的設計注意事項：

• 計算和存儲分離。隨著您對 CPU 能力和存儲需求的增長，這些資源具有非常不同的擴展成本和特性。從一開始就不必依賴本地存儲，這將使您能夠相對輕松地適應未來的工作負載。這既適用于文件系統等簡單的存儲形式，也適用于數據庫等更復雜的解決方案。
• 異步處理。通過添加越來越多的相互調用的子進程或對象來逐步構建應用程序的傳統方法隨著工作負載的增長而停止工作，并且應用程序本身必須跨多臺機器甚至數據中心擴展。將需要圍繞事件驅動模型重新構建應用程序。這意味著發送事件（而不是等待結果）而不是調用函數并同步等待結果。
• 擁抱消息總線。這是必須實現異步處理模型的直接后果。隨著您的單體應用程序被分解為事件處理程序和事件發射器，就需要一個健壯、高性能和靈活的消息總線。有多種選擇，選擇取決于應用程序規模和復雜性。對于一個簡單的用例，像 Redis 這樣的東西就可以做到。如果您需要您的應用程序真正是云原生的并自行擴展和縮減，您可能需要能夠處理來自多個事件源的事件：從 Kafka 等流管道到基礎設施，甚至監控事件。
• API 版本控制。由于您的微服務將使用彼此的 API 通過總線相互通信，因此設計用于保持向后兼容性的架構將是至關重要的。只需部署一個微服務的最新版本，開發人員就不應該要求其他人升級他們的代碼。這將是向整體方法向后兼容的一步，開發團隊必須在永遠支持舊 API 和保持更高的開發速度之間達成合理的妥協。這也意味著 API 設計成為一項重要的技能。頻繁的破壞性 API 更改是團隊無法高效開發復雜微服務的原因之一。
• 重新考慮您的安全性。許多開發人員沒有意識到這一點，但遷移到微服務為更好的安全模型創造了機會。由于每個微服務都是一個專門的進程，因此最好只允許它訪問所需的資源。這樣，僅一個微服務中的漏洞就不會將系統的其余部分暴露給攻擊者。這與大型單體形成對比，后者傾向于以更高的特權（每個人都需要的超集）運行，并且可能導致更多的違規行為。

Kubernetes 與微服務有什么關系？

Kubernetes太復雜了，無法在此詳細描述，但值得對其進行概述，因為很多人在有關微服務的對話中都會提到它。

嚴格來說，Kubernetes（又名 K8s）的主要好處是通過跨多個進程高效共享計算資源來提高基礎設施利用率。Kubernetes 是動態分配計算資源以滿足需求的大師。這允許組織避免為他們不使用的計算資源付費。但是，K8s 的一些附帶好處使向微服務的過渡變得更加容易。

當您將單體應用程序分解為單獨的、松散耦合的微服務時，您的團隊將獲得更多的自主權和自由度。但是，在與微服務必須運行的基礎設施進行交互時，它們仍然必須密切合作。

您必須解決以下問題：

• 預測每個服務需要多少計算資源；
• 這些要求在負載下如何變化；
• 如何劃分基礎設施分區并將它們劃分到微服務之間；
• 實施資源限制。

Kubernetes 非常優雅地解決了這些問題，并提供了一個通用框架來描述、檢查和推理基礎設施資源的共享和利用。這就是為什么采用 Kubernetes 作為微服務重新架構的一部分是一個好主意。

然而，Kubernetes 是一項需要學習的復雜技術，而且更難管理。如果可以，您應該利用云提供商提供的托管 Kubernetes 服務。但是，對于需要跨多個云提供商和企業數據中心運行自己的 Kubernetes 集群的公司來說，這并不總是可行的。

結論

總結一下：

• 容器只是具有應用受限制的 Linux 進程。限制的示例包括允許進程使用多少 CPU 或內存。Docker 之類的工具允許開發人員將他們的可執行文件與依賴項和附加配置打包在一起。這些包被稱為 鏡像，并且經常且容易混淆地也被稱為容器。
• 微服務并不新鮮。這是一種舊的軟件設計模式，由于互聯網公司的規模不斷擴大，它越來越受歡迎。微服務不一定要容器化。同樣，單體應用程序可以是微服務。
• 小項目不應該回避整體設計。它為較小的團隊提供更高的生產力。
• Kubernetes 是由多個微服務組成的復雜應用程序的絕佳平臺。
• Kubernetes 也是一個復雜的系統，學習曲線陡峭，管理成本非常高。