為什么要使用微服務(wù)架構(gòu)？【微服務(wù)架構(gòu)出現(xiàn)的背景】

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，傳統(tǒng)的應(yīng)用架構(gòu)已滿足不了實(shí)際需求，微服務(wù)架構(gòu)就隨之產(chǎn)生。那么傳統(tǒng)應(yīng)用架構(gòu)到底出了什么問(wèn)題呢?又如何解決?接下來(lái)我們將從傳統(tǒng)單體架構(gòu)的問(wèn)題開(kāi)始，對(duì)為什么需要微服務(wù)架構(gòu)進(jìn)行詳細(xì)講解。

傳統(tǒng)單體應(yīng)用架構(gòu)的問(wèn)題

通常我們所使用的傳統(tǒng)單體應(yīng)用架構(gòu)都是模塊化的設(shè)計(jì)邏輯，程序在編寫(xiě)完成后會(huì)被打包并部署為一個(gè)具體的應(yīng)用，而應(yīng)用的格式則依賴(lài)于相應(yīng)的應(yīng)用語(yǔ)言和框架。例如，在網(wǎng)上商城系統(tǒng)中，JavaWeb工程通常會(huì)被打成WA R包部署在Web服務(wù)器上，而普通Java工程會(huì)以JAR包的形式包含在WA R包中，如圖1-1所示。

早期單體架構(gòu)圖

上圖中的這種應(yīng)用開(kāi)發(fā)風(fēng)格很常見(jiàn)，它易于開(kāi)發(fā)和調(diào)試，并且易于部署。在用戶量不多時(shí)，此種架構(gòu)方式完全可以滿足需求，但隨著用戶人數(shù)的增加，一臺(tái)機(jī)器已經(jīng)滿足不了系統(tǒng)的負(fù)載，此時(shí)我們就會(huì)考慮系統(tǒng)的水平擴(kuò)展。通常情況下，我們只需要增加服務(wù)器的數(shù)量，并將打包好的應(yīng)用拷貝到不同服務(wù)器(如Tomcat)，然后通過(guò)負(fù)載均衡器(如Apache、Nginx)就可以輕松實(shí)現(xiàn)應(yīng)用的水平擴(kuò)展，如圖所示。

在早期，單體架構(gòu)的這種擴(kuò)展方式可以很好的滿足使用需求，但隨著時(shí)間的推移，這種方式就會(huì)產(chǎn)生很多問(wèn)題，具體表現(xiàn)如下：

1.應(yīng)用復(fù)雜度增加，更新、維護(hù)困難

一個(gè)簡(jiǎn)單的應(yīng)用會(huì)隨著時(shí)間的推移而逐漸變大。一旦應(yīng)用變的龐大而又復(fù)雜，那么開(kāi)發(fā)團(tuán)隊(duì)將會(huì)面臨很多問(wèn)題，其中最主要問(wèn)題就是這個(gè)應(yīng)用太復(fù)雜，以至于任何單個(gè)開(kāi)發(fā)者都很難進(jìn)行二次開(kāi)發(fā)或維護(hù)。

2.易造成系統(tǒng)資源浪費(fèi)

雖然使用負(fù)載均衡的方式可以對(duì)項(xiàng)目中的服務(wù)容量進(jìn)行水平擴(kuò)展，但由于傳統(tǒng)單體架構(gòu)的代碼中只有一個(gè)包含所有功能的WA R包，所以在對(duì)服務(wù)容量擴(kuò)容時(shí)，只能選擇重復(fù)的部署這個(gè)WA R包來(lái)擴(kuò)展服務(wù)能力，而不僅僅是擴(kuò)展了所需的服務(wù)。這樣導(dǎo)致其他不需要擴(kuò)展的服務(wù)也進(jìn)行了相應(yīng)的擴(kuò)展，但這種擴(kuò)展是不需要的，因此這種方式會(huì)極大的浪費(fèi)資源。

3.影響開(kāi)發(fā)效率

當(dāng)一個(gè)應(yīng)用越大時(shí)，啟動(dòng)時(shí)間就會(huì)越長(zhǎng)。開(kāi)發(fā)和調(diào)試的過(guò)程中，如果有很大一部分時(shí)間都要在等待中渡過(guò)，那么必然會(huì)對(duì)開(kāi)發(fā)效率有極大的影響。

4.應(yīng)用可靠性低

傳統(tǒng)單體應(yīng)用架構(gòu)在運(yùn)行時(shí)的可靠性比較低，當(dāng)所有模塊都運(yùn)行在一個(gè)進(jìn)程中時(shí)，如果任何一個(gè)模塊中出現(xiàn)了一個(gè)Bug，可能會(huì)導(dǎo)致整個(gè)進(jìn)程崩潰，從而影響到整個(gè)應(yīng)用。

5.不利于技術(shù)的更新

傳統(tǒng)單體應(yīng)用架構(gòu)一旦選定使用某些技術(shù)，則后期的開(kāi)發(fā)和擴(kuò)展將在這些技術(shù)的基礎(chǔ)上實(shí)現(xiàn)。如果需要更改某種技術(shù)，則可能需要將整個(gè)應(yīng)用全部重新開(kāi)發(fā)，這種成本是非常大的。當(dāng)然，傳統(tǒng)單體應(yīng)用架構(gòu)的問(wèn)題還不只這些，但出現(xiàn)這些問(wèn)題的根本原因可以說(shuō)就是由于傳統(tǒng)單體架構(gòu)中一個(gè)WA R包內(nèi)包含了系統(tǒng)的所有服務(wù)功能所導(dǎo)致的。隨著業(yè)務(wù)變的越來(lái)越多，問(wèn)題也就越來(lái)越多。

如何解決傳統(tǒng)應(yīng)用架構(gòu)的問(wèn)題

針對(duì)傳統(tǒng)單體架構(gòu)的問(wèn)題，大部分企業(yè)通過(guò)SOA(Service-Oriented Architecture，面向服務(wù)的架構(gòu))來(lái)解決上述問(wèn)題。SOA的思路是把應(yīng)用中相近的功能聚合到一起，以服務(wù)的形式提供出去，因此基于SOA架構(gòu)的應(yīng)用可以理解為一批服務(wù)的組合。

同樣以網(wǎng)上商城為例，一個(gè)簡(jiǎn)單的SOA系統(tǒng)如圖1-3所示。

SOA系統(tǒng)

從上圖可以看出，SOA將原來(lái)的單體架構(gòu)按照功能細(xì)分為不同的子系統(tǒng)，然后再由各個(gè)子系統(tǒng)依賴(lài)服務(wù)中間件(這里指企業(yè)服務(wù)總線Enterprise Service Bus，簡(jiǎn)稱(chēng)ESB)來(lái)調(diào)用所需服務(wù)。

使用SOA可以將系統(tǒng)切分成多個(gè)組件服務(wù)，這種通過(guò)多個(gè)組件服務(wù)來(lái)完成請(qǐng)求的方式有很多好處，具體如下：

l把項(xiàng)目拆分成若干個(gè)子項(xiàng)目，不同的團(tuán)隊(duì)可以負(fù)責(zé)不同的子項(xiàng)目，從而提高開(kāi)發(fā)效率;

l把模塊拆分，使用接口通信，降低了模塊之間的耦合度;

l為企業(yè)的現(xiàn)有資源帶來(lái)了更好的重用性;l能夠在最新的和現(xiàn)有的應(yīng)用之上創(chuàng)建應(yīng)用;

l能夠使客戶或服務(wù)消費(fèi)者免予服務(wù)實(shí)現(xiàn)的改變所帶來(lái)的影響;

l能夠升級(jí)單個(gè)服務(wù)或服務(wù)消費(fèi)者而無(wú)需重寫(xiě)整個(gè)應(yīng)用，也無(wú)需保留已經(jīng)不再適用于新需求的現(xiàn)有系統(tǒng)。

雖然使用SOA解決了單體架構(gòu)中的問(wèn)題，但多數(shù)情況下，SOA中相互獨(dú)立的服務(wù)仍然會(huì)部署在同一個(gè)運(yùn)行環(huán)境中(類(lèi)似于一個(gè)Tomcat實(shí)例下，運(yùn)行了很多web應(yīng)用)。和單體架構(gòu)類(lèi)似，隨著業(yè)務(wù)功能的增多，SOA的服務(wù)會(huì)變得越來(lái)越復(fù)雜。本質(zhì)上看，單體架構(gòu)的問(wèn)題并沒(méi)有因?yàn)槭褂肧OA而變的更好。

針對(duì)單體架構(gòu)和SOA的問(wèn)題，許多公司(如Amazon、eBay和NetFlix)通過(guò)采用微處理結(jié)構(gòu)模式解決了系統(tǒng)架構(gòu)中的問(wèn)題。其思路不是開(kāi)發(fā)一個(gè)巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。隨著微服務(wù)的使用，微服務(wù)架構(gòu)的思想也隨之產(chǎn)生。