你所不了解的微服务架构
一直以來,系統(tǒng)的架構(gòu)設(shè)計是IT領(lǐng)域經(jīng)久不衰的話題,也是構(gòu)建每一個系統(tǒng)最核心且重要的部分之一。它決定了系統(tǒng)能否滿足業(yè)務(wù)、技術(shù)、組織、靈活、可擴(kuò)展性等多種要求,同時肩負(fù)起了解放程序員生產(chǎn)力的作用。
2016年底,由于業(yè)務(wù)的不斷發(fā)展,我所在公司維護(hù)的項目也越來越“臃腫”。隨著無數(shù)個版本的迭代,以及開發(fā)人員的不斷增加,開發(fā)效率越來越低,每次投產(chǎn)的人力成本和時間成本都逐漸增加,我們一直在思索如何能破局。評估了各種方案后,最終微服務(wù)進(jìn)入了我們的視野。
談到微服務(wù),大家眾說紛紜,但卻很難有一個清晰的概念來描述。微服務(wù)不是“銀彈”,我理解的微服務(wù)是一種文化,而我們要做的就是將微服務(wù)的理念運(yùn)用到實際開發(fā)中。那么下面我們就來聊聊微服務(wù)架構(gòu)。
1.1 什么是微服務(wù)架構(gòu)
1.2 垂直應(yīng)用與微服務(wù)
1.3 實現(xiàn)一個最簡單的微服務(wù)框架
1.4 主流微服務(wù)框架介紹
隨著用戶需求個性化、產(chǎn)品生命周期變短,微服務(wù)架構(gòu)是未來軟件架構(gòu)朝著靈活性、擴(kuò)展性、伸縮性以及高可用性發(fā)展的必然方向。這里主要將對比傳統(tǒng)的垂直應(yīng)用與分布式微服務(wù)應(yīng)用之間的區(qū)別。
1.1 什么是微服務(wù)架構(gòu)
微服務(wù)是一種軟件架構(gòu)風(fēng)格,目標(biāo)是將一個復(fù)雜的應(yīng)用拆分成多個服務(wù)模塊,每個模塊專注單一業(yè)務(wù)功能對外提供服務(wù),并可以獨立編譯及部署,同時各模塊間互相通信彼此協(xié)作,組合為整體對外提供完整服務(wù)。
微服務(wù)架構(gòu)就像是活字印刷術(shù),每個文字模都可以看成是一個微服務(wù),它可以獨立地提供印刷服務(wù),又可以將模塊之間組合,最終形成一篇完整文章提供更為復(fù)雜的印刷服務(wù)。
由于每個模塊都獨立部署,各自擁有互不干擾的內(nèi)存空間,模塊之間無法直接調(diào)用,所以需要借助RPC(遠(yuǎn)程過程調(diào)用協(xié)議)或HTTP協(xié)議讓各個模塊之間傳遞通信報文及交換數(shù)據(jù),實現(xiàn)遠(yuǎn)程調(diào)用,整個通信管理的過程也是微服務(wù)架構(gòu)重要的組成部分。
1.2 垂直應(yīng)用與微服務(wù)
MVC模式構(gòu)建的垂直應(yīng)用非常適合項目初期,使用其能夠方便地進(jìn)行開發(fā)、部署、測試,但隨著業(yè)務(wù)的發(fā)展與訪問量的增加,垂直應(yīng)用的問題也隨之暴露出來,而微服務(wù)架構(gòu)可以很好地解決這些問題。
代碼維護(hù)
垂直應(yīng)用里,大部分邏輯都部署在一個集中化、單一的環(huán)境或服務(wù)器中運(yùn)行。垂直應(yīng)用程序通常很大,由一個大型團(tuán)隊或多個團(tuán)隊維護(hù)。龐大的代碼庫可能給希望熟悉代碼的開發(fā)人員增加學(xué)習(xí)成本,還會讓應(yīng)用程序開發(fā)過程中使用的開發(fā)環(huán)境工具和運(yùn)行容器不堪重負(fù),最終導(dǎo)致開發(fā)效率降低,可能會阻止對執(zhí)行更改的嘗試。
微服務(wù)架構(gòu)將這個龐大并且復(fù)雜的應(yīng)用拆分成多個邏輯簡單且獨立的小應(yīng)用,每個小應(yīng)用交由不同的團(tuán)隊或開發(fā)人員維護(hù),彼此之間互不干擾,通過標(biāo)準(zhǔn)接口互相通信。對于希望熟悉代碼的開發(fā)人員來說只需掌握他所負(fù)責(zé)的應(yīng)用即可,這樣做的好處是簡單、快速、邏輯清晰。
部署
垂直應(yīng)用需要處理一個龐大的應(yīng)用程序,編譯、部署需要花費(fèi)很長時間,一個小的修改就可能導(dǎo)致重新構(gòu)建整個項目。
微服務(wù)架構(gòu)中對其中某一個服務(wù)進(jìn)行修改,只需重新編譯、部署被改動的服務(wù)模塊。
資源控制
垂直應(yīng)用里,當(dāng)請求量過大導(dǎo)致單臺服務(wù)器無法支撐時,一般會將垂直應(yīng)用部署在多臺服務(wù)器形成服務(wù)集群,并通過反向代理實現(xiàn)負(fù)載均衡。集群中的每個服務(wù)必須部署完整的應(yīng)用,但在實際業(yè)務(wù)需求中僅有部分功能使用頻繁,但這種架構(gòu)必須為不常用的功能分配計算資源。
微服務(wù)將提供功能的各服務(wù)拆分為多個服務(wù)模塊,它具有天生的集群屬性,能夠輕松地根據(jù)用量部署。
例如系統(tǒng)中的消息功能使用頻率占了整個系統(tǒng)的90%,而密碼找回功能則只占到2%。為了分解消息功能的壓力,以傳統(tǒng)負(fù)載均衡的方式進(jìn)行集群化時,每個服務(wù)必須為使用量只有2%的密碼找回功能分配資源,這無疑造成了浪費(fèi)。
在微服務(wù)架構(gòu)中,消息功能使用率占據(jù)90%,則將消息模塊多部署幾個實例形成集群,而密碼找回功能所在的用戶模塊只部署一個就可以了。
穩(wěn)定
垂直應(yīng)用中如果有一個小的問題,就可能使整個系統(tǒng)崩潰。
微服務(wù)所拆分出的各個模塊中,由于模塊之間的耦合度很低,當(dāng)發(fā)生問題時影響范圍被固定在該模塊本身,整個系統(tǒng)依然健全。
1.3 實現(xiàn)一個最簡單的微服務(wù)框架
基本工作流程如下。
① 客戶端發(fā)起調(diào)用請求。
② 將調(diào)用的內(nèi)容序列化后通過網(wǎng)絡(luò)發(fā)給服務(wù)端。
③ 服務(wù)端接收到調(diào)用請求,執(zhí)行具體服務(wù)并獲得結(jié)果。
④ 將結(jié)果序列化后通過網(wǎng)絡(luò)返回給客戶端。
1.3.1 公共接口
在發(fā)起遠(yuǎn)程調(diào)用時,需要基于接口(Interface)來約定客戶端與服務(wù)端所調(diào)用服務(wù)的具體內(nèi)容。為了方便管理依賴關(guān)系,這里使用Maven構(gòu)建應(yīng)用并編寫一些接口,以提供給客戶端與服務(wù)端使用。
當(dāng)然也可以使用普通的Java應(yīng)用來實現(xiàn)此簡單微服務(wù)框架,只需將該應(yīng)用編譯后的jar包提供給后續(xù)的服務(wù)端與客戶端即可。
Maven 參數(shù)
編寫接口。
1.3.2 服務(wù)端
新建用于提供服務(wù)的Maven應(yīng)用,并引入剛編寫的接口應(yīng)用依賴。
Maven 參數(shù)
① 在pom.xml文件中引入依賴。
② 實現(xiàn)服務(wù)接口。
③ 編寫監(jiān)聽服務(wù)類。
register()
提供一個數(shù)組保存所注冊的服務(wù)接口及實現(xiàn)類。
start()
啟動一個阻塞式的Socket服務(wù)用于等待客戶端發(fā)起的調(diào)用請求,當(dāng)收到請求后將碼流反序列化成對象,并根據(jù)接口從注冊列表中尋找具體實現(xiàn)類,最終通過反射的方式調(diào)用該實現(xiàn)類返回結(jié)果。
④ 注冊服務(wù)并啟動服務(wù)端。
1.3.3 客戶端
新建用于調(diào)用服務(wù)的Maven應(yīng)用,并引入剛編寫的接口應(yīng)用依賴。
Maven 參數(shù)
① 在pom.xml文件中引入依賴。
② 編寫遠(yuǎn)程調(diào)用類。
使用JDK動態(tài)代理方式,根據(jù)提供的服務(wù)接口類將接口序列化成碼流,向目標(biāo)服務(wù)端發(fā)起Socket遠(yuǎn)程調(diào)用請求,獲得服務(wù)端反饋的結(jié)果并反序列化成對象后返回。
③ 調(diào)用測試。
運(yùn)行結(jié)果如下所示:
本章示例代碼詳見異步社區(qū)網(wǎng)站本書頁面。
1.3.4 完善框架
服務(wù)之間的調(diào)用已基本實現(xiàn),但想將它投入正式開發(fā)使用還有很多細(xì)節(jié)需要完善。
通信
當(dāng)請求過大后會發(fā)現(xiàn),BIO(同步阻塞式)的通信方式會消耗過多的資源導(dǎo)致服務(wù)器變慢甚至崩潰。
序列化與反序列化
在發(fā)起網(wǎng)絡(luò)請求前,將對象轉(zhuǎn)換成二進(jìn)制串便于網(wǎng)絡(luò)傳輸;收到消息請求后,將二進(jìn)制串反轉(zhuǎn)換成對象便于后續(xù)處理。序列化及反序列化直接影響到整個RPC框架的效率及穩(wěn)定性。
服務(wù)注冊中心
發(fā)起服務(wù)調(diào)用時,都需要指定服務(wù)提供方的訪問地址(ip + 端口),如果當(dāng)前服務(wù)提供方有多個或一個服務(wù)部署在多個機(jī)器上,調(diào)用時每次手動指定訪問地址非常麻煩,這時就需要一個公共的注冊中心去管理這些服務(wù)。
負(fù)載均衡
實施微服務(wù)的目的是為了讓系統(tǒng)在進(jìn)行橫向擴(kuò)展時能夠擁有更多的計算資源,如果發(fā)現(xiàn)某一提供服務(wù)的機(jī)器負(fù)載較大,這就需要將新的需求轉(zhuǎn)發(fā)到其他空閑的機(jī)器上。
服務(wù)監(jiān)控
服務(wù)提供方有可能崩潰無法繼續(xù)提供服務(wù),在客戶端進(jìn)行調(diào)用時就需要將這些無法使用的服務(wù)排除掉。
異常處理
當(dāng)服務(wù)端有異常發(fā)生導(dǎo)致無法返回正確的結(jié)果時,客戶端并不知道該如何處理,只能等待并最終以超時結(jié)束此次遠(yuǎn)程調(diào)用請求。
以上所有的問題在后續(xù)將要介紹的Dubbo與Spring Cloud分布式框架中都得到了很好的解決,甚至基于Spring Boot構(gòu)建的應(yīng)用能讓整個開發(fā)過程變得輕松愉快。
1.4 主流微服務(wù)框架介紹
1.4.1 Dubbo
阿里巴巴在2011年開源了Dubbo框架,雖然在2013年停止更新,但在2017年9月又重啟維護(hù)并發(fā)布了新版本。目前已有很多的公司將自己的業(yè)務(wù)建立在Dubbo之上,同時阿里云也推出了企業(yè)級分布式應(yīng)用服務(wù)EDAS,為Dubbo提供應(yīng)用托管。
Dubbo采用Zookeeper作為注冊中心,RPC作為服務(wù)調(diào)用方式,致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案。它與Spring無縫集成,基于服務(wù)提供方(服務(wù)端)與服務(wù)調(diào)用方(客戶端)角色構(gòu)建簡單模型,其優(yōu)點是使用方便、學(xué)習(xí)成本低。
0102.tif{60%}① 服務(wù)提供方發(fā)布服務(wù)到服務(wù)注冊中心。
② 服務(wù)消費(fèi)方從服務(wù)注冊中心訂閱服務(wù)。
③ 注冊中心通知消息調(diào)用方服務(wù)已注冊。
④ 服務(wù)消費(fèi)方調(diào)用已經(jīng)注冊的可用服務(wù)。
⑤ 監(jiān)控計數(shù)。
1.4.2 Spring Cloud
Spring Cloud基于Spring Boot實現(xiàn),使用HTTP的RESTful風(fēng)格API作為調(diào)用方式。它所包含的多個子項目共同構(gòu)建了微服務(wù)架構(gòu)體系。
0103.tif{70%}Netflix Eureka
Spring Cloud 的服務(wù)注冊中心提供服務(wù)注冊、服務(wù)發(fā)現(xiàn)、負(fù)載均衡等功能。
Netflix Hystrix
當(dāng)某個服務(wù)發(fā)生故障之后,則觸發(fā)熔斷機(jī)制(Hystrix)向服務(wù)調(diào)用方返回結(jié)果標(biāo)識錯誤,而不是一直等待服務(wù)提供方返回結(jié)果,這樣就不會使得線程因調(diào)用故障服務(wù)而被長時間占用不釋放,避免了故障在分布式系統(tǒng)中的蔓延。
Netflix Zuul
代理各模塊提供的服務(wù),統(tǒng)一暴露給第三方應(yīng)用。提供動態(tài)路由、監(jiān)控、彈性、全等的邊緣服務(wù)。
Config Server
分布式架構(gòu)下多微服務(wù)會產(chǎn)生非常多的配置文件,分布式配置中心(Config Server)將所有配置文件交由GIT或SVN進(jìn)行統(tǒng)一管理,避免出錯。
Spring Boot
在使用Spring開發(fā)時,通常需要完成Spring框架及其他第三方工具配置文件的編寫,非常麻煩。Spring Boot通過犧牲項目的自由度來減少配置的復(fù)雜度,約定一套規(guī)則,把這些框架都自動配置集成好,從而達(dá)到“開箱即用”。
本文摘自《微服務(wù)分布式構(gòu)架開發(fā)實戰(zhàn)》
《微服務(wù)分布式架構(gòu)開發(fā)實戰(zhàn)》
龔鵬rico 著
點擊封面購買紙書https://item.jd.com/25596768986.html
本書并沒有過多的探討理論性的東西,基于現(xiàn)有成熟框架,圍繞實際項目中遇見的具體需求,以微服務(wù)分布式架構(gòu)的角度去逐一分解并且實現(xiàn)這些需求。掌握這些知識的讀者,完全有能力快速搭建出可靠、高效、靈活的微服務(wù)分布式架構(gòu)。
微服務(wù)好書重磅推薦:
《深入理解Spring Cloud與微服務(wù)構(gòu)建》
方志朋 著
點擊封面購買紙書https://item.jd.com/12312724.html
本書主要針對Java開發(fā)者構(gòu)建微服務(wù)框架,作者比較青睞于Java 語言的Spring Cloud微服務(wù)框架,究其原因是Spring Cloud有快速開發(fā)、持續(xù)交付和易于部署等特點,且開源社區(qū)比較活躍,同時有國際巨頭公司的推動。本書在Spring Cloud框架范圍內(nèi),介紹了服務(wù)注冊和發(fā)現(xiàn)的Eureka組件、負(fù)載均衡Ribbon組件、熔斷器Hystrix組件、路由網(wǎng)關(guān)Zuul組件、Spring Cloud配置中心、服務(wù)鏈路追蹤等內(nèi)容,同時也與其他微服務(wù)框架做了對比,拓展了微服務(wù)知識的深度和廣度。本書結(jié)構(gòu)清晰,行文優(yōu)美,每一個例子都經(jīng)過作者斟酌再三,力求使用最簡單的例子,將復(fù)雜的邏輯原理闡述清楚,讓讀者印象深刻。
延伸推薦
你看過最有意思的科技類公眾號是什么?為什么?截止時間2月26日17時,小編將選出一名讀者贈送異步圖書一本。
點擊關(guān)鍵詞新書:
Python|機(jī)器學(xué)習(xí)|Kotlin|Java|移動開發(fā)|機(jī)器人|有獎活動|Web前端|書單
在“異步圖書”后臺回復(fù)“關(guān)注”,即可免費(fèi)獲得2000門在線視頻課程;推薦朋友關(guān)注根據(jù)提示獲取贈書鏈接,免費(fèi)得異步圖書一本。趕緊來參加哦!
點擊閱讀原文,查看本書更多信息
掃一掃上方二維碼,回復(fù)“關(guān)注”參與活動!
總結(jié)
以上是生活随笔為你收集整理的你所不了解的微服务架构的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【地图导航】3D地图软件是如何做路径规划
- 下一篇: #萌新日志#3.使用pix2pix Cy