Мікросервісна архітектура розділяє систему на сервіси з визначеною відповідальністю та інтерфейсами. Це може допомогти незалежно змінювати й масштабувати окремі можливості. Водночас локальний виклик перетворюється на взаємодію через мережу, а підтримка вимагає нових процедур. Кількість сервісів сама по собі не показує якість архітектури.
Знайдіть межі бізнес-відповідальності
Умовний приклад — замовлення, склад і повідомлення. Відокремлення сповіщень може бути корисним, якщо вони мають власне навантаження й не повинні затримувати основну операцію. Поділ лише за технічними таблицями часто створює постійні взаємні виклики замість незалежності.
Для кожної межі визначаємо власника, дані та правила зміни контракту. Якщо одна проста зміна завжди потребує одночасного оновлення всіх частин, очікувана незалежність може не досягатися. Перш ніж розділяти систему, корисно впорядкувати модулі й залежності.
Не приховуйте розподілені дані
Різні сервіси можуть володіти різними даними, тому спільна транзакція вже не є очевидним рішенням. Погоджуємо, коли оновлення стає видимим іншим частинам і як обробляється часткове виконання. Користувачеві потрібен чесний стан, якщо процес ще триває.
Повідомлення можуть надходити повторно або із затримкою. Потрібні ідентифікатори, правила повтору та контроль сумісності форматів. Компенсаційна дія повинна відповідати бізнес-сенсу: скасування повідомлення не рівнозначне поверненню грошей.
Підготуйте підтримку мережевих відмов
Погоджуємо таймаути, обмеження повторів і поведінку при недоступності залежності. Безконтрольні повтори можуть збільшити навантаження під час проблеми. Потрібно бачити, які частини можна тимчасово обмежити без пошкодження основних даних.
Журнали, метрики й трасування мають дозволяти відстежити операцію через межі сервісів. Для доступу потрібна перевірка повноважень між компонентами. Обсяг інфраструктури, чергування й діагностики враховуємо у вартості підтримки, а не лише в початковій розробці.
Перевірте, чи простіший варіант достатній
Модульний моноліт може бути доречним для команди, яка розвиває один продукт без потреби незалежних релізів. На сайті ALL IT Agency спільні PHP-компоненти вирішують повторне використання без поділу кожної сторінки на сервіс. Рішення повинне відповідати масштабу задачі.
Якщо поділ обґрунтований, починаємо з узгодженої межі та вимірюємо результат. Перевіряємо контракти, відновлення й повернення до попереднього стану. Поступовий перехід дозволяє перевірити припущення до перенесення всієї системи.
Джерела та подальше читання
