什麼是微服務？
什麼是微服務？你應該使用微服務嗎？微服務與容器和 Kubernetes 有什麼關係？如果這些問題在您的日常生活中不斷出現，那麼這篇文章適合您。
從根本上說，微服務只是一個執行在伺服器或虛擬計算例項上並響應網路請求的計算機程式。這與典型的Java、Django、Node.js應用程式沒有什麼不同。事實上，您可能會發現您的組織中已經部署了十幾個微服務。
沒有任何新的神奇技術使您的應用程式變成微服務，微服務不是由它的構建方式來定義的，而是由它如何適應更廣泛的系統或解決方案來定義的。
那麼是什麼使服務成為微服務呢？一般來說，微服務的範圍更窄，專注於做好較小的任務。讓我們通過看一個例子來進一步探索。
讓我們看看在Amazon上為您提供產品的頁面。它包含幾個資訊塊，可能是從不同的資料庫中檢索到的：
- 產品描述，包括價格、標題、照片等。
- 推薦專案，即其他人購買的類似書籍。
- 與此專案相關的贊助商列表。
- 關於本書作者的資訊。
- 顧客評論。
- 您自己在亞馬遜商店中瀏覽其他商品的歷史記錄。
如果您要快速編寫用於此列表的程式碼，那麼簡單的方法將如下所示：
當用戶從瀏覽器發起請求時，它將由Web應用程式（Linux 或 Windows 程序）提供服務。通常，被呼叫的應用程式程式碼片段稱為請求處理程式。處理程式內部的邏輯將依次多次呼叫資料庫，獲取呈現頁面所需的資訊並將其拼接在一起，然後呈現要返回給使用者的網頁。
很簡單吧？事實上，許多開發類的書籍都有類似這樣的教程和示例。那麼，你可能會問，為什麼要使用微服務把事情複雜化？
想象一下隨著應用程式的增長和越來越多的工程師參與其中會發生什麼。上面例子中的推薦引擎是由一群程式設計師和資料科學家維護的。有幾十個不同的團隊負責渲染該頁面的某些元件。這些團隊中的每一個通常都希望獲得以下自由：
- 更改他們的資料庫架構。
- 快速且頻繁的將他們的程式碼釋出到生產環境中。
- 使用他們選擇的程式語言或資料儲存開發工具。
- 在計算資源和開發人員生產力之間做出自己的權衡。
- 擁有自己偏好的維護或監控工具。
可以想象，隨著時間的推移，讓整個團隊就釋出應用程式的新版本的所有內容達成一致將變得更加困難。
解決方案是將元件拆分為更小的、獨立的服務（又名微服務）。
請求處理程式將傳入的頁面請求分解為幾個專門的請求，並將它們轉發給相應的微服務，這些微服務分別使用獨立的程序和資源執行。
微服務被分離出來後，每個開發它們的開發團隊都可以：
- 隨心所欲地部署他們的服務，而不會干擾其他團隊。
- 以他們認為合適的方式擴充套件他們的服務。例如，使用他們選擇的 AWS 例項型別，或者可能在專用硬體上執行。
- 擁有自己特定於其服務的監控、備份和災難恢復。
什麼是容器？
從技術上講，容器只是一個從可執行檔案產生的程序，執行在伺服器上，它有一些限制，例如：
- 容器不允許看到所有檔案系統，它只能訪問其中的指定部分。
- 一個容器不允許使用所有的CPU或記憶體。
- 容器在如何使用網路方面受到限制。
大多數時候，當人們說「容器」時，他們不僅僅指的是Linux程序，還指的是可執行檔案的打包和儲存方式。
類似的工具Docker允許開發人員獲取他們的可執行檔案及其依賴項，以及他們想要的任何其他檔案，並將它們全部打包成一個檔案。這項技術與tarball之類的打包工具沒有太大區別。Docker 還允許包含一些額外的指令和配置來執行這個打包的可執行檔案。通常這些檔案稱為映象。
但為了簡單起見，請記住：
- 一個容器是一個Linux程序
- 映象是Linux可執行檔案與它的依賴和配置檔案的打包
映象是可以在任何安裝了Docker的機器上執行的，因此容器化技術使得開發人員在不同的環境中部署程式更加容易。
微服務和容器有什麼區別？
我們剛剛瞭解到容器只是一種打包、部署和執行程式或者程序的方法。您可以將一個巨大的單體應用程式作為容器，也可以擁有一群完全不使用容器技術的微服務。
容器是一種有用的資源分配和共享技術。這是開發運維人員感到興奮的事情。
微服務是一種軟體設計模式。這是開發人員感到興奮的事情。
它們是相關的，但不需要彼此。您可以將單體應用部署為容器，也可以擁有不受限制的、非容器化的微服務。
什麼時候使用微服務？
微服務背後的想法並不新鮮。十幾年來，軟體架構師一直致力於將單體應用程式分離為可重用的元件。
微服務的好處很多，包括：
- 更簡單的自動化測試。
- 快速靈活的部署模式。
- 更高的整體彈性。
採用微服務的另一個好處是能夠為工作選擇最佳工具。應用程式的某些部分可以從 C++ 的速度中受益，而其他部分可以從更高級別語言（例如Python或JavaScript）的生產力提高中受益。
微服務的缺點包括：
- 需要更仔細的規劃。
- 更高的研發投入。
- 過度工程的誘惑。
如果應用程式和開發團隊足夠小並且工作量不具有挑戰性，則通常無需使用微服務。但是，如果您開始看到微服務的利大於弊，這裡有一些具體的設計注意事項：
計算和儲存分離
隨著您對 CPU 能力和儲存需求的增長，這些資源具有非常不同的擴充套件成本和特性。從一開始就不必依賴本地儲存，這將使您能夠相對輕鬆地適應未來的工作負載。這既適用於檔案系統等簡單的儲存形式，也適用於資料庫等更復雜的解決方案。
非同步處理
通過新增越來越多的相互呼叫的子程式或物件來逐步構建應用程式的傳統方法隨著工作負載的增長而停止工作，並且應用程式本身必須跨多臺機器甚至資料中心擴充套件。將需要圍繞事件驅動模型重新構建應用程式。
擁抱訊息匯流排
隨著您的單體應用程式被分解為事件處理程式和事件發射器，就需要一個健壯、高效能和靈活的訊息匯流排。有多種選擇，選擇取決於應用程式規模和複雜性。對於一個簡單的應用，像Redis這樣的東西就可以了。如果您的應用程式足夠複雜，您可能需要一個Kafka。
API 版本控制
由於您的微服務將使用彼此的 API 通過匯流排相互通訊，因此設計用於保持向後相容性的架構將是至關重要的。開發團隊必須在永遠支援舊 API 和保持更高的開發速度之間達成合理的妥協。這也意味著 API 設計成為一項重要的技能。頻繁的API更改是團隊無法高效開發複雜微服務的原因之一。
重新考慮您的安全性
許多開發人員沒有意識到這一點，但遷移到微服務為更好的安全模型創造了機會。由於每個微服務都是一個專門的程序，因此最好只允許它訪問所需的資源。這樣，僅一個微服務中的漏洞就不會將系統的其餘部分暴露給攻擊者。
Kubernetes 與微服務有什麼關係？
Kubernetes太複雜了，在本文中不會詳細描述，但值得對其進行概述，因為很多人在有關微服務的對話中都會提到它。
嚴格來說，Kubernetes（又名 K8s）的主要好處是通過跨多個程序高效共享計算資源來提高基礎設施利用率。Kubernetes是動態分配計算資源以滿足需求的大師。這允許組織避免為他們不使用的計算資源付費。
當您將單體應用程式分解為單獨的、鬆散耦合的微服務時，您的團隊將獲得更多的自主權和自由度。然而，在與執行微服務的基礎設施進行互動時，他們仍然必須密切合作。
您必須解決以下問題：
- 預測每個服務需要多少計算資源。
- 這些要求在負載下如何變化。
- 如何劃分基礎設施分割槽並將它們劃分到微服務之間。
- 實施資源限制。
Kubernetes非常優雅地解決了這些問題，並提供了一個通用框架來描述、檢查和推理基礎設施資源的共享和利用。這就是為什麼採用Kubernetes作為微服務架構的一部分是一個好主意。
然而，Kubernetes是一項需要學習的複雜技術，而且更難管理。如果允許，您可以利用第三方提供的服務，我們建議嘗試使用 StarOS，這是一個一站式雲原生線上開發平臺，底層技術基於Kubernetes。
StarOS 通過架構圖模型，將微服務的依賴關係固化，完成了對整個應用的封裝，從而實現了應用與環境的解耦。無論是應用複製，還是應用遷移，都得心應手。並且基於基礎設施下沉的理念，將底層的容器叢集資源、運維管理工具，以及中介軟體、環境配置等全部下沉為平臺能力，真正做到了一站式，而且開箱即用。
StarOS 還為研發團隊提供了多職能、多場景的多人線上協作研發工具，支援研發工作中多種輸出物的線上編輯交付，讓您在異地協同，遠端辦公的時候，盡享便利。
總結一下：
- 容器只是具有應用限制的Linux程序，限制的示例包括允許程序使用多少CPU或記憶體。Docker允許開發人員將他們的可執行檔案與依賴項和附加配置打包在一起，這些包被稱為映象。
- 微服務並不新鮮，這是一種軟體設計模式，由於網際網路公司的規模不斷擴大，它越來越受歡迎。微服務不一定要容器化，類似地，單體應用程式可以是微服務。
- 小專案不應該回避整體設計。它為較小的團隊提供更高的生產力。
- Kubernetes是由多個微服務組成的複雜應用程式的絕佳平臺。
- Kubernetes是一個複雜的系統。