跨微服務的查詢/分頁

Question

我們的商店最近開始採用SOA方法進行應用程序開發。我們看到SOA和微服務的關注點，可重用性和其他好處的分離帶來了一些很大的好處。

然而，一個大我們堅持的項目是聚合，篩選和跨服務分頁結果。讓我用一個場景來描述這個問題。

假設我們有3個服務：

1. PersonService - 對那些購買產品的商店信息 - 人們存儲的信息（姓名，地址等）
2. ItemService。
3. PaymentService - 存儲人們爲不同項目付款的信息。

現在，假設我們想要構建一個報告/管理工具，可以彙總顯示/報告多個服務。例如，我們想要顯示分類的付款清單，以及每個付款用於的人員和項目。這非常簡單：獲取付款清單，然後查詢相應的人員和物料記錄的PersonService和ItemService。

但是，當我們想要過濾掉這些數據時，問題就起作用了：例如，顯示購買了物品'Car'的名字爲「Bob」的人的付款分類列表。這使事情變得更加複雜，因爲我們需要過濾來自3種不同服務的結果，而不知道每個服務將返回多少結果。

從性能的角度來看，一遍又一遍查詢所有的服務來縮小結果將是非常昂貴的，所以我一直在研究更好的解決方案。但是，我找不到這個問題的具體解決方案（或者至少是「最佳實踐」）。在一個單一的應用程序中，我們簡單地在不同的表中使用SQL連接。我在計算各種服務如何/類似的情況時遇到了很多麻煩。

我對社區的問題是：你的方法是什麼？事情我已經考慮：

1. 使用某種形式的搜索索引（Elasticsearch，Solr的），它包含所有服務的所有數據（通過事件更新推出的服務），然後查詢搜索索引爲結果。
2. 試圖瞭解如何像GraphQL和Neo4j項目可能會幫助我們解決這些問題。

Answer 1

我堅持Sam Newman誰在第4章說他的書像「共享數據庫」：

還記得我們談到後面好微服務的核心原則是什麼？強大的內聚力和鬆散的耦合 - 與數據庫整合，我們失去了這兩件事。數據庫集成使服務共享數據變得非常容易，但對共享行爲沒有任何幫助。我們的內部代表性通過電線暴露給消費者，避免發生突變是非常困難的，因此不可避免地會導致對所有變化的恐懼。避免（幾乎）所有成本。

這是我在內容管理系統詛咒時所做的觀點。

在我看來，微服務是自治的，如果它共享事物或消費共享的東西，它是不可能的。我在這裏做的唯一例外是Domain-Objects，這些代表了對商業模式的共同理解，並且必須用於微服務之間的溝通。

如果ER或AggregationOriented數據庫（分爲基於文檔或基於圖表）更好地滿足需求，它取決於微服務本身。 有趣的是，通過鬆散耦合和自治，你就可以做到這一點！

如果PaymentService共享「爲A人支付多少費用」的行爲，他需要知道Person A才能滿足此要求。但是他所知道的有關人員A的一切必須來自PersonService，可能在運行時（PaymentService可能只是存儲一個id）或基於事件（PaymentService將它需要的數據存儲到Domain-Object用戶，觸發並提供更新的內容由PersonService）。 PaymentService本身不共享用戶本身。