1. Спрощена картина
2. Малюнок 1. Відмінності між архітектурою мікросервісов і SOA
3. Подвійна природа ініціатив SOA
4. Технічні аспекти, зумовлені інтеграцією
5. Функціональні аспекти, обумовлені бізнес-вимогами
6. Малюнок 2. Подання SOA з технічної та функціональної точок зору
7. Порівняння API з експортованими сервісами SOA
8. Повторне використання SOA
9. Поява управління API
10. Малюнок 3. Внутрішній і зовнішній експорт API
11. Мікросервіси: альтернативна архітектура
12. переваги мікросервісов
13. Основні фактори, что вплівають на Прийняття решение про использование мікросервісов
14. Місце мікросервісов в загальній картині SOA і проблеми інтеграції
15. Малюнок 6. Архітектура мікросервісов при розробці з нуля
16. Малюнок 7. ІТ-середовище великого підприємства з мікросервісамі
17. Перспективи об'єднання мікросервісов, SOA і API
18. тісна інтеграція
19. Малюнок 8. Комбінація мікросервісов, SOA і API
20. Сервісні компоненти
21. Висновки
22. Подякою
23. ресурси

Порівняння основних концепцій архітектури додатків і інтеграції для розвивається підприємства

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

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

Спрощена картина

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

Розглянемо наступні прості визначення:

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

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

Малюнок 1. Відмінності між архітектурою мікросервісов і SOA

Це занадто спрощені визначення SOA і мікросервісов. Насправді, їх взаємозв'язку набагато складніше.

Подвійна природа ініціатив SOA

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

Технічні аспекти, зумовлені інтеграцією

Перший підхід вирішує завдання тісної інтеграції з існуючими системами, що використовують складні і часто унікальні формати даних, протоколи та транспортні канали. Потім виникає завдання спростити їх повторне використання в нових додатках за допомогою стандартизованих механізмів (наприклад, SOAP / HTTP або останнім часом JSON / HTTP). Цей підхід, часто іменований шаблоном корпоративної сервісної шини (ESB), показаний зліва на малюнку 2 . Однак слід зазначити, що внаслідок нерозбірливого вживання цього терміна він втратив весь сенс.

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

Функціональні аспекти, обумовлені бізнес-вимогами

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

Існує потреба у функціональному рефакторінгу з метою експорту тільки цінних для бізнесу елементів, які має сенс вбудовувати в майбутні рішення. Даний рефакторинг вимагає створення нових додатків, щоб зв'язати запити з існуючих систем обліку. У базовій архітектурі SOA ці додатки, як правило, називаються сервісними компонентами (праворуч на малюнку 2 ). Ця схема відображає зв'язок з проектуванням додатків (і, відповідно, архітектурою мікросервісов), а також функціональним поділом системи на окремі компоненти.

Малюнок 2. Подання SOA з технічної та функціональної точок зору

Проблема поєднання двох аспектів

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

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

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

Розглянуті два підходи до SOA роблять порівняння з мікросервісамі проблематичним.

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

Термін API раніше часто мав на увазі низькорівневі інтерфейси програмного коду. В останні роки цей термін змінив своє значення, і зараз під ним розуміють прості інтерфейси, що надаються на основі HTTP. Зазвичай це рівнозначно інтерфейсів REST, які надають дані в форматі JSON (рідше - XML), і використовують дієслова HTTP: PUT, GET, POST і DELETE для опису дій «створити», «прочитати», «оновити» і «видалити». Ці протоколи і формати даних простіше у використанні, ніж стандарти веб-служб на основі SOAP, які переважали на момент появи SOA. Крім того, вони більшою мірою підходять для таких мов програмування, як JavaScript, які широко використовуються для здійснення запитів до API.

Проте різниця між веб-сервісами SOA і API визначається не тільки протоколами і форматами даних, так як їх використання не уніфіковане. Різниця обумовлена ​​ідеями, які лежать в основі API і сервісів SOA. Одним з ключових відмінностей є економічна складова.

Повторне використання SOA

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

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

Поява управління API

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

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

До сих пір акцент в API був зроблений на тому, щоб відкрито експортувати щось для зовнішніх споживачів; межа між API і внутрішніми сервісами SOA була очевидна. З розвитком технологій управління API додалися такі переваги, як зручність використання і можливість самоврядування. В результаті багато компаній тепер хочуть використовувати технології і протоколи API для експорту сервісів всередині компанії, як показано на малюнку 3 . Межі між веб-сервісами SOA і API стають розмитими і практично не мають значення. Ці концепції мають різне походження, різну цільове призначення і навіть моделі даних, проте багато «сервіси» SOA можуть бути представлені у вигляді внутрішніх API.

Малюнок 3. Внутрішній і зовнішній експорт API

Сьогодні термін APIs часто використовується для позначення будь-яких інтерфейсів, які надаються за допомогою REST (HTTP / JSON) або веб-служб (SOAP / HTTP). API зазвичай поділяються на категорії по області дії, зокрема загальнодоступні і корпоративні API. На підприємствах з працюючими ініціативами SOA під терміном «сервіс» іноді і раніше розуміють внутрішні, корпоративні API. Більш детально відмінності між SOA і API розглянуті в статті Архітектура інтеграції: порівняння веб-інтерфейсів API і сервіс-орієнтованої архітектури та інтеграція корпоративних додатків. (EN).

Термін API відображає еволюцію такого поняття SOA, як «експорт сервісів». Йдеться про спрощені протоколах і більш складних процедурах експорту, що включають в себе портали для розробників, контроль на основі політик і самоврядування.

Мікросервіси: альтернативна архітектура

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

Межі програми не змінюються. Як показано на малюнку 4, незважаючи на внутрішню структуру, що складається з безлічі окремих мікросервісних компонентів, ззовні додаток виглядає точно так же. Кількість і рівень структурованості API, які надає мікросервісное додаток, не повинні відрізнятися від API, розроблених у вигляді монолітного додатки. Приставка "мікро" в назві мікросервіс говорить про структурованості внутрішніх компонентів, а не експортованих інтерфейсів.

Логічне поділ компонентів всередині програми не є новою ідеєю. Згодом з'явилося безліч різних технологій, що забезпечують суворе поділ окремих частин цілого додатки. На серверах додатків протягом довгого часу може виконуватися кілька компонентів програми, як показано на другій схемі малюнка 5 .Мікросервіси пішли ще далі, забезпечуючи абсолютну ізоляцію між цими компонентами програми. На правій схемі малюнка 5 показані мережеві процеси, що працюють незалежно один від одного. Для отримання переваг ослаблення взаємозв'язків всередині програми модель даних також повинна відповідати принципам мікросервісной архітектури.

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

Повністю незалежні мікросервісние компоненти забезпечують абсолютно автономне володіння, що в результаті дає наступні переваги:

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

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

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

Перераховані переваги є основною причиною вибору мікросервісов багатьма організаціями.

Основні фактори, что вплівають на Прийняття решение про использование мікросервісов

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

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

  Якщо мікросервіси не підходять ні для старих, ні для нових додатків, де ж їх використовувати? У загальному випадку мікросервіси не рекомендується використовувати до тих пір, поки традиційне додаток не досягне певного порогу складності. Однак навіть у цьому випадку необхідно, щоб додаток спочатку мало підходить для мікросервісов структуру, яку можна перетворити в потрібний момент.

• Різні парадигми проектування. Архітектура додатків на основі мікросервісов вимагає іншого підходу до проектування. Для досягнення найкращих результатів може знадобитися наступне:
  • Перехід до моделі узгодженості в кінцевому рахунку (eventual consistency) замість звичних ітерацій.
  • Розуміння принципів роботи з подійними додатками (event sourcing) без централізованого зберігання робочих даних.

  Також необхідно зробити наступне:

  • Переконатися, що логіка програми не залежить від збереження стану - це необхідно для того, щоб реалізувати відчутні переваги швидкого масштабування.
  • Врахувати можливі побічні ефекти асинхронного зв'язку, якщо прийнято рішення піти від підлеглих компонентів.
  • Розуміння факторів впливу логіки на реалізацію шаблонів перевірки працездатності партнерських серверів Circuit Breaker.
  • Усвідомлення обмежень на обробку помилок при використанні HTTP / JSON на відміну від внутрішньої взаємодії.
  • Облік затримок в мережі при послідовному взаємодії.
• Зрілість DevOps. Мікросервіси вимагають склалася системи доставки. Безперервна інтеграція, розгортання і повністю автоматизоване тестування є обов'язковими вимогами. Розробники, що створюють вихідний код, повинні відповідати за нього після запуску в робочому середовищі. Для правильного розподілу зон відповідальності в середовищі мікросервісов необхідно внести істотні зміни в процеси компонування і розгортання.

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

Місце мікросервісов в загальній картині SOA і проблеми інтеграції

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

Якщо ж ментальна модель SOA включає перепроектування додатків в більш зрозумілі для бізнесу «сервісні компоненти», то такі компоненти, показані в правій частині малюнка 2 стають схожими на мікросервіси. В такому випадку архітектура мікросервісов може бути інтерпретована як еволюція SOA. В якості ілюстрації даної точки зору можна порівняти два протилежних сценарію.

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

Обчислювальну середу компанії можна створити практично з нуля. Основний акцент може бути зроблений на можливості швидкого додавання нових функцій, з мінімальним часом простою, і підвищенні рівня готовності середовища (концепція «Green Field»). Компанія може вибрати еластичне масштабування (т. Е. Горизонтальне і вертикальне) з урахуванням непередбачуваних потреб клієнтів. Можливо, буде потрібно забезпечити цілодобове, стійке і високодоступних присутність онлайн.

При таких умовах архітектура мікросервісов є логічним вибором, як показано на малюнку 6 .

Малюнок 6. Архітектура мікросервісов при розробці з нуля

Нові додатки можуть існувати в межах єдиної середовища мікросервісов, що забезпечує відповідність нефункціональним вимогам, таким як масштабованість, готовність і управління ресурсами. У числі очікуваних результатів - мінімізація низькорівневих проблем інтеграції, оскільки всі компоненти мікросервісов і пов'язані додатки SaaS використовують для зв'язку загальноприйняті протоколи, наприклад API HTTP / JSON. При цьому досягається одна з ключових цілей SOA - комбінування і використання цінних функцій в масштабі всього підприємства. В даному випадку межа між правильно реалізованої архітектурою SOA і мікросервісамі стає розмитою. Якщо існує ідеальна реалізація SOA, то цей приклад максимально наближений до неї, однак домогтися подібної однорідної архітектури можна тільки в нових компаніях.

Порівняння розмірів «сервісного компонента» SOA і мікросервіса виходить за рамки даної статті. Ступінь структурованості мікросервісов і спосіб їх об'єднання - вже тема зовсім іншої обговорення.

Тепер розглянемо протилежну ситуацію - велике підприємство, ІТ-середовище якого формувалася протягом кількох десятиліть. Прикладом такого підприємства може виступати традиційний банк або страхова компанія, з сотнями або навіть тисячами важливих додатків, розроблених на основі технологій, які були винайдені кілька десятків років тому. Таке підприємство може складатися з декількох строго розмежованих підрозділів (наприклад, охорона здоров'я / пенсійне забезпечення / загальне страхування або роздрібний / інвестиційний банкінг). У кожному бізнес-підрозділі можуть бути розгорнуті власні спеціалізовані додатки. При цьому не виключено наявність стандартного для всього підприємства набору додатків, наприклад для управління персоналом.

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

Питання інтеграції також стоять дуже гостро. Можуть знадобитися інструменти інтеграції, як показано на малюнку 7 , Використання мікросервісов на великих підприємствах починається з побудови нових додатків як «систем залучення клієнтів» (systems of engagement). Початкові ініціативи, цілком орієнтовані на інтеграцію, обмежили концепцію SOA. Тому мікросервіси часто сприймаються як щось відокремлене від SOA, спрямоване на забезпечення більшої гнучкості, масштабованості і адаптивності, але в багатьох випадках спирається з опорою на фундамент, підготовлений на етапі інтеграції SOA.

Малюнок 7. ІТ-середовище великого підприємства з мікросервісамі

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

Привабливість архітектури мікросервісов для нових додатків очевидна. Як показано на малюнку 7 , Використання мікросервісов на великих підприємствах починається з побудови нових додатків як «систем залучення клієнтів» (systems of engagement). Початкові ініціативи, цілком орієнтовані на інтеграцію, обмежили концепцію SOA. Тому мікросервіси часто сприймаються як щось відокремлене від SOA, спрямоване на забезпечення більшої гнучкості, масштабованості і адаптивності, але в багатьох випадках спирається з опорою на фундамент, підготовлений на етапі інтеграції SOA.

Перспективи об'єднання мікросервісов, SOA і API

З точки зору архітектури SOA складається з трьох ключових елементів:

• Тісна інтеграція з метою надання даних і функцій існуючих систем через інтерфейси
• Виставлення сервісів з метою стандартизації та спрощення доступу до цих інтерфейсів для широкої аудиторії
• Сервісні компоненти для об'єднання інтерфейсів в більш корисні для бізнесу ресурси

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

тісна інтеграція

Деякі системи все ще потребують функціях тісної інтеграції, які підтримуються інтеграційними брокерами, надаючи свої функції і дані у вигляді API. Інші системи, можливо, зможуть надавати API безпосередньо після оновлення. Головна відмінність починається там, де архітектура SOA намагається забезпечити централізовані функції тісної інтеграції. Більш сучасні інструменти і прийоми повинні забезпечувати об'єднання функцій інтеграції на рівні власників додатків, як показує розташування інтеграційних брокерів на малюнку 8 .

Малюнок 8. Комбінація мікросервісов, SOA і API

експорт сервісів

Забігаючи вперед, варто відзначити, що всі системи повинні забезпечувати API, щоб залишатися релевантними. API додатків вимагають створення спрощеного рівня управління, як показано на зображенні шлюзів API рисунок 8 . Цей рівень контролю - нова інтерпретація концепції експорту сервісів з SOA. Результатом став більш широкий і децентралізований експорт API.

Шлюз API і функції управління API можуть бути загальним ресурсом підприємства. Вони децентралізовані в тому сенсі, що окремі колективи розробників можуть самостійно публікувати API і підписуватися на ті API, які їм потрібні, без залучення інших команд. Стандартизовані механізми управління трафіком, відстеження трафіку, ведення протоколів, аудиту та безпеки мають вагомими перевагами для підприємства, при цьому зберігаючи потрібну для бізнесу гнучкість. Ті ж самі шлюзи API можна також використовувати для забезпечення керованого взаємодії з бізнес-партнерами і зовнішніми функціями SaaS.

Сервісні компоненти

Традиційні, більш монолітні додатки мають сенс для деяких реалізацій. Проте мікросервіси пропонують альтернативні способи компонування окремих класів додатків, надаючи переваги, недоступні в традиційних додатках, а саме гнучкість, масштабованість і стійкість. Додатки на основі мікросервісов найбільш поширені в сфері взаємодії і залучення клієнтів - там, де їх унікальні переваги найбільш затребувані. Це дозволяє створювати нові функції, що відповідають обраному каналу взаємодії, і API-інтерфейси для Інтернету.

Висновки

Існує як мінімум дві різні точки зору на цілі, які переслідувала архітектура SOA. Намагаючись безпосередньо порівнювати SOA і мікросервіси, ви швидше за все зіткнетеся з певними труднощами. В сучасних архітектурах використовуються модифіковані концепції SOA. Вдосконалені інструменти інтеграції, шаблони і стандарти забезпечують більш зручне надання функцій і даних. Експорт сервісів перетворився в API, тим самим спростивши завдання публікації, підписки, управління і (в яких випадках) монетизації бізнес-функцій. Нові архітектури додатків, включаючи мікросервіси, дозволяють розробникам приділити ще більше уваги бізнес-логікою, не відволікаючись на інфраструктурні особливості середовища, в якій ці додатки будуть працювати. Комбінація цих підходів дозволяє компонувати рішення в більш гнучкому форматі і реалізувати переваги за рахунок нових рівнів еластичною масштабованості і стійкості.

Подякою

Автор висловлює подяку наступним людям за допомогу в підготовці та перевірці матеріалів до даної статті: Andy Garratt, Andy Gibbs, Carlo Marcoli, Brian Petrini.

ресурси

Ресурси для скачування

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів