微服務是目前非常流行的技術框架。通過服務的小型化和原子化以及分布式架構的靈活性和高可用性，可以實現服務之間的松耦合、服務的靈活調整和組合以及系統的高可用性。它為業務創新和業務連續性提供了壹個良好的基礎平臺。本文分享了該技術框架下數據架構的設計思路和要點，包括以下內容。
微服務技術框架中多層數據架構的設計
數據架構設計的要點？
點1:數據易用性
第2點:主要數據和次要數據以及數據解耦
第三點:子數據庫和子表
第4點:多源數據適應
第5點:多源數據緩存
第6點:數據集市
為了便於理解，本文用壹個簡化的銷售模型來說明，如下圖所示。圖1展示了客戶、賣家、商品、定價、訂單之間的關系(此處省略支付、物流等其他要素)。
圖1銷售模式
在這種銷售模式下，賣家提供商品，制定價格，客戶選擇產品購買，形成銷售訂單。按照微服務的概念設計，可以分為客戶服務、賣家服務、商品服務、定價服務、訂單服務、公共服務(如認證、權限、通知等。)，如圖2所示。
圖2微服務功能
微服務架構中多層數據架構的設計
分布式架構壹般將系統分為三層:Saas(軟件即服務)、Paas(平臺即服務)和Iaas(基礎設施即服務)。其中，Saas層負責對外提供業務服務，Paas層提供基礎應用平臺，Iaas層提供基礎設施。微服務垂直嵌入在這三層服務中，相互獨立。因此，在設計數據架構時，需要考慮三層服務對數據的關註以及微服務的獨立性。
數據架構的分層設計
圖3微服務技術框架
如圖3所示，Iaas層提供了程序運行的物理基礎環境(這裏涉及到很多硬件和網絡內容，本文不再贅述)。Pass層又細分為三層，基礎服務層，主要負責數據存儲和處理；事務框架層主要負責微服務的註冊、調度管理和分布式事務處理；應用服務層，主要實現各個微服務的API，其他微服務和Saas層的服務調用可以直接調用。Saas服務是壹種公開提供的商業服務。
數據架構自下而上分為原始數據層、邏輯數據(內)層和邏輯數據(外)層(Iaas主要關註基礎硬件環境，本文略)。原始數據層基於數據庫、文件或其他形式的數據內容。邏輯數據(內層)層是微服務API使用的邏輯數據，比如客戶數據、訂單數據等等。邏輯數據(外部)層為外部服務提供數據，比如客戶訂單數據。因此，我們的數據架構的分層結果如圖4所示。
圖4數據層次結構
另外，很多信息會以圖片或者報告的形式展示出來。因此，基於邏輯數據(外部)，可以構造壹個信息塊(常用的信息塊)，最終在設置視圖類型後可以顯示視圖。
如圖4所示，越靠近外部服務層，客戶對設計師的影響越大，越要考慮可用性、易用性和適用性。相反，離外部服務層越遠，在設計上就越關心數據存儲。
數據三層架構的優點是實現了系統實現到業務實現的逐層過渡，實現了業務數據和系統數據的松耦合。同時實現業務和系統的靈活擴展。
數據架構設計的關鍵點
上面介紹了數據架構的分層設計，下面介紹數據架構設計的要點。
點1:數據易用性
無論數據是如何實現的，其最終目的都是為了業務(或客戶)。所以對外提供服務時，數據的易用性非常關鍵。
圖5數據易用性
如圖5所示，為了數據靈活性和非冗余性，客戶信息被分成邏輯數據(內部)層中的幾個子表。例如，人員地址表可以存儲無限的客戶地址信息。這樣做的好處是，每次更新壹個人的地址，不是直接更新這個人的地址，而是生成壹個新的地址數據，將原來的地址信息保存為歷史數據，便於數據快速恢復和歷史信息追蹤。但在邏輯數據(外層)層提供外部數據時，首先考慮的是壹次性提供足夠的信息(畢竟查詢操作遠高於修改操作)，以減少業務場景中不必要的信息。例如，當只為壹般客戶提供三個常用地址時，在數據設計中將地址1、地址2和地址3放在壹個表中。
第2點:主要數據和次要數據以及數據解耦
每壹個微服務API的數據都是完全獨立的，比如商品、客戶(包括收貨人)、賣家、價格，這是不太現實的。如果在訂單服務API中管理這些數據，那麽客戶信息變更、價格調整等信息都要和訂單API中的數據同步，數據的耦合度會變得非常高。在設計數據時，我們需要考慮減少數據之間的相互依賴。所以首先需要確定每個微服務API的壹級數據和二級數據。主數據是指微服務API的核心數據，這些數據的增加、刪除、修改主要集中在壹個微服務API中，比如訂單服務API中的訂單數據。輔助數據是指引用或映射其他微服務API的數據，如訂單服務API中的商品數據和價格數據。其次，為了降低數據之間的耦合度，采用數據關聯表來表示數據之間的關系。如果要刪除數據之間的關聯關系，直接刪除關聯表就可以了，對數據本身沒有影響。如圖6所示。
圖6主數據和輔助數據以及數據解耦
第三點:子數據庫和子表
隨著業務數據量的不斷增加，單個數據庫或單個數據表中會積累大量的數據，如訂單數據。隨著時間的推移，客戶數量的增加，會產生越來越多的訂單數據。當數據積累到壹定程度後，數據操作的性能會大大降低，也就是我們常說的數據庫動不了。因此，在數據架構設計階段，我們應該考慮數據庫和數據表。
如圖7所示，我們將訂單數據分為當前數據應用數據庫、歷史數據庫和歷史存檔數據庫。當前數據應用庫用於支持新訂單的生成以及執行中訂單的增加、刪除和查詢。歷史數據庫(例如，最近3個月和最近1年)僅在客戶希望查看過去訂單時使用。原則上，歷史存檔數據(按年份存檔)不直接向客戶披露，以供將來參考和統計分析。對於當前數據應用庫，可以根據客戶號範圍繼續分庫和分庫。因此可以有效地控制每個數據庫的大小。分表，即將壹條信息分別存儲在兩個或兩個以上的表中。例如，如果將訂單信息按照基本信息和詳細信息分成表格，則可以應用於訂單基本信息和詳細信息的查詢。總之，子數據庫和子表的核心是控制單個數據庫的負載(數據量和數據信息量)，通過多表多數據庫來應對業務數據量的增長。
圖7子表和子庫
第4點:多源數據適應
除了傳統的關系型數據庫，還有各種數據源，如圖像、聲音、視頻等多媒體數據文件或數據流，以及CSV、TXT、Doc、Excle、PDF、XML等各種異構數字。這些數據需要被處理並轉換成可管理的數據信息。因此，在設計數據架構時，需要為不同的數據源配置相應的讀寫適配器，同時需要有統壹的調度場所，如圖8所示。
圖8多源數據適配
第5點:多源數據緩存
數據處理的性能不僅是處理邏輯的復雜度，還有目標數據的運行時間(包括讀寫硬件磁盤設備和網絡傳輸)。網速尤其是使用光纖後有了很大的提高，但是機器磁盤的讀寫效率並沒有明顯的提高，所以減少磁盤讀寫是提高效率的重要途徑。數據緩存就是把常用的數據(不會經常變化的數據)和最近使用的數據放到內存中。這樣可以大大降低系統在硬件磁盤設備上的運行開銷，提高整個數據系統的性能，如圖9所示。
圖9數據緩存
第6點:數據集市
數據集市是壹個大話題。當現有的數據不能簡單的通過幾個表數據關聯和簡單的處理就用於業務時，就要考慮構建數據集市了。數據集市從數據利用的角度分析處理數據，通過多源數據的導入、清洗、處理、視圖制作等壹系列數據操作，為業務提供可用的、穩定的數據源。比如銷售分析的多維度分析要用到數據集市的概念，比如客戶喜歡什麽樣的產品，價格對銷售額的影響，銷售額與區域日期的相關性，如圖10所示。
圖10數據集市
數據承載著信息，好的數據架構設計會讓業務系統更加流暢，更容易理解和維護。本文只是總結了壹些實際工程中的經驗給大家分享。如有不足之處，請補充，並提出意見。
(本文轉載於GitChat技術談)