我開始研究面向服務的體系結構，並想知道如何在進程之間構建消息傳遞。看來，服務和/或pubsub總線之間的直接HTTP調用是兩種常見方法。在哪種情況下比另一種更有利？我可以看到pubsub如何導致更多的解耦服務，但我也覺得通過系統跟蹤消息路徑變得更加困難。微服務體系結構中的消息
有關這方面的更多知識，有哪些資源？我特別好奇這一點，在非常小的「手動」服務（即Ruby/Sinatra，Node/Express，Redis pubsub等）中，與任何指定的SOA堆棧/套件相反。雖然我確信同樣的原則適用。
謝謝！
我給你我兩分錢。
but I also get the impression that it becomes much harder to track a message's path though the system.
你說得對，發佈訂閱SOA架構AKA（SOA 2.0）提供脫鉤了很多，但也付出了代價，因爲這正是發生什麼事，但像Splunk的工具可以幫助許多。
seems that direct HTTP calls between services and/or a pubsub bus are two common approaches
其實，如果你看一下最常用的.NET事件的SOA框架（NServiceBus，騾子和MassTransit）他們不使用HTTP調用，但是是可以實現一個微服務架構和使用HTTP作爲通信協議。
我知道你想要開始應用一些最好的企業架構概念，但我會說你最好從更簡單但更強大的基礎開始。沒有意識到你跳到事件soa，不知道你是否真的需要它。如果我正在創建一個新系統，並希望確保我正確適應了DDD和SOA原則，我將首先確定我的域的服務。因此，假設您有3個服務，您可以先爲每個服務聲明公共合同，然後您不需要任何特殊的服務，就可以從帶有同步REST API的WCF/ASP.NET Web API開始。然後，您將確保每個服務都會獲得自己的數據庫，因爲您的目標是低耦合，然後您可以使用WCF/ASP.NET Web API再次創建一個API層（外部可見的層）因爲你的微服務不應該直接暴露給外部世界。因此，在這一點上，您將擁有一個像設計或體系結構一樣簡單的SOA，但由於您將擁有明確定義的合同，因此您可以通過向其添加異步功能來擴展服務，並且您可以從添加消息隊列開始到每個服務。你知道，你不需要從一個複雜的系統開始，從一些基本的，明確定義的開始，這可以讓你在必要時擴展。
如果您願意，我所描述的系統可以擴展爲支持事件，而且此時您已經同步消息的事實不會阻止您將異步消息添加到系統中。
但這些只是我的兩分錢。