數據做爲微服務 分佈式數據集中集成

1.引言

Microservices(微服務)是新軟件項目中所青睞的架構設計。隨着從單一系統到分佈式系統的演化不只發生在應用程序空間中，並且發生在數據存儲中，管理數據成爲最困難的挑戰之一，然而，要從這種類型的方法中得到最大的收益，須要克服前面的幾個需求。本文研究了將數據做爲服務實現的一些考慮事項。

在遵循微服務設計指南時，咱們找到一些對數據處理的參考。其中一些常見的方向包括:

• 每一個服務的使用各自的私有數據庫實現鬆散耦合。
• 擁抱最終一致性。
• 爲最終一致性事務實現saga pattern。
• 使用Command Query Responsibility Segregation(CQRS)和API組合。

考慮到這一點，當將鬆耦合做爲體系架構中的一個基本部分時，共享數據庫如今就變成了一個反模式，使得事務和查詢變得更加困難。每一個服務使用數據存儲都須要封裝數據，而與體系架構的其餘域的交互應該只發生在API級別，這鼓勵咱們隱藏數據實現細節。所以，使用諸如Spring Boot這樣的輕量級框架只是微服務之旅的第一步。

2.查詢的挑戰

由於每一個服務都有數據存儲，因此咱們須要使其可供其餘服務使用，從而成爲該域的入口點。因爲全部數據調用都發生在服務級別，而且根據它們的域，當須要組合數據視圖時，傳統的table join（錶鏈接）再也不是咱們在共享數據庫實現中使用的方案。此外，咱們沒法編寫查詢私有數據存儲並聚合數據的服務，由於它違反了封裝設計。

爲了解決前面的挑戰，咱們須要回到微服務體系架構中，使用成熟的企業集成模式(Enterprise Integration Patterns, EIP)，好比 content enrichment(內容濃縮)和aggregator( 聚合器)。大多數時候，這些模式被從新命名爲API組合模式，一般在API網關之類的組件中實現。

一般，API組合模式涉及到添加另外一個服務，該服務使用所需的信息調用底層數據服務來組合所需的數據視圖。以下圖所示，它將首先查詢客戶服務的基本信息，而後使用該信息從支付服務檢索該客戶的歷史記錄。

乍一看，這看起來像是一個簡單的組合任務，然而，業務一般須要對數據的使用方式進行愈來愈多的控制，並向此類服務添加更多的邏輯。對要檢索的數據量、消費終端用戶的權限等的限制是常見的業務需求，這使得實現這類服務成爲一項全職維護任務。

另外一方面，Command Query Responsibility Segregation(CQRS)試圖解決查詢挑戰，側重於維護從多個源事件聚合的一個或多個物化的數據集。 結果，系統的複雜性隨着事件總線如今的要求而增長。咱們將在之後的文章中討論這種模式。

3.分佈式數據集成

正如前面所討論的，微服務的分佈式特性使得服務與服務的通訊和服務組合對於成功實現相當重要。嘗試以一種主流的方式從頭開始實現全部的服務，儘管這是可能的，但並不老是建議這樣作，特別是在已存在專門的工具並幫助咱們簡化工做的狀況下。

實際上，從頭開始編碼全部內容，經過服務使數據可用於外部消費的例子是能夠避免的。 咱們能夠公開不一樣商店中的數據，不只是使用現有框架的關係數據庫，這些框架能夠幫助咱們實現API組合模式，還可使用簡單的數據即微服務服務。

分佈式數據集中集成經過一個統一的API提供對任何存儲實現中的數據的集成訪問。數據集成容許鏈接和統一數據，即便數據存儲在SQL或JDBC以外的不止一種數據源中。與數據庫管理系統相反，它不該該存儲任何數據，而應該做爲一個single point(單點)接口來優化訪問數據源。

顯然，這種框架應該與微服務的分佈式特性相兼容。所以，引擎和實現應該是輕量級的，而且可以做爲容器部署在雲環境中。它應該具備在運行時獨立執行組件的靈活性，好比Spring Boot或將其嵌入到應用程序中。

4.總結

綜上所述，除了在微服務體系架構中構建服務以外，還須要使用一般已證明的實踐，如 Enterprise Integration Patterns(企業集成模式)和Data Integration techniques(數據集成技術)。在以輕量級和分佈式方式提供安全訪問層的同時，查詢不一樣數據源並將其鏈接以顯示有意義信息的能力，能夠簡化您的應用程序。並且，正如 Christian Posta在他的微服務最難的部分:數據中所說，數據、數據集成、數據邊界、企業使用模式、分佈式系統理論、時間等都是微服務的難點(由於微服務實際上就是分佈式系統!)

送福利啦~ 近期將以前已翻譯文章，整理成了PDF。 ​ 在公衆號後臺回覆：002便可領取哦~ ​ 後續也會不斷更新PDF的內容，敬請期待！