數據作為微服務的實現方法是什么

這篇文章主要介紹“數據作為微服務的實現方法是什么”，在日常操作中，相信很多人在數據作為微服務的實現方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據作為微服務的實現方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

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或將其嵌入到應用程序中。

到此，關于“數據作為微服務的實現方法是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！