在微服務中該如何管理數據

本篇文章給大家分享的是有關在微服務中該如何管理數據，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

來自Stitch Fix團隊的工程副總裁Randy Shoup在QCon紐約2017會議上討論了如何在基于微服務的應用中管理數據和隔離持久化。他還介紹了將事件（Event）作為微服務的第一類構造。他介紹自己的團隊將機器學習技術應用到了業務的各個組成部分，比如購買、庫存管理以及風格推薦等。

個性化推薦會基于庫存運行機器學習，從而創建出推薦的算法。這些推薦算法隨后會被全國范圍內的設計師所監管，從而形成個性化風格的推薦。

微服務架構是漸進演化的。像eBay、Twitter和Amazon這樣的組織都經歷了一些架構的迭代，從單體應用轉換成了微服務。

微服務除了具有單一的目的、定義良好的接口、模塊化和獨立性之外，還需要負責隔離持久化。Shoup討論了一些持久化的方式，比如操作自己的數據存儲或使用持久化服務。在第一種方式中，會將數據存儲在自己的數據庫實例中，這個實例是由服務團隊擁有并進行運維的。而如果采用持久化服務的話，我們會將數據存儲在數據庫的一個單獨的模式中，由其他團隊或第三方供應商以服務的方式進行運維。數據應該是與服務的其他消費者相隔離的。

事件是微服務架構中的第一類構造。它們代表了現實世界是如何運作的并且保證應用符合一定的領域要求，比如在金融方面。事件是服務接口的重要組成部分，它應該包含服務產生的所有事件以及服務消費的所有事件。

從單體共享數據庫抽取微服務一般涉及到如下幾個步驟：

• 創建服務：服務邊界應該包含服務本身以及它所面對的數據庫；

• 應用要使用服務：通過使用新創建的服務，讓應用與共享數據庫解耦；

• 將數據轉移至私有數據庫：然后將數據從共享數據庫轉移至新的私有數據庫。這不會對客戶端應用造成任何影響，因為它們已經不直接依賴于數據庫；

• 重復操作：為應用中需要抽取成獨立微服務的其他業務功能采用相同的過程。

Shoup還討論到微服務用例涉及到共享數據（Shared Data）、連接（join）以及事務。

共享數據：創建的服務是單一系統記錄（System of Record，SoR）的并且擁有自己的所有數據。數據的其他副本是只讀的，只是非權威（non-authoritative）的緩存。為了訪問共享數據，我們有三個可選方案：同步查找（一個服務調用另外的服務來獲取數據）、具有緩存的異步事件或共享元數據庫；

連接：將數據切分為單獨的服務會讓連接變得很困難。在微服務領域中，我們可以在客戶端應用中進行數據連接，或者是通過監聽兩個服務的事件，創建“物化視圖（Materialized Views）”，并在本地存儲中維護非規格化（denormalized）的兩個數據集的連接結果。

事務：在單體應用中，事務管理非常容易，但是在微服務架構中卻非常困難，因為數據被拆分到了多個不同的服務中了。我們可以將事務實現為一種工作流，它會按照倒序使用補償操作從而形成一種回滾機制。很多現實系統已經采用了這種方式，比如支付處理和費用審批的系統。這些流程也是采用功能即服務（Serverless架構）的理想候選方案。

以上就是在微服務中該如何管理數據，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。