來自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架構)的理想候選方案。
本文作者：srini penchikala
來源：51cto