【51CTO.com原創(chuàng)稿件】 業(yè)務(wù)驅(qū)動(dòng)技術(shù)的發(fā)展是亙古不變的道理。最開始的時(shí)候，業(yè)務(wù)量少，業(yè)務(wù)復(fù)雜度低，采取的技術(shù)也相對(duì)簡(jiǎn)單，基本滿足用戶對(duì)功能的需求。
圖片來自 Pexels
隨著 IT 信息化的普及，更多的交易放到了網(wǎng)絡(luò)上，信息量增加和訪問次數(shù)頻繁就是要解決的問題了。
因此，逐漸加入了緩存、集群等技術(shù)手段。同時(shí)對(duì)業(yè)務(wù)的擴(kuò)展性和伸縮性的要求也越來越高。
高并發(fā)、高可用、可伸縮、可擴(kuò)展、夠安全的軟件架構(gòu)一直是架構(gòu)設(shè)計(jì)追求的目標(biāo)。
今天我們來看一下架構(gòu)設(shè)計(jì)經(jīng)歷了哪些階段，每個(gè)階段都解決了哪些問題，又引出了哪些新問題。
主要是引起大家的思考，在不同的業(yè)務(wù)發(fā)展階段采取合適技術(shù)手段，用變化擁抱變化是 IT 人追求的目標(biāo)。
應(yīng)用與數(shù)據(jù)一體模式
最早的業(yè)務(wù)應(yīng)用以網(wǎng)站、OA 等為主，訪問的人數(shù)有限，單臺(tái)服務(wù)器就能夠應(yīng)付。
通常，將應(yīng)用程序和數(shù)據(jù)庫(kù)部署到一臺(tái)服務(wù)器上面，如圖 1 所示：
圖 1：應(yīng)用與數(shù)據(jù)一體模式
在這一階段，我們利用 LAMP(Linux Apache MySQL PHP)技術(shù)就可以迅速搞定，并且這些工具都是開源的。
很長(zhǎng)一段時(shí)間內(nèi)，有各種針對(duì)這種應(yīng)用模式的開源代碼可以使用。這種模式基本上沒有高并發(fā)的要求，可用性也很差。
有的服務(wù)器采用托管模式，上面就安裝了不同的業(yè)務(wù)應(yīng)用，一旦服務(wù)器出現(xiàn)問題，所有的應(yīng)用就罷工了。
不過其開發(fā)和部署成本相對(duì)較低，適合剛剛起步的應(yīng)用服務(wù)。圖 1 就描述了單個(gè)應(yīng)用和數(shù)據(jù)庫(kù)運(yùn)行在單臺(tái)服務(wù)器的模式，我們稱這種模式為應(yīng)用與數(shù)據(jù)一體模式。
應(yīng)用與數(shù)據(jù)分離模式
隨著業(yè)務(wù)的發(fā)展，用戶數(shù)和請(qǐng)求數(shù)逐漸上升，服務(wù)器的性能出現(xiàn)了問題。其中比較簡(jiǎn)單的解決方案就是增加資源，將業(yè)務(wù)應(yīng)用和數(shù)據(jù)存儲(chǔ)分開。
其架構(gòu)圖如圖 2 所示：
圖 2：應(yīng)用與數(shù)據(jù)分離模式
其中，應(yīng)用服務(wù)器需要處理大量的業(yè)務(wù)請(qǐng)求，對(duì) CPU 和內(nèi)存有一定要求;而數(shù)據(jù)庫(kù)服務(wù)器需要對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)和索引等 IO 操作，對(duì)磁盤的轉(zhuǎn)速和內(nèi)存會(huì)考慮更多。
這樣的分離解決了性能的問題，我們需要擴(kuò)展更多的硬件資源讓其各司其職，使系統(tǒng)可以處理更多的用戶請(qǐng)求。
雖然業(yè)務(wù)上依舊存在耦和，但硬件層面的分離在可用性上比一體式設(shè)計(jì)要好很多。
緩存的加入
隨著信息化系統(tǒng)的發(fā)展和使用互聯(lián)網(wǎng)人數(shù)的增多，業(yè)務(wù)量、用戶量、數(shù)據(jù)量都在增長(zhǎng)。
我們同時(shí)發(fā)現(xiàn)，用戶會(huì)對(duì)某些數(shù)據(jù)的請(qǐng)求量特別大，例如新聞、商品信息和熱門消息。
之前這些信息的獲取方式是依靠數(shù)據(jù)庫(kù)，因此受到數(shù)據(jù)庫(kù) IO 性能的影響。此時(shí)數(shù)據(jù)庫(kù)成為了整個(gè)系統(tǒng)的瓶頸。
如果再增加服務(wù)器的數(shù)量，恐怕也很難解決，于是緩存技術(shù)就登場(chǎng)了，其架構(gòu)圖如圖 3 所示：
圖 3：緩存的加入
這里提到的緩存技術(shù)分為客戶端瀏覽器緩存、應(yīng)用服務(wù)器本地緩存和緩存服務(wù)器緩存。
①客戶端瀏覽器緩存：當(dāng)用戶通過瀏覽器請(qǐng)求服務(wù)器的時(shí)候，會(huì)發(fā)起 HTTP 請(qǐng)求。如果對(duì)每次 HTTP 請(qǐng)求進(jìn)行緩存，那么可以減少應(yīng)用服務(wù)器的壓力。
②應(yīng)用服務(wù)器本地緩存：它使用的是進(jìn)程內(nèi)緩存，又叫托管堆緩存。以 Java 為例，這部分緩存放在 JVM 的托管堆上面，同時(shí)會(huì)受到托管堆回收算法的影響。
由于它運(yùn)行在內(nèi)存中，對(duì)數(shù)據(jù)的響應(yīng)速度很快，通常我們會(huì)把熱點(diǎn)數(shù)據(jù)放在這里。
在進(jìn)程內(nèi)緩存沒有命中的時(shí)候，會(huì)到緩存服務(wù)器中獲取信息，如果還是沒有命中，才會(huì)去數(shù)據(jù)庫(kù)中獲取。
③緩存服務(wù)器緩存：它相對(duì)于應(yīng)用服務(wù)器本地緩存來說，就是進(jìn)程外緩存，既可以和應(yīng)用服務(wù)部署在同一服務(wù)器，也可以部署到不同的服務(wù)器。
一般來說，為了方便管理和合理利用資源，會(huì)將其部署到專門的緩存服務(wù)器上面。由于緩存會(huì)占用內(nèi)存空間，因此這類服務(wù)器會(huì)配置比較大的內(nèi)存。
圖 3 描述了緩存請(qǐng)求的次序，先訪問客戶端緩存，之后是進(jìn)程內(nèi)的本地緩存，接下來是緩存服務(wù)器，最后才是數(shù)據(jù)。
如果在任意一層獲取了緩存信息，就不再往下訪問了，否則會(huì)一直按照這個(gè)次序獲取緩存信息，直到數(shù)據(jù)庫(kù)。
用戶請(qǐng)求訪問數(shù)據(jù)的順序?yàn)榭蛻舳藶g覽器緩存→應(yīng)用服務(wù)器本地緩存→緩存服務(wù)器緩存。
如果按照以上次序還沒有命中數(shù)據(jù)，才會(huì)訪問數(shù)據(jù)庫(kù)獲取數(shù)據(jù)。加入緩存的設(shè)計(jì)，提高了系統(tǒng)的性能。
由于緩存放在內(nèi)存中，而內(nèi)存的讀取速度比磁盤要快得多，能夠很快響應(yīng)用戶請(qǐng)求。
特別針對(duì)一些熱點(diǎn)數(shù)據(jù)，優(yōu)勢(shì)尤為明顯。同時(shí)，在可用性方面也有明顯的改善。
即使數(shù)據(jù)庫(kù)服務(wù)器出現(xiàn)短時(shí)間的故障，緩存服務(wù)器中保存的熱點(diǎn)或者核心數(shù)據(jù)依舊可以滿足用戶暫時(shí)的訪問。當(dāng)然，后面還會(huì)對(duì)可用性進(jìn)行優(yōu)化。
服務(wù)器集群的加入
經(jīng)過前面三個(gè)階段的演進(jìn)，系統(tǒng)對(duì)用戶的請(qǐng)求量有了很好的支持。實(shí)際上，這都是在解決高性能和可用性的問題，這一核心問題會(huì)一直貫穿整個(gè)系統(tǒng)架構(gòu)的演進(jìn)過程中。
隨著用戶請(qǐng)求量的增加，另外一個(gè)問題又出現(xiàn)了，那就是并發(fā)。把這兩個(gè)字拆開了來看：并，理解為“一起并行“，有同時(shí)的意思;發(fā)，理解為“發(fā)出調(diào)用”，也就是請(qǐng)求的意思。
合起來就是多個(gè)用戶同時(shí)請(qǐng)求應(yīng)用服務(wù)器。如果說原來的系統(tǒng)面對(duì)的僅僅只是大數(shù)據(jù)量的話，那么現(xiàn)在就需要面對(duì)多用戶同時(shí)請(qǐng)求。
如果還是按照上一個(gè)階段的架構(gòu)圖推導(dǎo)，單個(gè)應(yīng)用服務(wù)器已經(jīng)無法滿足高并發(fā)的要求了。
此時(shí)，服務(wù)器集群就加入戰(zhàn)場(chǎng)了，其架構(gòu)圖如圖 4 所示：
圖 4：服務(wù)器集群的加入
服務(wù)器集群也就是多臺(tái)服務(wù)器扎堆的意思，用更多的服務(wù)器來分擔(dān)單臺(tái)服務(wù)器的負(fù)載壓力，提高性能和可用性。
再說白一點(diǎn)，就是提高單位時(shí)間內(nèi)服務(wù)處理請(qǐng)求的數(shù)量。原來是一個(gè)服務(wù)器處理，現(xiàn)在是一堆服務(wù)器來處理。就好像銀行柜臺(tái)一樣，增加柜員的人數(shù)來服務(wù)更多的人。
這次架構(gòu)演進(jìn)與上次相比，增加了應(yīng)用服務(wù)器的個(gè)數(shù)，用多臺(tái)應(yīng)用服務(wù)器形成集群。
應(yīng)用服務(wù)器中所部署的應(yīng)用服務(wù)沒有改變，在用戶請(qǐng)求與服務(wù)器之間加入了負(fù)載均衡器，幫助用戶請(qǐng)求路由到對(duì)應(yīng)的服務(wù)器中。增加服務(wù)器的舉動(dòng)表明，系統(tǒng)的瓶頸是在處理用戶并發(fā)請(qǐng)求上。
針對(duì)數(shù)據(jù)庫(kù)和緩存都沒有做更改，這樣僅僅通過增加服務(wù)器數(shù)量就能夠緩解請(qǐng)求的壓力。
服務(wù)器集群會(huì)通過多臺(tái)服務(wù)器來分擔(dān)原來一臺(tái)服務(wù)器需要處理的請(qǐng)求，在多臺(tái)服務(wù)器上同時(shí)運(yùn)行一套系統(tǒng)，因此可以同時(shí)處理大量并發(fā)的用戶請(qǐng)求。
有點(diǎn)三個(gè)臭皮匠頂個(gè)諸葛亮的意思，因此對(duì)集群中單個(gè)服務(wù)器的硬件要求也會(huì)降低。此時(shí)需要注意負(fù)載均衡均衡的算法，例如輪詢和加權(quán)輪詢。
我們要保證用戶請(qǐng)求能夠均勻分布到服務(wù)器上面，同一個(gè)會(huì)話的請(qǐng)求保證在同一個(gè)服務(wù)器上面處理，針對(duì)不同服務(wù)器資源的優(yōu)劣動(dòng)態(tài)調(diào)整流量。
負(fù)載均衡器加入之后，由于其位于互聯(lián)網(wǎng)與應(yīng)用服務(wù)器之間，負(fù)責(zé)用戶流量的接入，因此可以對(duì)用戶流量進(jìn)行監(jiān)控，同時(shí)對(duì)訪問用戶的身份和權(quán)限進(jìn)行驗(yàn)證。
數(shù)據(jù)庫(kù)讀寫分離
加入緩存可以解決部分熱點(diǎn)數(shù)據(jù)的讀取，但緩存數(shù)據(jù)的容量有限，那些非熱點(diǎn)的數(shù)據(jù)依舊會(huì)從數(shù)據(jù)庫(kù)中讀取。數(shù)據(jù)庫(kù)對(duì)于寫入和讀取的性能是不一樣的。
在寫入數(shù)據(jù)的時(shí)候，會(huì)造成鎖行或者鎖表，此時(shí)如果有其他寫入操作并發(fā)執(zhí)行，會(huì)存在排隊(duì)現(xiàn)象。
而讀取操作比寫入操作更加快捷，并且可以通過索引、數(shù)據(jù)庫(kù)緩存等方式實(shí)現(xiàn)。
因此，推出了數(shù)據(jù)庫(kù)讀寫分離的方案，其架構(gòu)圖如圖 5 所示：
圖 5：數(shù)據(jù)庫(kù)讀寫分離
此時(shí)設(shè)置了主從數(shù)據(jù)庫(kù)，主庫(kù)(master)主要用來寫入數(shù)據(jù)，然后通過同步 binlog 的方式，將更新的數(shù)據(jù)同步到從庫(kù)(slave)中。
對(duì)于應(yīng)用服務(wù)器而言，在寫數(shù)據(jù)的時(shí)候只需要訪問主庫(kù)，在讀數(shù)據(jù)的時(shí)候只用訪問從庫(kù)就好了。
利用數(shù)據(jù)庫(kù)讀寫分離的方式，將數(shù)據(jù)庫(kù)的讀/寫職責(zé)分離。利用讀數(shù)據(jù)效率較高的優(yōu)勢(shì)，擴(kuò)展更多的從庫(kù)，從而服務(wù)于讀取操作的用戶請(qǐng)求。畢竟在現(xiàn)實(shí)場(chǎng)景中，大多數(shù)操作都是讀取操作。
此外，從數(shù)據(jù)同步技術(shù)的角度來說，又可以分為同步復(fù)制技術(shù)、異步復(fù)制技術(shù)和半同步復(fù)制技術(shù)。在數(shù)據(jù)庫(kù)讀寫分離帶來益處的同時(shí)，架構(gòu)也需要考慮可靠性的問題。
例如，主庫(kù)如果掛掉，從庫(kù)如何接替主庫(kù)進(jìn)行工作。主庫(kù)在恢復(fù)以后，是成為從庫(kù)還是繼續(xù)擔(dān)當(dāng)主庫(kù)，以及如何同步數(shù)據(jù)的問題。
反向代理與 CDN
隨著互聯(lián)網(wǎng)的逐漸普及，人們對(duì)網(wǎng)絡(luò)安全和用戶體驗(yàn)的要求也越來越高。之前用戶都是通過客戶端直接訪問應(yīng)用服務(wù)器獲取服務(wù)，應(yīng)用服務(wù)器會(huì)暴露在互聯(lián)網(wǎng)中，容易遭到攻擊。
如果在應(yīng)用服務(wù)器與互聯(lián)網(wǎng)之間加上一個(gè)反向代理服務(wù)器，它接收用戶的請(qǐng)求，然后再轉(zhuǎn)發(fā)到內(nèi)網(wǎng)的應(yīng)用服務(wù)器，充當(dāng)外網(wǎng)與內(nèi)網(wǎng)之間的緩沖。
反向代理服務(wù)器只是做請(qǐng)求的轉(zhuǎn)發(fā)，在它上面沒有運(yùn)行任何應(yīng)用，因此當(dāng)有人攻擊它的時(shí)候，是不會(huì)影響到內(nèi)網(wǎng)的應(yīng)用服務(wù)器的。
這無形中保護(hù)了應(yīng)用服務(wù)器，提高了安全性。同時(shí)，它也在互聯(lián)網(wǎng)與內(nèi)網(wǎng)之間起到適配和網(wǎng)速轉(zhuǎn)換的作用。
例如，應(yīng)用服務(wù)器需要服務(wù)公網(wǎng)和教育網(wǎng)，但是兩個(gè)網(wǎng)絡(luò)的網(wǎng)速不同，可以在應(yīng)用服務(wù)器與互聯(lián)網(wǎng)之間放上兩臺(tái)反向代理服務(wù)器，一臺(tái)連接公網(wǎng)，另一臺(tái)連接教育網(wǎng)，屏蔽網(wǎng)絡(luò)差異，服務(wù)于更多的用戶群體。
如圖 6，公網(wǎng)客戶端和校園網(wǎng)客戶端分別來自公網(wǎng)與校園網(wǎng)兩個(gè)不同的網(wǎng)絡(luò)：
圖 6：加入反向代理服務(wù)器
由于兩個(gè)網(wǎng)絡(luò)訪問速度不同，因此會(huì)針對(duì)兩個(gè)網(wǎng)絡(luò)分別設(shè)置共網(wǎng)代理服務(wù)器和校園網(wǎng)代理服務(wù)器，通過這種方式將位于不通網(wǎng)絡(luò)的用戶請(qǐng)求接入到系統(tǒng)中。
聊完反向代理，再來說說 CDN，它的全稱是 Content Delivery Network，也就是內(nèi)容分發(fā)網(wǎng)絡(luò)。
如果把互聯(lián)網(wǎng)想象成一張大網(wǎng)的話，每個(gè)服務(wù)器或者客戶端就是分布式在網(wǎng)中的一個(gè)節(jié)點(diǎn)。
節(jié)點(diǎn)之間的距離有遠(yuǎn)有近，用戶請(qǐng)求會(huì)從一個(gè)節(jié)點(diǎn)跳轉(zhuǎn)到另外一個(gè)節(jié)點(diǎn)，最終跳轉(zhuǎn)到應(yīng)用服務(wù)器獲取信息。
如果跳轉(zhuǎn)的次數(shù)越少，就能夠更快地獲取信息，因此可以在離客戶端近的節(jié)點(diǎn)存放信息。
這樣用戶通過客戶端，只需要較少的跳轉(zhuǎn)次數(shù)就能夠觸達(dá)信息。由于這部分信息更新頻率不高，推薦存放一些靜態(tài)數(shù)據(jù)，例如 JavaScript 文件、靜態(tài)的 HTML、圖片文件等。
這樣客戶端就可以從離自己最近的網(wǎng)絡(luò)節(jié)點(diǎn)獲取資源，大大提高了用戶體驗(yàn)和傳輸效率。
加入 CDN 后的架構(gòu)圖如圖 7 所示：
圖 7：加入 CDN
CDN 的加入明顯加快了用戶訪問應(yīng)用服務(wù)器的速度，同時(shí)也減輕了應(yīng)用服務(wù)器的壓力，原來必須直接訪問應(yīng)用服務(wù)器的請(qǐng)求，不用經(jīng)過層層網(wǎng)絡(luò)，而只用找到最近的網(wǎng)絡(luò)節(jié)點(diǎn)就可以獲取資源。
但從請(qǐng)求資源的角度上來看，這種方式也有局限性，它只能對(duì)靜態(tài)資源起作用，需要定時(shí)對(duì) CDN 服務(wù)器進(jìn)行資源更新。反向代理和 CDN 的加入解決了安全性、可用性和高性能的問題。
分布式數(shù)據(jù)庫(kù)與分表分庫(kù)
經(jīng)歷前面幾個(gè)階段以后，軟件的系統(tǒng)架構(gòu)相對(duì)趨于穩(wěn)定。隨著系統(tǒng)運(yùn)行時(shí)間的增加，數(shù)據(jù)庫(kù)中累積的數(shù)據(jù)越來越多，同時(shí)系統(tǒng)還會(huì)記錄一些過程數(shù)據(jù)，例如操作數(shù)據(jù)和日志數(shù)據(jù)，這些數(shù)據(jù)也會(huì)加重?cái)?shù)據(jù)庫(kù)的負(fù)擔(dān)。
即便數(shù)據(jù)庫(kù)設(shè)置了索引和緩存，但在海量數(shù)據(jù)查詢的時(shí)候還會(huì)捉襟見肘。如果說讀寫分離，是將數(shù)據(jù)庫(kù)從讀寫層面進(jìn)行資源分配，那么分布式數(shù)據(jù)庫(kù)就需要從業(yè)務(wù)和數(shù)據(jù)層面對(duì)資源進(jìn)行分配。
①對(duì)于數(shù)據(jù)表來說，當(dāng)表中包含的記錄過多時(shí)，會(huì)將其分成多張表來存儲(chǔ)。
例如：有 1000 萬(wàn)個(gè)會(huì)員記錄，就可以將其分成兩個(gè) 500 萬(wàn)，分別放到兩個(gè)表中存儲(chǔ)。
也可以按照業(yè)務(wù)將表中的列進(jìn)行分割，把表中的某些列放到其他表中存儲(chǔ)，然后通過外鍵關(guān)聯(lián)到主表，被分割出去的列通常是不經(jīng)常訪問的數(shù)據(jù)。
②對(duì)于數(shù)據(jù)庫(kù)來說，每個(gè)數(shù)據(jù)庫(kù)能夠承受的最大連接數(shù)和連接池是有上限的。為了提高數(shù)據(jù)訪問效率，會(huì)根據(jù)業(yè)務(wù)需求對(duì)數(shù)據(jù)庫(kù)進(jìn)行分割，讓不同的業(yè)務(wù)訪問不同的數(shù)據(jù)庫(kù)。當(dāng)然，也可以將相同業(yè)務(wù)的不同數(shù)據(jù)放到不同的庫(kù)中存儲(chǔ)。
如果將這些數(shù)據(jù)庫(kù)資源分別放到不同的數(shù)據(jù)庫(kù)服務(wù)器中，就是分布式數(shù)據(jù)庫(kù)設(shè)計(jì)了。
由于數(shù)據(jù)存儲(chǔ)在不同的表/庫(kù)中，甚至在不同的服務(wù)器上面，在進(jìn)行數(shù)據(jù)庫(kù)操作的時(shí)候會(huì)增加代碼的復(fù)雜度。此時(shí)可以加入數(shù)據(jù)庫(kù)中間件來消除這些差異。
圖 8：分布式數(shù)據(jù)庫(kù)與分表分庫(kù)
架構(gòu)如圖 8 所示，將數(shù)據(jù)拆分以后分別放在表 1 和表 2 中，兩張表所在的數(shù)據(jù)庫(kù)服務(wù)器也各不相同，庫(kù)與庫(kù)之間還需要考慮數(shù)據(jù)同步的問題。
由于數(shù)據(jù)的分散部署，要從業(yè)務(wù)應(yīng)用獲取數(shù)據(jù)就需要依靠數(shù)據(jù)庫(kù)中間件幫忙。
數(shù)據(jù)庫(kù)的分表分庫(kù)以及分布式設(shè)計(jì)，會(huì)帶來性能的提升，同時(shí)也增大了數(shù)據(jù)庫(kù)管理和訪問的難度。原來只用訪問一張表和一個(gè)庫(kù)，現(xiàn)在需要跨越多張表和多個(gè)庫(kù)。
從軟件編程的角度來看，有一些數(shù)據(jù)庫(kù)中間件提供了最佳實(shí)踐，例如 MyCat 和 Sharding JDBC。
此外，從數(shù)據(jù)庫(kù)服務(wù)器管理的角度來看，需要監(jiān)控服務(wù)器的可用性。從數(shù)據(jù)治理的角度來看，需要考慮數(shù)據(jù)擴(kuò)容和數(shù)據(jù)治理的問題。
業(yè)務(wù)拆分
當(dāng)解決大數(shù)據(jù)量存儲(chǔ)問題以后，系統(tǒng)就能夠存儲(chǔ)更多的數(shù)據(jù)，這意味著能夠處理更多的業(yè)務(wù)。
業(yè)務(wù)量的增加，訪問數(shù)的上升，是任何一個(gè)軟件系統(tǒng)在任何時(shí)期都要面臨的嚴(yán)峻考驗(yàn)。
通過前面幾個(gè)階段的學(xué)習(xí)，我們知道系統(tǒng)提升基本依靠空間換取時(shí)間，使用更多的資源和空間處理更多的用戶請(qǐng)求。
隨著業(yè)務(wù)的復(fù)雜度越來越高，以及高并發(fā)的來臨，一些大廠開始將業(yè)務(wù)系統(tǒng)進(jìn)行切分，分開部署。
此時(shí)的架構(gòu)圖如圖 9 所示：
圖 9：業(yè)務(wù)拆分
如果說前面的服務(wù)器集群模式是將同一個(gè)應(yīng)用復(fù)制到不同的服務(wù)器上，那么業(yè)務(wù)拆分就是將一個(gè)應(yīng)用拆成多個(gè)部署到不同的服務(wù)器中。
此外，還可以對(duì)核心應(yīng)用進(jìn)行水平擴(kuò)展，將其部署到多臺(tái)服務(wù)器上。應(yīng)用雖然做了拆分，但應(yīng)用之間仍舊有關(guān)聯(lián)，存在應(yīng)用之間的調(diào)用、通信和協(xié)調(diào)問題。
由此也會(huì)引入隊(duì)列、服務(wù)注冊(cè)發(fā)現(xiàn)、消息中心等中間件，它們可以協(xié)助系統(tǒng)管理分布到不同服務(wù)器、網(wǎng)絡(luò)節(jié)點(diǎn)上的應(yīng)用。
業(yè)務(wù)拆分以后會(huì)形成一個(gè)個(gè)應(yīng)用服務(wù)，既有基于業(yè)務(wù)的服務(wù)，例如商品服務(wù)、訂單服務(wù)，也有基礎(chǔ)服務(wù)，例如消息推送和權(quán)限驗(yàn)證。
這些應(yīng)用服務(wù)連同數(shù)據(jù)庫(kù)服務(wù)器分布在不同的容器、服務(wù)器、網(wǎng)絡(luò)節(jié)點(diǎn)中，對(duì)它們的通信、協(xié)調(diào)、管理和監(jiān)控都是我們需要解決的問題。
分布式與微服務(wù)
近幾年，微服務(wù)是比較火的架構(gòu)方式，它將業(yè)務(wù)應(yīng)用進(jìn)行更加精細(xì)化的切割，使之成為更加小的業(yè)務(wù)模塊。
做到模塊的高內(nèi)聚低耦合，每個(gè)模塊可以獨(dú)立存在，由獨(dú)立的團(tuán)隊(duì)維護(hù)。每個(gè)模塊內(nèi)部可以采取特有的技術(shù)，而不用關(guān)心其他模塊的技術(shù)實(shí)現(xiàn)。
模塊通過容器的部署運(yùn)行，模塊之間通過接口和協(xié)議進(jìn)行調(diào)用。任何一個(gè)模塊都可以將自己公開給其他的模塊調(diào)用。
同時(shí)可以將熱點(diǎn)模塊進(jìn)行水平擴(kuò)展，增強(qiáng)系統(tǒng)的性能。當(dāng)其中某一個(gè)模塊出現(xiàn)問題時(shí)，又可以由其他相同的模塊代替其工作，增強(qiáng)了可用性。
大致總結(jié)下來，微服務(wù)擁有以下特點(diǎn)，業(yè)務(wù)精細(xì)化拆分、自治性、技術(shù)異構(gòu)性、高性能、高可用。
它像極了分布式架構(gòu)，下面來看看它們的區(qū)別，如圖 10 所示：
圖 10：分布式與微服務(wù)的區(qū)別
從概念上理解，它們都做了“拆”的動(dòng)作，但在下面這幾個(gè)方面存在區(qū)別：
①拆分目的不同：分布式設(shè)計(jì)是為了解決單體應(yīng)用資源有限的問題，在一個(gè)服務(wù)器上無法支撐更高的用戶訪問，因此將一個(gè)應(yīng)用拆解成不同的部分，然后將其部署到不同服務(wù)器上，從而分擔(dān)高并發(fā)的壓力。
微服務(wù)是對(duì)服務(wù)組件進(jìn)行精細(xì)化，目的是更好地解耦，讓服務(wù)之間通過組合完成高性能、高可用、可伸縮、可擴(kuò)展。
②拆分方式不同：分布式服務(wù)架構(gòu)將系統(tǒng)按照業(yè)務(wù)和技術(shù)分類進(jìn)行拆分，目的是讓拆分的服務(wù)負(fù)載原來單一服務(wù)的業(yè)務(wù)。
微服務(wù)則是在分布式的基礎(chǔ)上進(jìn)行更細(xì)的拆分，它將服務(wù)拆成更小的模塊，更加專業(yè)化，分工更加精細(xì)，并且每個(gè)小模塊都可以獨(dú)立運(yùn)行。
③部署方式不同：分布式將服務(wù)拆分以后，通常會(huì)部署到不同的服務(wù)器上。
而微服務(wù)也可以將不同的服務(wù)模塊放到不同的服務(wù)器上，同時(shí)它也可以在一個(gè)服務(wù)器上部署多個(gè)微服務(wù)，或者同一個(gè)微服務(wù)的多個(gè)備份，并且多使用容器的方式部署。
雖然分布式與微服務(wù)有以上區(qū)別，但從實(shí)踐的角度來看，它們都是基于分布式架構(gòu)的思想構(gòu)建的。
微服務(wù)是分布式的進(jìn)化版本，也是分布式的子集。它同樣會(huì)遇到服務(wù)拆分、服務(wù)通信、協(xié)同、管理調(diào)度等問題。
總結(jié)
本文按照技術(shù)跟隨業(yè)務(wù)變化的思路，描述從單體架構(gòu)到集群，再到分布式架構(gòu)以及微服務(wù)的發(fā)展階段，講述了每個(gè)軟件架構(gòu)階段變化的特點(diǎn)，前后架構(gòu)更替的原因和關(guān)系，說明了軟件架構(gòu)發(fā)展會(huì)一直隨著業(yè)務(wù)發(fā)展的方向變化。遵循高性能，高可用，伸縮性，擴(kuò)展性，安全性的架構(gòu)目的。
【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】
聯(lián)系客服
