Нещодавно прочитав книжку «Building Microservices: Designing Fine-Grained Systems» Сема Ньюмена.
Після прочитання цієї книжки в голові крутилися фрази: «парадайм шифт», «дизрапт», «зе некст біг синг». Більшість із вас перебуває по той бік браузера й мало цікавиться розвитком інтернет-технологій. А вони змінюються дуже сильно. Настільки сильно, що за 10 років єдина річ, яка залишилася такою самою, — це протокол HTTP, а все інше змінилося: вебсервери, бази даних, архітектури вебзастосунків, методи тестування, інтеграції та розгортання.
Мікросервісна архітектура — така організація системи, де кожна підсистема — це автономний, незалежний вебсервіс, відповідальний за одне невелике завдання. Повна протилежність — це монолітна архітектура, де є лише один вебсервіс, що розвʼязує всі завдання.
У мікросервісній архітектурі кожен мікросервіс розробляється, розгортається, масштабується ізольовано від інших сервісів. Це означає, що вибраний стек технологій — це більше не прокляття на все життя. Наприклад, десять років був популярний стек LAMP — Linux, Apache, MySQL, PHP. Раніше всі ці технології встановлювалися в межах одного вебсервісу. І якщо потрібно було розробити нову функцію, то шукали спеціаліста, який знає ці технології. А в мікросервісній архітектурі один мікросервіс може бути реалізований на Ruby, інший на Go, третій на Java. В одного база даних може бути MongoDB, в іншого GraphDB, а в третього blob store, наприклад. І це нормально. Вибирайте ту мову й базу даних, яка найефективніше розвʼяже конкретне завдання.
Раніше, якщо вебсервіс не витримував навантаження, то виконували горизонтальне масштабування: запускали ще один екземпляр сервісу LAMP і робили балансування навантаження. У мікросервісній архітектурі можна аналізувати продуктивність кожного окремого мікросервісу й масштабувати тільки той мікросервіс, який не справляється з навантаженням.
Читаючи книжку, я згадував, де я як користувач стикався з мікросервісами. Памʼятаю, зайшов якось у Facebook, а там стрічка новин є, а особисті повідомлення переглянути не можу. Це означає, що у Facebook є щонайменше два мікросервіси (насправді їх сотні) — мікросервіс новинної стрічки й мікросервіс особистих повідомлень. І того дня мікросервіс повідомлень вийшов з ладу. Перевага в тому, що решта мікросервісів зберегли свою роботу, бо працюють автономно. У монолітній архітектурі таке неможливо: вихід із ладу однієї підсистеми призводить до поломки всієї системи.
Я суворо рекомендую книжку «Building Microservices» усім технічним директорам і просто розробникам.