微服務(wù)引出

從早期的單體架構(gòu),逐漸演化出SOA架構(gòu)模式,webService、ESB、Dubbo等等實(shí)現(xiàn)方式,到現(xiàn)在流行的微服務(wù)架構(gòu),核心解決問題,就是服務(wù)的高可用、高并發(fā).

而在大多數(shù)場(chǎng)景下,服務(wù)的高可用是我們尤為關(guān)心的(畢竟高并發(fā)并不是所有系統(tǒng)都需要),但高并發(fā)和高可用是相互影響,高并發(fā)說白了就是在大TPS下的高可用的支持.

微服務(wù)

微服務(wù)架構(gòu)中,各個(gè)業(yè)務(wù)單獨(dú)運(yùn)行,要求支持橫向擴(kuò)展.其要求每個(gè)子服務(wù)由單獨(dú)的緩存、單獨(dú)的數(shù)據(jù),盡量避免單點(diǎn)故障造成的服務(wù)雪崩.

微服務(wù)的基本架構(gòu),要求我們將系統(tǒng)根據(jù)不同領(lǐng)域分成一個(gè)個(gè)單體子服務(wù),那我們?cè)诓鸱址?wù)時(shí)有什么原則呢?

微服務(wù)拆分

常用的微服務(wù)拆分原則,常用有下面這四個(gè):

1. AKF拆分原則(AKF的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴(kuò)展的三個(gè)維度):理論上按照x,y,z三個(gè)擴(kuò)展模式，可以將一個(gè)單體系統(tǒng)，進(jìn)行無限擴(kuò)展。

   
   
   AKF

2. 前后端分離:前后端分開部署,互不影響

3. 無狀態(tài)服務(wù):無狀態(tài)服務(wù)原則并不是說在微服務(wù)架構(gòu)里就不允許存在狀態(tài)，表達(dá)的真實(shí)意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o狀態(tài)的計(jì)算類服務(wù)，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

4. Restful通信風(fēng)格:支持多語言,服務(wù)兼容性強(qiáng)

理想的微服務(wù)是要將系統(tǒng)按照業(yè)務(wù)的功能進(jìn)行拆分,直到每個(gè)服務(wù)的功能和職責(zé)單一,甚至不可拆分位置.這樣優(yōu)點(diǎn)是

1. 單機(jī)負(fù)荷小,服務(wù)耦合度小,內(nèi)聚性高,發(fā)布上線快
2. 故障影響小
3. 系統(tǒng)伸縮靈活
4. 擴(kuò)容成本可控

但缺點(diǎn)同樣明顯:

1. 服務(wù)數(shù)量過多,相互依賴關(guān)系服務(wù),系統(tǒng)管理難度加大
2. ,鏈路太長(zhǎng),問題排查困難

所以,實(shí)際項(xiàng)目中,我們需要根據(jù)業(yè)務(wù),能夠滿足上層服務(wù)對(duì)底層服務(wù)自由編排并獲得更多的業(yè)務(wù)功能即可,并需要根據(jù)組織團(tuán)隊(duì)人員的建設(shè)進(jìn)行調(diào)整.

微服務(wù)組合模式

業(yè)務(wù)被拆分為一個(gè)微服務(wù),這里總結(jié)下微服務(wù)間的組合模式:

1. 服務(wù)代理模式:通過一個(gè)代理層進(jìn)行服務(wù)轉(zhuǎn)發(fā),在系統(tǒng)遷移時(shí),通過新老系統(tǒng)雙寫、遷移數(shù)據(jù)、代理切換等操作可以平滑的進(jìn)行服務(wù)遷移

微服務(wù)代理模式

2. 服務(wù)聚合模式:常用的系統(tǒng)都如此,前端業(yè)務(wù)根據(jù)業(yè)務(wù)需要聚合底層的微服務(wù),如交易系統(tǒng)對(duì)外提供商戶定制服務(wù),根據(jù)需要,調(diào)用商戶系統(tǒng)獲取商戶數(shù)據(jù)、調(diào)用支付系統(tǒng)進(jìn)行交易、調(diào)用計(jì)費(fèi)系統(tǒng)進(jìn)行費(fèi)用計(jì)算.....

微服務(wù)聚會(huì)模式

3. 服務(wù)串聯(lián)模式:服務(wù)形成級(jí)聯(lián)模式,層層調(diào)用,最后返回結(jié)果,此模式切記層級(jí)不要太深,否則問題很難處理

微服務(wù)串聯(lián)模式

4. 服務(wù)分支模式: 串聯(lián)和聚合的組合,大多數(shù)微服務(wù)將形成此鏈路.因?yàn)閷?shí)際業(yè)務(wù)的復(fù)雜性,形成分支組合很常見,這也是我們?cè)谧鑫⒎?wù)治理時(shí),提出要全鏈路跟蹤的重要性原因.

微服務(wù)分支模式

5. 服務(wù)異步消息模式:通過消息隊(duì)列或異步定時(shí)處理,將長(zhǎng)鏈路拆分為短鏈路,提高系統(tǒng)的TPS,但這里就會(huì)引出后面提到的數(shù)據(jù)的最終一致性、異步補(bǔ)償措施等問題處理.

微服務(wù)異步消息模式

6. 服務(wù)共享數(shù)據(jù)模式:對(duì)于一些批處理、運(yùn)營(yíng)功能集中處理需求,我們經(jīng)常和各個(gè)微服務(wù)進(jìn)行數(shù)據(jù)共享,即公用相同數(shù)據(jù)庫(kù),但這些系統(tǒng)大多數(shù)是提供輔助功能

微服務(wù)共享模式

微服務(wù)的一致性設(shè)計(jì)

系統(tǒng)根據(jù)業(yè)務(wù)需求拆分成多個(gè)微服務(wù),狀態(tài)一致性問題將無處不在,我們一般遵守如下原則:

1. ACID理論:指數(shù)據(jù)庫(kù)中事務(wù)正確執(zhí)行的四個(gè)要素的縮小，包含原子性(Atomicity),一致性(Consistency),隔離性(Isolation),持久性(Durability)。當(dāng)用到分布式系統(tǒng)設(shè)計(jì)上同樣適用.

2. CAP原則:指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼。CAP定理明確了分布式系統(tǒng)所能實(shí)現(xiàn)系統(tǒng)的局限性，目前互聯(lián)網(wǎng)中的很多分布式系統(tǒng)是基于首要滿足可用性和分區(qū)容忍性而設(shè)計(jì)的。

3. BASE理論: BASE全稱是BasicallyAvailable（基本可用）, Soft-state（軟狀態(tài)/柔性事務(wù)）, Eventually Consistent（最終一致性）。BASE模型在理論邏輯上是相反于ACID（原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability）模型的概念，它犧牲高一致性，獲得可用性和分區(qū)容忍性。

常用的處理一致性實(shí)踐方法有很多,下面類舉常用5種:

1. 查詢模式:應(yīng)對(duì)超時(shí),異步調(diào)用失敗的常用方法.

2. 補(bǔ)償模式: 對(duì)于異步處理邏輯,總會(huì)出現(xiàn)各種各樣問題引起調(diào)用失敗,通過補(bǔ)償機(jī)制,我們實(shí)現(xiàn)最終的狀態(tài)一致性.

3. 異步回調(diào)確認(rèn)模式: 核心服務(wù)迅速返回,通過異步回調(diào),通知調(diào)用方進(jìn)行狀態(tài)變更

4. 定期校對(duì)模式: 對(duì)于數(shù)據(jù)定期掃描檢查,核對(duì)一致性.發(fā)現(xiàn)異常,即使預(yù)警糾正

5. 服務(wù)端冪等的可靠消息模式:服務(wù)端提高冪等服務(wù),消息發(fā)送端必須在接受服務(wù)端的成功反饋后才結(jié)束狀態(tài)同步操作.

微服務(wù)的容災(zāi)和降級(jí)

系統(tǒng)雪崩效應(yīng)是我們實(shí)際微服務(wù)部署中不可容忍的.常見的問題此處簡(jiǎn)單列舉些:

1. 用戶請(qǐng)求超過預(yù)估,數(shù)據(jù)庫(kù)壓力過大導(dǎo)致了響應(yīng)變慢---影響范圍最大
2. tomcat服務(wù)器超時(shí)斷開連接，但service邏輯仍然在運(yùn)轉(zhuǎn)。再加上,用戶系統(tǒng)不斷失敗重試,造成系統(tǒng)壓力累增.惡性循環(huán)下,直至系統(tǒng)崩潰.
3. 單個(gè)系統(tǒng)崩潰,引起對(duì)其依賴系統(tǒng)大范圍崩潰.
4. 緩存設(shè)置不當(dāng),造成緩存穿透,數(shù)據(jù)庫(kù)壓力集中時(shí)間點(diǎn)暴增

等等,影響系統(tǒng)崩潰的問題很多,其重點(diǎn)是我們?nèi)绾螌?zāi)難控制到最小.
本文由于篇幅原因,沒有重點(diǎn)分享這部分內(nèi)容,這里推薦大家看下微服務(wù)中Hystrix(https://github.com/Netflix/Hystrix/wiki/How-it-Works)的設(shè)計(jì)思想,從中總結(jié)對(duì)于微服務(wù)容災(zāi)和降級(jí)到處理方案,和找出適合自己業(yè)務(wù)的處理方案.

總結(jié)下其核心思想:

• 資源隔離：Hystrix通過艙壁模式來分隔服務(wù)提供者，使得某服務(wù)提供方失敗不會(huì)影響整個(gè)項(xiàng)目系統(tǒng)的穩(wěn)定性*
• 熔斷：Hystrix可以通過監(jiān)控一段事件內(nèi)的異常次數(shù)和響應(yīng)速度來判斷當(dāng)前服務(wù)的健康狀況，若服務(wù)健康狀況不佳則進(jìn)行熔斷，熔斷之后新的請(qǐng)求將不會(huì)調(diào)用實(shí)際的業(yè)務(wù)，而是通過快速失敗或降級(jí)的方式來快速給用戶進(jìn)行響應(yīng)
• 快速失敗：熔斷的后續(xù)選擇之一，直接返回失敗*
• 降級(jí)：熔斷的后續(xù)選擇之一，降級(jí)到靜態(tài)響應(yīng)或是下級(jí)服務(wù)*
• 監(jiān)控報(bào)警：提供近實(shí)時(shí)的監(jiān)控、報(bào)警和運(yùn)維手段

微服務(wù)項(xiàng)目結(jié)構(gòu)

微服務(wù)項(xiàng)目對(duì)外提供restful服務(wù),各語言間可以通過http傳輸json格式進(jìn)行通信.而常用的java微服務(wù)項(xiàng)目一般可以分為三層:服務(wù)發(fā)布層、接口層、實(shí)現(xiàn)層.

1. 發(fā)布層:提供對(duì)外web服務(wù)
2. 接口層:提供服務(wù)端和消費(fèi)端公用的類
3. 實(shí)現(xiàn)層:提供實(shí)際的業(yè)務(wù)實(shí)現(xiàn)

當(dāng)然實(shí)際項(xiàng)目中,根據(jù)各個(gè)公司規(guī)范,項(xiàng)目結(jié)構(gòu)可能有些出入,但基本三層接口大體一致.

微服項(xiàng)目結(jié)構(gòu)

總結(jié)

在實(shí)際工作中,微服務(wù)的拆分和部署更加復(fù)雜多變,我們要考慮的問題也更多.如對(duì)于系統(tǒng)故障的處理,如何做系統(tǒng)的失敗熔斷措施,如何實(shí)現(xiàn)對(duì)核心服務(wù)的限流保護(hù),甚至單系統(tǒng)中不同模塊的線程池隔離保護(hù)等等.

“編程路漫漫,修行在個(gè)人”,其實(shí)好多道理可能大家或多或少都接觸過,我們要做的就是不斷總結(jié)、反省、提煉、優(yōu)化,才能不斷提高自己藝術(shù)水平!

上一節(jié): 談?wù)勗O(shè)計(jì)思想(2)-延伸代碼設(shè)計(jì)思想和微服務(wù)思想
首頁(yè): 談?wù)勗O(shè)計(jì)思想(1)-從我認(rèn)識(shí)的支付架構(gòu)說起