微服務架構的優點與不足

上篇文章給你們簡單介紹了一下微處理架構，如今我來爲你們分析微服務架構的優點與不足。

 

微處理架構——處理復瑣事物

許多公司，好比Amazon、eBay和NetFlix，經過採用微處理結構模式解決了上述問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解爲小的、互相鏈接的微服務。

一個微服務通常完成某個特定的功能，好比下單管理、客戶管理等等。每個微服務都是微型六角形應用，都有本身的業務邏輯和適配器。一些微服務還 會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每個實例多是一個雲VM或者是Docker容器。

好比，一個前面描述系統可能的分解以下：

每個應用功能區都使用微服務完成，另外，Web應用會被拆分紅一系列簡單的Web應用（好比一個對乘客，一個對出租車駕駛員）。這樣的拆分對於不一樣用戶、設備和特殊應用場景部署都更容易。

每個後臺服務開放一個REST API，許多服務自己也採用了其它服務提供的API。好比，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務。UI服務激活其它服務來更新Web頁面。全部服務都是採用異步的，基於消息的通信。微服務內部機制將會在後續系列中討論。

一些REST API也對乘客和駕駛員採用的移動應用開放。這些應用並不直接訪問後臺服務，而是經過API Gateway來傳遞中間消息。API Gateway負責負載均衡、緩存、訪問控制、API 計費監控等等任務，能夠經過NGINX方便實現，後續文章將會介紹到API Gateway。

·微服務架構模式在上圖中對應於表明可擴展Scale Cube的Y軸，這是一個在《The Art of Scalability》書中描述過的三維擴展模型。另外兩個可擴展軸，X軸由負載均衡器後端運行的多個應用副本組成，Z軸是將需求路由到相關服務。

應用基本能夠用以上三個維度來表示，Y軸表明將應用分解爲微服務。運行時，X軸表明運行多個隱藏在負載均衡器以後的實例，提供吞吐能力。一些應用可能仍是用Z軸將服務分區。下面的圖演示行程管理服務如何部署在運行於AWS EC2上的Docker上。

運行時，行程管理服務由多個服務實例構成。每個服務實例都是一個Docker容器。爲了保證高可用，這些容器通常都運行在多個雲VM上。服務實例前是 一層諸如NGINX的負載均衡器，他們負責在各個實例間分發請求。負載均衡器也同時處理其它請求，例如緩存、權限控制、API統計和監控。

這種微服務架構模式深入影響了應用和數據庫之間的關係，不像傳統多個服務共享一個數據庫，微服務架構每一個服務都有本身的數據庫。另外，這種思路也影響到了企業級數據模式。同時，這種模式意味着多份數據，可是，若是你想得到微服務帶來的好處，每一個服務獨有一個數據庫是必須的，由於這種架構須要這種鬆耦合。下面的圖演示示例應用數據庫架構。

每種服務都有本身的數據庫，另外，每種服務能夠用更適合本身的數據庫類型，也被稱做多語言一致性架構。好比，駕駛員管理（發現哪一個駕駛員更靠近乘客），必須使用支持地理信息查詢的數據庫。

表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。可是，能夠從另一個角度看此問題，微服務架構模式是一個不包含Web服務 （WS-）和ESB服務的SOA。微服務應用樂於採用簡單輕量級協議，好比REST，而不是WS-，在微服務內部避免使用ESB以及ESB相似功能。微服 務架構模式也拒絕使用canonical schema等SOA概念。

微服務架構的好處

微服務架構模式有不少好處。首先，經過分解巨大單體式應用爲多個服務方法解決了複雜性問題。在功能不變的狀況下，應用被分解爲多個可管理的分支 或服務。每一個服務都有一個用RPC-或者消息驅動API定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由 此，單個服務很容易開發、理解和維護。

第二，這種架構使得每一個服務均可以有專門開發團隊來開發。開發者能夠自由選擇開發技術，提供API服務。固然，許多公司試圖避免混亂，只提供某 些技術選擇。而後，這種自由意味着開發者不須要被迫使用某項目開始時採用的過期技術，他們能夠選擇如今的技術。甚至於，由於服務都是相對簡單，即便用如今 技術重寫之前代碼也不是很困難的事情。

第三，微服務架構模式是每一個微服務獨立的部署。開發者再也不須要協調其它服務部署對本服務的影響。這種改變能夠加快部署速度。UI團隊能夠採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成爲可能。

最後，微服務架構模式使得每一個服務獨立擴展。你能夠根據每一個服務的規模來部署知足需求的規模。甚至於，你可使用更適合於服務資源需求的硬件。 好比，你能夠在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內存數據庫。

微服務架構的不足

Fred Brooks在30Year前寫道，「there are no silver bullets」，像任何其它科技同樣，微服務架構也有不足。其中一個跟他的名字相似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹創建稍微大一 些的，10-100 LOC服務組。儘管小服務更樂於被採用，可是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

另一個主要的不足是，微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者須要在RPC或者消息傳遞之間選擇並完成進程間通信機制。更甚 於，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。固然這並非什麼難事，但相對於單體式應用中經過語言層級的方法或者進程調用，微 服務下這種技術顯得更復雜一些。

另一個關於微服務的挑戰來自於分區的數據庫架構。商業交易中同時給多個業務分主體更新消息很廣泛。這種交易對於單體式應用來講很容易，由於只 有一個數據庫。在微服務架構應用中，須要更新不一樣服務所使用的不一樣的數據庫。使用分佈式交易並不必定是好的選擇，不只僅是由於CAP理論，還由於今天高擴 展性的NoSQL數據庫和消息傳遞中間件並不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

測試一個基於微服務架構的應用也是很複雜的任務。好比，採用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，一樣的服務測試須要啓動和它有關的全部服務（至少須要這些服務的stubs）。再重申一次，不能低估了採用微服務架構帶 來的複雜性。

另一個挑戰在於，微服務架構模式應用的改變將會波及多個服務。好比，假設你在完成一個案例，須要修改服務A、B、C，而A依賴B，B依賴C。 在單體式應用中，你只須要改變相關模塊，整合變化，部署就行了。對比之下，微服務架構模式就須要考慮相關改變對不一樣服務的影響。好比，你須要更新服務C， 而後是B，最後纔是A，幸運的是，許多改變通常隻影響一個服務，而須要協調多服務的改變不多。

部署一個微服務應用也很複雜，一個分佈式應用只須要簡單在複雜均衡器後面部署各自的服務器就行了。每一個應用實例是須要配置諸如數據庫和消息中間件等基礎服務。相對比，一個微服務應用通常由大批服務構成。例如，根據Adrian Cockcroft，NetFlix 有大約600個服務。每一個服務都有多個實例。這就形成許多須要配置、部署、擴展和監控的部分，除此以外，你還須要完成一個服務發現機制（後續文章中發 表），以用來發現與它通信服務的地址（包括服務器地址和端口）。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署一個微服務應用須要開 發者有足夠的控制部署方法，並高度自動化。

一種自動化方法是使用PaaS服務，例如Cloud Foundry。 PaaS給開發者提供一個部署和管理微服務的簡單方法，它把全部這些問題都打包內置解決了。同時，配置PaaS的系統和網絡專家能夠採用最佳實踐和策略來 簡化這些問題。另一個自動部署微服務應用的方法是開發對於你來講最基礎的PaaS系統。一個典型的開始點是使用一個集羣化方案，好比配合Docker使 用Mesos或者Kubernetes。後面的系列咱們會看看如何基於軟件部署方法例如NGINX，能夠方便的在微服務層面提供緩存、權限控制、API統 計和監控。

總結

構建複雜的應用真的是很是困難。單體式的架構更適合輕量級的簡單應用。若是你用它來開發複雜應用，那真的會很糟糕。微服務架構模式能夠用來構建複雜應用，固然，這種架構模型也有本身的缺點和挑戰。

在後續的博客中，我會深刻探索微服務架構模式，並討論諸如服務發現、服務部署選擇和如何分解一個分佈式應用爲多個服務的策略。

-----------------------------------------------------------------------------------

完整的項目源碼   歡迎你們一塊兒學習研究相關技術，源碼獲取請加求求:2670716182