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


16

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

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

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

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

Відповіді:


10

Відмовившись від 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 Публічний веб-сервіс не обов'язково використовується користувачами за межами компанії. У великих або середніх компаніях вашою послугою часто користуються інші підрозділи тієї самої компанії і мають ті ж вимоги, що і ті, які використовували б будь-які треті сторони: вона повинна недовіряти будь-яким викликам (факт, що якийсь хлопець, якого ви ніколи про те, хто телефонує вашій службі, працює в тій же компанії, що ви робите, це не означає, що він не буде використовувати свої проблеми безпеки), це має бути задокументовано належним чином (адже той самий хлопець з Індії не обов’язково знає ваш номер телефону і не обов'язково знати англійську) тощо.


Що з завантаженням залежних об'єктів за допомогою AMQP? Як і користувач, пов’язаний із службою виставлення рахунків (у масивній архітектурі мікросервісу), сильний доступ до астеронічності доступу до гетео (синхронного) VS REST?
Томас Томас

5

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

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

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

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

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


1
"якщо ти косиш на це" хаха, це було чудово.
Ієн Дункан

0

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

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


2
Я не згоден, наскільки я переживаю, вони мають перехресні цілі; ви (як правило) не повинні піддавати AMQP через загальнодоступний Інтернет; у нього набагато менше аутентичних можливостей для однієї речі, і зазвичай користувачі загальнодоступного Інтернету хочуть відповідей від своєї активності. REST ідеально підходить для публічного користування Інтернетом з цієї причини. Найбільша різниця, однак, полягає в тому, що AMQP є асинхронним ( можливі синхронні схожі форми поведінки, але це не те, для чого призначені MQ), а REST - синхронний (так, повернення 202диктує асинхронність, але чому ви використовували REST тоді? Можливо, тому що це публічно.)
Джиммі Хоффа

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

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

Так, це має сенс напевно; Я читав його питання по-іншому: Схоже, він читав про ідею мікросервісів, і не розуміє відповідних причин вибрати AMQP проти REST. Всередині ви можете використовувати все, що завгодно, але все ж є конкретні причини використовувати AMQP проти REST навіть внутрішньо; сервіси, які хочуть асинхронність, повинні використовувати AMQP внутрішньо, сервіси, які синхронізуються (думаю, чиста послуга обробки: Сировина даних в -> Оброблені дані), повинні бути REST. Для обох технологій IPC існують чіткі переваги та недоліки, ви їх знаєте і повинні перелічити їх у своїй відповіді! :)
Джиммі Хоффа

0

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.