歡迎光臨
每天分享高質量文章

圖解分佈式架構的發展和演進

編註: 架構決定的系統的穩定性,擴展性和併發性,架構的演進是從簡單到複雜,從單一到複合持續改進的過程,也是經驗的積累和技術的結晶。

 

初始階段架構

初始階段的小型系統、應用程式、資料庫、檔案等所有的資源都在一臺服務器上。通俗稱為LAMP。

特征:應用程式、資料庫、檔案等所有的資源都在一臺服務器上。

描述:通常服務器操作系統使用linux,應用程式使用PHP開發,然後部署在Apache上,資料庫使用Mysql,彙集各種免費開源軟體以及一臺廉價服務器就可以開始系統的發展之路了。

應用服務和資料服務分離

好景不長,發現隨著系統訪問量的再度增加,webserver機器的壓力在高峰期會上升到比較高,這個時候開始考慮增加一臺webserver。

特征:應用程式、資料庫、檔案分別部署在獨立的資源上。

描述:資料量增加,單台服務器性能及儲存空間不足,需要將應用和資料分離,併發處理能力和資料儲存空間得到了很大改善。

使用快取改善性能

特征:資料庫中訪問較集中的一小部分資料儲存在快取服務器中,減少資料庫的訪問次數,降低資料庫的訪問壓力。

描述:系統訪問特點遵循二八定律,即80%的業務訪問集中在20%的資料上。快取分為本地快取和遠程分佈式快取,本地快取訪問速度更快但快取資料量有限,同時存在與應用程式爭用記憶體的情況。

使用應用服務器集群

在做完分庫分表這些工作後,資料庫上的壓力已經降到比較低了,又開始過著每天看著訪問量暴增的幸福生活了,突然有一天,發現系統的訪問又開始有變慢的趨勢了,這個時候首先查看資料庫,壓力一切正常,之後查看webserver,發現apache阻塞了很多的請求,而應用服務器對每個請求也是比較快的,看來是請求數太高導致需要排隊等待,響應速度變慢。

 

特征:多台服務器通過負載均衡同時向外部提供服務,解決單台服務器處理能力和儲存空間上限的問題。

描述:使用集群是系統解決高併發、海量資料問題的常用手段。通過向集群中追加資源,提升系統的併發處理能力,使得服務器的負載壓力不再成為整個系統的瓶頸。

資料庫讀寫分離

享受了一段時間的系統訪問量高速增長的幸福後,發現系統又開始變慢了,這次又是什麼狀況呢,經過查找,發現資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈,導致了系統變慢。

特征:多台服務器通過負載均衡同時向外部提供服務,解決單台服務器處理能力和儲存空間上限的問題。

描述:使用集群是系統解決高併發、海量資料問題的常用手段。通過向集群中追加資源,使得服務器的負載壓力不在成為整個系統的瓶頸。

反向代理和CDN加速

特征:採用CDN和反向代理加快系統的 訪問速度。

描述:為了應付複雜的網絡環境和不同地區用戶的訪問,通過CDN和反向代理加快用戶訪問的速度,同時減輕後端服務器的負載壓力。CDN與反向代理的基本原理都是快取。

分佈式檔案系統和分佈式資料庫

隨著系統的不斷運行,資料量開始大幅度增長,這個時候發現分庫後查詢仍然會有些慢,於是按照分庫的思想開始做分表的工作。

特征:資料庫採用分佈式資料庫,檔案系統採用分佈式檔案系統。

描述:任何強大的單一服務器都滿足不了大型系統持續增長的業務需求,資料庫讀寫分離隨著業務的發展最終也將無法滿足需求,需要使用分佈式資料庫及分佈式檔案系統來支撐。分佈式資料庫是系統資料庫拆分的最後方法,只有在單表資料規模非常龐大的時候才使用,更常用的資料庫拆分手段是業務分庫,將不同的業務資料庫部署在不同的物理服務器上。

使用NoSQL和搜索引擎

特征:系統引入NoSQL資料庫及搜索引擎。

描述:隨著業務越來越複雜,對資料儲存和檢索的需求也越來越複雜,系統需要採用一些非關係型資料庫如NoSQL和分資料庫查詢技術如搜索引擎。應用服務器通過統一資料訪問模塊訪問各種資料,減輕應用程式管理諸多資料源的麻煩。

業務拆分

特征:系統上按照業務進行拆分改造,應用服務器按照業務區分進行分別部署。

描述:為了應對日益複雜的業務場景,通常使用分而治之的手段將整個系統業務分成不同的產品線,應用之間通過超鏈接建立關係,也可以通過訊息佇列進行資料分發,當然更多的還是通過訪問同一個資料儲存系統來構成一個關聯的完整系統。縱向拆分:將一個大應用拆分為多個小應用,如果新業務較為獨立,那麼就直接將其設計部署為一個獨立的Web應用系統縱向拆分相對較為簡單,通過梳理業務,將較少相關的業務剝離即可。

橫向拆分:將復用的業務拆分出來,獨立部署為分佈式服務,新增業務只需要呼叫這些分佈式服務橫向拆分需要識別可復用的業務,設計服務接口,規範服務依賴關係。

分佈式服務

特征:公共的應用模塊被提取出來,部署在分佈式服務器上供應用服務器呼叫。

描述:隨著業務越拆越小,應用系統整體複雜程度呈指數級上升,由於所有應用要和所有資料庫系統連接,最終導致資料庫連接資源不足,拒絕服務。

 

分佈式服務應用會面臨哪些問題?

  • (1) 當服務越來越多時,服務URL配置管理變得非常困難,F5硬體負載均衡器的單點壓力也越來越大。

  • (2) 當進一步發展,服務間依賴關係變得錯蹤複雜,甚至分不清哪個應用要在哪個應用之前啟動,架構師都不能完整的描述應用的架構關係。

  • (3) 接著,服務的呼叫量越來越大,服務的容量問題就暴露出來,這個服務需要多少機器支撐?什麼時候該加機器?

  • (4) 服務多了,溝通成本也開始上升,調某個服務失敗該找誰?服務的引數都有什麼約定? 

 

  • (5) 一個服務有多個業務消費者,如何確保服務質量?

  • (6) 隨著服務的不停升級,總有些意想不到的事發生,比如cache寫錯了導致記憶體上限溢位,故障不可避免,每次核心服務一掛,影響一大片,人心慌慌,如何控制故障的影響面?服務是否可以功能降級?或者資源劣化?

Java分佈式應用技術基礎

分佈式服務下的關鍵技術:訊息佇列架構



訊息佇列通過訊息物件分解系統耦合性,不同子系統處理同一個訊息。

分佈式服務下的關鍵技術:訊息佇列原理

分佈式服務下的關鍵技術:服務框架架構

服務框架通過接口分解系統耦合性,不同子系統通過相同的接口描述進行服務啟用服務框架是一個點對點模型服務框架面向同構系統適合:移動應用、互聯網應用、外部系統。

分佈式服務下的關鍵技術:服務框架原理

分佈式服務下的關鍵技術:服務總線架構

服務總線同服務框架一樣,均是通過接口分解系統耦合性,不同子系統通過相同的接口描述進行服務啟用服務總線是一個總線式的模型服務總線面向同構、異構系統適合:內部系統。

分佈式服務下的關鍵技術:服務總線原理

分佈式系統間交互5種通信樣式

  • Request/Response樣式(同步樣式):客戶端發起請求一直阻塞到服務端傳回請求為止。

  • Callback(異步樣式):客戶端發送一個RPC請求給服務器,服務端處理後再發送一個訊息給訊息發送端提供的callback端點,此類情況非常合適以下場景:A組件發送RPC請求給B,B處理完成後,需要通知A組件做後續處理。

  • Future樣式:客戶端發送完請求後,繼續做自己的事情,傳回一個包含訊息結果的Future物件。客戶端需要使用傳回結果時,使用Future物件的.get(),如果此時沒有結果傳回的話,會一直阻塞到有結果傳回為止。

  • Oneway樣式:客戶端呼叫完繼續執行,不管接收端是否成功。

  • Reliable樣式:為保證通信可靠,將借助於訊息中心來實現訊息的可靠送達,請求將做持久化儲存,在接收方在線時做送達,並由訊息中心保證異常重試。

通信樣式的實現方式

  • 同步點對點服務樣式

  • 異步點對點訊息樣式1

  • 異步點對點訊息樣式2

  • 異步廣播訊息樣式

分佈式架構下的服務治理

服務治理是服務框架/服務總線的核心功能。所謂服務治理,是指服務的提供方和消費方達成一致的約定,保證服務的高質量。服務治理功能可以解決將某些特定流量引入某一批機器,以及限制某些非法消費者的惡意訪問,併在提供者處理量達到一定程度是,拒絕接受新的訪問。

基於服務框架Dubbo的服務治理-服務管理可以知道你的系統,對外提供了多少服務,可以對服務進行升級、降級、停用、權重調整等操作可以知道你提供的服務,誰在使用,因業務需求,可以對該消費者實施屏蔽、停用等操作基於服務框架Dubbo的服務治理-服務監控可以統計服務的每秒請求數、平均響應時間、呼叫量、峰值時間等,作為服務集群規劃、性能調優的參考指標。

基於服務框架Dubbo的服務治理

  • 服務路由

  • 服務保護

基於服務總線OSB的服務治理

功能描述

說明:以上內容來自網絡,作者佚名,僅供學習參考,版權歸原作者所有。

已同步到看一看
赞(0)

分享創造快樂