Мікросервіси - це шлях розбиття великої програми на слабко пов'язані модулі, які комунікують один з одним за допомогою просто API.
Останнім часом про мікросервіси не каже хіба що німий. Це стає все популярнішим. Модульний архітектурний стиль здається особливо добре підходить для хмарного середовища (cloud-based environment) і його популярність зростає. Перш ніж заглибитися в деталі, давайте подивимося на все "з висоти пташиного посліду польоту". Тому: Мікросервіси - це спосіб розбиття великого проекту на невеликі, незалежні та слабко зв'язкові модулі.Незалежні модулі відповідають за чітко визначені та дискретні завдання та спілкуються один з одним за допомогою простого та доступного API. Іншими словами - мікросервіси - це просто інший архітектурний стиль для проектування складних, в основному, веб-додатків. Але що такого поганого існуючих архітектрних рішеннях, таких як SOA (Service oriented architecture — сервісно орієнтована архітектура)? Більшість сучасних ентерпрайз-рішень написані з використанням SOA, схоже, працюють досить добре. Мабуть, це чудовий час для того, щоб поговорити про деякі виклики в промисловості, з якими стикаються в наш час ... Давайте почнемо з простого прикладу. Припустимо, мені потрібно запустити класичну програму написану на Java. Першим я розроблю User Interface, потім шар з бізнес-логікою, причому кілька компонентів, які будуть взаємодіяти з UI та, нарешті, шар для бази даних, який буде доступний до стійкої бази даних. Тепер у відповідності з тим, що я хочу запустити програму, я створю WAR/EAR/JAR і змонтую його на сервер (таких як JBoss, Tomcat або WebLogic). Так як зроблено це все в одному, я отримую монолітну програму, що означає, що всі компоненти в одному місці... Приклад на картинці:
Швидше за все, що ви вже знайомі з таким підходом і використовували його, але ідея саме в тому, щоб на цьому прикладі показати з якими викликами доведеться зіткнутися розробникам, використовуючи це архітектурне рішення. Монолітний додаток: виклики проблеми
Під час того, як зростає програма, зростає і кількість написаного коду, яка цілком може перевантажувати середовище розробки щоразу, коли потрібно відкрити його. Це безперечно зменшує ККД розробника.
Так як доводиться все монтувати в одному місці, це призводить до того, що перехід іншою мовою програмування або перехід на інші технології є великою проблемою. Наприклад, ви написали додаток на Java, а через час вийшов Kotlin і ви зайнялися бажанням переписати на нього, тому що він розпиарений крутіше-краще-швидше. З монолічним додатком навіть думки про рефакторинг будуть принижувати реальний біль, не кажучи вже про сам процес. На даний момент є безліч додатків, які зроблені таким чином, і кількість рядків коду просто неймовірна.
Якщо якийсь із компонентів з якоїсь причини накриється мідним тазом перестане працювати, то вся програма також обрушиться. Тільки уявіть, що є веб-додаток, у якому є модулі, такі як, авторизація, оплата, історія тощо. І з якоїсь причини один із них ламається. Це просто шок для бізнесу і, отже, для розробників.
Масштабування монолітного додатка може бути здійснено лише за допомогою підняття ще одного такого ж додатка. А якщо потрібно масштабування тільки одного компонента, а не всього додатка. Скільки ресурсів буде витрачено марно?
Це може вплинути на процес розробки та на процес монтування програми. Що більше додаток, то важливіше, щоб розробники могли розділити додаток більш м'які робочі частини. Тому що всі модулі в монолітній програмі пов'язані один з одним, розробники не можуть працювати/монтувати незалежно один від одного ці модулі. Оскільки розробники залежить один від одного, час розробки збільшується.
Разом з тим ми готові розглянути і зрозуміти зміст мікросервісів, а саме як їх можна використовувати для відновлення гнучкості, яка була втрачена із SOA-стилем. Бог Мікросервіси на допомогу Одна з найважливіших характеристик у будь-якому архітектурному вирішенні - це масштабованість. Поки я вперше вивчав мікросервіси, я бачив, що все так схоже на цитати з книги "Мистецтво Машстабування (The Art of Scalability)". Це чудовий початок та місце для обговорення. У цій книзі визначають так звану модель "Куба Масштабованості", який описує тривимірну систему масштабованості:
Як ви бачите, вісь X описує "горизонтальне масштабування" (яке ми бачабо також доступно для монолітної архітектурою), вісь Y є машстабування в сенсі поділу різних компонентів серсисів. Ідея Z осі розуміється коли дані поділяються і програма відправляє запити саме на те місце, де знаходяться дані. Тобто, вони не в одному місці все. Ідея осі Y – саме та, на якій ми зупинимося докладніше. Ця вісь є функціональною декомпозицією. У цій стратегії різні функції можна розглядати як незалежні сервіси. Тому, разом монтування цільного додаток тільки тоді, коли все зроблено, розробники можуть монтувати окремі сервіси незалежно один від одного і не чекати на інших, поки ті закінчать роботу над своїми модулями. Це не тільки покращить час розробки, але також пропонує гнучкість у зміні та перемонтуванні без необхідності хвилюватися про інші компоненти програми. Порівняємо цю діаграму з попередньою монолітною:
Мікросервіси: переваги Переваги мікросервісів виглядають цілком достатніми, що переконали таких ентерпрайз-розробників, як Amazon, Netflix, Ebay - почати використовувати цей підхід. На відміну від монолітних архітектурних програм, мікросервіси:
Покращує ізоляцію збою компонентів: великі програми можуть продовжити ефективно працювати навіть при несправності якогось окремого модуля.
Усуває відданість додатку до одного технологічного стеку: якщо хочеш спробувати новий технологічний стек на якомусь сервісі – будь ласка. Залежно будуть набагато легше, ніж при монолітному, до того ж буде набагато простіше відкотити все назад. Чим менший код в одному додатку, тим легше працювати.
Робить набагато простіше для нових співробітників, щоб зрозуміти функціональність сервісу.
Мікросервіси: особливості монтування та віртуалізації Тепер нам зрозуміло, що таке мікросервіси. І найбільша перевага, що монтується не одним архівом WAR/EAR/JAR. Але як він монтується? Найкращий спосіб монтування мікросервісів усередині контейнерів. Контейнер – це повністю налаштована віртуальна операційна система з налаштованим необхідним оточенням, що допомагає ізолювати доступ до ресурсів системи заліза, на якому стоїть контейнер. Найвідоміше рішення на ринку – це звичайно Docker. Віртуальні машини від IaaS (інфраструктура як сервіс), такі як AWS можуть також добре працювати для монтування мікросервісів, але відносно легкі мікросервіси можуть використовувати не всі ресурси, які є у віртуальній машині, можуть зменшити вигідність у використанні. Також ви можете монтувати свої мікросервіси, використовуючи OSGI (Open Service Gateway Initiative) пакет. У цьому випадку всі мікросервіси будуть запущені в одній JVM, але це пов'язано з проблемами компромісу між керуванням та ізоляцією. Мікросервіси: недоліки Тільки через те, що "все це круто" і "як ми раніше не бачабо", не означає, що немає своїх недоліків. Нижче наведено список можливих областей болю, який приносить із собою мікросервісна архітектура:
Розробка розподілених систем може бути складною. Під цим я маю на увазі, що всі компоненти тепер незалежні сервіси - потрібно дуже акуратно обробляти запити між модулями. Може бути сценарій, коли один модуль не відповідає, змушуючи писати додатковий код, щоб уникнути збою системи. Це може бути складніше, якщо віддалені виклики чутливі до latency .
Безліч баз даних та управління транзакцій може бути реальним болем.
тестування мікросервісних програм може бути громіздко. Використовуючи монолітну програму, нам потрібно тільки запустити WAR/EAR/JAR архів на сервер і переконатися у зв'язку з базою даних. А в мікросервісах кожен окремий сервіс повинен бути запущений перед тим, як почати тестування.
Монтування програм може бути складним. Вони можуть вимагати координації навколо безлічі сервісів, які можуть бути не так просто монтуватися, як контейнер WAR.
.... Звичайно, з правильними інструментами та підходами можна уникнути ці недоліки. Але вони й самі вимагають підтримки та не повністю вирішують усі проблеми. Стаття була перекладена з сайту CloudAcademy . Переклад вільний. Усі вільні випромінювати усі свої думки у коментарях. Вони будуть обов'язково прочитані. Оригінал статті Мій Github аккаунт
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ