《深刻理解Spring Cloud與微服務構建》第1章 微服務簡介

一、單體架構及其存在的不足

1.一、單體架構簡介

一個典型的單體應用就是將全部的業務場景的表示層、業務邏輯層和數據訪問層放在一個工程中，最終通過編譯打包，部署在一臺服務器上。

1.二、單體架構存在的不足

• 業務愈來愈複雜，單體應用的代碼量愈來愈大，代碼的可讀性、可維護性和可擴展性降低，新人接手代碼所需的時間成倍增長，業務擴展帶來的代價愈來愈大。
• 隨着用戶的愈來愈多，程序承受的併發愈來愈高，單體應用的併發能力有限。
• 測試的難度愈來愈大。

1.三、單體架構使用服務器集羣及存在的不足

用負載均衡服務器分發高併發的網絡請求，用戶訪問被分派到不一樣的應用服務器，應用服務器的負載再也不成爲瓶頸，用戶量增長時，添加應用服務器便可。經過添加緩存服務器來緩解數據庫的數據以及數據庫讀取數據的壓力。大多數的讀取操做是由緩存完成的，可是仍然由少數讀操做是從數據庫讀取的，例如緩存失效、實時數據等。當有大量的讀寫操做時，將數據庫進行讀寫分離是一個不錯的選擇，例如MySQL的主從熱備份，經過相關配置能夠將主數據庫服務器的數據同步到從數據庫服務器，實現數據庫的讀寫分離，讀寫分離可以改善數據庫的負載能力。

這種架構有必定的處理高併發的能力，也能應對必定複雜的業務需求，改善了系統的性能，可是依然沒有改變系統爲單體架構的事實，此時存在的不足之處以下。

• 系統仍然爲單體應用，大量的業務必然會有大量的代碼，代碼的可讀性和可維護性依然不好。
• 面對海量的用戶，數據庫將會成爲瓶頸，解決方案將使用分佈式數據庫，也就是將數據庫進行分庫分表。
• 持續交付能力差，業務越複雜，代碼越多，修改代碼和添加代碼所需的時間越長。新人熟悉代碼的時間越長，成本高。

因此，單體架構已經不能知足複雜的業務和海量的用戶系統，改變單體架構勢在必行。

二、微服務

簡而言之，微服務架構的風格，就是將單一程序開發成一個微服務，每一個微服務運行在本身的進程中，並使用輕量級機制通訊，一般是 HTTP RESTFUL API。這些服務圍繞業務能力來劃分構建的，並經過徹底自動化部署機制來獨立部署。這些服務可使用不一樣的編程語言，以及不一樣數據存儲技術，以保證最低限度的集中式管理。

2.一、微服務單元按業務來劃分

按業務劃分的微服務單元獨立部署，運行在獨立的進程中。這些微服務單元是高度組件化的模塊，並提供了穩定的模塊邊界，服務與服務之間沒有任何的耦合，有很是好的擴展性和複用性。

2.二、微服務經過HTTP來互相通訊

微服務單元之間的通訊方式通常傾向於使用HTTP這種簡單的通訊機制，更多的時候是使用RESTful API的。這種接受請求、處理業務邏輯、返回數據的HTTP模式很是高效，而且這種通訊機制與平臺和語言無關。

服務與服務之間也能夠經過輕量級的消息總線來通訊，例如RabbitMQ、Kafaka等。經過發送消息或者訂閱消息來達到服務與服務之間通訊的目的。

它們通訊的數據格式通常爲JSON、XML，與語言、平臺、通訊協議無關。JSON格式的數據比XML輕量，而且可讀性也比XML好。

2.三、微服務的數據庫獨立

一個典型的微服務架構就是每一個微服務都有本身獨立的數據庫，數據庫之間沒有任何聯繫。這樣作的好處在於，隨着業務的不斷擴張，服務與服務不須要提供數據庫集成，而是提供API接口相互調用；還有一個好處是數據庫獨立，單業務的數據量少，易於維護，數據庫性能有着明顯的優點，數據庫的遷移也很方便。每一個服務的數據庫不必定都相同，它們所使用的數據存儲技術須要根據業務需求來選擇。

2.四、微服務的自動化部署

自動化部署能夠提升部署的效率，減小人爲的控制，部署過程當中出現錯誤的機率下降，部署過程的每一步自動化，提升軟件的質量。

2.五、服務集中化管理

微服務系統是按業務單元來劃分服務的，服務數量越多，管理起來就越複雜，所以微服務必須使用集中化管理。目前流行的微服務框架中，例如Spring Cloud 採用Eureka來註冊服務和發現服務，另外，Zookeeper、Consul等都是很是優秀的服務集中化管理框架。

2.六、分佈式架構

微服務架構是分佈式架構，分佈式系統比單體系統更加複雜，主要體如今服務的獨立性和服務相互調用的可靠性，以及分佈式事務、全局鎖、全局ID等，而單體系統不須要考慮這些複雜性。

另外，分佈式系統的應用都是集羣化部署，會給數據一致性帶來困難。分佈式系統中的服務通訊依賴於網絡，網絡很差，必然會對分佈式系統帶來很大的影響。在分佈式系統中，服務之間相互依賴，若是一個服務出現了故障或者是網絡延遲，在高併發的狀況下，會致使線程阻塞，在很短的時間內該服務的線程資源會消耗殆盡，最終使得該服務不可用。因爲服務的相互依賴，可能會致使整個系統的不可用，這就是「雪崩效應」。

2.七、熔斷機制

爲了防止「雪崩效應」事件的發生，分佈式系統採用了熔斷機制。當某服務出現故障，請求失敗次數超過設定的閥值以後，該服務就會開啓熔斷器，以後該服務不進行任何的業務邏輯操做，執行快速失敗，直接返回請求失敗的信息。

三、微服務的優點和不足

3.一、微服務的優點

• 複雜的業務分解成若干小的業務，服務按業務劃分，邊界明確，將複雜的問題簡單化。
• 微服務系統的微服務單元具備很強的橫向擴展能力。
• 服務與服務之間經過HTTP網絡通訊協議來通訊，單個微服務內部高度耦合，服務與服務之間徹底獨立，無耦合。提升開發效率，下降開發成本。
• 重寫某個服務就至關於重寫某個業務的代碼，很是簡單。
• 服務獨立部署，對其餘服務不產生影響。
• 微服務在CAP理論中採用的是AP架構，即具備高可用和分區容錯的特色。高可用主要體如今系統7x24小時不間斷的服務，它要求系統有大量的服務器集羣，從而提升了系統的負載能力。另外，分區容錯也使得系統更加健壯。

3.二、微服務的不足

• 微服務的複雜度
• 分佈式事務：參考《分佈式服務架構：原理、設計與實戰》第二章完全解決分佈式系統一致性的問題
• 服務的劃分：領域驅動設計
• 服務的部署：微服務系統須要對每一個系統進行治理、監控和管理等，而每一個服務有大量的配置，還須要考慮服務的啓動順序和啓動時機等。微服務是核心；Docker爲容器技術，是微服務最佳部署的容器；DevOps是一種部署手段或理念。

四、微服務和SOA的關係

SOA即面向服務的架構，微服務將複雜的業務組件化，實際也是一種面向服務思想的體現。對於微服務來講，它是SOA的一種實現，可是它比ESB實現的SOA更加輕便、敏捷和簡單。

能夠看下《分佈式服務架構：原理、設計與實戰》第一章分佈式微服務架構設計原理

五、微服務的設計原則

軟件設計每一個版本都在變化，因此軟件設計應該是漸進式發展。軟件從一開始就不該該被設計成微服務架構，微服務架構當然有優點，可是它須要更多的資源，包括服務器資源、技術人員等。追求大公司所帶來的技術解決方案，刻意地追求某個新技術，企圖使用技術解決全部的問題，這些都是軟件設計的誤區。

技術應該是隨着業務的發展而發展的，任何脫離業務的技術是不能產生價值的。在初創公司，業務很單一時，若是在LAMP單體架構夠用的狀況下，就應該用LAMP，由於它開發速度快，性價比高。隨着業務的發展，用戶量的增長，能夠考慮將數據庫讀寫分離、加緩存、加負載均衡服務器、將應用程序集羣化部署等。若是業務還在不斷髮展，這時能夠考慮使用分佈式系統，例如微服務架構的系統。無論使用什麼樣的架構，驅動架構的發展必定是業務的發展，只有當前架構再也不適合當前業務的發展，才考慮更換架構。

能夠看下《大型網站技術架構——核心原理與案例分析》第1章：大型網站架構演化

在微服務架構中，有三大難題，那就是服務故障的傳播性、服務的劃分和分佈式事務。在微服務設計時，必定要考慮清楚這三個難題，從而選擇合適的框架。目前比較流行的微服務框架有Spring社區的Spring Cloud、Google公司的Kubernetes等。爲了解決服務故障的傳播性，通常的微服務框架都有熔斷機制組件。另外，服務的劃分沒有具體的劃分方法，通常來講根據業務來劃分服務，領域驅動設計具備指導做用。最後，分佈式事務通常的解決辦法就是兩階段提交或者三階段提交，無論使用哪種都存在事務失敗，致使數據不一致的狀況，關鍵時刻還得人工去恢復數據。