信息模型驅動的微服務拆分設計思考
微服務傾向於分離的數據庫。我們將數據分離的時候一定會有這些疑問：
- 如何將數據拆分開來；遵循什麼原則；
- 拆分的數據如何組合組織起來進行訪問；
其實拆分數據本事也是微服務劃分的一個影響因素。尼古拉斯·沃斯（Niklaus Wirth）曾經說過“算法+數據結構=程序”。狹義一點來說，很多公司的系統中，數據本身就是業務價值的載體，經年積累的業務價值都存儲在數據中。所以依賴數據爲中心是很多微服務劃分的重要依據。
業務的變化導致數據模型也是會經常變化的。增加刪除字段、實體是經常發生的事情來適配業務的變化。正如算法的設計一樣，數據的變化也需要抽象，將相對不變的概念抽取出來，變化的都是那些具體的一些細節。
由於數據本身細節太多（有些業務細節的表，可能有數十到上百個字段），如果將所有的細節放在一起，肯定眼花繚亂，不好一目瞭然的掌握其中的規律。而且這些細節的增刪其實是不影響整體的概念的。而一般設計也是自頂而下的，所以最初的設計都是從基本的信息實體和關係開始。這層方便講解和溝通，這也就是信息模型，或者說概念模型。
概念模型最終都是要變成物理上的實際實現細節。大體上是分爲這麼兩層：
這兩層模型要互相印證，保證實體模型的修改不能違背信息概念模型的設計。
正是因爲數據的如此重要（大部分業務應用都是圍繞數據的維護進行的），圍繞數據爲中心的設計方法論也層出不窮。DDD就是很熱的一種。DDD中的Domain模型其實是高層次的信息模型。
微服務的優點就是允許系統的不同部分可以獨立的進行構造和優化和演進。這種好處的同時也帶來了運維、性能、數據一致性等一系列的副作用。爲了克服這些副作用，合理的拆分微服務是必須的。數據一致性就要求系統一定要有一種方法保證各個部分的數據依賴是合理的，而不是互相之間斷裂的。傳統的單一實例數據庫的資源管理模塊天然支持事務，而且使用界面非常簡單，所以被廣泛的用於簡化業務的實現。一旦拆分，這些就交給框架或者甚至程序開發人員本身了。目前微服務框架層面支持事務的方式很多，但是很難找到一個像原來單一資源管理器下一樣完美和性能高的方式。
大家常採用的方法就是補償。這種方式需要程序員瞭解更多的實現技術細節以及業務細節。系統平臺只能是提供一個基本的架子（例如TCC，到底如何補償，補償過程會不會產生別的影響，Try的過程如果被Cancel了，中間的數據會不會被錯誤的使用等這些都留給程序員去實現了，而程序員咋知道業務上會有啥影響呢，無疑增加了他們的負擔）。
正是因爲上述的的諸多方案存在的問題，那就儘量減少多次交互的過程，將這些數據高依賴的操作（其實背後就是數據）儘量放在一個交互中，而相關性小的才拆開放在不同的流程中。這樣至少減少了出錯的可能性。一旦出錯也好跟蹤。設計補償的時候也更加容易。
合適的信息粒度很重要，太小就會導致過於頻繁的操作，更高的補償難度以及出錯機率。而太大則會失去微服務本身的優點。
還有一個概念就是信息本身也是內聚的，例如訂單和訂單明細。訂單明細不能單獨存在，必須有一個訂單才能存在，這種在概念模型上就是訂單信息，它是整個信息的根。所有的操作都是有這個根來確定的，而信息明細流水號關鍵字沒有實際的業務含義。我們將業務上通常一起操作的一組對象的操作單元稱爲信息訪問邊界，而那個根爲訪問根，所有的訪問都是通過根來進行的操作。
其實傳統的數據庫建模和訪問並沒有這麼明確的要求，因爲只要有表的唯一key就可以隨意操作，這些操作上下文可以使用標準的Transaction語句來約束。而新的分佈式模型我們提到沒有合適的事務管理器了，之所以這麼做就是要增加抽象層次，減少後面的設計難度。
所有的操作都是根據信息組（所謂信息邊界）的根來定位的。所以事務的操作跟蹤也可以根據這個根來進行。除了問題的補償也是依據這個爲單位，這樣下來關注的細節就大大減少。
由於微服務的目的不是爲了拆分而拆分，它的目的是爲了構造和運維，所以微服務的劃分粒度和信息組的粒度不一定在一個級別上。但是有一點是確定的，就是微服務千萬不要將信息組拆掉。
注：
- 信息組是相對的，要綜合信息訪問的場景來進行劃分。
- 可以一個微服務多個信息組。但是不要拆分信息組。
如果我們將微服務概念和原來UML設計方法論比，和其中的部署模型很類似，只不過那個時候的部署模型不強調數據的分離（後端可能是一個庫），所以沒有過多的衝突點。微服務話作爲新的架構模式，將數據這部分清晰的提了出來，所以帶來了新的價值（和SOA也有類似的關係）。
上述的信息組之間也是有聯繫的，也就是說微服務和微服務之間的數據怎麼進行關聯呢？關聯操作如何才更清晰呢？後面的章節會繼續思考和分析。