Мікросервісна архітектура (Microservice Architecture)
Last updated
Last updated
Мікросервісна архітектура або просто мікросервіси – це особливий метод розробки програмних систем, який намагається зосередитись на створенні однофункціональних модулів із чітко визначеними інтерфейсами та операціями. Ця тенденція стала популярною в останні роки, оскільки підприємства прагнуть стати більш гнучкими та перейти до DevOps та безперервного тестування.
Мікросервіси мають безліч переваг для Agile-і DevOps-команд - як зазначає Мартін Фаулер, Netflix, eBay, Amazon, Twitter, PayPal та інші зірки технологій перейшли від монолітної до мікросервісної архітектури. На відміну від мікросервісів монолітний додаток будується як єдина автономна одиниця. Це сповільнює внесення змін до програми, оскільки впливає всю систему. Модифікація, внесена в невелику ділянку коду, може вимагати створення та розгортання нової версії програмного забезпечення. Масштабування певних функцій програми також означає, що вам необхідно масштабувати всю програму. Мікросервіси вирішують ці проблеми монолітних систем, будучи максимально модульними. У найпростішій формі вони допомагають створити додаток у вигляді набору невеликих служб, кожна з яких працює у своєму власному процесі та розгортається незалежно. Ці послуги можуть бути написані різними мовами програмування та можуть використовувати різні способи зберігання даних. Хоча це призводить до розробки систем, які є масштабованими та гнучкими, вони потребують динамічного перетворення. Мікросервіси часто підключаються через API і можуть використовувати багато тих же інструментів і рішень, які виросли в екосистемі RESTful і веб-сервісів. Тестування цих API допоможе перевірити потік даних та інформації під час розгортання мікросервісу. вони потребують динамічного перетворення. Мікросервіси часто підключаються через API і можуть використовувати багато тих же інструментів і рішень, які виросли в екосистемі RESTful і веб-сервісів. Тестування цих API допоможе перевірити потік даних та інформації під час розгортання мікросервісу. вони потребують динамічного перетворення. Мікросервіси часто підключаються через API і можуть використовувати багато тих же інструментів і рішень, які виросли в екосистемі RESTful і веб-сервісів. Тестування цих API допоможе перевірити потік даних та інформації під час розгортання мікросервісу.
Так само, як не існує формального визначення терміну «мікросервіси», немає і стандартної моделі, яку ви побачите представленої в кожній системі, що базується на цьому архітектурному стилі. Але ви можете очікувати, що більшість мікросервісних систем матимуть кілька примітних характеристик:
Мультикомпонентні : Програмне забезпечення, створене як мікрослужби, за визначенням може бути розбите на кілька складових служб. Чому? Таким чином, кожну з цих служб можна розгортати, налаштовувати, а потім повторно розгортати незалежно один від одного без шкоди для цілісності програми. В результаті вам може знадобитися змінити лише одну або кілька окремих служб замість повторного розгортання цілих програм. Але цей підхід має свої недоліки, у тому числі дорогі віддалені виклики (замість викликів усередині процесу), більш грубі віддалені API і підвищена складність при перерозподілі обов'язків між компонентами;
Створені для бізнесу : Стиль мікросервісів зазвичай організований навколо бізнес-можливостей та пріоритетів. На відміну від традиційного монолітного підходу до розробки, коли різні команди приділяють особливу увагу, скажімо, інтерфейсу користувача, баз даних, технологічним рівням або логіці на стороні сервера, в мікросервісній архітектурі використовуються кросфункціональні команди. До обов'язків кожної команди входить створення конкретних продуктів з урахуванням одного чи кількох окремих сервісів, взаємодіючих через шину сообщений. У мікросервісах команда володіє продуктом все життя, як у найчастіше цитованій максимі Amazon: " ";
Проста маршрутизація : Мікросервіси діють приблизно так само, як класична система UNIX: вони отримують запити, обробляють їх та генерують відповідну відповідь. Це протилежно тому, як працює багато інших продуктів, таких як ESB (Enterprise Service Buses), де використовуються високотехнологічні системи для маршрутизації повідомлень, хореографії та застосування бізнес-правил. Можна сказати, що мікросервіси мають інтелектуальні кінцеві точки (endpoints), які обробляють інформацію та застосовують логіку, і тупі канали (?dumb pipes), якими інформація тече;
Децентралізовані : Оскільки мікросервіси включають безліч технологій та платформ, старі методи централізованого керування не є оптимальними. Спільнота мікросервісів віддає перевагу децентралізованому управлінню, тому що його розробники прагнуть створювати корисні інструменти, які потім можуть використовуватися іншими для вирішення тих же проблем. Як і децентралізоване управління, мікросервісна архітектура також сприяє децентралізованого управління даними. Монолітні системи використовують одну логічну базу даних для різних програм. У мікросервісному додатку кожна служба зазвичай керує своєю унікальною базою даних;
Відмовостійкі : Як всебічно розвинена дитина, мікросервіси створені, щоб справлятися з помилками. Оскільки кілька унікальних та різноманітних сервісів взаємодіють один з одним, цілком можливо, що сервіс може вийти з ладу з тієї чи іншої причини (наприклад, коли постачальник недоступний). У цих випадках клієнт повинен дозволити своїм сусіднім службам працювати, доки він відключається. Однак моніторинг мікросервісів може допомогти запобігти ризику збою. Зі зрозумілих причин ця вимога робить мікросервіси складнішими в порівнянні з архітектурою монолітних систем;
Еволюційні : Архітектура мікросервісів є еволюційним дизайном і, знову ж таки, ідеально підходить для систем, що еволюціонують, в яких ви не можете повністю передбачати типи пристроїв, які одного разу можуть отримати доступ до вашого додатку. , можна поступово перетворити на мікросервіси, що взаємодіють з більш старою монолітною архітектурою через API.
Приклади
Netflix має широко поширену архітектуру, яка перетворилася з монолітної на SOA. Щодня він отримує більше одного мільярда дзвінків з більш ніж 800 різних типів пристроїв на свій API потокового відео. Потім кожен виклик API запитує близько п'яти додаткових викликів серверної служби. Amazon також перейшов на мікросервіс. Вони отримують незліченну кількість викликів з різних програм, включаючи програми, які управляють API веб-служби, а також самим веб-сайтом, які були б просто неможливі для їхньої старої дворівневої архітектури. Аукціонний сайт eBay - ще один приклад, що пройшов той самий перехід. Їх основна програма складається з кількох автономних програм, кожна з яких виконує бізнес-логіку для різних функціональних областей.
SOA vs. Microservices
«Почекайте, - можуть бурмотіти деякі з вас за ранковою кавою, - хіба це не просто інша назва SOA?» Сервіс-орієнтована архітектура (SOA), що виникла в перші кілька років цього століття, та мікросервісна архітектура (скорочено MSA) мають низку загальних рис. Однак традиційна SOA являє собою ширшу структуру і може означати різні речі. Деякі прихильники мікросервісів взагалі відкидають тег SOA, тоді як інші вважають мікросервіси просто ідеальною, вдосконаленою формою SOA. У будь-якому випадку ми вважаємо, що існує досить чітких відмінностей, щоб виправдати окрему концепцію «мікросервісу» (принаймні як особливу форму SOA, як ми проілюструємо пізніше). Типова модель SOA, наприклад, зазвичай має більш залежні ESB, а мікросервіси використовують швидше механізми обміну повідомленнями. SOA також орієнтована на імперативне програмування, тоді як архітектура мікросервісів орієнтована стиль програмування з гнучким суб'єктом. Крім того, моделі SOA, як правило, мають реляційну базу даних занадто великого розміру, тоді як мікросервіси часто використовують бази даних NoSQL або micro-SQL (які можуть бути підключені до звичайних баз даних). Але реальна різниця насамперед пов'язані з методами архітектури, використовуваними щоб одержати інтегрованого набору сервісів. Оскільки в цифровому світі все змінюється, гнучкі методи розробки, які можуть йти в ногу із вимогами еволюції програмного забезпечення, є безцінними. Більшість методів, що використовуються в архітектурі мікросервісів, походять від розробників, які створювали програмні програми для великих корпоративних організацій і знають, що сьогоднішні кінцеві користувачі очікують динамічної, але узгодженої взаємодії на різних пристроях. Масштабовані, адаптовані, модульні та швидкодоступні хмарні програми користуються великим попитом. І це змусило багатьох розробників змінити свій підхід.
Джерела:
Дод. матеріал: