爲何微服務架構勢在必行？

做者：成富，資深架構師，擁有多年一線開發經驗，曾就任於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 與容器化技術」，歡迎你來收聽。