微服務開發中的數據架構設計

本文來自做者 陳偉榮 在 GitChat 分享的文章【微服務開發中的數據架構設計】

前言

微服務是當前很是流行的技術框架，經過服務的小型化、原子化以及分佈式架構的彈性伸縮和高可用性，能夠實現業務之間的鬆耦合、業務的靈活調整組合以及系統的高可用性。爲業務創新和業務持續提供了一個良好的基礎平臺。本文分享在這種技術架構下的數據架構的設計思想以及設計要點，本文包括下面若干內容。

• 微服務技術框架中的多層數據架構設計

• 數據架構設計中的要點

• 要點1：數據易用性

• 要點2：主、副數據及數據解耦

• 要點3：分庫分表

• 要點4：多源數據適配

• 要點5：多源數據緩存

• 要點6：數據集市

爲了容易理解，本文用一個簡化的銷售模型來闡述，以下圖。圖1顯示了客戶、賣家、商品、訂價、訂單的關係（這裏省略支付、物流等其餘元素）。

圖1 銷售模型

在這個銷售模型中，賣家提供商品、制訂價格，客戶選擇產品購買、造成銷售訂單。根據微服務的理念設計，能夠劃分爲客戶服務、賣家服務、商品服務、訂價服務、訂單服務，以及公共服務（好比認證、權限、通知等），如圖2所示。

圖2 微服務功能

微服務架構中的多層數據架構設計

分佈式架構通常把系統分爲 Saas（Software-as-a-Service）、Paas（Platform-as-a-Service）、Iaas（Infrastructure as a Service ）三層。其中 Saas 層負責對外部提供業務服務，Paas 層提供基礎應用平臺，Iaas 層提供基礎設施。微服務垂直嵌入這三層服務之中，相互獨立。所以數據架構設計時須要考慮三層服務對數據的關注點，又要考慮微服務的獨立性。

數據架構的分層設計

圖3 微服務技術框架

如圖3所示，Iaas 層提供程序運行的物理基礎環境（這邊涉及不少硬件·網絡內容，在本文中省略）。Pass 層細分爲三層，基礎服務層，主要負責數據存儲處理；事務框架層，主要負責微服務的註冊·調度管理、分佈式事務處理；應用服務層、主要實現各個微服務的 API，供其它微服務直接調用以及 Saas 層的服務調用。Saas 服務就是公開對外提供的業務服務。全文中架構技術運用到的知識點能夠在羣619881427免費獲取。感興趣的能夠加入進來。

數據架構自下向上相應的分爲 Raw Data 層、Logic Data（inner）層和 Logic Data（outer）層（Iaas 中主要以基礎硬件環境爲主，在本文中省略）。Raw Data 層是基於數據庫、文件或者其餘形式數據內容。Logic Data（inner）層是微服務 API 使用的邏輯數據，好比客戶數據、訂單數據等等。Logic Data（outer）層是對外服務提供數據，好比客戶訂單數據。所以，咱們的數據架構的分層結果如圖4所示。

圖4 數據分層架構

除此以外，不少情報會以畫面或報表的形式展示出來。所以在 Logic Data(outer) 之上，能夠構建 Information Block（經常使用的信息塊）、經過 View type（顯示模式）的設定後，最終 View 展示出來。

如圖4所示，越靠近對外服務層，客戶對設計者的影響度越大，越須要從使用性、易用性、適用性等考慮。反之，越遠離對外服務層，設計上更關心數據的存儲。

數據三層架構的好處是實現數據從系統實現到業務實現的逐層過渡，實現業務數據和系統數據間的鬆耦合。同時實現業務的靈活擴展和系統的靈活擴展。

數據架構設計中的要點

上面講述了數據架構的分層設計，下面講述數據架構設計中的要點。

要點1：數據易用性

數據不管用什麼方式實現，其最終目的都是爲業務（或者是客戶）使用的。所以，在對外提供服務的時候，數據的易用性很是關鍵。

圖5 數據易用性

如圖5所示，客戶信息在 Logic Data（inner） 層中爲了數據的柔軟性和非冗餘，把人員信息拆成若干子表來存儲。好比，人員地址表能夠無限多的存儲客戶地址信息。這樣的好處在於每次人員地址更新時，不用直接更新人員地址，而是生成一個新的地址數據，原有的地址信息做爲歷史數據獲得保存，易於數據快速恢復和歷史信息追蹤。但在 Logic Data（outer）層提供外部數據的時候，首先考慮的是一次性能提供足夠用的信息（畢竟查詢的操做大大高於修改的操做），減小業務場景中不須要的信息。好比對通常客戶只提供三個經常使用地址的時候，數據設計中地址一、地址2和地址3放在一張表中。

要點2：主、副數據及數據解耦

每一個微服務 API 的數據徹底獨立是不太現實的，好比訂單中須要有商品、客戶（包括收貨者）、賣家以及價格等數據。若是這些數據都在訂單服務 API 中管理，那麼客戶情報的變動、價格調整等信息都要同步給訂單 API 中數據，數據的耦合度就會變得很是高。在數據設計的時候，須要考慮下降數據間的相互依賴性。所以，首先須要肯定每一個微服務 API 的主數據和副數據。主數據指微服務 API 的核心數據，這種數據的增刪改主要集中在某個微服務 API 中，好比訂單服務 API 中的訂單數據。副數據指參照或者映射其餘微服務 API 的數據，好比訂單服務 API 中的商品數據、價格數據等。其次，爲了下降數據之間的耦合度，用數據關聯表來表徵數據間的關係。若是想去掉數據間的關聯關係，直接去掉關聯表便可，對數據自己的沒有任何影響。具體如圖6所示。

圖6 主、副數據及數據解耦

要點3：分庫分表

隨着業務數據量不斷增長，單一數據庫或單一數據表中會積累大量的數據，好比訂單數據，隨着時間推移和客戶數量的增長，產生的訂單數據也會愈來愈多。當數據累積到必定程度後，數據操做的性能會大幅降低，也就是咱們常說的數據庫「帶不動了」。因此，在數據架構設計階段就應該考慮數據的分庫分表。

如圖7所示，分庫，即咱們把訂單數據分爲當前數據應用庫、歷史數據庫、歷史歸檔數據庫。當前數據應用庫用來支持新訂單的生成以及執行中訂單的增刪改查。歷史數據庫（這裏舉例分爲最近3個月和最近1年）當客戶想看過往訂單的時候才使用。歷史歸檔數據（按年間歸檔）原則上不直接對客戶公開，用於備查、統計分析。對於當前數據應用庫，能夠繼續再分庫，按客戶號範圍來分庫。這樣每一個數據庫的大小都能獲得有效控制。分表，即把一條信息分別存儲在兩張或多張表中。好比把訂單信息按基本信息和詳細信息分表，就能夠適用於訂單的基本信息查詢和訂單詳細信息查詢。總之，分庫分表的核心就是控制單一數據庫的負荷（數據量和數據信息量），經過多表多庫來應對業務數據量的增加。

圖7 分表分庫

要點4：多源數據適配

傳統的關係型數據庫以外，有多種多樣的數據源，好比圖像、聲音、視頻等多媒體數據文件或數據流，CSV、TXT、Doc、Excle、PDF、XML 等各類異構數。這些數據都須要作相應的處理，轉換成可管理的數據信息。所以在數據架構設計的時候，須要給不一樣性質的數據源配置相對應的讀寫適配器，同時也須要有統一調度的地方，如圖8所示。全文中架構技術運用到的知識點能夠在羣619881427免費獲取。感興趣的能夠加入進來。

圖8 多源數據適配

要點5：多源數據緩存

數據處理的性能除了處理邏輯的複雜度之外，還有很大一部分是目標數據的操做時長（含對硬件磁盤設備的讀寫以及網絡的傳輸）。網絡速度特別是光纖的使用後已經大幅度提升，但機器磁盤的讀寫效率並無顯著提升，所以減小磁盤讀寫是提升效率的一個重要途徑。數據緩存就是把經常使用的數據（不會常常更改的數據）、最近使用數據放到內存中。這樣就能夠大幅下降系統對硬件磁盤設備的操做開銷，提升整個數據系統的性能，如圖9所示。

圖9 數據緩存

要點6：數據集市

數據集市是一個很大的話題。當現有的數據不能簡單地經過幾個表數據關聯以及簡單加工後就能夠供業務使用的時候，就須要考慮構建數據集市。數據集市以數據運用的觀點來分析加工數據，經過多源數據的導入、清洗、加工、視圖作成等一系列的數據操做後，爲業務提供可用的、穩定的數據源。例如，對銷售分析中、什麼樣的客戶喜歡什麼樣的商品、價格對銷售金額的影響、銷售金額跟地區日期的關聯關係等多維度分析，就要用數據集市的概念，如圖10所示。

圖10 數據集市

數據承載着信息，好的數據架構設計會使業務系統變得更加流暢、更加容易理解和維護。本文只是總結一些在實際工程中的體會，供你們分享。若是有不足之處、也請你們補充、賜教。

全文完！若是以爲本文有用就收藏轉載一下吧！

感謝你們的閱讀！