Чи повинні служби спілкуватися безпосередньо між собою в архітектурі мікросервісу?

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

Чи повинні ці служби мати можливість спілкуватися безпосередньо між собою? Якщо так, чи не зробить їх пара, що суперечить концепції мікросервісів?

Якщо клієнт повинен зателефонувати їм один за одним, щоб отримати необхідні йому дані для завантаження веб-сторінки на клієнта?

Або я повинен мати ще один шар поверх своїх послуг, який обробляє запит від клієнта, отримує дані для цього запиту і потім надсилає його назад клієнту?

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

Зрештою, у вас з’явиться додаток для мікросервісів, який повільніше, ніж це було б альтернативне монолітне додаток, але майже все ті ж проблеми!

Я повинен не погодитися з @Robert Harvey

На практиці, однак, один або кілька ваших мікросервісів (можливо, всі вони) спілкуватимуться з деяким центральним сховищем даних, таким як база даних SQL.

Інтеграційна база даних є добре відомою антипатернією

Набагато кращим рішенням є використання моделі публікації та підписки, щоб зробити зв’язок між вашими службами асинхронним:

Погляньте, будь ласка, на CQRS / ES спосіб реалізації цього способу спілкування, Грег Янг та інші хлопці пропонують безліч приємних відеозаписів на цю тему. Просто google для ключового слова "CQRS / ES". При такому підході кожна послуга одночасно стане видавцем та передплатником, що дозволить послугам бути значно меншими.

Ось хороша серія статей про мікросервіси, які проливають світло на суперечки навколо теми. Дуже детальне пояснення з приємними ілюстраціями.

Ви отримаєте багато дуже хороших ідей, прочитавши, що Уді Дахан має сказати про SOA .

Служба - це технічний орган для конкретних можливостей бізнесу. Будь-який фрагмент даних або правило повинен належати лише одній службі.

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

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

Зокрема, що стосується складу інтерфейсу, стаття Мауро Сервієнті про склад інтерфейсу є гарною відправною точкою. Дивіться також відео Уді, доступне тут .

Чи повинні ці служби мати можливість спілкуватися безпосередньо між собою? Якщо так, чи не зробить їх пара, що суперечить концепції мікросервісів?

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

Крім того, такі методи, як виявлення послуг, можуть полегшити залежність від конкретного постачальника послуг, а брокери повідомлень можуть від'єднати виробників і споживачів (вони все ще повинні розуміти повідомлення один одного та як взаємодіяти з API брокера повідомлення - немає ніякої магії ).

Це залежить від того, що ви маєте на увазі під «безпосередньо».

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

Що не в порядку - це одна мікрослужба викликати іншу, використовуючи прямі виклики методу; це зробило б обидва мікропослуги частиною одного моноліту.

Чи повинні ці служби мати можливість спілкуватися безпосередньо між собою? Якщо так, чи не зробить їх пара, що суперечить концепції мікросервісів?

З’єднання не є поганим словом. Кожна програма вже має певний ступінь зв'язку; програми, які спілкуються з вашими мікросервісами, вже поєднані з мікросервісами, інакше вони не працюватимуть.

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

На практиці, однак, один або кілька ваших мікросервісів (можливо, всі вони) спілкуватимуться з деяким центральним сховищем даних, як, наприклад, база даних SQL. Залежно від того, як ви хочете досягти своєї мети, у вас може бути просто одна мікросервіс певним чином змінити дані бази даних, яку інша мікросервіс запитає, щоб отримати зміни.

Здається, що говорячи про SOA та архітектуру взагалі, люди захоплюються семантикою та жаргоном. Що робить послугу "мікро"? Зрештою, це певний набір характеристик, який у будь-якій "системі балів", яку ви використовуєте, явно не робить послугу "немікро". Що це таке, що правосуддя верховного суду говорило про непристойність? "Я це буду знати, коли побачу".

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

Якщо клієнт повинен зателефонувати їм один за одним, щоб отримати необхідні йому дані для завантаження веб-сторінки на клієнта?

Це залежить; однак я б запропонував надати клієнтам безпосередньо корисні можливості та приховати (інкапсулювати) деталі того, як збираються результати (наприклад, за допомогою декількох мікросервісів).

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

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

(Крім того, поїздки до клієнта, ймовірно, дорожчі, ніж у ваших мікросервісів один до одного.)

Наприклад, якщо ви подивитеся на напрямок, який веде GraphQL, ви знайдете клієнтів, які видають безпосередньо відповідні запити до кінцевої точки, які можуть бути, а можуть і не бути реалізовані як набір мікрослужб. Оскільки архітектура мікросервісів прихована за GraphQL, це робить архітектуру простішою для рефакторингу, а також більш зручною для клієнта. Дивіться, наприклад, https://stackoverflow.com/a/38079681/471129 .

Основна мета мікропослуг - зробити вашу заявку вільно пов'язаною. Тому служби не можуть телефонувати один одному. В іншому випадку він буде зв'язаний між собою. Але що ми будемо робити, якщо у нас є два сервіси, які потребують обміну даними? Відповідь - Брокер повідомлень. Таким чином, служба, яка отримує дані від клієнта, може обмінюватися даними з центральним брокером повідомлень, тоді сервіси повинні використовувати ці дані, щоб їх споживати, перетворювати та розміщувати у власне сховище даних. Я рекомендую Kafka, тому що ви можете приєднатись до даних з різної тематики під час польоту Kafka Stream. PS. краще розділити свої мікропослуги за функціями.