Посібник з проектування мікросервісів

2018 рік, всі чули про мікросервіси. Але чи знаєте ви, як його спроектувати?

Мікросервіси є актуальною темою серед інженерів програмного забезпечення сьогодні. Давайте розберемося, як ми можемо створити справді модульні ІТ-системи, спритні для бізнесу, в архітектурному стилі Microservices.

Концепція мікросервісів

Архітектура мікросервісів складається з колекцій легких, нещільно пов'язаних послуг. Кожна служба реалізує можливість єдиного бізнесу. В ідеалі ці сервіси повинні бути досить згуртованими, щоб розробляти, перевіряти, випускати, розгортати, масштабувати, інтегрувати та підтримувати незалежно.

Формальне визначення
«Архітектурний стиль мікросервісу - це підхід до розробки єдиного додатку як набору невеликих сервісів, кожен із яких працює у своєму процесі та спілкується з легкими механізмами, часто API HTTP-ресурсу. Ці сервіси побудовані на основі можливостей бізнесу та незалежно розгортаються за допомогою повністю автоматизованої машини розгортання. Є мінімум централізованого управління цими службами, які можуть бути написані різними мовами програмування та використовувати різні технології зберігання даних. "
- Джеймс Льюїс та Мартін Фаулер

Визначення характеристик мікросервісів

  • Кожна послуга - це легкий, незалежний та нещільно пов'язаний бізнес-підрозділ.
  • Кожна служба має власну кодову базу, якою керує та розвивається невелика команда (переважно в спритних умовах).
  • Кожна служба несе відповідальність за окрему частину функціональності (бізнес-можливості), і робить це добре.
  • Кожна служба може вибрати найкращий стек технологій для своїх випадків використання (не потрібно дотримуватися однієї рамки протягом усього додатка).
  • Кожна служба має свій власний план DevOp (перевірити, випустити, розгорнути, масштабувати, інтегрувати та підтримувати незалежно).
  • Кожна служба розміщується в автономному середовищі.
  • Служби спілкуються між собою за допомогою чітко визначених API (розумних кінцевих точок) та простих протоколів, таких як REST через HTTP (німі труби).
  • Кожна служба несе відповідальність за збереження власних даних та збереження зовнішнього стану (Тільки якщо кілька служб споживають одні й ті самі дані, такі ситуації обробляються в загальному рівні даних).

Переваги мікросервісів

Мікросервіс створений для масштабування великих систем. Вони є прекрасними умовами для постійної інтеграції та доставки.

Куб масштабу: тривимірна модель масштабування (Зображення: Блог Nginx)
  • Незалежне масштабування - архітектура мікросервісів підтримує концепцію масштабу куба, описану у чудовій книзі «Мистецтво масштабування». Розробляючи мікросервіси для досягнення функціонального розкладання, додаток автоматично масштабується по осі Y. Коли витрата велика, мікросервіси можуть масштабуватись по осі X, клонуючи більше процесора та пам'яті. Для розповсюдження даних на декількох машинах великі бази даних можна розділити (розточувати) на більш дрібні, швидші та простіші управління частинами, що дозволяє масштабувати вісь Z.
  • Незалежні випуски та розгортання - виправлення помилок та випуски функцій є більш керованими та менш ризикованими, за допомогою мікросервісів. Ви можете оновити послугу без повторної розробки всієї програми та відкотити або повернути оновлення, якщо щось піде не так.
  • Самостійна розробка - кожен сервіс має свою кодову базу, яку розробляє, тестує та розгортає невелика цілеспрямована команда. Розробники можуть зосередитися лише на одній службі та порівняно невеликому обсязі. Це призводить до підвищення продуктивності, швидкості проекту, постійних інновацій та якості джерела.
  • Витончена деградація - якщо сервіс знижується, його вплив не поширюватиметься на іншу програму та призведе до катастрофічної несправності системи, що дозволить проявити певну ступінь антистійкості.
  • Децентралізоване управління - розробники вільні вибирати стеки технологій та приймати стандарти дизайну та рішення щодо впровадження, які найкраще підходять для їх обслуговування. Команди не повинні отримувати штрафні санкції через прийняті рішення у галузі технологій.

Оперативні проблеми

Самі незалежні служби не можуть сформувати систему. Для справжнього успіху архітектури мікросервісів потрібні значні інвестиції для вирішення проблем, пов'язаних з міжсистемними системами, як-от:

  • Реплікація служби - механізм, за допомогою якого служби можуть легко масштабуватися на основі метаданих
  • Реєстрація та виявлення послуги - механізм, що дозволяє шукати службу та знаходити кінцеву точку для кожної послуги
  • Моніторинг сервісу та ведення журналів - механізм для агрегації журналів з різних мікросервісів та забезпечення послідовної звітності
  • Стійкість - це механізм для служб, які автоматично вживають коригувальних дій під час відмов
  • DevOps - механізм для безперервної інтеграції та розгортання (CI та CD)
  • Шлюз API - механізм забезпечення точки входу для клієнтів

Проміжне програмне забезпечення та шаблони дизайну

Шлюз API (Єдина точка входу для всіх клієнтів)

API Gateway Style Microservices Architecture (Зображення: Microsoft Azure Docs) - це найпоширеніший шаблон дизайну, який використовується в мікросервісах. API Gateway - це посередник з мінімальними можливостями маршрутизації і просто виступає як

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

  • Побудувати це програмно - щоб мати кращі налаштування та контроль
  • Розгорнути існуючий продукт шлюзу API - щоб заощадити початковий час розробки та використовувати розширені вбудовані функції (Мінуси: Такі продукти залежать від постачальника та не є абсолютно безкоштовними. Конфігурації та обслуговування часто можуть бути виснажливими та трудомісткими)

Деякі зразки дизайну, що пояснюють поведінку шлюзу API, такі: (Прочитайте Шаблони дизайну для мікросервісів).

  • Агрегація шлюзу - сукупність декількох запитів клієнтів (зазвичай HTTP-запитів), орієнтованих на декілька внутрішніх мікросервісів, в один запит клієнта, зменшуючи чат і затримку між споживачами та послугами.
  • Завантаження шлюзу - дозволяє окремим мікросервісам вивантажувати свою функціональність спільного обслуговування до рівня шлюзу API. Такі наскрізні функції включають аутентифікацію, авторизацію, виявлення сервісу, механізми відмовостійкості, QoS, балансування навантаження, ведення журналів, аналітику тощо.
  • Маршрутизація шлюзу (маршрутизація рівня 7, зазвичай запити HTTP) - запити маршрутів до кінцевих точок внутрішніх мікросервісів з використанням єдиної кінцевої точки, щоб споживачам не потрібно було керувати багатьма окремими кінцевими точками

Зауважте, що шлюз API завжди повинен бути високодоступним та ефективним компонентом, оскільки він є вхідною точкою для всієї системи.

Шина подій (канал Pub / sub Mediator для асинхронного зв'язку, керований подіями)

Побічна узгодженість між мікросервісами на основі асинхронного зв'язку, керованого подіями (Зображення: microsoft.com)

Для різних частин програми для спілкування один з одним, незалежно від послідовності повідомлень (асинхронних) або якою мовою вони користуються (мова агностики), може використовуватися шина подій. Більшість автобусів подій підтримують публікацію / підписку, розповсюдження, вказівку на пункт та повідомлення на відповідь на запит. Деякі шини подій (як, наприклад, у Vert.x) дозволяють клієнтові спілкуватися з відповідними вузлами сервера за допомогою тієї ж шини подій, що є класною функцією, яку люблять команди з повним стеком.

Сервісна сітка (коляска для міжслужбового зв'язку)

Міжсервісне спілкування у стилі Service Mesh (Зображення: Мікросервіси на практиці)Як використовуються службові сітки в додатку (Зображення: christianposta.com)

Service Mesh реалізує схему Sidecar, забезпечуючи хелперну інфраструктуру для міжсервісного зв'язку. Сюди входять такі функції, як стійкість (відмовостійкість, балансування навантаження), виявлення послуги, маршрутизація, спостережливість, безпека, контроль доступу, підтримка протоколу зв'язку тощо.

Як сервісні сітки вписуються в мережевий стек (Зображення: christianposta.com)

На практиці екземпляр Sidecar розміщується поруч із кожною службою (в ідеалі в одному контейнері). Вони можуть спілкуватися через примітивні функції мережі. План управління службовою сіткою окремо розгорнуто для забезпечення центральних можливостей, таких як виявлення служби, контроль доступу та спостережливість (моніторинг, розподілений журнал). Найголовніше, що стиль Mesh-сервісу дозволяє розробникам відключати функції мережевого зв’язку від коду мікросервісу та зберігати послуги, орієнтовані лише на бізнес-можливості. (Читайте: Netflix Prana, службова сітка для мікросервісів)

Незважаючи на те, що вищезазначені зображення вказують на прямі зв'язки між службами, гарним способом керувати міжслужбовим спілкуванням було б використання простої шини подій як посередника для збереження зв'язку на мінімальному рівні.

Бакенди для фронтенів (BFF)

Реалізація Backends для моделей Frontends і Aggregator на рівні шлюзу API (Зображення: microsoft.com)

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

Кращі практики

Design Дизайн, керований доменом - Модельні послуги навколо бізнес-домену.

Для роботи з великими моделями та командами може застосовуватися дизайн, керований доменом (DDD). Він стосується великих моделей, поділяючи їх на різні обмежені контексти та чітко розказуючи про їх взаємозв'язки та доменну область. Ці обмежені контексти можуть бути перетворені в окремі мікросервіси на рівні дизайну додатків (Читайте: Обмежений контекст у дизайні, керованому доменом).

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

Уникайте спільних сховищ даних та механізмів доступу до даних (Зображення: christianposta.com)

Розумні кінцеві точки та німі труби - кожна служба має чітко визначений API для зовнішнього зв'язку. Уникайте деталей щодо впровадження. Для спілкування завжди використовуйте прості протоколи, такі як REST через HTTP.

Асинхронний зв’язок - коли асинхронний зв’язок використовується між службами, потік даних не блокується для інших служб.

Синхронний та асинхронний обмін повідомленнями (Зображення: microsoft.com)

Уникайте зв'язку між службами - Служби повинні мати слабку зв'язок і високу функціональну згуртованість. Основними причинами зв'язку є спільні схеми баз даних і жорсткі протоколи зв'язку.

Децентралізуйте розробку - уникайте обміну кодовими базами, схемами даних або членами групи розробників серед декількох служб / проектів. Нехай розробники зосереджуються на інноваціях та якості у джерелі.

Тримайте знання про домен поза шлюзом. Нехай шлюз обробляє питання щодо маршрутизації та наскрізного перегляду (автентифікація, припинення SSL).

Aut Аутентифікація на основі токена. Замість того, щоб впроваджувати компоненти безпеки на кожному рівні мікросервісів, які розмовляють з централізованим / спільним сховищем користувачів та отримують інформацію про аутентифікацію, розгляньте можливість застосування автентифікації на рівні шлюзу API з широко використовуваними стандартами безпеки API, такими як OAuth2 та OpenID Підключення. Отримавши маркер автентифікації від постачальника аутентифікації, його можна використовувати для спілкування з іншими мікросервісами.

Безпека мікросервісу за допомогою OAuth2 та OpenID Connect (Зображення: Блог Касуна)

Nature Природа, спричинена подіями - людина є автономними агентами, здатними реагувати на події. Хіба наші системи не можуть бути такими? (Читайте: Чому мікросервіси повинні керуватися подіями: Автономія проти повноважень)

Побічна послідовність - Через високу згуртованість у мікропослугах важко досягти міцної послідовності у всій системі. Команді розробників доведеться поводитися з можливою послідовністю по мірі її надходження.

Tole Толерантність відмов - Оскільки система складається з декількох компонентів сервісу та програмного забезпечення, відмови можуть відбутися десь дуже легко. Реалізація таких моделей, як розрив ланцюга, об'ємна робота, повторні спроби, тайм-аути, вихід з ладу, кешування на відмову, обмежувачі швидкості, провідники завантаження в таких вразливих компонентах можуть мінімізувати ризики великих збоїв. (Читайте: Проектування архітектури мікросервісів для відмови)

Engineering Інжиніринг продукту - мікросервіси працюватимуть добре до тих пір, поки вони не розробляються як продукт, а не як проект. Йдеться не про те, щоб це якось попрацювало і було поставлено до встановлених строків, а про довготривале зобов'язання в галузі інженерної досконалості.

Мікросервіси на практиці

Коли користуватися мікросервісами

Архітектура мікросервісів найкраще підходить для:

  • Програми з високими потребами в масштабованості
  • Проекти з високою швидкістю випуску
  • Ділові випадки з багатими доменами або багатьма субдоменами
  • Спритний середовище з невеликими, багатофункціональними командами розвитку, що спільно розробляють великі продукти (Читайте: Історія справжнього успіху архітектури мікросервісів)

Деякі рамки для впровадження мікросервісів

  • Vert.x - легкий, простий у розумінні / впровадженні / підтримці, поліглот (підтримує багато мов), керований подіями, не блокує, дотепер найкраща продуктивність та масштабованість при обробці високих потреб в одночасності з мінімальним обладнанням, непідтримуваний ( надає лише корисну цеглу, розробники мають свободу бути інноваційними та ретельно будувати свої програми, а не як традиційні обмежувальні рамки)
  • Akka - задовільна продуктивність, реалізована модель актора, добре підходить для реактивних та подій мікросервісів
  • PSpringBoot / Cloud - легко запустити (знайомі парадигми), засновані на старому доброму рамках Spring, трохи важкій рамці, доступно багато інтеграцій, велика підтримка громади
  • Dropwizard - хороший для швидкого розвитку веб-сервісів RESTful, оснащений деякими приємними інструментами та бібліотеками Java, такими як Google Guava, сервер Jetty, Logback, Hibernate Validator, Joda Time, Jersey та Jackson.

Параметри розгортання

  • Контейнери - корисні для виконання цілей DevOp (швидкий розвиток, скорочення часу на ринок, безшовне масштабування)
  • Хмара - добре для створення надійної та масштабованої інфраструктури для обслуговування географічно розсіяних користувачів
  • Без сервера - підходить для обробки легколетучих перевезень
  • Підтримувати власну ІТ-інфраструктуру - добре для тих, хто має високі потужності та ресурси для створення всієї інфраструктури

Розробка концепцій навколо мікросервісів

  • Самостійні системи - збирають програмне забезпечення з незалежних систем (наприклад, вертикалі в мікросервісах)
  • Micro Frontends - розділіть монолітні веб-інтерфейси на незалежні функції, які можуть бути розроблені як автономні компоненти інтерфейсу та безпосередньо спілкуватися з мікропослугами

Ключові слова для google (і вивчення!)

Дизайн, керований доменом (DDD) | Обмежений контекст (BC) | Постійність поліглоту (PP) | Сегрегація відповідальності за команду та запити (CQRS) | Розділ запитів команд (CQS) | Sourcing-події (ES) | Теорема CAP | Побічна послідовність | Дванадцятифакторний додаток | Тверді принципи |

Пропозиції щодо архітектури

Архітектура мікросервісів для інтернет-додатків для покупок (Зображення: microsoft.com) - Ця архітектура запропонована розробниками Microsoft, що використовують технології Microsoft. Тут шлюз API був розроблений для того, щоб по-різному ставитися до користувачів Інтернету та мобільних пристроїв. Для рівня даних технології зберігання даних ретельно підбираються відповідно до можливостей бізнесу (реляційні бази даних для структурованих даних, Redis для тимчасового кешування даних, MongoDB та CosmosDB для неструктурованих даних). Міжслужбовий зв’язок, який обробляється автобусом події. Якщо не відмовлятися від технологій, це найпоширеніша схема інтеграції, яка використовується в додатках на базі мікросервісів.Архітектура мікросервісів для програми, яка відображає оновлення в реальному часі для кінцевих користувачів, використовуючи велику кількість потоків вхідних даних, що надходять з різних джерел подій (наприклад, дані про трафік, погодні показання, канали фондового ринку, повідомлення в соціальних мережах, виходи датчиків). Ці потоки вхідних даних спочатку збираються журналом подій, реалізованим за допомогою Kafka. Він зберігає дані на диску і, таким чином, може бути використаний для цілей споживання (аналітика, звітність, наука даних, резервне копіювання, аудит) або відправлений для цілей споживання в режимі реального часу (оперативна аналітика, CEP, інформаційні панелі адміністратора, програми попередження). Однак, згідно з цією діаграмою, безперервний вхідний потік ділиться на мікропарти із заданими інтервалами за допомогою Spark та подається в двигун WSO2 Siddhi CEP. Потім він визначає події та зберігає їх у неструктурованих формах, використовуючи сховища даних MongoDB. Мікросервіси споживають ці дані та відображаються кінцевим користувачам. Якщо ви уважно подивитеся на дизайн, оскільки шина подій Vert.x має можливість створювати з'єднання з компонентами інтерфейсу інтерфейсу, ця функція використовується для ефективного оновлення лише відповідних частин інтерфейсу користувача. Не відмовляючись від технологій, це чудова архітектура для керованих подіями програм, що не блокують мікросервіси.Хмарна архітектура багатоканальних мікросервісів для додатків управління замовленнями (Зображення: ibm.com) - Однією з головних особливостей у цьому дизайні є, замість того, щоб використовувати шлюз API, архітектори IBM запропонували крайовий шар із окремими перехідними каналами для кожного каналу на стороні клієнта ( мобільні додатки, веб-програми, пристрої IOT, споживачі API). Ще однією особливістю є те, що шар мікропослуг розділений на 2 підшари, які називаються шаром «Бізнес логіка» та «Основний шар». Основний шар (a.k.a. Core Services Layer) розглядає завдання щодо збереження та інтеграції за допомогою різних хмарних служб (хмарні сховища даних, двигуни Elasticsearch, які інтегрують та індексують розмову Ватсона). Рівень бізнес-логіки інтегрує дані з основного рівня та забезпечує значущі бізнес-можливості. Це була б чудова архітектура для обслуговування дуже великої кількості баз користувачів, які географічно розповсюджені та отримують доступ до додатків через різні платформи.
Вам подобається поки що? Не забудьте рекомендувати to