如何設計微服務以及設計原則 之 AKF 拆分原則

2021-09-12 03:51:15 字數 2394 閱讀 2530

1) akf 拆分原則

2) 前後端分離原則

3) 無狀態服務

4) restful 的通訊風格

1 akf  拆分原則

業界對於可擴充套件的系統架構設計有乙個樸素的理念,就是:

通過加機器(水平擴充套件)就可以解決容量和可用性問題 。( 如果一台不行那就兩台) 。

我是個段子:( 世界上沒有什麼事是一頓燒烤不能解決的。如果有,那就兩頓 。)

這一理念在「雲計算」概念瘋狂流行的今天,得到了廣泛的認可!對於乙個規模

迅速增長的系統而言,容量和效能問題當然是首當其衝的。但是隨著時間的向前,

系統規模的增長,除了面對效能與容量的問題外,還需要面對功能與模組數量上

的增長帶來的系統複雜性問題以及業務的變化帶來的提供差異化服務問題。而許

多系統,在架構設計時並未充分考慮到這些問題,導致系統的重構成為常態,從

而影響業務交付能力,還浪費人力財力!對此,《可擴充套件的藝術》一書提出了一

個更加系統的可擴充套件模型—— akf  可擴充套件立方(scalability cube)。這個立方

體中沿著三個座標軸設定分別為:x、y、z。

y 軸(功能) —— 關注應用中功能劃分,基於不同的業務拆分

x 軸(水平擴充套件) —— 關注水平擴充套件,也就是」加機器解決問題」,集群

z 軸(資料分割槽) —— 關注服務和資料的優先順序劃分,如按地域劃分

1.1 y  軸( 功能)

y 軸擴充套件會將龐大的整體應用拆分為多個服務。每個服務實現一組相關的功

能,如訂單管理、客戶管理等。在工程上常見的方案是  服務化架構(soa) 。比

如對於乙個電子商務平台,我們可以拆分成不同的服務,組成下面這樣的架構:

但通過觀察上圖容易發現,當服務數量增多時,服務呼叫關係變得複雜。其實就是個rpc架構,為

系統新增乙個新功能,要呼叫的服務數也變得不可控,由此引發了服務管理上的

混亂。所以,一般情況下,需要採用服務註冊的機制形成服務閘道器來進行服務治

理。系統的架構將變成下圖所示:

1.2 x  軸( 水平擴充套件)

x 軸擴充套件與我們前面樸素理念是一致的,通過絕對平等地復**務與資料,

以解決容量和可用性的問題。其實就是將微服務執行多個例項,做集群加負載均

衡的模式。

為了提公升單個服務的可用性和容量,對每乙個服務進行 x

1.3 z  軸( 資料分割槽)

z 軸擴充套件通常是指基於請求者或使用者獨特的需求,進行系統劃分,並使得劃

分出來的子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例:福特公司

為了發展在中國的業務,或者利用中國的廉價勞動力,在中國建立乙個完整的子

工廠,與美國工廠一樣,負責完整的汽車生產。這就是一種 z 軸擴充套件。

1.3.1 工程領域常見的 z  軸擴充套件有以下兩種方案:

1.3.1.1  單元化架構

在分布式服務設計領域,乙個單元(cell)就是滿足某個分割槽所有業務操作

的自包含閉環。如上面我們說到的 y 軸擴充套件的 soa 架構,客戶端對服務端節點

的選擇一般是隨機的,但是,如果在此加上 z 軸擴充套件,那服務節點的選擇將不再

是隨機的了,而是每個單元自成一體。如下圖:

1.3.1.2  資料分割槽

為了效能資料安全上的考慮,我們將乙個完整的資料集按一定的維度劃分出

不同的子集。 乙個分割槽(shard),就是是整體資料集的乙個子集(最終子集還要合成乙個整體)。比如用尾

號來劃分使用者,那同樣尾號的那部分使用者就可以認為是乙個分割槽。資料分割槽為一

般包括以下幾種資料劃分的方式:

資料型別(如:業務型別)

資料範圍(如:時間段,使用者 id)

資料熱度(如:使用者活躍度,商品熱度)

按讀寫分(如:商品描述,商品庫存)

舉例:比如滴滴打車,你在哪個城市打車,就給你展示哪個城市的司機資料分割槽

微服務設計原則

相比於單機服務與其他架構,微服務架構的主要特徵是元件化 松耦合 獨立 去中心化。主要表現在如下幾個方面 細粒度的服務分解 將專案中每個模組 每個職責拆分出來,專注做好一件事情。獨立部署執行和擴充套件 每個微服務又是乙個單獨的專案,獨立執行在自己的程序裡。它可以不依賴於其他服務進行單獨使用和靈活擴充套...

微服務架構的設計原則

高內聚 低耦合。無縫的 api 整合。為每一項服務分配唯一的資源標識。實時流量管理。最小化資料表,以優化載入。通過內 外部 api,執行持續監控。為每個微服務隔離資料的儲存。這對於限制資料的訪問和避免 服務的耦合 是非常有用的。例如 基於使用者的分類資料,我們可以實施命令查詢的責任分離 comman...

微服務1之微服務設計要點

在開始轉為微服務之前,需要注意如下要點,考慮清楚再決定要不要做微服務。1 服務粒度 如何劃分各個服務之間的職責邊界。劃分過粗,則服務中包含的業務過多,時間長了之後,又會變為乙個複雜的單體應用。劃分過細,則服務增多,又會增加整體複雜性。2 通訊協議 各服務之間的通訊模式。是採用json,還是xml,還...