前言
什麼是微服務？微服務（Microservice Architecture）是近幾年流行的一種架構思想，關于它的概念很難一言以蔽之。簡而言之，微服務架構風格是一種将單個應用程式作為一套小型服務開發的方法，每種應用程式都在自己的程序中運作，并與輕量級機制（通常是HTTP資源API）進行通信。 這些服務是圍繞業務功能建構的，可以通過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的程式設計語言編寫，并使用不同的資料存儲技術。
正文
微服務是目前非常流行的技術架構，通過服務的小型化、原子化以及分布式架構的彈性伸縮和高可用性，可以實作業務之間的松耦合、業務的靈活調整組合以及系統的高可用性。為業務創新和業務持續提供了一個良好的基礎平台。本文分享在這種技術架構下的資料架構的設計思想以及設計要點，本文包括下面若幹内容。
微服務技術架構中的多層資料架構設計
資料架構設計中的要點
要點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所示，越靠近對外服務層，客戶對設計者的影響度越大，越需要從使用性、易用性、适用性等考慮。反之，越遠離對外服務層，設計上更關心資料的存儲。
資料三層架構的好處是實作資料從系統實作到業務實作的逐層過渡，實作業務資料和系統資料間的松耦合。同時實作業務的靈活擴充和系統的靈活擴充。
上面講述了資料架構的分層設計，下面講述資料架構設計中的要點。
資料無論用什麼方式實作，其最終目的都是為業務（或者是客戶）使用的。是以，在對外提供服務的時候，資料的易用性非常關鍵。
圖5 資料易用性
如圖5所示，客戶資訊在 Logic Data（inner） 層中為了資料的柔軟性和非備援，把人員資訊拆成若幹子表來存儲。比如，人員位址表可以無限多的存儲客戶位址資訊。這樣的好處在于每次人員位址更新時，不用直接更新人員位址，而是生成一個新的位址資料，原有的位址資訊作為曆史資料得到儲存，易于資料快速恢複和曆史資訊追蹤。但在 Logic Data（outer）層提供外部資料的時候，首先考慮的是一次性能提供足夠用的資訊（畢竟查詢的操作大大高于修改的操作），減少業務場景中不需要的資訊。比如對一般客戶隻提供三個常用位址的時候，資料設計中位址1、位址2和位址3放在一張表中。
每個微服務 API 的資料完全獨立是不太現實的，比如訂單中需要有商品、客戶（包括收貨者）、賣家以及價格等資料。如果這些資料都在訂單服務 API 中管理，那麼客戶情報的變更、價格調整等資訊都要同步給訂單 API 中資料，資料的耦合度就會變得非常高。在資料設計的時候，需要考慮降低資料間的互相依賴性。是以，首先需要确定每個微服務 API 的主資料和副資料。主資料指微服務 API 的核心資料，這種資料的增删改主要集中在某個微服務 API 中，比如訂單服務 API 中的訂單資料。副資料指參照或者映射其他微服務 API 的資料，比如訂單服務 API 中的商品資料、價格資料等。其次，為了降低資料之間的耦合度，用資料關聯表來表征資料間的關系。如果想去掉資料間的關聯關系，直接去掉關聯表即可，對資料本身的沒有任何影響。具體如圖6所示。
圖6 主、副資料及資料解耦
要點3：分庫分表随着業務資料量不斷增加，單一資料庫或單一資料表中會積累大量的資料，比如訂單資料，随着時間推移和客戶數量的增加，産生的訂單資料也會越來越多。當資料累積到一定程度後，資料操作的性能會大幅下降，也就是我們常說的資料庫“帶不動了”。是以，在資料架構設計階段就應該考慮資料的分庫分表。
如圖7所示，分庫，即我們把訂單資料分為目前資料應用庫、曆史資料庫、曆史歸檔資料庫。目前資料應用庫用來支援新訂單的生成以及執行中訂單的增删改查。曆史資料庫（這裡舉例分為最近3個月和最近1年）當客戶想看過往訂單的時候才使用。曆史歸檔資料（按年間歸檔）原則上不直接對客戶公開，用于備查、統計分析。對于目前資料應用庫，可以繼續再分庫，按客戶号範圍來分庫。這樣每個資料庫的大小都能得到有效控制。分表，即把一條資訊分别存儲在兩張或多張表中。比如把訂單資訊按基本資訊和詳細資訊分表，就可以适用于訂單的基本資訊查詢和訂單詳細資訊查詢。總之，分庫分表的核心就是控制單一資料庫的負荷（資料量和資料資訊量），通過多表多庫來應對業務資料量的增長。
圖7 分表分庫
傳統的關系型資料庫之外，有多種多樣的資料源，比如圖像、聲音、視訊等多媒體資料檔案或資料流，CSV、TXT、Doc、Excle、PDF、XML 等各種異構數。這些資料都需要做相應的處理，轉換成可管理的資料資訊。是以在資料架構設計的時候，需要給不同性質的資料源配置相對應的讀寫擴充卡，同時也需要有統一排程的地方，如圖8所示。
圖8 多源資料适配
資料處理的性能除了處理邏輯的複雜度以外，還有很大一部分是目标資料的操作時長（含對硬體磁盤裝置的讀寫以及網絡的傳輸）。網絡速度特别是光纖的使用後已經大幅度提高，但機器磁盤的讀寫效率并沒有顯著提高，是以減少磁盤讀寫是提高效率的一個重要途徑。資料緩存就是把常用的資料（不會經常更改的資料）、最近使用資料放到記憶體中。這樣就可以大幅降低系統對硬體磁盤裝置的操作開銷，提高整個資料系統的性能，如圖9所示。
圖9 資料緩存
資料集市是一個很大的話題。當現有的資料不能簡單地通過幾個表資料關聯以及簡單加工後就可以供業務使用的時候，就需要考慮建構資料集市。資料集市以資料運用的觀點來分析加工資料，通過多源資料的導入、清洗、加工、視圖做成等一系列的資料操作後，為業務提供可用的、穩定的資料源。例如，對銷售分析中、什麼樣的客戶喜歡什麼樣的商品、價格對銷售金額的影響、銷售金額跟地區日期的關聯關系等多元度分析，就要用資料集市的概念，如圖10所示。
資料承載着資訊，好的資料架構設計會使業務系統變得更加流暢、更加容易了解和維護。本文隻是總結一些在實際工程中的體會，供大家分享。
總結
由于篇幅限制文章寫到這裡就結束啦，小編在這裡整理了一份微服務的詳細學習資料文檔，想要對微服務有更深入了解的小夥伴可以幫忙點贊+關注一下 ，私信小編“微服務”擷取哦 。
由于篇幅限制小編隻為大家展示部分内容
文檔内容包括基礎知識、微服務架構、負載均衡、微服務釋出與調用、微服務跟蹤、微服務資料庫實戰等等
一.基礎知識
二.微服務架構
三.微服務釋出與調用