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在他的微服務最難的部分:數據中所說，數據、數據集成、數據邊界、企業使用模式、分布式系統理論、時間等都是微服務的難點(因為微服務實際上就是分布式系統!)
8月福利准時來襲，關注公眾號
后台回復：003即可領取7月翻譯集錦哦~
往期福利回復：001，002即可領取！
