處理微服務請求的設計模式

我有一個基於微服務的應用程序。我有一個接收HTTP請求的Broker/Gateway API。然後我還有兩個服務Service A和Service B.當Broker API收到消息時，它使用RabbitMQ將它發送到服務。然後在他們中的每一箇中，我都應該處理它，並根據消息以不同的方式處理它（執行不同的操作）。處理微服務請求的設計模式

這是我目前正在處理消息的方式：這是有道理使用switch語句，如果我有不超過5

服務A

public string ProcessAsync(Message message) 
    { 

     switch (message.EventCode) 
     { 
      case "context 1": 
       return action1(); 
      case "context 2": 
       return action2(); 
      case "context 3": 
       return action3(); 
      case "context 4": 
       return action4(); 
      case "context 5": 
       return action5(); 
      default: 
       throw new Exception("Unknown message event code!"); 
     } 
    }

- 10種不同的消息類型。但在我的應用程序中，我有30個。編寫這樣一個大條件語句是醜陋的，不同於維護。我正在尋找一種將從應用程序中刪除此問題的設計模式。你有什麼想法？你怎麼看國家模式？

來源

2017-06-20 StefanL19

https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism – jaco0646

您可以嘗試CQRS架構。

在CQRS中，每個命令只有一個處理程序;作爲組件，您需要有一個CommandDispatcher，它使用CommandSubscriber將每個命令分配給正確的處理程序。每個命令執行後，會生成一個或多個事件;每個事件也被分派給一個或多個事件處理程序。

如果每條消息具有相同的類別Message，那麼您的CommandSubscriber應該基於message.EventCode註冊命令處理程序。如果每條消息具有不同的類別（即，Message是interface），則CommandSubscriber應該基於消息類別來註冊命令處理程序。此架構風格尊重Open-close principle，而您的基於交換機的風格則不適用。

來源

2017-06-21 06:00:55

處理微服務請求的設計模式

回答

相關問題