本篇內(nèi)容介紹了“分布式架構(gòu)的演進(jìn)過(guò)程是怎樣的”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的義安網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

架構(gòu)是演變而來(lái)的，不是設(shè)計(jì)出來(lái)的。沒(méi)有最好的架構(gòu)，只有最適合的架構(gòu)。

下面以一個(gè)簡(jiǎn)單的電商系統(tǒng)為例，當(dāng)數(shù)據(jù)量、訪問(wèn)量提升，觀察這個(gè)系統(tǒng)可能會(huì)發(fā)生的結(jié)構(gòu)變化。假如我們系統(tǒng)具備以下功能：用戶模塊（用戶注冊(cè)和管理），商品模塊（商品展示和管理），交易模塊（創(chuàng)建交易及支付結(jié)算）。

階段一，單應(yīng)用架構(gòu)

網(wǎng)站的初期也可以認(rèn)為是互聯(lián)網(wǎng)發(fā)展的早起，我們經(jīng)常會(huì)在單機(jī)上跑我們所有的程序和軟件。把所有軟件和應(yīng)用都部署在一臺(tái)機(jī)器上，這樣就完成一個(gè)簡(jiǎn)單系統(tǒng)的搭建，這個(gè)時(shí)候的講究的是效率。

階段二，應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器分離

隨著網(wǎng)站的上線，訪問(wèn)量逐步上升，服務(wù)器的負(fù)載慢慢提高，在服務(wù)器還沒(méi)有超載的時(shí)候，我們應(yīng)該做好規(guī)劃，提升網(wǎng)站的負(fù)載能力。假如代碼層面的優(yōu)化已經(jīng)沒(méi)辦法繼續(xù)提高，在不提高單臺(tái)機(jī)器的性能，增加機(jī)器是一個(gè)比較好的方式，投入產(chǎn)出比非常高。這個(gè)階段增加機(jī)器的主要目的是將web 服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器拆分，這樣不僅提高了單機(jī)的負(fù)載能力，也提高了容災(zāi)能力。

階段三，應(yīng)用服務(wù)器集群

隨著訪問(wèn)量的繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無(wú)法滿足需求。在假設(shè)數(shù)據(jù)庫(kù)服務(wù)器還沒(méi)有遇到性能問(wèn)題的時(shí)候，我們可以增加應(yīng)用服務(wù)器，通過(guò)應(yīng)用服務(wù)器集群將用戶請(qǐng)求分流到各個(gè)服務(wù)器中，從而繼續(xù)提升負(fù)載能力。此時(shí)多臺(tái)應(yīng)用服務(wù)器之間沒(méi)有直接的交互，他們都是依賴數(shù)據(jù)庫(kù)各自對(duì)外提供服務(wù)。

架構(gòu)發(fā)展到這個(gè)階段，各種問(wèn)題也會(huì)慢慢呈現(xiàn)，比如用戶請(qǐng)求由誰(shuí)來(lái)轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器，這時(shí)候可能會(huì)出現(xiàn)下面的架構(gòu)模型。

階段四，數(shù)據(jù)庫(kù)讀寫分離

當(dāng)數(shù)據(jù)庫(kù)壓力變大時(shí)，那么怎么去提高數(shù)據(jù)庫(kù)層面的負(fù)載呢？有了前面的思路以后，自然會(huì)想到增加服務(wù)器。但是假如我們單純的把數(shù)據(jù)庫(kù)一分為二，然后對(duì)于后續(xù)數(shù)據(jù)庫(kù)的請(qǐng)求，分別負(fù)載到兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上，那么一定會(huì)造成數(shù)據(jù)庫(kù)不統(tǒng)一的問(wèn)題。所以我們一般先考慮讀寫分離的方式。

階段五，使用搜索引擎緩解讀庫(kù)的壓力

數(shù)據(jù)庫(kù)做讀庫(kù)的話，常常對(duì)模糊查找效率不是特別好，像電商類的網(wǎng)站，搜索是非常核心的功能，即便是做了讀寫分離，這個(gè)問(wèn)題也不能有效解決。那么這個(gè)時(shí)候可以引入搜索引擎，使用搜索引擎能夠大大提高我們的查詢速度。

如果你是Java程序員，如果你想提升自己，如果你想變強(qiáng)，加q群：479499375，可獲取一份Java架構(gòu)進(jìn)階技術(shù)精品視頻。（高并發(fā)+Spring源碼+JVM原理解析+分布式架構(gòu)+微服務(wù)架構(gòu)+多線程并發(fā)原理等...這些成為架構(gòu)師必備的內(nèi)容）以及Java進(jìn)階學(xué)習(xí)路線圖。

階段六，引入緩存機(jī)制緩解數(shù)據(jù)庫(kù)的壓力

隨著訪問(wèn)量的持續(xù)增加，逐漸出現(xiàn)許多用戶訪問(wèn)同一部分內(nèi)容的情況。對(duì)于這些熱點(diǎn)數(shù)據(jù)，沒(méi)必要每次都從數(shù)據(jù)庫(kù)去讀取，我們可以使用緩存技術(shù)，比如memcache、redis 來(lái)作為我們應(yīng)用層的緩存；另外在某些場(chǎng)景下，比如我們對(duì)用戶的某些IP 的訪問(wèn)頻率做限制，那這個(gè)放內(nèi)存中又不合適，放數(shù)據(jù)庫(kù)又太麻煩，這個(gè)時(shí)候可以使用NOSQL 的方式比如mongDB 來(lái)代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)。

階段七，數(shù)據(jù)庫(kù)的水平/垂直拆分

我們的網(wǎng)站演進(jìn)的變化過(guò)程，交易、商品、用戶的數(shù)據(jù)都還在同一個(gè)數(shù)據(jù)庫(kù)中，盡管采取了增加緩存，讀寫分離的方式，但是隨著數(shù)據(jù)庫(kù)的壓力持續(xù)增加，數(shù)據(jù)庫(kù)的瓶頸仍然是個(gè)最大的問(wèn)題。因此我們可以考慮對(duì)數(shù)據(jù)的垂直拆分和水平拆分。

垂直拆分：把數(shù)據(jù)庫(kù)中不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)。

水平拆分：把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至更多的表中。

階段八，應(yīng)用的拆分

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來(lái)越多，應(yīng)用的壓力越來(lái)越大，工程規(guī)模也越來(lái)越龐大。這個(gè)時(shí)候就可以考慮將應(yīng)用拆分，按照領(lǐng)域模型將系統(tǒng)拆成用戶、商品、交易子系統(tǒng)。

這樣拆分以后，可能會(huì)有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會(huì)導(dǎo)致每個(gè)系統(tǒng)都會(huì)有用戶查詢?cè)L問(wèn)相關(guān)操作。這些相同的操作一定是要抽象出來(lái)，可以通過(guò)服務(wù)化的方式來(lái)解決。

階段九，服務(wù)化

服務(wù)拆分以后，各個(gè)服務(wù)之間可以通過(guò)RPC 技術(shù)進(jìn)行通信，比較典型的有：webservice、hessian、http、RMI等。

“分布式架構(gòu)的演進(jìn)過(guò)程是怎樣的”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！