微服務架構依賴

我已經閱讀了很多關於微服務架構，但有一兩件事，我不知道如何實現，並希望你能幫助我這個...微服務架構依賴

可以說我有一個網絡的API - 接收OrderMicroservice負責處理的訂單的端點。訂單放置時必須更新庫存，以便OrderMS將訂單發佈給訂戶（例如Nats使用的訂單/訂單）和InventoryMS將更新庫存，因爲它訂閱了當前的事件/消息....我想要放寬耦合架構，並使用對給定信息感興趣的模塊/ MS的異步調用。

如果您有1個InventoryMS實例，那麼給定的方案可以很好地工作，但是如果您已經橫向擴展了InventoryMS，會發生什麼情況，即有5個InventoryMS實例，並且它們都訂閱inventory.change.event並嘗試更新庫存？

什麼樣的體系結構或消息模式應該用於像這樣的場景，這種情況下，MS可以在MS相互依賴的情況下使用鬆耦合體系結構？一種方法是通信內部是通過使用斷路器模式的REST-呼叫，但是然後我覺得我用一些智能（斷路器）建立MS的monolite ...

感謝您的幫助！

來源

2017-04-12 user3154653

使用點對點消息模型，只有一個消費者會收到消息。在pub/sub模型中，所有訂閱者都會收到通知。
ActiveMQ的示例。

來源

2017-04-12 20:00:57 dstar55

好吧，我會對此展開調查點使用納茨:)，這要歸功於點消息的情況下！ – user3154653

如果您使用Java，請檢查AvtiveMQ，例如 – dstar55

您仍然可以使用發佈/訂閱模型，但您需要設置多個實例，以便只有一個會收到消息。具體取決於pubs/sub機制

例如在AMQP系統（如RabbitMQ）中，您將在交易所上發佈事件。消費者服務將對該交換進行排隊，並且相同服務的所有實例將從同一隊列中讀取（因此只有一個會處理任何給定的消息）

另一個例子是Kafka-在Kafka中的所有實例相同的服務將使用相同的consumer group - 因此，每個訂閱服務只有一個實例會收到消息

其他發佈/訂閱系統也會有類似的解決方案。

點對點具體實例是不是一個很好的解決方案，因爲它會在幾個不同的服務

來源

2017-04-12 21:00:57

ActiveMQ中的點對點（目標：隊列）正在消費者端使用循環分配，因此如果您有更多消費者，它們將不會與特定實例耦合。但是你也可以用pub/sub模型來實現同樣的事情。 – dstar55

微服務架構依賴

回答

相關問題