為什麼微服務架構勢在必行？

作者：成富，資深架構師，擁有多年一線開發經驗，曾就職於IBM，後移居海外創業，現任公司首席軟體工程師，負責基於微服務架構的雲原生產品研發。資深技術作家，著有多部中英文技術書籍：《深入理解 Java7 》《Exploring Java9》等。

*本文經作者授權整理釋出，內容選自《雲原生微服務架構實戰精講》

這兩年，微服務作為一種架構方式，已經從論壇熱詞走向了真正的技術熱點， 諸多大廠（比如 Amazon、Netflix、螞蟻金服、網易雲音樂等）已經遷移並採用了微服務架構。市面上微服務的圖書、教程也層出不窮，為什麼網際網路行業如此擁抱微服務？瞭解一下行業發展問題和微服務架構的優勢，也就不難理解了。

目前，我們開發的大部分應用都是單體應用。

當單體應用的複雜度增加時，會出現一系列的問題。

單體應用的問題：

第 1 個問題是單體應用過於複雜，超出了單個開發人員的理解能力。

雖然可以透過元件化把單體應用劃分成多個單元，降低每個單元的複雜度，但在實際開發中，元件化的效果並不是很好。一方面是因為公共程式碼的存在，這些共享的程式碼由於被多個元件使用，難以高效更新；另一方面由於文件缺失和開發過程中的各種不規範行為，造成元件之間的介面不清晰。在 Java 程式碼中，我們可以很容易地呼叫其他元件中的介面和類的方法，從而在不同元件之間有意或無意的引入依賴。所產生的結果就是單體應用中不同元件之間的依賴關係非常複雜。

第 2 個問題是緩慢的開發速度。

當應用變得複雜時，開發人員則需要花費更多的時間來理解所做的改動對已有程式碼的潛在影響。經常遇到的情況有，一個看似很小的改動，會對應用造成很大的影響。當這樣的情況出現多次之後，開發人員由於怕承擔責任，變得不情願改進程式碼的質量，同時，在本地開發環境上進行開發和除錯變得更加耗時。在 IDE 中修改程式碼之後，編譯和重啟應用的時間過長，本地單元測試也需要更長的時間來執行。所產生的結果就是開發人員的寶貴時間耗費在無意義的等待上。

第 3 個問題是應用的擴充套件變得很困難。

當應用的處理能力不能滿足業務需求時，需要進行擴充套件，擴充套件分為垂直擴充套件和水平擴充套件兩種。垂直擴充套件的做法是增加單個應用例項所能使用的資源，這導致的問題是不同元件對資源需求的衝突，有些元件對記憶體的消耗較大，而另外一些元件對 CPU 的要求高，當無法同時滿足兩者時，則需要作出取捨。水平擴充套件的做法是增加應用的例項數量，水平擴充套件只能以應用為單位來進行，如前面的圖片所示，應用中不同元件的負載程度是不同的，以電子商務應用為例，商品展示和訂單處理相關元件的負載要大於客戶服務相關的元件，以應用為單元的擴充套件方式無法有效的分配資源。

第 4 個問題是新版本更新上線的速度變慢。

現在的應用都要求能夠及時響應使用者的需求，以最快的速度新增新功能和修復問題，這意味著一天可能要進行很多次的產品更新。單體應用由於複雜度高，每一次程式碼提交之後的持續整合所花費的時間過長。由於需要執行全部的測試用例，限制了更新的頻率。

第 5 個問題是整個應用的穩定性變差。

由於整個應用只有一個程序，元件之間缺少必要的隔離性，任何一個元件中出現的問題，比如記憶體洩漏，都會導致整個應用的崩潰。當某個元件佔用大量的 CPU 和記憶體資源時，會導致其他元件由於資源不足而無法正常工作。

第 6 個問題是技術棧的選型和更新變得困難。

單體應用通常只使用單一的技術棧，包括程式語言、所用框架、第三方庫，以及資料庫和訊息中介軟體等，這就要求所有的開發人員都掌握相同的技術棧，事實上，不同元件由於需求的不同，有它最適合的技術棧。強制使用單一技術棧，無疑會對開發效率產生影響，一旦技術棧選型確定之後，要對它進行更新是一件非常困難的事情，整個應用都可能受到影響。所產生的效果就是應用的技術棧不斷的老化，帶來更多的問題，形成惡性迴圈。

如果你的單體應用遇到了上述問題，則說明該應用的架構到了需要調整的時候，

微服務架構則是針對以上問題的解決方案

。下面我們來看一下微服務架構到底是什麼？

微服務架構的核心思想是把應用按照功能劃分成多個獨立的服務，每個服務都是獨立執行的應用。

如下圖所示，外部的邊框是應用的邊界，不同的形狀表示不同的單元。圖中左側表示的是單體應用，所有單元在同一個應用的邊界內。在進行擴充套件時，單體應用只能整體擴充套件；右側表示的是微服務架構的應用，每個單元在自己的應用邊界內。在進行擴充套件時，微服務架構的應用以服務為單位進行擴充套件。不同服務在執行時的例項數量可以根據負載動態進行調整。

微服務架構的特徵：

1.微服務架構使用服務作為元件化的單元。

元件化是軟體開發中的基本實踐，在 Java 應用開發中，元件通常以 JAR 檔案的形式出現，Maven 倉庫中包含了海量的第三方庫可供使用，Java 開發人員都熟悉這種使用元件的方式。

在微服務架構中，元件的單元變成了服務，服務執行在獨立的程序中，不能透過直接的方法呼叫來訪問，而需要使用類似 HTTP 這樣的程序間通訊方式，每個服務可以獨立部署，使用 API 規範來描述其公開介面。一個微服務只能透過 API 訪問另外的微服務，並不能訪問內部的實現程式碼。

如下圖所示，不同服務之間存在呼叫關係，呼叫的方式可以是 REST 或 gRPC。

2.微服務架構的開發團隊圍繞業務能力來組織。

單體應用的開發團隊通常按照技能來劃分，一個典型的 3 層應用開發團隊可能分成前端開發、後端開發和資料庫管理等小組。微服務架構的開發團隊以服務為單元來組織，每個服務與特定的業務需求相對應。

服務的開發團隊規模較小，包含開發、測試和 DevOps 相關的全部人員，負責該微服務的團隊對該微服務的實現可以全權負責。較小的開發團隊意味著更少的溝通成本和更高的開發效率。

3.微服務架構使用去中心化的管理模式。

單體應用的開發團隊通常會對使用的技術棧做出限制，要求整個團隊使用統一的技術棧。這種方式的弊端在於，沒有一種技術棧適用於解決所有的問題。

微服務架構中的服務都可以獨立部署，這就意味著每個服務在實現時可以選擇最適合的技術棧，只需要滿足服務的 API 契約即可。

每個團隊自主管理所負責的服務，不但負責構建，還同樣負責執行和維護，這在無形中提高了團隊的主觀能動性，同時降低了管理的開銷。

如下圖所示，每個微服務都有對應的團隊，而每個團隊中都有各種角色的人員。

4.微服務架構使用去中心的資料儲存。

單體應用通常使用單一資料庫來儲存資料，微服務架構中的服務通常有自己專有的資料儲存，如下圖所示。這些儲存方式的實現可能各不相同，只包含服務所需的資料。

5.微服務架構強調基礎設施的自動化。

持續整合和持續部署都是通用的實踐，單體應用由於只有一個部署單元，對自動化的要求並不高。微服務架構中的服務可以獨立部署，但當服務的數量較多時，必須透過自動化的流程來完成。

微服務架構的實現：

微服務架構所涵蓋的內容非常廣泛，對不同角色的人員，其意義並不相同：

從架構的角度來說，它是由多個獨立服務組成的分散式系統；

從人員管理的角度來說，它要求員工組成小而完備的自主團隊；

從專案管理的角度來說，它推薦使用敏捷軟體開發流程，如 Scrum 或 Kanban；

從開發的角度來說，每個服務有獨立的業務邏輯實現和資料儲存，使用開放 API 作為邊界；

從測試的角度來說，需要對服務的 API 契約進行測試；

從運維的角度來說，持續整合和持續部署對微服務架構的成功至關重要。

微服務架構的實踐是一項系統化的工程，需要很多人的協同合作。作為開發人員，我們更多關注的是如何完成服務的實現，但除了每個服務本身的實現之外，還包括與其他服務的協作。

從實現的角度來說，我們需要考慮表中的這些因素。

表中列出的關於服務實現的相關內容，在大部分微服務架構的應用中都會出現。但在實際的專案開發中，你並不會從零開始實現所有相關的內容，而是使用已有的平臺、框架和技術，流行的技術選擇包括 Netflix OSS 棧、Spring Cloud 和 Kubernetes 等。

Netflix 是微服務架構實踐中的引領者，不僅在生產系統中成功應用了微服務架構，還把相關的庫和工具以開放原始碼的形式共享出來，形成了 Netflix OSS 棧。

Spring Cloud 是由多個開源專案組成的開發套件，用來實現分散式系統中的常見模式，如配置管理、服務發現和斷路器等，可以用來實現微服務架構的應用。它的優勢在於提供了一個抽象框架，可以避免供應商鎖定的問題，對於同一個模式，它可以切換底層的實現方式。Spring Cloud 本身是基於 Spring 框架的，對於一直工作在 Spring 框架上的團隊來說，Spring Cloud 是一個不錯的選擇。

Kubernetes 是管理容器化工作負載和服務的平臺，同時也是容器編排平臺，微服務及其依賴的其他服務通常以容器的形式執行。Kubernetes 對錶中的很多需求都提供了原生的解決方案，對於另外的一些需求則有開源實現，是執行微服務架構應用的良好平臺。

微服務架構所包含的內容非常多，在本文中，我著重介紹了微服務架構的基本概念，從單體應用的問題來闡述引入微服務架構的必要性，以及微服務架構的應用具備的特徵。

在微服務的實現上，還有許多具體的問題，比如如何拆分服務，服務之間如何協作，這些內容，都會在我的專欄中做具體的闡述。

雲原生微服務架構實戰精講 - 資深架構師 - 拉勾教育

感興趣的話，你可以點選卡片，檢視我的專欄，本章節內容也會有更詳細的補充，比如微服務架構存在哪些問題，下一講我將詳述“什麼是 Docker 與容器化技術”，歡迎你來收聽。