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

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

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

Якщо говорити непрофесіоналом, то можна сказати, що монолітна архітектура схожа на великий контейнер, у якому всі програмні компоненти програми зібрані в єдиний пакет.

Давайте обговоримо приклад магазину електронної комерції в контексті монолітної архітектури.

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

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

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

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

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

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

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

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

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

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

В іншому світі, SOA це як оркестр, де кожен виконавець виступає зі своїм інструментом, а музичний керівник дає вказівки всім.

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

Microservices — це як трупа, де кожен танцюрист незалежний і знає, що йому потрібно робити. Отже, якщо вони пропустять деякі кроки, вони знають, як повернутися до правильної послідовності. У цьому посібнику з архітектури мікросервісів давайте дізнаємося про різницю між 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тектура

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

Підсумки

• Мікросервіси — це шаблон архітектури, орієнтованої на сервіси, у якому додатки будуються як сукупність різноманітних найменших незалежних одиниць сервісу.
• Мікросервіс Architecture — це архітектурний стиль розробки, який дозволяє створювати додаток як набір невеликих автономних сервісів, розроблених для бізнес-домену.
• Монолітна архітектура схожа на великий контейнер, у якому всі програмні компоненти програми зібрані в єдиний пакет
• У мікросервісі кожна одиниця всієї програми має бути найменшою, і вона повинна мати можливість досягти однієї конкретної бізнес-цілі
• У монолітній архітектурі велика кодова база може уповільнити весь процес розробки. Випуск нових випусків може тривати місяцями. Підтримка коду складна
• Два типи мікросервісів: 1) без збереження стану 2) із збереженням стану
• Мікросервіси в Java покладатися один на одного, і їм доведеться спілкуватися один з одним. Допомагає вам акцентувати увагу на певній функції та бізнес-потребах
• Сервісно-орієнтована архітектура, коротко відома як SOA, є еволюцією розподілених обчислень на основі моделі запиту або відповіді для синхронних і асинхронних програм
• У SOA компоненти програмного забезпечення доступні зовнішньому світу для використання у формі служб, тоді як Micro Service є частиною SOA. Це реалізація SOA
• Wiremock, Docker і Hystrix є популярними мікросервісними інструментами