溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

實戰(zhàn)案例——分布式架構(gòu)演變

發(fā)布時間:2020-06-04 03:18:40 來源:網(wǎng)絡(luò) 閱讀:456 作者:慕容千羽 欄目:建站服務(wù)器

前言

隨著計算機系統(tǒng)規(guī)模變得越來越大,將所有的業(yè)務(wù)單元集中部署在一個或若干個大型機上的體系架構(gòu),已經(jīng)越來越不能滿足當今計算機系統(tǒng)。同時,隨著微型計算機的出現(xiàn),越來越多廉價的PC機成為了各大企業(yè)IT架構(gòu)的首選,分布式的處理方式越來越受到業(yè)界的青睞。本文將介紹分布式架構(gòu)的發(fā)展歷史和分布式架構(gòu)的一些相關(guān)概念。

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

一、單應(yīng)用架構(gòu)

實戰(zhàn)案例——分布式架構(gòu)演變

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

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

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

實戰(zhàn)案例——分布式架構(gòu)演變

順便給大家推薦一個Java技術(shù)交流群:908676731,里面會分享一些資深架構(gòu)師錄制的視頻資料:有Spring,MyBatis,Netty源碼分析,高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理,JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系。還能領(lǐng)取免費的學(xué)習(xí)資源,目前受益良多!

三、應(yīng)用服務(wù)器集群

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

實戰(zhàn)案例——分布式架構(gòu)演變

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

實戰(zhàn)案例——分布式架構(gòu)演變

四、數(shù)據(jù)庫讀寫分離

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

實戰(zhàn)案例——分布式架構(gòu)演變

五、使用搜索引擎緩解讀庫的壓力

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

實戰(zhàn)案例——分布式架構(gòu)演變

六、引入緩存機制緩解數(shù)據(jù)庫的壓力

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

實戰(zhàn)案例——分布式架構(gòu)演變

七、數(shù)據(jù)庫的水平/垂直拆分

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

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

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

實戰(zhàn)案例——分布式架構(gòu)演變

八、應(yīng)用的拆分

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

實戰(zhàn)案例——分布式架構(gòu)演變

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

九、服務(wù)化

服務(wù)拆分以后,各個服務(wù)之間可以通過RPC 技術(shù)進行通信,比較典型的有:webservice、hessian、http、RMI等。

實戰(zhàn)案例——分布式架構(gòu)演變

感謝您耐心看完的文章

順便給大家推薦一個Java技術(shù)交流群:908676731,里面會分享一些資深架構(gòu)師錄制的視頻資料:有Spring,MyBatis,Netty源碼分析,高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理,JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系。還能領(lǐng)取免費的學(xué)習(xí)資源,目前受益良多!

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI