Selamün Aleyküm Друзі,
https://www.dreamstime.com/gitarra-saks-converted-image205598557
У третій частині нашої серії про мікросервіси ми розглянемо тему "компонування мікросервісів". Ідея в тому, що необхідно зібрати відповіді від кількох сервісів і повернути їх клієнту як єдину відповідь. Хоча це суперечить принципу незалежності мікросервісів, у деяких випадках, згідно з вимогами бізнес-моделі, такий підхід може бути необхідним. Однак потрібно бути обережним, оскільки це може призвести до виникнення взаємозалежних сервісів, що може погіршити загальний дизайн системи. Тому важливо продумати цю частину архітектури так, щоб не допустити подальших залежностей між сервісами. Давайте розглянемо деталі.
Уявімо, що в нас є велика кількість сервісів. Кожен з них виконує певну задачу, але вимоги реального світу, як ви могли здогадатися, можуть бути дуже складними. Іноді потрібно зібрати дані з кількох сервісів і сформувати на їх основі єдину відповідь. У таких випадках ми можемо застосувати один з підходів, наприклад, зібрати всі ці відповіді через API або скористатися централізованою структурою — оркестрацією (Orchestration), яка викликає сервіси по черзі і об'єднує їхні відповіді. Інший варіант — хореографія (Choreography), коли сервіси взаємодіють без центрального керівника, обмінюючись повідомленнями та виконуючи свої локальні транзакції.
Ці методи, хоч і мають спільну мету — зібрати відповіді від кількох сервісів, — але можуть призвести до різних проблем, таких як несумісність даних (про це ми поговоримо в наступній статті), проблеми з продуктивністю, управління помилками тощо. Однак ці питання можна вирішити, зокрема, шляхом застосування певних рішень.
Існують і альтернативні методи, наприклад CQRS, GraphQL, дублювання даних (Data Replication) або правильне проектування контекстів. Однак кожен з них теж має свої виклики. Як на мене, головною технічною задачею є правильне визначення проблеми та вибір найбільш відповідного рішення для кожного конкретного випадку.
Варто зазначити, що використання одного з рішень не означає відмову від інших. Їх можна комбінувати. Наприклад, коли ви робите запит до одного сервісу і потрібно отримати лише одне значення, можна застосувати дублювання даних (Data Replication), але якщо потрібно забрати багато важливих даних з кількох сервісів, можливо, буде краще звернутися до цих сервісів без дублювання, а просто зібрати все в одному запиті. Кожен підхід має свої переваги та недоліки, і важливо вибрати той, який найбільше підходить для вашого конкретного випадку.
Підсумовуючи, для кожної бізнес-проблеми можуть бути знайдені різні рішення. Важливо в процесі впровадження ретельно зважити плюси і мінуси кожного з підходів і адаптувати їх до вашої архітектури, мінімізуючи при цьому негативні наслідки.
Я хочу завершити статтю цитатою з Корану і хадисом, що стосується пророка Мухаммеда (с.а.в.), який надає рішення для кожної проблеми.
“Запрошуй до шляху твого Господа з мудрістю та гарним повчанням і веди з ними найкращу боротьбу.”
“Безсумнівно, твій Господь найкраще знає тих, хто збився з його шляху, і тих, хто знайшов правильний шлях.” (Нахль, 16/125)“О, Посланцю Аллаха! Яка з добрих справ найкраща?” — коли йому поставили це питання, він давав різні відповіді різним супутникам.
- Наприклад: одному він сказав — “Виконувати молитву вчасно”
- Іншому — “Бути добрим до батьків”
- А ще одному — “Боротися за шляхом Аллаха”
Цей хадис показує, що надавати рішення відповідно до стану, потреб і пріоритетів людей є важливим принципом в Ісламі. (Бухарі, Едеб 1; Муслім, Іман 137)
Перекладено з: Mikroservis Yazı Serisi 3 — Composing Microservice