Spring Cloud微服務的概念是什么

本篇文章為大家展示了Spring Cloud微服務的概念是什么，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

單體架構(gòu)

簡介

在軟件設計中，頻繁被使用的就是我們的經(jīng)典三層架構(gòu)了。
1、表示層：用于直接與用戶進行交互，通常是頁面、UI等；
2、業(yè)務邏輯層（service）：用于處理業(yè)務，比如用戶從表示層輸入了消息就要經(jīng)過業(yè)務邏輯層的邏輯處理之后再進行的相關操作；
3、數(shù)據(jù)訪問層（dao）：用于與數(shù)據(jù)庫進行交互；

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

優(yōu)劣

單體應用的優(yōu)勢在于：
1、性價比非常高，通常只需要一臺服務器就能夠把項目跑起來；
2、開發(fā)的速度也比較快，運維較簡單，項目架構(gòu)比較簡單明了，適合小型應用開發(fā)。

單體應用的劣勢在于：
1、所有的業(yè)務相關操作都放在了一個服務器上，如果項目中某個業(yè)務出現(xiàn)了bug，不急時發(fā)現(xiàn)就會導致整個項目的癱瘓，最終宕機，而這對于一個大型網(wǎng)站來說無疑是十分致命的問題；
2、業(yè)務越來越復雜的時候，單體應用的代碼量就會越來越多，導致最后的代碼可讀性、可維護性越來越差，最終只能進行重構(gòu)；
3、用戶越來越多的時候，單體應用的并發(fā)能力有限；

由此可見：在應用初期，單體應用從成本、開發(fā)時間和運維等方面都有優(yōu)勢，但是單體應用會隨著業(yè)務量和用戶量的增加，會暴露出的缺點也是顯而易見的，所以到了現(xiàn)在的這個完全互聯(lián)網(wǎng)的時代，單體應用已經(jīng)不適應時代的發(fā)展了！

微服務

什么是微服務

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

微服務特點

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

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

3、微服務的數(shù)據(jù)庫獨立
服務會有他的獨立的數(shù)據(jù)庫，數(shù)據(jù)庫之間沒有任何的聯(lián)系，這樣的好處在于，隨著業(yè)務的不斷擴張，數(shù)據(jù)庫相對獨立，數(shù)據(jù)量不會太大，易于維護；
但是隨之而來的問題就是如何解決分布式的事務問題了；（這個在后續(xù)介紹）

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

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

6、分布式的架構(gòu)
分布式的系統(tǒng)是集群部署的，通常是由許多臺計算機共同完成了一個微服務的部署，而分布式的架構(gòu)是通過HTTP來通信的，所以我們的微服務可以搭建在相隔萬里的不同的兩臺計算機上，對于空間沒有任何束縛。
微服務架構(gòu)是分布式的架構(gòu)，而分布式的架構(gòu)比單體架構(gòu)更為復雜，主要要確定服務的獨立性和服務的準去可靠性，以及分布式事務、全局鎖、全局Id等問題，都是分布式系統(tǒng)需要考慮的。

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

優(yōu)劣

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

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

第一個階段：服務通過發(fā)起一個分布式事務，交給事務協(xié)調(diào)器TC進行處理，事務調(diào)節(jié)器TC通過向所有參與該事物的服務節(jié)點發(fā)送處理事務的準備操作，所有的參與節(jié)點執(zhí)行準備操作，將Undo和Redo信息寫進日志中，并且向事務管理器返回準備操作是否成功；
第二階段：事務協(xié)調(diào)器TC在一定的時間閾值收集所有節(jié)點的準備操作是否成功，如果都成功，則通知所有的節(jié)點執(zhí)行提交操作，如果有一個失敗了，則執(zhí)行回滾操作！

微服務的設計原則

1、如果在LAMP單體架構(gòu)夠用的情況下，就該使用LAMP，因為它開發(fā)速度快，性價比高，但是隨著業(yè)務的發(fā)展，用戶的激增，可以考慮把數(shù)據(jù)庫讀寫分離、加緩存、加復雜均衡服務、將應用集群化部署等等，如果還不夠解決效率，那就可以考慮使用分布式系統(tǒng)，例如微服務的系統(tǒng)架構(gòu)。
2、微服務在設計的時候一定要考慮到三大難題，服務故障的傳播性、服務的劃分、分布式事務的處理?？傊?，微服務的設計是漸進的，并且是隨著業(yè)務發(fā)展而發(fā)展的！

上述內(nèi)容就是Spring Cloud微服務的概念是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。