架構師成長之路：微服務開發中的數據架構設計分析

數據庫設計技術 SaaS IaaS 軟件硬件 Java進階交流 2019-05-24

前言

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

微服務技術框架中的多層數據架構設計
數據架構設計中的要點
要點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 服務就是公開對外提供的業務服務。

數據架構自下向上相應的分為 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所示。

圖8 多源數據適配

要點5：多源數據緩存

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

圖9 數據緩存

要點6：數據集市

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