web設(shè)計模式有哪些架構(gòu)

這篇文章主要介紹“web設(shè)計模式有哪些架構(gòu)”，在日常操作中，相信很多人在web設(shè)計模式有哪些架構(gòu)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”web設(shè)計模式有哪些架構(gòu)”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

 一、什么是架構(gòu)

我想這個問題，十個人回答得有十一個答案，因為另外的那一個是大家妥協(xié)的結(jié)果，哈哈，我理解，架構(gòu)就是骨架

人類的身體的支撐是主要由骨架來承擔的，然后是其上面的肌肉、神經(jīng)、皮膚。架構(gòu)對于軟件的重要性不亞于骨架對人類身體的重要性。

二、什么是設(shè)計模式

這個問題我問過的面試者不下數(shù)十次，回答五花八門，在我看來，模式就是經(jīng)驗，涉及模式就是涉及經(jīng)驗，有了這些經(jīng)驗，我們就能在特定情況下使用特定的設(shè)計、組合設(shè)計。這樣可以大大節(jié)省我們的設(shè)計時間，提高工作效率。

作為一個老碼農(nóng)，經(jīng)理的系統(tǒng)架構(gòu)設(shè)計也不算少，接下來，我會把工作中用到的一些架構(gòu)方面的設(shè)計模式分享給大家，望大家少走彎路?？傮w而言，有八種，分別是：

1、單庫單應(yīng)用模式：最簡單的，可能大家都見過

2、內(nèi)容分發(fā)模式：目前用的比較多

3、查詢分類模式：對于大并發(fā)的查詢、業(yè)務(wù)。

4、微服務(wù)模式：適用于復(fù)雜的業(yè)務(wù)模式的拆解

5、多級緩存模式：可以把緩存玩的很好

6、分庫分表模式：解決單及數(shù)據(jù)庫瓶頸

7、彈性伸縮模式：解決波峰波谷業(yè)務(wù)的流量不均勻的方法之一

8、多機房模式：解決高可用、高性能的一種方法

三、單庫單應(yīng)用模式

這是最簡單的一種設(shè)計模式，我們的大部分本科畢業(yè)設(shè)計、一些小的應(yīng)用，基本上都是這種模式，這種模式的一般設(shè)計見下圖：

如上圖所示，這種模式一般只有一個數(shù)據(jù)庫，一個業(yè)務(wù)應(yīng)用層，一個后臺管理系統(tǒng)，所有的業(yè)務(wù)都是用業(yè)務(wù)層完成的，所有的數(shù)據(jù)也都是存儲在一個數(shù)據(jù)庫中，好一點會有數(shù)據(jù)庫的同步，雖然簡單，但是也并不是一無是處。

優(yōu)點：結(jié)構(gòu)簡單、開發(fā)速度快、實現(xiàn)簡單，可用于產(chǎn)品的第一版等有原型驗證需求。

缺點：性能差、基本沒有高可用、擴展性差，不適合用于大規(guī)模部署、應(yīng)用等生產(chǎn)環(huán)境。

四、內(nèi)容分發(fā)模式

基本上所有的大型的網(wǎng)站都有或多或少的采用這一種設(shè)計模式，常見的應(yīng)用場景是采用CDN技術(shù)把網(wǎng)頁、圖片、CSS、JS等這些靜態(tài)資源分發(fā)到離用戶最近的服務(wù)器，這種模式的一般設(shè)計見下圖：

如上圖所示，這種模式較單庫單應(yīng)用的模式多了一個CDN、一個云存儲OSS(七牛、又拍等雷同)。一個經(jīng)典的應(yīng)用流程(以用戶上傳、查看圖片需求為例如下：)

1、上傳的時候，用戶選擇本地機器上的一個圖片進行上傳

2、程序會把這個圖片上傳到云存儲OSS上，并返回該圖片的一個URL

3、程序把這個URL字符串存儲在業(yè)務(wù)數(shù)據(jù)庫中，上傳完成

4、查看的時候，程序從業(yè)務(wù)數(shù)據(jù)庫得到該圖片的URL

5、程序通過DNS查詢到這個URL的圖片服務(wù)器

6、智能DNS會解析這個URL，得到于用戶最近的服務(wù)器(或集群)的地址A

7、然后把服務(wù)器A上的圖片返回給程序

8、程序顯示該圖片，查看完成

由上可知，這個模式的關(guān)鍵是智能DNS，它能夠解析出離用戶最近的服務(wù)器，運行原理大致是：根據(jù)請求者的IP得到請求地點B，然后通過計算或者配置得到與B最近或通訊時間最短的服務(wù)器C，然后把C的IP地址返回給請求者。這種模式的優(yōu)缺點如下：

優(yōu)點：資源下載快，無需過多的開發(fā)與配置，同時也減輕了后端服務(wù)器對資源的存儲壓力，減少帶寬的使用。

缺點：目前來說OSS、CDN的價格還是稍微有點貴的，只適用于中小規(guī)模的應(yīng)用，另外由于網(wǎng)絡(luò)傳輸延遲、CDN的同步策略等，會有一些一致性、更新慢方面的問題。

五、查詢分離模式

這種模式主要解決單及數(shù)據(jù)庫壓力過大，從而導(dǎo)致業(yè)務(wù)緩慢甚至超時，查詢影響時間變長的問題，也包括需要大量數(shù)據(jù)庫服務(wù)器計算資源的查詢請求，這個可以說是單庫應(yīng)用模式的升級版本，也是技術(shù)架構(gòu)迭代演進過程中的必經(jīng)之路。

這種模式的一般設(shè)計如下圖：

如上圖所示，這種模式較單庫但應(yīng)用模式與內(nèi)容分發(fā)模式多了幾個部分，一個是業(yè)務(wù)數(shù)據(jù)庫的主從分離，一個是引入ES，為什么要這樣?都解決的哪些痛點，下面具體結(jié)合業(yè)務(wù)需求場景進行敘述。

場景一：全文關(guān)鍵詞檢索

我想這個需求，絕大多數(shù)應(yīng)用都會有，如果使用傳統(tǒng)的數(shù)據(jù)庫技術(shù)，大部分可能會使用like這種sql語句，高級一點的是先分詞，然后同分詞index相關(guān)的記錄。sql語句的性能問題與全表掃描機制導(dǎo)致了非常嚴重的性能問題，現(xiàn)在基本上很少見到。

ES較Solr配置簡單、使用方便，所以這里選用了他。另外，ES支持橫向擴展，理論上沒有性能的瓶頸。同時，還支持各種插件、自定義分詞器等，可擴展性較強。在這里，使用ES不僅可以替代數(shù)據(jù)庫完成全檢索功能，還可以實現(xiàn)諸如分頁、排序、分組、分面等功能。具體的，請同學(xué)們自行學(xué)習(xí)之，那怎么使用呢?一個一般的流程是這樣的：

1、服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)落庫

2、服務(wù)器異步把該條數(shù)據(jù)發(fā)送到ES

3、ES把該條記錄按照規(guī)則、配置放入自己的索引庫

4、客戶端查詢的時候，由服務(wù)端把這個請求發(fā)送到ES，得到數(shù)據(jù)后，根據(jù)需求拼裝、組合數(shù)據(jù)，返回給客戶端

實際中怎么用，還請同學(xué)們根據(jù)實際情況做組合、取舍

場景二：大量的普通查詢

這個場景是指我們的業(yè)務(wù)中的大部分輔助性的查詢，如：取錢的時候先查詢一下余額，根據(jù)用戶的ID查詢用戶的記錄，取得該用戶最新的一條取錢記錄等，我們肯定是要天天用到的，而且用的還非常多。同時呢，我們的寫入請求也是非常多的，導(dǎo)致大量的寫入、查詢操作壓向同一數(shù)據(jù)庫，然后，數(shù)據(jù)庫掛了，系統(tǒng)掛了，領(lǐng)導(dǎo)生氣了，被開除了，還不起房貸了，露宿街頭了，老婆跟別人跑了……

不敢想，所以要求我們必須分散數(shù)據(jù)庫的壓力，一個業(yè)界較成熟的方案就是數(shù)據(jù)庫的讀寫分離，寫的時候入主庫，讀的時候讀分庫。這樣就把壓力分散到不同的數(shù)據(jù)庫了，如果一個讀庫性能不行，扛不住的話，可以一主多從，橫向擴展，可謂是一劑良藥啊!那么怎么使用呢?一個一般的流程是這樣的：

1、服務(wù)端把一條數(shù)據(jù)落庫

2、數(shù)據(jù)庫同步或異步或半同步把這條數(shù)據(jù)復(fù)制到從庫

3、服務(wù)端讀取數(shù)據(jù)的時候直接去從庫讀相應(yīng)的數(shù)據(jù)

比較簡單吧，一些聰明的、愛思考的、上進的同學(xué)可能發(fā)現(xiàn)問題了，也包括上面介紹的場景一，就是延遲問題，如：數(shù)據(jù)還沒到從庫，我就馬上讀，那么是讀不到的，會發(fā)生問題的。對于這個問題，各家公司解決的思路也是不一樣的，方法不盡相同，一個普遍的解決方案是：讀不到就讀主庫，當然這么說也是有前提條件的，但具體的方案就不在這里一一展開了，我可能會在接下來的分享中詳解各種方案。

另外，關(guān)于數(shù)據(jù)庫復(fù)制模式，還請同學(xué)們自行學(xué)習(xí)，太多了，這里說不清，該總結(jié)一下這種模式的優(yōu)缺點了，如下：

優(yōu)點：減少數(shù)據(jù)庫的壓力，理論上提供無限高的讀性能，簡介提高業(yè)務(wù)(寫)的性能，專用的查詢、索引、全文(分詞)解決方案。

缺點：數(shù)據(jù)延遲，數(shù)據(jù)一致性的保證。

六、微服務(wù)模式

上面的模式看似不錯，解決了性能問題，我可以不用魯肅街頭了、老婆還是我的，哈哈，但是軟件系統(tǒng)天生的復(fù)雜性決定了，除了性能，還有其他諸如高可用、健壯性等大量問題等待我們?nèi)ソ鉀Q，再加上各個部門的撕逼、扯皮，更讓我們碼農(nóng)雪上加霜，所以，繼續(xù)吧……

微服務(wù)模式可以說是最近的熱點，花花綠綠、大大小小、國內(nèi)國外的公司都在鼓吹，實踐這個模式，可是大部分都沒有弄清為什么要這么做，也并不知道這么做有什么好處、壞處，在這里，我將以我自己的親身實踐說一下我對這個模式的看法，不喜勿噴，隨著業(yè)務(wù)與人員的增加，遇到的問題如下：

1、單及數(shù)據(jù)庫寫請求量大量增加，導(dǎo)致數(shù)據(jù)庫壓力變大

2、數(shù)據(jù)庫一旦掛了，那么整個業(yè)務(wù)都掛了

3、業(yè)務(wù)代碼越來越多，都在一個GIT里，越來越難以維護

4、代碼腐化嚴重，臭味越來越濃

5、上線越來越頻繁，經(jīng)常是一個小功能的修改，就要整個大項目重新編譯

6、部門越來越多，該哪個部門改動大項目中的哪個東西，撕逼的厲害

7、其他一些外圍系統(tǒng)直接連數(shù)據(jù)庫，導(dǎo)致一旦數(shù)據(jù)庫結(jié)構(gòu)發(fā)生變化，所有的相關(guān)系統(tǒng)都要通知，甚至對修改不敏感的系統(tǒng)也要通知

8、每個應(yīng)用服務(wù)器需要開通所有權(quán)限、網(wǎng)絡(luò)、FTP、各種各樣的，因為每個服務(wù)器部署的應(yīng)用都是一樣的。

9、作為架構(gòu)師，我已經(jīng)失去了對這個系統(tǒng)的把控……

為了解決上述問題，我司使用了微服務(wù)模式，這種模式的一般設(shè)計如下圖：

如上圖所示，我把業(yè)務(wù)分塊，做了垂直切分，切成一個個獨立的系統(tǒng)，每個系統(tǒng)各自衍化，有自己的庫、緩存、ES等輔助系統(tǒng)，系統(tǒng)之間的實時交互通過RPC，異步交互通過MQ，通過這種組合，共同完成整個系統(tǒng)功能。

那么，這么做是否真的能解決上述問題了呢?不玩虛的，一個一個來說。

對于問題一，由于拆分成多個子系統(tǒng)，系統(tǒng)的壓力被分散了，而各個子系統(tǒng)都有自己的數(shù)據(jù)庫實例，所以數(shù)據(jù)庫的壓力變小。

對于問題二，一個子系統(tǒng)A的數(shù)據(jù)庫掛了，只是影響到系統(tǒng)A和使用系統(tǒng)A的那些功能，不會所有的功能不可用，從而解決一個數(shù)據(jù)庫掛了，導(dǎo)致所有的功能都不可用的情況。

對于問題三、四，也因為拆分得到了解決，各個子系統(tǒng)都有自己獨立的GIT代碼庫，不會相互影響。通用的模塊可通過庫、服務(wù)、平臺的形式解決。

對于問題五，子系統(tǒng)A發(fā)生改變，需要上線，那么我們只需要編譯A，然后上線就可以了，不需要其他系統(tǒng)做通向的事情。

對于問題六，順應(yīng)了康威定律，我部門該干什么事，輸出什么，也通過服務(wù)的形式暴露出來，我部門只管把我部的職責、軟件功能做好就可以。

對于問題七，所有需要我部數(shù)據(jù)的需求，都通過接口的形式發(fā)布出去，客戶通過接口獲取數(shù)據(jù)，從而屏蔽了底層數(shù)據(jù)庫結(jié)構(gòu)，甚至數(shù)據(jù)來源，我部只需保證我部的接口契約沒有發(fā)生變化即可，新的需求增加新的接口，不會影響老的接口。

對于問題八，不同的子系統(tǒng)需要不同的權(quán)限，這個問題也優(yōu)雅的解決了。

對于問題九，暫時控制住復(fù)雜性，我只需要控制好大方面，定義好系統(tǒng)邊界、接口、大的流程，然后再分而治之、逐個擊破、合縱連橫。

目前來說，所有問題得到解決!bingo!

但是，還有許多其他的副作用會隨之產(chǎn)生，如RPC、MQ的超高穩(wěn)定性、超高性能，網(wǎng)絡(luò)延遲，數(shù)據(jù)一致性等問題，這個就不展開來講了，太多了，一本書都講不完。

另外，對于這個模式來說，最難把握的是度，切記不要切分過細，我見過一個功能一個子系統(tǒng)，上百個方法分成上百個子系統(tǒng)的，真的是太過度了。實踐中，一個比較可行的方法是：能不分就不分，除非有非常必要的理由!

優(yōu)點：相對高性能，可擴展性強，高可用，適用于中等以上規(guī)模公司架構(gòu)。

缺點：復(fù)雜、度不好把握。指不僅需要一個能在高層把控大方向、大流程、總體技術(shù)的人，還需要能夠針對各個子系統(tǒng)有針對性的開發(fā)。把握不好度或者濫用的話，這個模式適得其反!

七、多級緩存模式

這個模式可以說是應(yīng)對超高查詢壓力的一種普遍采用的策略，基本的思想就是在所有鏈路的地方，能加緩存的就加緩存，如下圖所示：

如上圖所示，一般在三個地方加入緩存，一個是客戶端處，一個是API網(wǎng)關(guān)處，一個是具體的后端業(yè)務(wù)處，下面分別介紹：

客戶端處緩存：這個地方加緩存可以說是效果最好的一個——無延遲。因為不用經(jīng)過長長的網(wǎng)絡(luò)鏈條去后端業(yè)務(wù)處獲取數(shù)據(jù)，從而導(dǎo)致加載時間過長，客戶流失等損失，雖然有CDN的支持，但是從客戶端到CDN還是有網(wǎng)絡(luò)延遲的，雖然不大，具體的技術(shù)依據(jù)不同的客戶端而定，對于WEB來講，有瀏覽器本地緩存、Cookie、Storage、緩存策略等技術(shù);對于APP來講，有本地數(shù)據(jù)庫，本地文件，本地內(nèi)存，進程內(nèi)緩存支持，以上提到的各種技術(shù)有興趣的同學(xué)可以繼續(xù)展開學(xué)習(xí)，如果客戶端緩存沒有命中，那么會去后端業(yè)務(wù)拿數(shù)據(jù)，一般來講，就會有個API網(wǎng)關(guān)，在這里加緩存也是非常重要的。

后端業(yè)務(wù)處理：這個我就不用多說了，大家應(yīng)該差不多都知道，什么Redis、Memcache、Jvm等等，不贅述了。

實踐中，要結(jié)合具體的實際情況，綜合利用各級緩存技術(shù)，使得各種請求最大程度的在到達后端業(yè)務(wù)之前就被解決掉，從而減少后端服務(wù)器壓力、減少占用帶寬、增強用戶體驗。至于是否只有這三個地方加緩存，我覺得要活學(xué)活用，心法比劍法重要!總結(jié)一下這個模式的優(yōu)缺點：

優(yōu)點：抗住大量讀請求，減少后端壓力。

缺點：數(shù)據(jù)一致性問題較為突出，容易發(fā)生雪崩，即：如果客戶端緩存失效、API網(wǎng)關(guān)緩存失效，那么所有的大量請求瞬間壓向后端業(yè)務(wù)系統(tǒng)，后果可想而知。

八、分庫分表模式

這種模式主要解決單表寫入、讀取  、存儲壓力過大，從而導(dǎo)致業(yè)務(wù)緩慢甚至超時，交易失敗，容量不夠的問題。一般有水平切分和垂直切分兩種，這里主要介紹水平切分。這個模式也是技術(shù)架構(gòu)迭代演進的必經(jīng)之路。

這種模式的一般設(shè)計見下圖：

如上圖所示紅色部分，把一張表分到了幾個不同的庫中，從而分擔壓力。是不是很籠統(tǒng)?哈哈，那我們接下來就詳細的講解一下，首先澄清幾個概念，如下：

主機：硬件，指一臺物理機，或虛擬機，有自己的CPU，內(nèi)存，硬盤等。

實例：數(shù)據(jù)庫實例，如一個MySql服務(wù)進程，一個主機可以有多個實例，不同的實例有不同的進程，監(jiān)聽不同的端口。

庫：指表的集合，如學(xué)校庫，可能包含教師表、學(xué)生表、食堂表等等，這些表在一個庫中。一個實例中可以有多個庫，庫與庫之間用庫名來區(qū)分。

表：庫中的表，不必多說，不懂的就不用往下看了，不解釋。

那么怎么把單表分散呢?到底怎么個分發(fā)呢?分發(fā)到哪里呢?以下是幾個工作中的實踐，分享一下：

主機：這是最主要的也是最重要的點，本質(zhì)上分庫分表是因為計算與存儲資源不夠?qū)е碌?，而這種資源主要由物理機，主機提供的，畢竟沒有可用的計算資源，怎么分效果都不是太好。

實例：實例控制著連接數(shù)，同時受OS限制，CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)IO也會受間接影響。會出現(xiàn)熱實例的現(xiàn)象，即：有些實例特別忙，有些實例非常的空閑。一個典型的現(xiàn)象是：由于單表反應(yīng)慢，導(dǎo)致連接池被拉滿，所以其他的業(yè)務(wù)都受影響了。這時候，把表分到不同的實例是有一些效果的。

庫：一般是由于單庫中最大單表數(shù)量的限制，才采取分庫。

表：單表壓力過大，索引量大，容量大，單表的鎖。據(jù)以上，把單表水平切分成不同的表。

大型應(yīng)用中，都是一臺主機上只有一個實例，一個實例中只有一個庫，庫==實例==主機，所以才有了分庫分表這個簡稱。

既然知道了這個基本理論，那么具體是怎么做的呢?邏輯是怎么跑的呢?接下來以一個例子來講解一下。

這個需求很簡單，用戶表(user)，單表數(shù)據(jù)量1億，查詢、插入、存儲都出現(xiàn)了問題，怎么辦呢?

首先，分析問題，這個明顯是由于數(shù)據(jù)量太大了而導(dǎo)致的問題。

其次，設(shè)計方案，可以分為10個庫，這樣每個庫的數(shù)據(jù)量就降到了1KW，單表1KW數(shù)據(jù)量還是有些大，而且不利于以后量的增長，所以每個庫再分100個表，這樣每個單表數(shù)據(jù)量就為10W了，對于查詢、索引更新、單表文件大小、打開速度，都有一些溢出。接下來，給IT部門打電話，要10臺物理機，擴展數(shù)據(jù)庫……

最后，邏輯實現(xiàn)，這里應(yīng)該是最有學(xué)問的地方。首先是寫入數(shù)據(jù)，需要知道寫到哪個分庫分表中，讀也是一樣的，所以，需要有個請求路由曾，負責把請求分發(fā)、轉(zhuǎn)換到不同的庫表中，一般有路由規(guī)則的概念。

怎么樣，簡單吧?哈哈。說說這個模式的問題，主要是帶來了事務(wù)上的問題，因為分庫分表，事務(wù)完成不了，而分布式事務(wù)又太笨重，所以這里需要有一定的策略，保證在這種情況下事務(wù)能夠完成。采取的策略如：最終一致性、復(fù)制、特殊設(shè)計等。再有就是業(yè)務(wù)代碼的改造，一些關(guān)聯(lián)查詢要改造，一些單表orderBy的問題需要特殊處理，也包括groupBy語句，如何解決這些副作用不是一句兩句能夠說清楚的，以后有時間，我單獨講講這些。

該總結(jié)一下這種模式的優(yōu)缺點了，如下：

優(yōu)點：減少數(shù)據(jù)庫單表的壓力。

缺點：事務(wù)保證困難、業(yè)務(wù)邏輯需要做大量改造。

九、彈性伸縮模式

這種模式主要解決突發(fā)流量的到來，導(dǎo)致無法橫向擴展或者橫向擴展太慢，進而影響業(yè)務(wù)，全站崩潰的問題。這個模式是一種相對來說比較高級的技術(shù)，也是各大公司目前都在研究、試用的技術(shù)。截至今日，有這種思想的架構(gòu)師已經(jīng)是很不錯的了，能夠拿到較高薪資，更別提那些已經(jīng)實踐過的，甚至實現(xiàn)了底層系統(tǒng)的那些，所以，你懂得……

這種模式的一般設(shè)計如下圖：

如上圖所示，多了一個彈性伸縮服務(wù)，用來動態(tài)的增加、減少實例。原理上非常簡單，但是這個模式到底解決了什么問題呢?先說說由來和意義。

每年的雙11、618或者一些大促銷到來之前，我們都會為大流量的到來做以下幾個方面的工作：提前準備10倍甚至更多的機器，即便用不上也要放在那里備著，以防萬一，這樣浪費了大量的資源。每臺機器配置、調(diào)試、引流，以便讓所有的機器都可用，這樣浪費了大量的人力、物力，更容易出錯。如果機器準備不充分，那么還要加班加點的重復(fù)上面的工作，這樣特別容易出錯，引來領(lǐng)導(dǎo)的不滿，沒時間回家陪老婆，然后你老婆就……哈哈

在雙十一之后，我們還要人工做縮容，非常的辛苦。一般一年中會有多次促銷，那么我們就會一直這樣，實在是煩!

最嚴重的，突然間的大流量爆發(fā)，會讓我們猝不及防，半夜起來擴容是正常不過的事情，為此，我們偷懶起來，要更多的機器備著，也就出現(xiàn)了大量CPU利用率為1%的機器。

相信我，如果你是老板一定很震驚吧!

哈哈，那么如何改變這種情況呢?請接著看

為此，首先把所有的計算資源整合成資源池的概念，然后通過一些策略、監(jiān)控、服務(wù)，動態(tài)的從資源池中獲取資源，用完后再放回到池子中，供其他系統(tǒng)使用。具體實現(xiàn)上比較成熟的兩種資源池方案是VM、docker，每個都有著自己強大的生態(tài)。監(jiān)控點有CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)IO、服務(wù)質(zhì)量等，根據(jù)這些，再配合一些預(yù)留、擴張、收縮策略，就可以簡單的實現(xiàn)自動收縮。怎么樣?是不是很神奇?深入的內(nèi)容我會在后面的文章中詳細的講述，該總結(jié)以下這種模式的優(yōu)缺點了。如下：

優(yōu)點：彈性、隨需計算，充分優(yōu)化企業(yè)計算資源。

缺點：應(yīng)用要從架構(gòu)層做到可橫向擴展化改造、依賴的底層配套比較多，對技術(shù)水平、實力、應(yīng)用規(guī)模要求比較高。

十、多機房模式

這種模式主要解決不同地區(qū)高性能、高可用的問題

隨著應(yīng)用用戶的不斷增加，用戶群體分布在全球各地，如果把服務(wù)器都部署在一個地方，一個地方，比如北京，那么美國的用戶使用應(yīng)用的時候會特別慢，因為每個請求都需要通過海底光纜走上那么一秒鐘左右，這樣對用戶體檢及其不好，怎么辦?使用多機房部署。這種模式一般設(shè)計如下圖所示：

如上圖所示，一個典型的用戶請求流程如下：

用戶請求一個連接A

通過DNS智能解析到離用戶最近的機房B

使用B機房服務(wù)連接A

是不是覺得很簡單，沒啥?其實這里面的問題沒有表面這么簡單，下面一一道來，

首先是數(shù)據(jù)同步問題，在中國產(chǎn)生的數(shù)據(jù)要同步到美國，美國的也一樣，數(shù)據(jù)同步就會涉及數(shù)據(jù)版本、一致性、更新丟棄、刪除等問題。

其次是一地多機房的請求路由問題，典型的是如上圖，中國的北京機房和杭州機房，如果北京機房掛了，那么要能夠通過路由把所有發(fā)往北京機房的請求轉(zhuǎn)發(fā)到杭州機房，異地也存在這個問題。

所以，多機房模式，也就是異地多活并不是那么的簡單，這里只是起了個頭，具體的有哪些坑，會在后面的文章中介紹。

該總結(jié)以下這種模式的優(yōu)缺點了，如下：

優(yōu)點：高可用、高性能、異地多活。

缺點：數(shù)據(jù)同步、數(shù)據(jù)一致性、請求路由。

到此，關(guān)于“web設(shè)計模式有哪些架構(gòu)”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>