Мікросервіси REST або AMQP, у цьому випадку

Я читав багато статей, що стосуються архітектури мікросервісів, і мені було цікаво, коли використовувати AMQP або REST.

Я читав, що слабке з'єднання між послугами - це добре, і AMQP, здається, є гарним вибором у такому випадку. Але якщо ми використовуємо AMQP, це означає, що нам більше не потрібні кінцеві точки REST (але це означає, що ми втрачаємо концепцію HATEOAS).

Але чи REST справді хороший спосіб побудувати свої послуги? Тому що я не використовуватиму жодних кінцевих точок ... У якому випадку одна краща за іншу?

Коли я повинен використовувати те чи інше?

Відмовившись від REST, ви втрачаєте набагато більше, ніж просто HATEOAS. Якщо ваші мікросервіси є загальнодоступними (і це гарна ідея, щоб вони були публічними або принаймні мали тенденцію до публічності одного дня¹), використовувати що-небудь, крім REST та SOAP, було б проблематично:

• Деякі розробники ніколи не використовували AMQP,

• Деякі використовували AMQP, але часто набагато більше знайомі з REST та SOAP,

• Бібліотеки AMQP для деяких мов не особливо прості,

• Ручне експериментування із сервісом дуже обмежене: я можу використовувати CURL для будь-якого запиту до Amazon S3; що я повинен встановити на своїй машині, якщо хочу грати з AMQP-варіантом S3?

• Налагодження REST і SOAP легко. Я просто відстежую біржі HTTP і аналізую їх. Не впевнений, які інструменти слід використовувати для відладки бірж AMQP.

AMQP - це чудово, але він робиться для дуже конкретних цілей обміну на основі подій. Хоча технічно можливо зробити RPC з AMQP, це не його головне призначення.

Важливий і асинхронний аспект. Іноді це користь: я не хочу блокувати користувальницький інтерфейс програми, роблячи запити на сервери. Іноді це просто робить складніше, ніж потрібно: якщо мені потрібно відновити резервну копію файлу з Amazon S3, оскільки локальний був пошкоджений, а потім відновити резервну копію, мій пакетний файл обов'язково потребує CURL, щоб закінчити свою роботу, перш ніж продовжувати, і синхронна операція (з певним тайм-аутом) має ідеальний сенс.

Зберігайте REST для основних операцій:

• Отримуючи товар,

• Зберігання рахунку-фактури,

і використовувати AMQP для завдань, де обмін повідомленнями має сенс:

• Обробляючи всі рахунки-фактури з вересня та повідомляючи програму, коли звіт буде готовий до показу (враховуючи, що операція зазвичай займає від двох до десяти хвилин),

  ^{Перевага AMQP тут полягає в його асинхронності. Запит HTTP, який очікує на десять хвилин, має хороші шанси викликати тайм-аут та інші проблеми.}

• Повідомлення про те, що резервні копії були пошкоджені для кожного, хто може зацікавити, таких як люди, які підтримують службу, адміністратори бази даних, команда моніторингу, розробники програми, яка використовує цю базу даних тощо.

  ^{Перевагою AMQP тут є, серед іншого, можливість додавання передплатників без зміни програми, яка відстежує резервні копії та спрацьовує сповіщення, коли вона виявляється пошкодженою.}

^{Public Публічний веб-сервіс не обов'язково використовується користувачами за межами компанії. У великих або середніх компаніях вашою послугою часто користуються інші підрозділи тієї самої компанії і мають ті ж вимоги, що і ті, які використовували б будь-які треті сторони: вона повинна недовіряти будь-яким викликам (факт, що якийсь хлопець, якого ви ніколи про те, хто телефонує вашій службі, працює в тій же компанії, що ви робите, це не означає, що він не буде використовувати свої проблеми безпеки), це має бути задокументовано належним чином (адже той самий хлопець з Індії не обов’язково знає ваш номер телефону і не обов'язково знати англійську) тощо.}

Використовуйте обидва.

Веб-сервіси JSON у стилі REST чудово підходять для взаємодії з javascript, ios тощо

AMQP чудово підходить для тривалих процесів, подій та оркестровки мікросервісів.

Але обидва - це лише обгортки зв'язку для фактичної послуги, ви можете виставити одну і ту ж послугу декількома способами і, мабуть, повинні.

AMPQ може добре працювати з веб-розетками, що може виглядати майже як кінцева точка REST, якщо ви прижмуріться.

REST - це стандартна технологія, яка особливо підходить для сумісності між компонентами - це ключова частина, яка чудово підходить для створення веб-сервісу, який може використовувати хтось інший. Однак він страждає від звичайних проблем такої сумісності тим, що він менш ефективний, ніж користувацький протокол.

Якщо ви пишете бек-енд-архітектуру, де послуги споживаються лише ви самі, то ви можете використовувати будь-який протокол, який вам подобається - ви більше не обмежуєтесь використанням такого взаємодіючого. Ви можете використовувати MQ або щось більш щільно з'єднане і виконуюче. Те, яке ви використовуєте, залежить від вашого випадку використання, шина повідомлень дуже хороша для розподіленого набору служб, які обробляють дані, де клієнту не важливо, хто отримує повідомлення, які він надсилає.

AMQP також підтримує точкову комунікацію (наприклад, дивіться python-qpid-protonпідручник). Ви можете реалізувати інтерфейс RESTful за допомогою цього, оскільки REST !=HTTP.

AMQP також працює набагато краще, ніж HTTP.