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

Популярним вибором архітектури високого рівня в сучасній програмі є система мікросервісів на базі REST. Це має ряд переваг, таких як нещільне з’єднання, легке повторне використання, обмежене обмеження технологій, які можна використовувати, висока масштабованість тощо.

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

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

Які схеми чи інструменти можна використовувати для зменшення цього ризику

Підтримуючи сумісність ваших API та можливостей вашого бізнесу назад.

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

Перевірки здоров'я.

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

Таким чином, ваші журнали показують, як часто якась інша послуга перевіряє, чи є кожна конкретна послуга, яку ви пропонуєте, все ще доступна, так само як і показує, як часто використовується кожна конкретна послуга, яку ви пропонуєте.

Є щонайменше два місця, де можна знайти залежності:

• Конфігурація. Для доступу до зовнішніх API потрібно знати купу інформації про кожен з цих API. Ідентифікатори доступу, секретні ключі, кінцеві точки. Все це не може бути в коді, так як така інформація буде змінюватися. Як приклад, я нещодавно почав мігрувати всі свої мікросервіси до SSL. Це означає, що кожну службу, що спирається на міграцію, слід переналаштувати так, щоб вона вказувала на https://версію http://. Я радий, що кінцеві точки були в конфігурації, а не жорстким кодом.

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

Коли настає час рефактора, щоквартальні дзвінки мають високий ризик перерви.

Це те, для чого призначено регресійне тестування.

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

API REST чітко визначено, тому в якийсь момент може бути корисним перейти до gRPC, протоколів google або Thrift для визначення інтерфейсу RPC, а потім його версії.