天天看點

架構設計基礎:單服務.叢集.分布式,基本差別和聯系一、分布式簡介二、分布式技術棧三、資料存儲四、最後總結

一、分布式簡介

1、架構簡介

現在的網際網路,幾乎常見的複雜系統都會使用分布式架構,如果在不清楚概念之前,剛接觸分布式架構這個名詞會感覺十分的高大上,其實在對比單服務,叢集服務之後,你就會發現本質上都是一樣的。

絮叨一句

:所謂Java架構師,基本就是看被單服務,叢集,分布式不斷暴打的頻率,架構師因為被虐頻率高,自然做出來的系統架構坑少,新手不能做架構的原因,是以你該懂的。

言歸正傳,分布式架構對于Java開發來說基本算是分水嶺,能不能從開發層面跳出來,就看你工作個三五年之後,對分布式系統了解到什麼程度。單服務應用,基于單服務做叢集化部署,這種操作運維可以自行搭建環境,是以基本對能力要求不算高。但是如何設計出彈性、配置化、分布化、高性能、高容錯、安全的分布式系統,的确是一件很有挑戰的事情。

2、叢集和分布式

首先需要理清楚單服務,叢集,分布式這幾種不同架構的差別。

單服務和叢集

一張圖,你品,你細品:

架構設計基礎:單服務.叢集.分布式,基本差別和聯系一、分布式簡介二、分布式技術棧三、資料存儲四、最後總結

業務體量小,所有服務和應用部署在一台服務上,節省成本,這是單服務結構。當業務量逐漸增大,把一台服務進行水準擴充,做一個服務群,每台服務稱為叢集的一個節點,到這就是叢集服務。叢集服務要面對的一個問題就是:請求配置設定,自然需要一個排程元件來均衡伺服器壓力,這也被稱為負載均衡。

補刀一句

:做到叢集模式的應用,在程式員面試的時候已經會被拿來做高格調的自吹自擂了,其實單服務和叢集的本質差別就是:在處理請求的時候多了一個配置設定服務的過程,現在你還覺得跟人吹叢集很高端嗎?

分布式

架構設計基礎:單服務.叢集.分布式,基本差別和聯系一、分布式簡介二、分布式技術棧三、資料存儲四、最後總結

這個概念解釋起來就不容易了,單服務到叢集,是部署上的改變,在代碼層面改動極小,叢集模式會加入更多的服務監控,為了快速的判斷哪個服務當機。

首先要解釋一下上圖:常見的電商系統架構(部分業務),訂單,倉儲,物流。

  • 使用者在訂單服務下單,自然需要校驗庫存;
  • 下單成功之後,需要追蹤訂單物流;
  • 商家需要倉儲服務管理上架商品,發貨等;
  • 如果訂單服務出現高并發,可以水準擴充,做訂單服務的叢集化;

這是一個基礎的業務場景,特點:多應用服務,多資料庫存儲,且服務之間有通信行為,在個别服務壓力大的情況下可以水準擴充叢集化部署。

分布式結構就是按照業務系統的功能,拆分成獨立的子服務,可以獨立運作,且服務之間通信和互動。帶來的好處也是非常的多,例如:降低業務間的耦合度,友善開發維護,水準擴充,複用性高等等。

補刀一句

:不要出現思維上的錯覺,認為分布式系統的邊界大于叢集,如果把一個分布式整體看做一個服務,針對這個分布式服務做叢集化部署,邏輯上是說的通的,隻是這樣違背分布式系統的初衷,比如背景服務,沒有那麼大的高并發,自然不用浪費資源。

3、一句總結

分布式和叢集模式磨刀霍霍的根本原因,都是為了解決兩個問題:提高系統吞吐量和高可用性,隻是兩種模式站在的角度和業務場景不同,例如業務單調的高并發場景,業務複雜但不具備并發的場景,當然也有這兩種業務場景同時具備的。

補刀一句

:針對系統架構和選型,各大公司也确實沒有統一的标準,但是都強調寫代碼的規範和邏輯,這樣做的根本原因就是友善後續的系統架構更改。

二、分布式技術棧

上面聊完了基本概念,現在聊聊分布式系統中的技術體系。這個話題依舊有點飄逸。分布式是一種架構思維和模式,并不一定非要使用特定的架構,現在很火的幾個架構,SpringCloud,Dubbo,AliCloud等等,這些的出現都是給架構提供了更多的選擇。

補刀一句

:架構體系和架構,一定是可以分的開概念,架構更多是友善架構快速落地和實作。

1、服務架構

作為開發人員,分布式系統要處理的問題非常多,但是主流的子產品有下面幾個:

  • 網關控制

網關主要涉及到請求校驗,聚合API,路由配置,鑒權管理,安全,灰階釋出等等。常用的Zuul元件。

  • 配置中心

動态資源配置加載,例如運作時流量管理,環境切換,靜态資源管理等。常用Nacos和config元件。

  • 服務管理

分布式中最難管理的子產品,也最容易出錯,首先多服務運作情況下,需要保證服務間的互動正常,避免請求在鍊路的某個服務上積壓,出現異常還要及時熔斷,進行服務降級,高并發到峰值時,要配置限流政策,還有最難處理的分布式事務。這裡也被稱為服務容錯設計,常用Eureka、Hystrix、Sentinel、Dubbo等元件。

補刀一句

:分布式系統中真正的核心内容,即使一個很牛的架構師,搭建的分布式環境也是在業務發展中不斷優化的,不會一成不變。

2、容器化運維

作為運維人員:部署分布式系統的确是一件極其繁雜的事情,這時就應景誕生了容器化運維。

  • 部署環境

有的服務需要部署公有雲(就是常說的幾家大公司雲服務),有的要部署私有雲(自己公司搭建,隻服務自己業務的雲服務),混合雲就是上述兩種環境都需要部署服務。總之,現在不這麼說,會顯得自己很低調。

  • 容器化技術

将服務打包部署在Docker容器中,如果需要臨時擴充,把Docker容器鏡像快速部署到多個伺服器上即可,如果對這個概念比較懵,就好比自己電腦裡面多個虛拟機,可以基于一個虛拟機鏡像檔案,快速複制多個。Docker一大特色就是:搭建一次,到處運作。

補刀一句

:此處必須要感歎一句,Java一直火那麼久是有原因的,後續的很多技術出現都在參考這個基本理念。

  • 環境監控

分布式系統的應用非常複雜,是以要對監控做的非常到位,這裡不僅僅要對服務監控,硬體環境同樣重要。快速擴充,定位當機服務。

三、資料存儲

上面一直沒有提到這個超大子產品,意識必須清楚,任何系統最複雜的邏輯莫過于資料存儲,從開發層面看:一個架構的核心價值就是在于資料的管理。

1、基礎描述

基于上面分布式的概念,資料庫的了解方式也是同樣。分布式資料庫可以解決單個資料庫存儲的IO或CPU瓶頸而誕生的。常用的模式如下:

  • 關系型

應用內建一個資料庫代理的中間件,把資料基于特定政策路由到不同的資料庫表中,取資料的時候在以同樣的邏輯查詢。很經典的sharding-jdbc元件,分庫分表的模式。

上面關系資料庫的分庫分表處理,是比較顯式且刻意的,在分布式資料庫中,天然的支援,且具有良好的水準擴充能力。例如:Hbase、mongodb、Greenplum分布式數倉等等。

2、資料庫選型

分布式系統架構和分布式資料存儲相輔相成,不管架構選型還是存儲選型,都沒有可建議的标準,這裡隻能用一句很有用的廢話來描述:基于自己的技術認知範圍,和業務場景綜合考量。

四、最後總結

如何架構分布式系統,這說不好,但是如何判斷分布式架構是否好,這很好說:服務良好的擴充性,高可用性,例如高并發業務随時擴充,提高系統可用性,處理能力,這是必須具備的基礎特性。