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

Я розробляю програму за допомогою Micro-Services, і я не впевнений, що найкращий механізм використовувати для збору даних з декількох сервісів.

Я вважаю, що є два варіанти:

• Інтегруйте механізм зв'язку між послугами, який дозволяє послугам спілкуватися безпосередньо. Шлюз API повинен викликати окрему службу, яка потім викликає інші служби для збору даних, перш ніж повертати консолідовану відповідь на шлюз API. Потім API повертає відповідь абоненту. (Це повинні бути синхронні дзвінки, коли на дзвінок до служби B потрібна відповідь від служби A.. IE окрема особа та адресні служби.)
• Попросіть шлюз API викликати кожну службу безпосередньо та консолідувати дані в API перед поверненням відповіді.

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

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

• Цей метод означав би, що API повинен «усвідомлювати» те, що намагається зробити додаток (IE Logic доведеться запрограмувати в API для обробки викликів служб по черзі, а потім для консолідації даних), а не просто діють як німа 'кінцева точка' для мікропослуг.

Мені хотілося б знати, що таке стандартний підхід до цієї проблеми і чи є ще третій варіант, який мені не вистачає?

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

Я б чітко розрізняв операції, що змінюються станом, і операції зчитування ( розділення запитів команд CQS ). Для операцій, що змінюються державою, я використовував би якусь інфраструктуру обміну повідомленнями та йшов у вогонь і забувати. Для запитів ви б використовували синхронний зв'язок з відповіддю на запит і могли використовувати API API або просто переходити безпосередньо до вашого сховища даних.

Якщо ви використовуєте обмін повідомленнями, ви також можете переглянути підписку на публікацію для підняття подій між службами.

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

І останнє, але не менш важливо, намагайтеся зробити все можливе, щоб ваші послуги були автономними (принаймні, на логічному рівні).

Сподіваюся, це має сенс.

Це залежить від того, для чого вам потрібні ці дані. Якщо він призначений для інтерфейсу користувача, то він прекрасно. Тим більше, що так і має бути. Кріс Річардсон має чітке пояснення цієї концепції , а Сем Ньюман має чудову статтю про дуже схожу концепцію під назвою Backends for Frontends .

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

Є кілька характеристик, якими здоровий глузд говорить, що наші послуги повинні мати . Вони є:

1. Низька муфта. Якщо ви внесли деякі зміни в службу A, ви не хочете, щоб вони вплинули на службу B.
2. Висока згуртованість. Якщо вам потрібно реалізувати якусь функцію, ви хочете, щоб це впливало на найменшу кількість послуг.
3. Висока автономія. Якщо якась служба виходить з ладу, ви не хочете, щоб вся система вийшла з ладу.
4. Правильна деталізація. Ви не хочете, щоб ваші послуги були занадто балакучими, оскільки ваша мережа є більш складною справою, ніж ви могли подумати.
5. Служби повинні спілкуватися через події. Ви не хочете, щоб ваша служба усвідомлювала один одного, оскільки це зменшує ремонтопридатність. Подумайте, що станеться, якщо вам потрібно додати нову послугу.
6. Децентралізовані дані. Служба не повинна ділитися способом зберігання інформації. Як і хороший об’єкт, він викриває поведінку, а не дані.
7. Службова хореографія над оркестром.

Щоб досягти цього, розглядайте межі своїх служб як бізнес-можливості . Формальний процес визначення меж обслуговування виглядає наступним чином:

1. Визначте межі вищого рівня. Мені подобається думати про них як про кроки, якими повинна пройти ваша організація для досягнення своєї бізнес-цілі, щоб отримати свою цінність для бізнесу. Можна ознайомитись із основними кроками, ознайомившись з ланцюжком вартості Портера .
2. У межах кожної служби заглиблюйтесь глибше. Визначте дитячі автономні підрозділи з власними обов'язками.
3. Зважайте на те, як вони спілкуються. Коректні сервіси спілкуються насамперед через події. Подумайте про свою організаційну структуру. Спілкування всередині них досить інтенсивне, хоча, як правило, піддаються декілька зовнішніх подій.

Приклад застосування такого підходу може бути якийсь - то інтерес.

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

Щоб зробити це трохи менш суб'єктивно, скажімо, одна служба залежить від іншої, якщо перша вимагає даних або послуг від другої, прямо чи опосередковано . Математично ми хочемо, щоб це відношення було частковим порядком, а не попереднім замовленням . У формі діаграми, якщо ви побудували свою діаграму залежності, ви повинні отримати діаграму Hasseі не мати ніяких (спрямованих) циклів. (На діаграмі Хассе, краї неявно спрямовані від нижнього до вищого.) У якості подальшого керівництва ви хочете, щоб шляхи від верху до низу зазвичай були коротшими. Це означає, що за замовчуванням ви хочете більш безпосередньо залежати від речей. Причини в тому, що мінімізується кількість речей, які можуть піти не так для будь-якого конкретного запиту, це мінімізує накладні витрати та зменшує складність. Отже, в «ідеальному» випадку за цією метрикою діаграма Хассе мала б лише два рівні. Звичайно, є безліч причин, чому ви можете ввести проміжні сервіси, такі як кешування, консолідація, балансування навантаження, управління відмовами.

Щоб уточнити свою другу проблему щодо того, щоб шлюз API був "розумним", модель, яка зараз набирає тягу за такими рамками, як Falcor та Relay / GraphQL, полягає в тому, щоб запити більше специфікацій, що робити, щоб "Шлюз API" міг загалом виконувати ці специфікації, не знаючи, що GetTimelineозначає. Натомість він отримав би запит на кшталт "запросити цю інформацію користувача від сервісу користувача та отримати ці повідомлення від служби поштового зв’язку" або будь-якого іншого.

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

Чи можете ви пояснити більше проблеми, яку ви намагаєтеся вирішити? Простий англійською?