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

　　·微服務技術框架中的多層資料架構設計

　　·資料架構設計中的要點

　　·要點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 服務就是公開對外提供的業務服務。全文中架構技術運用到的知識點可以在群575745314 免費獲取。感興趣的可以加入進來。

　　資料架構自下向上相應的分為 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所示。全文中架構技術運用到的知識點可以在群 575745314 免費獲取。感興趣的可以加入進來。

　　圖8 多源資料適配

　　要點5：多源資料快取

　　資料處理的效能除了處理邏輯的複雜度以外，還有很大一部分是目標資料的操作時長(含對硬體磁碟裝置的讀寫以及網路的傳輸)。網路速度特別是光纖的使用後已經大幅度提高，但機器磁碟的讀寫效率並沒有顯著提高，因此減少磁碟讀寫是提高效率的一個重要途徑。資料快取就是把常用的資料(不會經常更改的資料)、最近使用資料放到記憶體中。這樣就可以大幅降低系統對硬體磁碟裝置的操作開銷，提高整個資料系統的效能，如圖9所示。

　　圖9 資料快取

　　要點6：資料集市

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

　　圖10 資料集市

　　資料承載著資訊，好的資料架構設計會使業務系統變得更加流暢、更加容易理解和維護。

​