微服務架構中的API調用

Question

我不確定我的問題是否可以解釋，但我會盡可能地在這里解釋一下。 我目前正在探索和使用微服務架構，以了解它是如何工作和了解更多。 大多數情況下，我了解事情的運作方式，API Gateway在此架構中的作用等等......

所以我還有一個理論問題。 例如，假設有2個服務，即。 事件（管理可能的事件）和管理與特定事件相關的票證的服務票證（可能有許多票證）。 所以這兩個服務實際上是相互依賴的，但它們有一個獨立的數據庫，完全是隔離的，松散耦合的，就像應該在“理想的”微服務環境中一樣。

現在想象一下，我想獲取與該事件相關的事件和所有票證，並將其顯示在移動應用程序或Web應用程序或其他任何內容中。 在這種情況下，調用多個服務/ URL來獲取數據並輸出到UI完全沒問題嗎？ 或者有更好的方法來獲取和聚合這些數據。

從我的閱讀中，從另一個服務調用一個服務的不同來源是增加延遲，使服務相互依賴，一個服務中的未來變化將破壞另一個服務等，所以這根本不是一個好主意。

我很抱歉，如果我重復一個問題並且已經在某個地方被問過（雖然我找不到它），但是我需要早些時候遇到這個問題的人的意見，並且可以更好地解釋這里的流程。

Answer 1

在這種情況下，調用多個服務/ URL來獲取數據並輸出到UI完全沒問題嗎？ 或者有更好的方法來獲取和聚合這些數據。

1. 是的，可以從您的UI調用多個服務，並根據您的需要聚合您的前端代碼中的數據。 實際上，在這種情況下，您可以調用2 Rest API來從票務微服務和事件微服務中獲取數據。

2. 另一個選擇是你有一些Views / Read優化的微服務，它將聚合來自兩個微服務的數據，並作為只讀微服務。 這當然涉及一些延遲考慮和其他事情。 例如，如果您有像View這樣的需求，可以使用這種方法，該View包含多個模型（類似於非規范化視圖），這些模型將被大量訪問和/或具有一些復雜的過濾器選項。 在這種方法中，您將擁有第三個微服務，該服務將根據您的2個微服務（票證和事件）的數據進行匯總。 這種微服務將針對閱讀進行優化，並且如果需要還可以使用不同的存儲類型（文檔db或類似）。 對於您的情況，如果您決定這樣做，您只能對此微服務進行一次API調用，它將為您提供所有數據。

3. 從另一個調用一個微服務。 在某些情況下，你無法避免這種情況。 盡管網上有一些消息來告訴你不要這樣做但有時這是不可避免的。 對於您的示例，我不建議使用此方法，因為它會產生耦合和不必要的延遲，這可以通過其他方法避免。

背景資料：

您可以閱讀此答案，其中主題是關於是否可以從另一個微服務調用一個微服務。 對於您的特定情況，它不是一個好的選擇，但在某些情況下可能是。 所以請閱讀它以獲得一些澄清。

摘要：

我曾經在系統中工作，我們在那里做所有這三件事。 這實際上取決於您的業務場景和應用程序的需求。 選擇哪種方法取決於以下幾個標准：來自UI的可用性，擴展（如果您對微服務有很高的需求，您可以考慮添加第三個微服務，它可以匯集門票和事件微服務的數據） ，域耦合。 對於您的情況，我建議用戶預期選項1或選項2（如果您有高要求的UI）。 對於某些情況，選項1就足夠了，並且擁有第三個微服務將是一種過度殺傷，但有時這也是一個選項。

Answer 2

根據我對基於雲的服務（主要是Microsoft Azure）的體驗，一個服務調用另一個服務的延遲確實存在，但可以依賴於最小化。 與用戶設備通過他們碰巧具有的任何互聯網計划進行呼叫所涉及的未知延遲相比，尤其如此。

總是有一個消費客戶端依賴於服務及其定義的接口，無論是SPA應用程序還是其他服務。 因此，在您描述的場景中，必須聚合兩個服務的有效負載。

基於此，我已經看到通過使用處理客戶端請求的服務，聚合來自n個服務的結果並相應地響應來改進性能。 這確實會導致依賴性，但隨着服務的發展，可以同時激活多個版本的服務，從而允許您在適當的時候折舊舊版本。

我希望有所幫助。

Answer 3

可選建議

您可以在任何最適合的服務中維護讀取表（非規范化）。 為什么？ - 因為CQRS適用於需要的地方，CQRS最適合大型和復雜的應用。 它介紹了系統的復雜性，並且您獲得的利潤更少，更令人頭痛。