Архитектура, ориентированная на обслуживание - Транспортный уровень (http vs messaging)

108
9

Мы рассматриваем возможность изменения разделов нашей архитектуры (и добавления новых компонентов) с использованием сервис-ориентированной архитектуры (SOA). Будет существовать ряд внешних API, которые будут использоваться третьими лицами, которые мы будем использовать с использованием HTTP-интерфейса REST, однако мне было интересно, что лучше всего использовать внутри, поскольку все компоненты находятся под нашим контролем и будут находиться на в то же время потенциально разные технологии (в основном .net и ruby ​​на рельсах).


Будет ли высокая производительность/функциональность в использовании системы обмена сообщениями (redis, rabbitmq, EMS, другие заметные исключения, о которых я не слышал...) вместо HTTP (REST, SOAP и т.д.).


Я изо всех сил пытался найти хорошую информацию по этой теме и (как вы, вероятно, можете сказать), я довольно новичок в этой области, поэтому любые советы или хорошие ресурсы будут оценены!


Thnaks

спросил(а) 2021-01-25T20:55:06+03:00 4 месяца, 4 недели назад
1
Решение
125

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


Недостатком является сложность, переход парадигмы к асинхронной модели и, возможно, производительность (особенно, если вы постоянно сохраняете сообщения).

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


К счастью, шина сообщений может быть длинной, без того, чтобы люди путались и касались ее, самого большого источника ошибок и нестабильности в любой системе.

ответил(а) 2021-01-25T20:55:06+03:00 4 месяца, 4 недели назад
109

В дополнение к тому, что сказал @Will Hartung, я бы также сказал, что это зависит от того, что вы собираетесь делать с вашей системой. Если у вас в основном есть приложения типа клиент-сервер, где у вас мало серверов/служб, и они, как правило, полностью независимы, то, вероятно, будет проще выполнять контракты на обслуживание через REST через HTTP.


Если, с другой стороны, вся ваша система выполняет двунаправленную связь или существует много межпроцессных вызовов (и особенно, если каждый участник системы будет и клиентом, и сервером на некоторых точка), тогда обмен сообщениями - ваш лучший выбор. Из вариантов обмена сообщениями я обнаружил, что AMQP/RabbitMQ является наиболее функциональным и простым в использовании из всех этих. Он предлагает вам настоящую асинхронную платформу для кодирования.


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

Наконец, и это, на мой взгляд, огромная вещь, правильное использование сообщений способствует небольшим независимым фрагментам кода. Они являются более проверяемыми и более удобными в обслуживании, и в целом упрощают вашу корпоративную архитектуру. Если вы попытаетесь обработать слишком много сервисов из конечных точек HTTP, вы в конечном итоге (в течение года или двух) закончите с (1) слишком большим количеством конечных точек, чтобы отслеживать или (2) недостижимый беспорядок кода спагетти.


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

ответил(а) 2021-01-25T20:55:06+03:00 4 месяца, 4 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема