Підручник з мікросервісів: що таке, Archiтектура та приклад

Що таке мікросервіси?

Мікросервіс це шаблон архітектури, орієнтованої на обслуговування, в якому додатки будуються як сукупність різноманітних найменших незалежних одиниць обслуговування. Це а розробка програмного забезпечення підхід, який зосереджується на розкладанні програми на однофункціональні модулі з чітко визначеними інтерфейсами. Ці модулі можуть бути незалежно розгорнуті та керовані невеликими командами, які володіють усім життєвим циклом служби.

Термін «мікро» стосується розміру мікросервісу, який має бути керованим однією командою розробників (від 5 до 10 розробників). У цій методології великі програми поділяються на найменші незалежні одиниці.

Що таке моноліт Archiтектура?

Простими словами, можна сказати, що монолітна архітектура схожа на великий контейнер, в якому всі програмні компоненти програми об'єднані в один пакет. Давайте розглянемо приклад магазину електронної комерції в контексті монолітної архітектури.

Монолітний Archiтектура програми електронної комерції

У будь-якій програмі електронної комерції є деякі стандартні функції, такі як пошук, RevПерегляд і оцінки, а також платежі. Ці функції доступні клієнтам за допомогою браузера або додатків. Коли розробник сайту електронної комерції розгортає додаток, він являє собою єдиний монолітний блок. Код для різних функцій, таких як Пошук, RevПерегляд та оцінки, а також платежі знаходяться на одному сервері. Для масштабування програми потрібно запускати кілька екземплярів (серверів) цих програм.

Що таке мікросервіс Archiтектура?

Мікросервіс Archiтектура це архітектурний стиль розробки, який дозволяє створювати програми як набір невеликих автономних служб, розроблених для бізнес-домену. Це варіант архітектури структурного стилю, який допомагає організовувати програми як слабко пов’язану колекцію сервісів. Мікросервіс Architecture містить детальні служби та спрощені протоколи.

Розглянемо приклад застосунку електронної комерції, розробленого з використанням мікросервісної архітектури. У цьому прикладі мікросервісної архітектури кожен мікросервіс зосереджений на одній бізнес-можливості. Пошук, рейтинг та Revview та Payment мають свій екземпляр (сервер) та взаємодіють один з одним.

Мікросервіс Archiтектура

В моноліті ArchiУ структурі всі компоненти об'єднуються в один модуль. Але в мікросервісах ArchiУ структурі вони розподілені на окремі модулі (мікросервіси), які взаємодіють один з одним, як показано у прикладі мікросервісів вище.

Зв’язок між мікросервісами – це зв’язок без стану, де кожна пара запиту та відповіді є незалежною. Таким чином, мікросервіси можуть легко спілкуватися. В мікросервісі ArchiУ структурі дані об'єднані. Кожен мікросервіс має окреме сховище даних.

Мікросервіси проти монолітних Archiтектура

Мікросервіс	Монолітний Archiтектура
Кожна одиниця всієї програми має бути найменшою, і вона повинна бути в змозі досягти однієї конкретної бізнес-цілі.	Єдина база коду для всіх бізнес-цілей.
Запуск сервісу відбувається відносно швидко.	Запуск сервісу займає більше часу.
Ізоляція несправностей проста. Навіть якщо один сервіс вийде з ладу, інші можуть продовжувати функціонувати.	Ізоляція несправностей є складною. Якщо якась певна функція не працює, вся система виходить з ладу. Щоб вирішити цю проблему, програму потрібно перебудувати, повторно протестувати та повторно розгорнути.
Усі мікросервіси повинні бути слабо пов'язані, щоб зміни, внесені в одному, не впливали на інший.	Монолітна архітектура тісно пов'язана. Зміни в одному модулі коду впливають на інший.
Бізнес може спрямовувати більше ресурсів на послуги, які генерують вищу рентабельність інвестицій.	Оскільки послуги не є ізольованими, розподіл індивідуальних ресурсів неможливий.
Більше апаратних ресурсів можна було б виділити на сервіс, який часто використовується. У наведеному вище прикладі електронної комерції більше користувачів перевіряють список товарів та здійснюють пошук порівняно з платежами, тому на мікросервіс пошуку та списку товарів можна було б виділити більше ресурсів.	Масштабування програми є складним завданням, а також марнотратним.
Мікросервіси завжди залишаються послідовними та постійно доступними.	Інструменти розробки перевантажуються, оскільки процес потрібно починати з нуля.
Дані об'єднані. Це дозволяє окремим мікросервісам використовувати модель даних, яка найкраще відповідає їхнім потребам.	Дані централізовані.
Невеликі цілеспрямовані команди. Паралельна та швидша розробка.	Потрібна велика команда та значні зусилля з управління командою.
Зміна моделі даних одного мікросервісу не впливає на інші мікросервіси.	Зміна моделі даних впливає на всю базу даних.
Взаємодіє з іншими мікросервісами за допомогою чітко визначених інтерфейсів.	Не застосовується.
Мікросервіси працюють за принципом, який зосереджений на продуктах, а не на проектах.	Робить акцент на всьому проєкті.
Відсутність перехресних залежностей між базами коду. Ви можете використовувати різні технології для різних мікросервісів.	Одна функція або програма залежить від інших.

Виклики мікросервісу

• Мікросервіси залежать один від одного, і їм доведеться взаємодіяти один з одним.
• Порівняно з монолітними системами, існує більше служб для моніторингу, які розроблені з використанням різних мови програмування.
• Оскільки це розподілена система, це за своєю суттю складна модель.
• Різні сервіси матимуть свої окремі механізми, що призведе до великого обсягу пам'яті для неструктурованих даних.
• Для запобігання каскадним проблемам необхідні ефективне управління та командна робота.
• Відтворення проблеми буде складним завданням, коли вона зникла в одній версії та повернулася в останній.
• Незалежне розгортання ускладнюється з мікросервісами.
• Архітектура мікросервісу передбачає велику кількість операцій.
• Важко керувати застосунком, коли до системи додаються нові сервіси.
• Для підтримки гетерогенно розподілених мікросервісів потрібен широкий спектр кваліфікованих фахівців.
• Мікросервіс є дорогим, оскільки вам потрібно підтримувати різний простір на сервері для різних бізнес-завдань.

SOA проти мікросервісів

Сервіси SOA підтримуються в організації реєстром, який діє як список каталогів. Програмам потрібно шукати сервіси в реєстрі та викликати цей сервіс. Іншими словами, SOA це як оркестр, де кожен виконавець виступає зі своїм інструментом, а музичний керівник дає вказівки всім.

З іншого боку, мікросервіси – це форма сервісно-орієнтованої архітектури, де додатки будуються як набір різних менших сервісів, а не як одне програмне забезпечення чи додаток. Мікросервіси – це як трупа, де кожен танцюрист є незалежним і знає, що йому потрібно робити. Тож, якщо вони пропускають деякі кроки, вони знають, як повернутися до правильної послідовності. Ось детальне порівняння SOA та мікросервісів.

Параметр	SOA	Мікросервіс
Тип дизайну	У SOA компоненти програмного забезпечення надаються зовнішньому світу для використання у формі сервісів.	Micro Service є частиною SOA. Це реалізація SOA.
Залежність	Підрозділи є залежними.	Вони незалежні один від одного.
Розмір програмного забезпечення	Розмір програмного забезпечення більший, ніж будь-яке звичайне програмне забезпечення.	Розмір програмного забезпечення в мікросервісах завжди невеликий.
Стек технологій	Технологічний стек нижчий порівняно з Microservice.	Стек мікросервісних технологій може бути дуже великим.
Характер застосування	Монолітний за своєю природою.	Повний стек у природі.
Незалежний і зосереджений	Програми SOA створені для виконання кількох бізнес-завдань.	Вони створені для виконання одного бізнес-завдання.
розгортання	Процес розгортання займає багато часу.	Розгортання є простим і займає менше часу.
Економічна ефективність	Економічніший.	Less економічно ефективним.
масштабованість	Less порівняно з мікросервісами.	Висока масштабованість.
Бізнес-логіка	Компоненти бізнес-логіки зберігаються в одному сервісному домені за допомогою простих протоколів зв'язку (HTTP з XML або JSON) та API, що керуються SDK/клієнтами.	Бізнес-логіка може існувати в різних доменах, з шарами, подібними до корпоративної сервісної шини, між сервісами (проміжне програмне забезпечення).

Інструменти мікросервісів

1) Wiremock: Тестування мікросервісів

WireMock — це гнучка бібліотека для заглушення та імітації веб-сервісів. Вона може налаштовувати відповідь, що повертається HTTP API, коли отримує певний запит. Вона також використовується для тестування мікросервісів.

Посилання для скачування: http://wiremock.org/

2) Докер

Docker — це проєкт з відкритим кодом, який дозволяє нам створювати, розгортати та запускати програми за допомогою контейнерів. Використовуючи ці контейнери, розробники можуть запускати програми як єдиний пакет. Це дозволяє постачати бібліотеки та інші залежності в одному пакеті.

Посилання для скачування: https://www.docker.com/

3) Гістрикс

Hystrix — це відмовостійка система. Java бібліотека. Цей інструмент призначений для розділення точок доступу до віддалених сервісів, систем та сторонніх бібліотек у розподіленому середовищі, такому як мікросервіси. Він покращує загальну систему, ізолюючи сервіси, що виходять з ладу, та запобігаючи каскадному ефекту збоїв.

Посилання для скачування: https://github.com/Netflix/Hystrix

Найкращі практики мікросервісів Archiтектура

• Окреме сховище даних для кожного мікросервісу.
• Підтримуйте код на однаковому рівні зрілості.
• Окрема збірка для кожного мікросервісу.
• Завжди розглядайте кожен сервер як сервер без статусу.

Поширені запитання