Java生鮮電商平臺-SpringCloud微服務開發中的數據架構設計實戰精講

Java生鮮電商平臺-SpringCloud微服務開發中的數據架構設計實戰精講

Java生鮮電商平臺:? ?微服務是當前非常流行的技術框架，通過服務的小型化、原子化以及分布式架構的彈性伸縮和高可用性，可以實現業務之間的松耦合、業務的靈活調整組合以及系統的高可用性。為業務創新和業務持續提供了一個良好的基礎平臺。本文包括下面若干內容。

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

2.數據架構設計中的要點

3.要點1：數據易用性

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

5.要點3：分庫分表

6.要點4：多源數據適配

7.要點5：多源數據緩存

8.要點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 服務就是公開對外提供的業務服務.

數據架構自下向上相應的分為 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）層提供外部數據的時候，首先考慮的是一次性能提供足夠用的信息（畢竟查詢的操作大大高于修改的操作），減少業務場景中不需要的信息。比如對一般客戶只提供三個常用地址的時候，數據設計中地址1、地址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所示。