微服務-數據聚合CQRS

微服務常常是按業務維度劃分多個服務(固然還有其餘各類考慮維度), 劃分爲多個維度後, 好處天然不少, 其中也會有一些問題, 好比咱們講的數據依賴問題html

好比前端要展現一個商品詳情頁面, 不只依賴商品服務、還須要依賴庫存服務、評分服務等等, 那麼誰來對接這套服務呢?前端

在咱們劃分衆多微服務的同時, 在這些微服務的上層確定要有一層專門提供給前端聚合數據, 咱們一般稱爲 BFF(Back-end For Front-end), 服務於前端的後端服務, BFF功能是根據業務需求常常變化調整的mysql

普通的用戶按這種方式是沒有問題的, 每一個服務獨佔一個數據資源, 之間互不影響, 舉例若是爲運營後臺數據查詢聚合的時候, 這種在數據資源獨立的狀況下, 需求實現起來是很是困難的.redis

一般咱們採用數據分發預聚合方式來知足此類需求, 將資源聚合到 mysql、mongo、redis、es提供查詢。其實這也是咱們常說的 CQRS 模式sql

咱們看下面兩種預聚合的方式:後端

此模式對業務是有必定的侵入性的, 上圖是在插入業務表後, 同時將對應事件記錄插入到發件箱表中, Relay任務會定時讀取發件箱表, 推送給對應消費者, 存入對應倉庫。markdown

是指捕獲mysql binlog或mongo oplog等日誌變動記錄, 此方式對業務沒有侵入, 可是業務運維難度較高.運維

上面咱們提到了一下 CQRS, 簡單描述的話能夠理解爲資源的讀寫分離, 其實在工做中這種模式是很是常見的.異步

經過各個服務寫入->數據聚合到ES、REDIS等->數據中心讀取微服務

這種方式寫入和讀取拆分紅了兩種數據資源, 帶來的好處是更容易和更靈活知足業務需求, 下降對原服務的影響. 固然也擴大了數據不一致性的時間窗口, 須要從上層用戶體驗設計上去配合支持這種系統(好比異步通知等)