公司重構(gòu)系統(tǒng)的時(shí)候我選擇了spring-cloud的微服務(wù)模式替代SpringMVC進(jìn)行代碼改造。在使用的一年半中磕磕絆絆遇到問題解決問題,但瑕不掩瑜,spring-cloud改變了以往的運(yùn)作方式,無論從運(yùn)維還是代碼開發(fā)都大大節(jié)約了人力成本。
現(xiàn)在跟大家分享下我為什么選擇spring-cloud,對比以往傳統(tǒng)架構(gòu)他的優(yōu)點(diǎn)是什么。理解不足或描述錯(cuò)誤的地方還請斧正。
順便說一句,歡迎轉(zhuǎn)載~請標(biāo)明出處。
常見的架構(gòu)
單體架構(gòu)
單體架構(gòu)在小微企業(yè)比較常見,一個(gè)應(yīng)用、一個(gè)數(shù)據(jù)庫、一個(gè)web容器就可以跑起來。
在兩種情況下可能會選擇單體架構(gòu):
一、在企業(yè)發(fā)展的初期,為了保證快速上線,采用此種方案較為簡單靈活;
二、傳統(tǒng)企業(yè)中垂直度較高,訪問壓力較小的業(yè)務(wù)。在這種模式下對技術(shù)要求較低,方便各層次開發(fā)人員接手,也能滿足客戶需求。?
單體架構(gòu)的架構(gòu)圖:?
在單體架構(gòu)中,技術(shù)選型非常靈活,優(yōu)先滿足快速上線的要求,也便于快速跟進(jìn)市場。?
垂直架構(gòu)
在單體架構(gòu)發(fā)展一段時(shí)間后,公司的業(yè)務(wù)模式得到了認(rèn)可,交易量也慢慢的大起來。這時(shí)候?yàn)榱藨?yīng)對更大的訪問流量,就會對原有的業(yè)務(wù)進(jìn)行拆分,比如說:后臺系統(tǒng)、前端系統(tǒng)、鑒權(quán)系統(tǒng)和業(yè)務(wù)系統(tǒng)等。
在這一階段往往會將系統(tǒng)分為不同的層級,每個(gè)層級有對應(yīng)的職責(zé)。UI層負(fù)責(zé)和用戶進(jìn)行交互、業(yè)務(wù)邏輯層負(fù)責(zé)具體的業(yè)務(wù)功能、數(shù)據(jù)庫層負(fù)責(zé)和上層進(jìn)行數(shù)據(jù)交換和存儲。比如我們開發(fā)的資產(chǎn)盤活和資產(chǎn)驗(yàn)收就是垂直架構(gòu)的系統(tǒng)。
垂直架構(gòu)的架構(gòu)圖:
在這個(gè)階段SSM(SpringMVC、Spring、MyBatis)是項(xiàng)目的關(guān)鍵技術(shù),SpringMVC負(fù)責(zé)邏輯控制、Spring負(fù)責(zé)業(yè)務(wù)層管理Bean、MyBatis負(fù)責(zé)數(shù)據(jù)庫操作進(jìn)行封裝,持久化數(shù)據(jù)。?
服務(wù)化架構(gòu)SOA
如果公司進(jìn)一步的做大,垂直子系統(tǒng)會變的越來越多,系統(tǒng)和系統(tǒng)之間的調(diào)用關(guān)系呈指數(shù)上升。在這樣的背景下很多公司都會考慮服務(wù)SOA化。
SOA代表面向服務(wù)的架構(gòu),將應(yīng)用程序根據(jù)不同的職責(zé)劃分為不同的模塊,不同的模塊直接通過特定的協(xié)議和接口進(jìn)行交互。
整個(gè)系統(tǒng)切分成很多單個(gè)組件服務(wù)來完成請求,當(dāng)流量過大時(shí)通過水平擴(kuò)展相應(yīng)的組件來支撐,所有的組件通過交互來滿足整體的業(yè)務(wù)需求。優(yōu)點(diǎn)是可以根據(jù)需求通過網(wǎng)絡(luò)對應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)化架構(gòu)是一套松耦合的架構(gòu),服務(wù)的拆分原則是服務(wù)內(nèi)部高內(nèi)聚,服務(wù)之間低耦合。?
服務(wù)化架構(gòu)圖:
SOA的隱性缺陷
當(dāng)集中式應(yīng)用轉(zhuǎn)變成分布式系統(tǒng)后,系統(tǒng)之間的相互可靠調(diào)用一直以來都是分布式架構(gòu)的難題。
網(wǎng)絡(luò)通信,序列化協(xié)議設(shè)計(jì)等很多技術(shù)細(xì)節(jié)需要確定。
一個(gè)高性能的框架,能夠構(gòu)建高可用的分布式系統(tǒng),系統(tǒng)地考慮各個(gè)應(yīng)用之間的分布式服務(wù)發(fā)現(xiàn)、服務(wù)路由、服務(wù)調(diào)用以及服務(wù)安全等細(xì)節(jié)。
對比SOA和微服務(wù)架構(gòu)
服務(wù)化架構(gòu)已經(jīng)可以解決大部分企業(yè)的需求了,為什么要研究微服務(wù)?
微服務(wù)架構(gòu)強(qiáng)調(diào):
業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化,一個(gè)組件就是一個(gè)產(chǎn)品,可以獨(dú)立對外提供服務(wù)。
不再強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線。
強(qiáng)調(diào)每個(gè)微服務(wù)都有自己獨(dú)立的運(yùn)行空間,包括數(shù)據(jù)庫資源。
源于互聯(lián)網(wǎng)的思路,服務(wù)強(qiáng)調(diào)了采用HTTP Rest API的方式來進(jìn)行
切分粒度會更小
微服務(wù)架構(gòu)是 SOA 架構(gòu)思想的一種擴(kuò)展,更加強(qiáng)調(diào)服務(wù)個(gè)體的獨(dú)立性、拆分粒度更小。
微服務(wù)架構(gòu)關(guān)鍵詞
有新的應(yīng)用上線應(yīng)該怎么辦?
應(yīng)用是運(yùn)維管理的基本單位
完整的應(yīng)用生命周期管理機(jī)制應(yīng)該包括:
1、應(yīng)用創(chuàng)建 2、部署 3、啟動(dòng) 4、回滾 5、擴(kuò)容縮容 6、停止下線等。
我們需要服務(wù)注冊和發(fā)現(xiàn)
服務(wù)中心將所有的可以提供的服務(wù)都注冊到它這里來管理,其它各調(diào)用者需要的時(shí)候去注冊中心獲取,然后再進(jìn)行調(diào)用,避免了服務(wù)之間的直接調(diào)用,方便后續(xù)的水平擴(kuò)展、故障轉(zhuǎn)移等。
隨著系統(tǒng)的流量不斷增加,需要根據(jù)情況來擴(kuò)展某個(gè)服務(wù),只需要增加相應(yīng)的服務(wù)端實(shí)例既可。
在系統(tǒng)的運(yùn)行期間服務(wù)中心有一個(gè)心跳檢測機(jī)制,如果某實(shí)例在規(guī)定的時(shí)間內(nèi)沒有進(jìn)行通訊則會自動(dòng)被剔除掉,避免了某個(gè)實(shí)例掛掉影響服務(wù)。從而實(shí)現(xiàn)了注冊、負(fù)載均衡、故障轉(zhuǎn)移的功能。
多應(yīng)用如何相互訪問才能保證安全?
一個(gè)好的服務(wù)框架要保證用戶每一次分布式調(diào)用的穩(wěn)定與安全。在服務(wù)注冊、服務(wù)訂閱以及服務(wù)調(diào)用等每一個(gè)環(huán)節(jié),都需要進(jìn)行嚴(yán)格的服務(wù)鑒權(quán)。
我們需要服務(wù)網(wǎng)關(guān)?
網(wǎng)關(guān)提供了動(dòng)態(tài)路由,監(jiān)控,彈性,安全等的邊緣服務(wù)。它的具體作用就是服務(wù)轉(zhuǎn)發(fā),接收并轉(zhuǎn)發(fā)所有內(nèi)外部的客戶端調(diào)用。作為資源的統(tǒng)一訪問入口,同時(shí)也可以做權(quán)限校驗(yàn)等類似的功能。
不同的服務(wù)一般有不同的網(wǎng)絡(luò)地址,而外部的客戶端可能需要調(diào)用多個(gè)服務(wù)的接口才能完成一個(gè)業(yè)務(wù)需求。
以資產(chǎn)盤活數(shù)據(jù)統(tǒng)計(jì)為例,可能會調(diào)用以下幾個(gè)服務(wù):
用戶微服務(wù)? 資產(chǎn)分類微服務(wù)? 訂單微服務(wù)等
如果客戶端直接和微服務(wù)進(jìn)行通信,會存在以下問題:
客戶端會多次請求不同服務(wù),增加復(fù)雜性。
存在跨域請求,處理復(fù)雜。
每一個(gè)服務(wù)都需要獨(dú)立認(rèn)證認(rèn)。
代碼難以重構(gòu)。
上述問題,都可以借助網(wǎng)關(guān)解決。微服務(wù)網(wǎng)管是介于客戶端和服務(wù)器端之間的中間層,所有的外部請求都會先經(jīng)過微服務(wù)網(wǎng)關(guān)。
應(yīng)用如何高效管控,服務(wù)又如何治理?
服務(wù)降級
流量管控
我們需要熔斷器
服務(wù)雪崩效應(yīng):一種因“服務(wù)提供者”的不可用導(dǎo)致“服務(wù)消費(fèi)者”的不可用,并將不可用逐漸放大的過程。
熔斷器在某個(gè)服務(wù)連續(xù)調(diào)用N次不響應(yīng)的情況下,立即通知調(diào)用端調(diào)用失敗,避免調(diào)用端持續(xù)等待而影響了整體服務(wù)。間隔一段時(shí)間后再次檢查此服務(wù),如果服務(wù)恢復(fù)將繼續(xù)提供服務(wù)。
不適用場景
核心無降級業(yè)務(wù):拍照驗(yàn)收時(shí)驗(yàn)收照片是業(yè)務(wù)核心,這時(shí)如果拍照服務(wù)無法使用整個(gè)資產(chǎn)驗(yàn)收服務(wù)就應(yīng)該終止。
適用場景
邊緣業(yè)務(wù)或者可降級的業(yè)務(wù):同樣是拍照,在資產(chǎn)盤活中上架物品對照片的需求沒有非常強(qiáng)烈,這時(shí)如果拍照服務(wù)出現(xiàn)問題,不應(yīng)該影響資產(chǎn)上架,就可以利用熔斷器來保證上架流程正常進(jìn)行。
運(yùn)維如何高效定位問題?
隨著服越來越多,對調(diào)用鏈的分析會越來越復(fù)雜。服務(wù)之間的調(diào)用關(guān)系、某個(gè)請求對應(yīng)的調(diào)用鏈、調(diào)用之間消費(fèi)的時(shí)間等,對這些信息進(jìn)行監(jiān)控就成為一個(gè)問題。
在實(shí)際的使用中我們需要監(jiān)控服務(wù)和服務(wù)之間通訊的各項(xiàng)指標(biāo),這些數(shù)據(jù)將是我們改進(jìn)系統(tǒng)架構(gòu)的主要依據(jù)。因此分布式的業(yè)務(wù)流程跟蹤就變的非常重要。
我們需要鏈路跟蹤
通過鏈路追蹤可以很清楚的了解到一個(gè)服務(wù)請求經(jīng)過了哪些服務(wù),每個(gè)服務(wù)處理花費(fèi)了多長時(shí)間。從而讓我們可以很方便的理清各微服務(wù)間的調(diào)用關(guān)系。
微服務(wù)的技術(shù)棧
Eureka進(jìn)行服務(wù)注冊發(fā)現(xiàn),連接微服務(wù)
Hystrix監(jiān)控服務(wù)調(diào)用進(jìn)行熔斷保護(hù)
Config提供了統(tǒng)一的配置中心服務(wù)
所有對外的請求和服務(wù)都通過Zuul來進(jìn)行轉(zhuǎn)發(fā),起到API網(wǎng)關(guān)的作用
使用Sleuth、Zipkin將所有的請求數(shù)據(jù)記錄下來,進(jìn)行后續(xù)分析
這些功能都是以插拔的形式提供出來,方便我們系統(tǒng)架構(gòu)演進(jìn)的過程中,可以合理的選擇需要的組件進(jìn)行集成,從而在架構(gòu)衍進(jìn)的過程中會更加平滑順利。