Зразок роботи
Вступ
Теперішні підприємства наштовхуються на значні проблеми, що орієнтовані на клієнта в розподільному порядку. Парадигма мікросервісів постала «наступною великою річчю» задля реалізації ІТ-результатів для сприяння сучасного виробництва, з великою кількістю постачальників технологій та послуг.
Не дивлячись на те, що поняття «мікросервіси» постало з середини 2000-х років, масове появлення терміну відбулося в 2011 рік. Зокрема у 2012 році мікросервіси згадувались на конференції 33d Degree в Кракові....
1. Що таке мікросервіси?
Мікропослуги – також відомі як архітектура мікропослуг – це архітектурний стиль, який структурує додаток як сукупність послуг, які є:
• Дуже ремонтопридатними та перевіряються
• Слабко зчеплені
• Незалежно розгортаються
• Організовано навколо ділових можливостей
• Належить невеликій команді
Архітектура мікросервісу дозволяє швидко, часто і надійно доставляти великі, складні програми. Це також дозволяє організації розвивати свій стек технологій.
Мікросервіси мають багато переваг для команд Agile та DevOps – як зазначає Мартін Фаулер (інженер-програміст), Netflix, eBay, Amazon, Twitter, PayPal та інші технічні зірки еволюціонували від монолітної до архітектури мікросервісів. На відміну від мікросервісів, монолітний додаток побудований як єдиний, автономний блок. Це вносить зміни в додаток повільно, оскільки це впливає на всю систему. Зміни, внесені до невеликого розділу коду, можуть вимагати створення та розгортання абсолютно нової версії програмного забезпечення. Масштабування конкретних функцій програми також означає, що потрібно масштабувати всю програму.
......
3. Приклади мікропослуг
Значна кількість масштабних веб – сайтів, зокрема такі як: Netflix, Amazon і eBay розвивались та трансформувались з монолітної архітектури і перейшли до архітектури мікросервісів.
Netflix має широко розповсюджену архітектуру, яка трансформувалася з монолітної на SOA. Щодня він одержує понад один мільярд дзвінків з понад 800 різноманітних видів пристроїв до особистого API потокового відео. Потім кожен виклик API запрошує біля п’яти побічних запитів до серверної служби.
Amazon також перейшов на мікросервіси. Вони отримують незліченну кількість дзвінків з різних програм – зокрема програми, що розпоряджаються API веб-служби, і сам веб-сайт, це було б неможливо для старішої дворівневої архітектури.
Сайт аукціону eBay – ще один приклад, який пройшов таку ж трансформацію. Зазначу, що провідний додаток формується з кількох окремих додатків, кожен з них реалізовує бізнес-логіку для розбіжних видів функцій.
4. Переваги та недоліки
Шлюзи API у мікросервісах можуть значно скоротити час та зусилля для збірки та контролю якості.
Однією із поширених проблем є спільне використання схеми, логіки перевірки між службами. Те, що потрібно A, щоб вважати деякі дані дійсними, не завжди стосується B, якщо B має інші потреби. Найкраща рекомендація – застосовувати схему керування версіями та розповсюджувати у спільних бібліотеках. Зміни в бібліотеках стають обговореннями між командами. Крім того, із сильним керуванням версіями виникають залежності, які можуть спричинити більші накладні витрати. Найкращою практикою для подолання цього є планування зворотної сумісності та прийняття регресійних тестів від зовнішніх служб. Вони спонукають до розмови до того, як порушити чужий бізнес-процес, а не після.
Як і в усьому іншому, чи підходить мікросервісна архітектура, залежить від ряду вимог, оскільки всі вони мають свої плюси і мінуси. Ось короткий опис хорошого і поганого:
Плюси
....
7. Майбутнє архітектури мікросервісів
Незважаючи на те, чи стане архітектура мікросервісів улюбленим стилем розробників у майбутньому, це явно потужна ідея, яка пропонує серйозні переваги при розробці та впровадженні корпоративних програм. Багато розробників та організацій, ніколи не використовуючи назви або навіть не позначаючи свою практику як SOA, застосовують підхід до використання API, які можна класифікувати як мікросервіси.
Можна спостеріати, як низка існуючих технологій намагається вирішити частини проблем сегментації та зв'язку, які мікросервіси мають на меті вирішити. SOAP добре описує операції, доступні для даної кінцевої точки, і де їх можна знайти за допомогою WSDL. Теоретично UDDI є гарним кроком на шляху до реклами того, що може зробити послуга і де її можна знайти. Але ці технології були скомпрометовані порівняно складним впровадженням, і, як правило, не застосовуються в нових проєктах. Послуги REST, що базуються, стикаються з тими ж проблемами, і хоча можна використовувати WSDL .............