Spring Cloud|01 微服務簡介

2019 年 10 月 4 日
筆記

幾點說明 1、本系列Spring Cloud的部落格參考了方誌朋所著《深入理解Spring Cloud與微服務構建》； 2、大家如果想更加深入的理解Spring Cloud 建議多實戰、多看書；

單體架構

簡介

在軟體設計中，頻繁被使用的就是我們的經典三層架構了。 1、表示層：用於直接與用戶進行交互，通常是頁面、UI等； 2、業務邏輯層（service）：用於處理業務，比如用戶從表示層輸入了消息就要經過業務邏輯層的邏輯處理之後再進行的相關操作； 3、數據訪問層（dao）：用於與資料庫進行交互；

而在單體應用中，我們就會把這三層都放在一個工程中，最終通過打成war包發布到服伺服器的tomcat的web-app中上線。可以說是十分方便的一個設計理念了！

優劣

單體應用的優勢在於： 1、性價比非常高，通常只需要一台伺服器就能夠把項目跑起來； 2、開發的速度也比較快，運維較簡單，項目架構比較簡單明了，適合小型應用開發。

單體應用的劣勢在於： 1、所有的業務相關操作都放在了一個伺服器上，如果項目中某個業務出現了bug，不急時發現就會導致整個項目的癱瘓，最終宕機，而這對於一個大型網站來說無疑是十分致命的問題； 2、業務越來越複雜的時候，單體應用的程式碼量就會越來越多，導致最後的程式碼可讀性、可維護性越來越差，最終只能進行重構； 3、用戶越來越多的時候，單體應用的並發能力有限；

由此可見：在應用初期，單體應用從成本、開發時間和運維等方面都有優勢，但是單體應用會隨著業務量和用戶量的增加，會暴露出的缺點也是顯而易見的，所以到了現在的這個完全互聯網的時代，單體應用已經不適應時代的發展了！

微服務

什麼是微服務

微服務最初是由Martin Fowler在2014年的一篇文章中提出來的，簡單來說，就是將單一的程式開發成一個微服務，每個服務運行在自己的進程中，通常使用HTTP RESTful API的通訊風格，獨立部署的工程！

微服務特點

1、微服務單元按業務來劃分：服務到底要多「微」，這是一個很難的界定的概念，可以從三個方面來定義： 1、根據程式碼量定義 2、根據開發時間的長短來定義 3、根據業務大小來劃分按業務劃分的微服務是主流，各個微服務獨立部署，獨立運行在進程中。微服務單元是高度組件化的模組，並且提供了穩定的模組邊界，服務與服務之間沒有任何耦合。

2、微服務通過HTTP來互相通訊微服務之間通過簡單的HTTP來調用，更多的是使用RESTful API的風格來調用，實現了服務與語言和平台無關，例如：使用JAVA寫的微服務可以消費使用Python寫的服務。服務之間通訊也可以通過輕量級的消息匯流排來實現，例如：RabblitMQ、Kafaka等，通過發布-訂閱的設計模式來實現服務之間通訊。服務與服務之間通訊的數據格式一般使用的是json和xml，這兩個也是與語言、平台無關的，一般來說json更加高效、輕量。另一種是使用Protobuf進行數據的序列化，這種方式比json更加輕量，但是可讀性十分差，需要反序列化才能讀懂，所以在Protobuf在通訊協議和數據存儲中經常被使用到。

3、微服務的資料庫獨立服務會有他的獨立的資料庫，資料庫之間沒有任何的聯繫，這樣的好處在於，隨著業務的不斷擴張，資料庫相對獨立，數據量不會太大，易於維護；但是隨之而來的問題就是如何解決分散式的事務問題了；（這個在後續介紹）

4、微服務的自動部署一個大工程里會有許多的微服務，如果讓人工去手動部署的話，難免會出紕漏，但是隨著技術的發展，docker的容器化技術的出現，微服務的自動部署的出現，讓微服務的部署越來越簡便。

5、服務集中化管理隨著服務的增多，服務的管理也就越來越麻煩了，所以需要使用集中化的管理方式，市場上的主流框架就是 Spring Cloud提供的Eureka註冊中心來註冊服務和發現服務，另外，zookeeper和Consul都是優秀的服務集中化管理框架。

6、分散式的架構分散式的系統是集群部署的，通常是由許多台電腦共同完成了一個微服務的部署，而分散式的架構是通過HTTP來通訊的，所以我們的微服務可以搭建在相隔萬里的不同的兩台電腦上，對於空間沒有任何束縛。微服務架構是分散式的架構，而分散式的架構比單體架構更為複雜，主要要確定服務的獨立性和服務的准去可靠性，以及分散式事務、全局鎖、全局Id等問題，都是分散式系統需要考慮的。

7、熔斷機制為了防止一個服務出現bug，導致的系統資源的耗盡而引起的雪崩效應，系統應該對微服務具有一個熔斷機制；熔斷機制的意思就是：在一個微服務出現bug的時候，請求失敗次數達到一定的閾值之後，通過熔斷器讓這個微服務斷開服務主體，並且快速返回想要顯示的錯誤資訊，過一段時間後再重新連接測試，如此反覆的一個機制來保護整個系統的安全運作。 Spring Cloud中對於服務的熔斷提供了Hystrix來實現。

優劣

微服務的優勢： 1、服務進行拆分，每個服務只是負責小小的一塊內容，這讓複雜問題簡單化，開發、維護單個服務較為簡單； 2、微服務的系統是分散式的系統，服務與服務之間沒有任何耦合，隨著業務的增加，我們可以根據業務再拆分服務，這讓微服務系統具備很強大橫向擴展能力； 3、微服務之間完全通過HTTP協議來進行通訊，單個微服務內部高度耦合，服務與服務之間完全獨立； 4、重寫單個微服務的業務程式碼變得較為簡單； 5、微服務在CAP理論中採用的是AP架構，具有高可用（Availability）和分區容錯（Partition tolerance）的特點，高可用體現在系統7*24小時不斷的服務，它要求系統具有大量的伺服器集群配置，分區容錯性也讓系統更加的健壯。

微服務的劣勢： 1、微服務的複雜度比單體服務更為複雜，更難拆分，這讓我們的服務的架構設計上應該設計出一個很棒的架構！ 2、分散式的事務處理，如何處理分散式事務是一個業界所一直存在的問題，一般的處理方式是分為兩階段的提交:

第一個階段：服務通過發起一個分散式事務，交給事務協調器TC進行處理，事務調節器TC通過向所有參與該事物的服務節點發送處理事務的準備操作，所有的參與節點執行準備操作，將Undo和Redo資訊寫進日誌中，並且向事務管理器返回準備操作是否成功；第二階段：事務協調器TC在一定的時間閾值收集所有節點的準備操作是否成功，如果都成功，則通知所有的節點執行提交操作，如果有一個失敗了，則執行回滾操作！

微服務的設計原則

1、如果在LAMP單體架構夠用的情況下，就該使用LAMP，因為它開發速度快，性價比高，但是隨著業務的發展，用戶的激增，可以考慮把資料庫讀寫分離、加快取、加複雜均衡服務、將應用集群化部署等等，如果還不夠解決效率，那就可以考慮使用分散式系統，例如微服務的系統架構。 2、微服務在設計的時候一定要考慮到三大難題，服務故障的傳播性、服務的劃分、分散式事務的處理。總之，微服務的設計是漸進的，並且是隨著業務發展而發展的！