Сообщения в архитектуре микросервиса

Я начинаю исследовать сервисно-ориентированные архитектуры и задаюсь вопросом, как лучше всего структурировать обмен сообщениями между процессами. Кажется, что прямые HTTP-вызовы между службами и/или шиной pubsub - это два общих подхода. В каких ситуациях ситуация более благоприятная, чем другая? Я вижу, как pubsub приведет к более развязанным службам, но у меня также создается впечатление, что гораздо сложнее отслеживать путь сообщения, хотя система.

Каковы некоторые ресурсы, чтобы узнать больше об этом? Мне особенно интересно это в контексте очень маленьких "ручных" сервисов (например, Ruby/Sinatra, Node/Express, Redis pubsub и т.д.), В отличие от любого из установленных стеков/пакетов SOA там... хотя я уверен, что применяются те же принципы.

Ответы

Ответ 1

Я дам вам два цента.

but I also get the impression that it becomes much harder to track a message path though the system.

Вы правы, что архитектура pubsub SOA AKA (SOA 2.0) обеспечивает большую развязку, но вы также платите цену, потому что это именно то, что происходит, хотя инструменты, такие как splunk, могут многое помочь.

seems that direct HTTP calls between services and/or a pubsub bus are two common approaches

На самом деле, если вы посмотрите на наиболее используемые .max-события soa frameworks (NServiceBus, Mule и MassTransit), они не используют HTTP-вызовы, но да, вы можете реализовать архитектуру микросервисов и использовать http в качестве протокола связи.

Я понимаю, что вы хотите начать применять некоторые из лучших концепций архитектуры предприятия, но я бы сказал, что вам лучше начать с более простых, но более прочных основ. Нет смысла в вас прыгать на событие soa, не зная, действительно ли вам это нужно. Если бы я начал новую систему и хотел убедиться, что я правильно адаптирую принципы DDD и SOA, я бы начал с определения служб для своего домена. Скажите, что у вас есть 3 службы, вы можете начать с объявления публичных контрактов для каждой из этих служб, вам не нужно ничего особенного, вы можете начать с веб-API WCF/ASP.NET с помощью REST API синхронизации. Затем вы должны убедиться, что каждая служба получит свою собственную базу данных, потому что вы нацелены на низкое взаимодействие, и затем вы можете снова создать слой API (тот, который видится во внешнем мире) с использованием веб-API WCF/ASP.NET, потому что ваши микросервисы не должны подвергаться непосредственно внешнему миру. Таким образом, на данный момент у вас будет SOA, хотя и простой в дизайне, архитектуре, но поскольку у вас были бы четко определенные контракты, вы могли бы расширить свои сервисы, добавив для них возможности асинхронной работы, и для этого вы начнете с добавления очереди сообщений к каждой из услуг. Вы знаете, вам не нужно начинать со сложной системы, начинать с чего-то основного, четко определенного, что позволяет масштабировать, если вам нужно.

Система, о которой я описал, может быть расширена, чтобы легко поддерживать события, если вы этого захотите, и тот факт, что на данный момент вы уже синхронизируете сообщения, не помешает вам добавлять асинговые сообщения в систему.

Но это только мои два цента.