Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!14.10.2022
Чому ми обираємо один великий сервіс замість купи мікросервисів
🐳🤝🐳 Сьогодні з двох сервісів вирішили зробити один. І то навіть не мікро-, а дуже такі макросервіси. Просто підстава причина мати два окремих сервіси. І то добре
Взагалі на мою думку, сервісів має бути якнайменше, і мікросервіси — то безглузда ідея. Розділяти частини системи додатковими прошарками мережі та протоколів ніяк не спрощує розробку.
Є декілька приводів робити більше одного сервісу:
- якщо треба використати іншу мову програмування — наприклад, щоб прискорити високонавантажену частину.
- якщо сервіси мають фізично знаходитись в різних місцях — можливо, в різних географічних регіонах, або на локаціях клієнтів.
- якщо є потреби безпеки — може, треба мінімізувати частину, що має доступ до важливих даних.
Щоб масштабувати я б порадив не розділяти сервіси, а створювати більше копій великого сервісу. Можна створювати окремі копії під різні потреби: одну під внутрішнє API, одну під зовнішнє — тоді вони будуть ізольовані по навантаженню. В нас була ще така система, коли для цього запити на рівні маршрутів розділялись на два окремих, але ідентичних сервіси.
Щоб розділяти контексти та спростити розробку, краще використати можливості вашої мови програмування — модулі та таке інше. Може це не ідеально, але я не бачив ще, щоб мікросервіси робили щось краще. Крім того, очевидно що мікросервіси впроваджують в розробку купу складнощів, потребують гарного дизайну інтерфейсів, та навичок мережевого програмування. Тому я не бачу, як введення мікросервісів дозволить, наприклад, долучити до розробки більшу кількість менш досвідчених інженерів — принаймні, ефективно. Бо то тільки здається, що легко замінити виклик функції на виклик API. Розкажу про це якось іншим разом.