服務(wù)化到微服務(wù)

1、微服務(wù)的產(chǎn)生

　　隨著互聯(lián)網(wǎng)企業(yè)的不斷發(fā)展，海量用戶發(fā)起的大規(guī)模、高并發(fā)請(qǐng)求是企業(yè)不得不面對(duì)的，上一篇?架構(gòu)雜談《一》雜談的SOA服務(wù)化系統(tǒng)能夠分解任務(wù)，讓每個(gè)服務(wù)更簡(jiǎn)單、職責(zé)單一、更易于擴(kuò)展。但無論是Web Service 還是ESB，都有時(shí)代遺留下的問題。

　　Web Service：

　　　1）依賴中心化的服務(wù)發(fā)現(xiàn)機(jī)制

　　　2）使用SOAP通訊協(xié)議，通常使用XML格式來序列化通信數(shù)據(jù)，XML格式的數(shù)據(jù)冗余太大，協(xié)議太重

　　　3）服務(wù)化管理和治理設(shè)施并不完善

　?ESB：

　　　1）ESB 雖然是SOA實(shí)現(xiàn)的一種方式，卻更多地體現(xiàn)了系統(tǒng)集成的便利性，通過統(tǒng)一的服務(wù)總線將各個(gè)服務(wù)組合在一起

? ? ? ??2）組合在ESB上的服務(wù)本身有可能是一個(gè)臃腫的服務(wù)

　　　3）系統(tǒng)內(nèi)部的復(fù)雜性仍然存在。ESB試圖通過總線來掩蓋系統(tǒng)內(nèi)部的復(fù)雜性

? ? ? ? 4）對(duì)于總線本身中心化的管道模型，系統(tǒng)變更時(shí)影響的范圍會(huì)隨之?dāng)U大

出現(xiàn)問題解決問題是人類進(jìn)步的階梯，對(duì)于軟件架構(gòu)也是一樣，近年來服務(wù)架構(gòu)設(shè)計(jì)得到了進(jìn)一步的演化和發(fā)展，微服務(wù)架構(gòu)已經(jīng)出現(xiàn)在不同公司的討論、設(shè)計(jì)和實(shí)踐中，經(jīng)過市場(chǎng)檢驗(yàn)的東西肯定會(huì)被大家所接受。

　　微服務(wù)架構(gòu)提倡將軟件應(yīng)用設(shè)計(jì)成多個(gè)可獨(dú)立開發(fā)、配置、運(yùn)行和維護(hù)的子服務(wù)，子服務(wù)之間通過良好的接口定義通信機(jī)制，通常使用RESTful風(fēng)格的API形式來通信。因?yàn)镽ESTful 風(fēng)格的 API 通常是在 HTTP 或者 HTTPS 通道上傳輸 JSON 格式的數(shù)據(jù)來實(shí)現(xiàn)的， HTTP協(xié)議有跨語言、跨異構(gòu)系統(tǒng)的優(yōu)點(diǎn)，?當(dāng)然也可通過底層的二進(jìn)制協(xié)議、消息隊(duì)列協(xié)議等進(jìn)行交互。這些服務(wù)不需要中心化的統(tǒng)一管理，每個(gè)服務(wù)的功能可自治，并且可由不同的語言、系統(tǒng)和平臺(tái)實(shí)現(xiàn)?。?

　　微服務(wù)架構(gòu)致力于松耦合和高內(nèi)聚的效果，與SOA和ESB相比，不再強(qiáng)調(diào)服務(wù)總線和通信機(jī)制的多樣性，通常通過RESTful 風(fēng)格的API和輕量級(jí)的消息通信協(xié)議來完成。

微服務(wù)架構(gòu)并不是為了拆分而拆分，真正的目的是通過對(duì)微服務(wù)進(jìn)行水平擴(kuò)展解決傳統(tǒng)的單體應(yīng)用在業(yè)務(wù)急劇增長(zhǎng)時(shí)遇到的問題，而且由于拆分的微服務(wù)系統(tǒng)中專業(yè)的人做?專業(yè)的事，人員和項(xiàng)目的職責(zé)單一、低藕合、高內(nèi)聚，所以產(chǎn)生問題的概率就會(huì)降到最小。

2、微服務(wù)與單體的對(duì)比

?

（微服務(wù)架構(gòu)圖）

從上圖可以得到：

　　1）? 微服務(wù)把每一個(gè)職責(zé)單一的功能放在一個(gè)獨(dú)立的服務(wù)中

　　2）? 每個(gè)服務(wù)運(yùn)行在一個(gè)單獨(dú)的進(jìn)程中

　　3）? 每個(gè)服務(wù)有多個(gè)實(shí)例在運(yùn)行，每個(gè)實(shí)例可以運(yùn)行在容器化平臺(tái)內(nèi)

　　4）? 每個(gè)服務(wù)有自己的數(shù)據(jù)存儲(chǔ)，實(shí)際上，每個(gè)服務(wù)應(yīng)該有自己獨(dú)享的數(shù)據(jù)庫、緩存、消息隊(duì)列等

　　5）? 每個(gè)服務(wù)都可根據(jù)性能需求獨(dú)立地水平伸縮

?

（單體架構(gòu)圖）

通過對(duì)比，可以得到傳統(tǒng)單體架構(gòu)的特點(diǎn)：

　　1）? 傳統(tǒng)單體架構(gòu)將所有模塊化組件糅合后運(yùn)行在同一個(gè)服務(wù)的進(jìn)程中

　　2）? 某個(gè)模塊發(fā)生變更時(shí)，需要將所有的模塊編譯、打包上線

　　3）? 久而久之，模塊間的依賴將會(huì)不清晰，互相耦合，互相依賴成為常態(tài)

通過將兩種架構(gòu)對(duì)比來看，微服務(wù)架構(gòu)更加的靈活并且可水平伸縮，可以讓專業(yè)的人干專業(yè)的事。

3、微服務(wù)與SOA服務(wù)的對(duì)比

　　微服務(wù)架構(gòu)的一些特點(diǎn)與 SOA 服務(wù)化架構(gòu)相似， 事實(shí)上微服務(wù)架構(gòu)與 SOA 服務(wù)化架構(gòu)并不沖突，它們一脈相承，微服務(wù)架構(gòu)是服務(wù)化架構(gòu)響應(yīng)特定歷史時(shí)期的使用場(chǎng)景的延續(xù)，是服務(wù)化進(jìn)行升華井落地的一種實(shí)現(xiàn)方式。SOA 服務(wù)化的理念在微服務(wù)架構(gòu)中仍然有效，微服務(wù)在 SOA 服務(wù)化的基礎(chǔ)上進(jìn)行了演進(jìn)和疊加，形成了適合現(xiàn)代化應(yīng)用場(chǎng)景的一個(gè)方法論。

經(jīng)過幾十年互聯(lián)網(wǎng)的高速發(fā)展，以及敏捷、持續(xù)集成、持續(xù)交付、DevOps、云技術(shù)等的深入人心，服務(wù)架構(gòu)的開發(fā)、測(cè)試、部署以及監(jiān)控等，相比SOA已經(jīng)發(fā)生大的變化。

　　1）? SOA 服務(wù)化涉及的范圍更廣一些，強(qiáng)調(diào)不同的異構(gòu)服務(wù)之間的協(xié)作和契約 ，并強(qiáng)調(diào)有效集成、業(yè)務(wù)流程編排、歷史應(yīng)用集成等，典型代表為 Web Service 和 ESB

　　2）? 微服務(wù)使用一系列的微小服務(wù)來實(shí)現(xiàn)整體的業(yè)務(wù)流程，目的是有效地拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署，在每個(gè)微小服務(wù)的團(tuán)隊(duì)里，減少了跨團(tuán)隊(duì)的溝通，讓專業(yè)的人做專業(yè)的事，縮小變更和法代影響的范圍，并達(dá)到單一微服務(wù)更容易水平擴(kuò)展的目的

　　3）? 微服務(wù)將完整的應(yīng)用拆分成多個(gè)細(xì)小的服務(wù)，通常使用敏捷擴(kuò)容、縮容的 Docker 技術(shù)來實(shí)現(xiàn)自動(dòng)化的容器管理 ， 每個(gè)微服務(wù)運(yùn)行在單一的進(jìn)程內(nèi)，微服務(wù)中的部署互相獨(dú)立 、 互不影響。

　　4）? SOA 服務(wù)化通常將多個(gè)業(yè)務(wù)服務(wù)通過組件化模塊方式打在一個(gè)包里，然后統(tǒng)一部署在一個(gè)應(yīng)用服務(wù)器上。

　　6）? SOA 對(duì)粒度沒有要求 ， 在實(shí)踐中服務(wù)通常是粗粒度的，強(qiáng)調(diào)接口契約的規(guī)范化，內(nèi)部實(shí)現(xiàn)可以更粗粒度。

相比SOA的服務(wù)實(shí)現(xiàn)方式，微服務(wù)更具靈活性、可實(shí)施性以及可擴(kuò)展性，其強(qiáng)調(diào)的是一種獨(dú)立測(cè)試、獨(dú)立部署、獨(dú)立運(yùn)行的軟件架構(gòu)模式。對(duì)于微服務(wù)的概念而言，它是SOA的一個(gè)子集，而對(duì)于其實(shí)現(xiàn)方式而言，它是一種更符合現(xiàn)代化互聯(lián)網(wǎng)發(fā)展趨勢(shì)的實(shí)踐，是一種更容易幫助企業(yè)或組織有效并成功實(shí)施的服務(wù)架構(gòu)。

總結(jié)

最后讓我來總結(jié)下微服務(wù)架構(gòu)的主要特點(diǎn)

• 將傳統(tǒng)單體應(yīng)用拆分成網(wǎng)絡(luò)服務(wù)，來實(shí)現(xiàn)模塊化組件 。

• 根據(jù)微服務(wù)架構(gòu)的服務(wù)劃分來分組職能團(tuán)隊(duì)，減少跨團(tuán)隊(duì)的溝通 。

• 每個(gè)服務(wù)對(duì)應(yīng)一個(gè)團(tuán)隊(duì)，團(tuán)隊(duì)成員負(fù)責(zé)開發(fā)、測(cè)試、運(yùn)維和運(yùn)營(yíng) ，開發(fā)后在團(tuán)隊(duì)內(nèi)運(yùn)維和運(yùn)營(yíng)，不需要交付給其他團(tuán)隊(duì)。

• 去中 心化、 去 SOA 服務(wù)化的中 心服務(wù)治理和去企業(yè)服務(wù)總線 。

• 微服務(wù)重視服務(wù)的合理拆分、分層和構(gòu)造，可建設(shè)自動(dòng)化持續(xù)發(fā)布平臺(tái)，井進(jìn)行敏捷開發(fā)和部署。

?說明：

　　1、文中的圖都來自于百度圖片

　　2、參考書籍：《分布式服務(wù)架構(gòu)：原理、設(shè)計(jì)與實(shí)戰(zhàn)》

　　3、如有不合適的地方請(qǐng)反饋。綜合后更改。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的架构杂谈《二》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。