понедельник, 15 мая 2017 г.

Микросервисы, SOA и API: друзья или враги?


Оригинал: Microservices, SOA, and APIs: Friends or enemies? by Kim Clark, опубликован 21 января 2016.

Сравнение ключевых концепций архитектуры приложений и интеграции для развивающегося предприятия.


Введение


При сравнении микросервисной и сервисно-ориентированной (SOA) архитектуры практически невозможно прийти к согласию о том, как же все-таки они соотносятся друг с другом. Добавление в список еще и application programming interfaces (APIs) картину очевидно не проясняет. Некоторые могут сказать, что это вообще абсолютно изолированные друг от друга понятия, не имеющие ничего общего и предназначенные для решения разных задач. Другие заметят, что данные концепции разделяют общие принципы и созданы для достижения неких общих целей. Микросервисная архитектура может казаться этакой "тонкоструктурной (fine-grained) SOA" или "правильно внедренной SOA".

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


Чрезмерно упрощенный взгляд


Причиной сложности сравнения SOA и микросервисов является тот факт, что определения данных концепций дает слишком много пространства для интерпретации. Если вы имеете лишь поверхностное понимание данных двух концепций, то они действительно могут выглядеть похожими. Ключевые аспекты, такие как разбиение системы на компоненты, обеспечение слабой связности и использование стандартных протоколов коммуникации, описывают множество инициатив в мире ПО, с которыми всем пришлось столкнуться в последние десятилетия, так что мы вынуждены разобраться глубже. Рассмотрим следующие простые определения:

  • Микросервисная архитектура - это альтернативный подход к построению структуры приложений. Приложение разбивается на несколько небольших, полностью независимых друг от друга компонентов, что позволяет данным компонентам иметь значительно большую гибкость, масштабируемость и доступность.

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

Данные понятия продемонстрированы на рисунке 1. SOA проявляется на уровне предприятия, где различные приложения вынуждены взаимодействовать друг с другом. SOA выставляет сервисы через стандартные интерфейсы между приложениями. Микросервисная архитектура имеет место на уровне отдельного приложения, фокусируясь на его структуре и компонентах.


Рисунок 1. Отличия между микросервисной архитектурой и SOA

Данные выше определения SOA и микросервисов довольно таки упрощены. Фактически, отношение между данными понятиями гораздо сложнее.

Дихотомия SOA-инициатив


Если вы взглянете на SOA более пристально, то сможете заметить, что первоначальная цель данной инициативы была несколько шире, чем просто выставление интерфейсов в качестве SOAP веб-сервисов. SOA основана на двух представлениях, которые рассматривают удовлетворение двух различных потребностей.

Обусловленные интеграцией технические аспекты

Первое представление охватывает потребность в интеграции существующих систем с учетом их сложности, а также часто используемых проприетарных форматов данных, протоколов и транспортов. Т.е. необходимо выставить данные системы с использованием стандартных механизмов (таких как SOAP/HTTP или, в последнее время,JSON/HTTP) с целью облегчения их повторного использования в новых приложениях. Данное представление проиллюстрировано в левой части рисунка 2. Некоторые или все варианты данного представления часто именуются паттерном Enteprise Service Bus (ESB). Впрочем, данный термин используется всеми без разбора, что делает его бессмысленным.

Необходимость в широкой интеграции (integration hub и adapters) и в выставлении данных интеграций в качестве сервисов или API некоторым стандартным способом (exposure gateway) весьма важна. Данный аспект лежит полностью в области интеграции и практически не касается дизайна конкретных приложений. Соответственно по этой причине он по всей видимости имеет слабое отношение к микросервисной архитектуре.

Обусловленные бизнесом функциональные аспекты

Второе представление порождается бизнес перспективой. Обеспокоенность вызывает тот факт, что интерфейсы эксплуатируемых систем по большому счету бесполезны. Они не имеют никакого влияния на бизнес и не предоставляют того, что нужно новому поколению приложений. Интерфейсы могут быть излишне структурированными (too granular), выставляя излишне много о сложных моделях данных, используемых в системах. Эти модели данных могут даже не поддерживать терминологию, используемую бизнесом.

Потребность предполагает функциональный рефакторинг с целью выделить что-то, что бизнес сможет осязаемо встроить в будущие решения. Данный рефакторинг требует создания новых приложений, чтобы связывать (to bind together) запросы по всем существующим корневым системам (systems of record). В референсной архитектуре SOA данные приложения зачастую называются сервисными компонентами (service components, см. правую часть рисунка 2). Данное представление демонстрирует отношение к дизайну приложения (и, соответственно, к понятию микросервисной архитектуры) и функциональную декомпозицию возможностей системы на отдельные компоненты.


Рисунок 2. Техническое и функциональное представление SOA

Проблема смещения данных представлений

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

Для многих основной проблемой является смещение данных представлений. Это тяжело, поскольку не просто объединить оба представления в единое направление действий. Интеграционные инструменты - это не то место, куда следует помещать бизнес-логику. И, наоборот, для вас может быть нежелательно загромождать бизнес-приложения техническими аспектами интеграции.

Цель большинства программ внедрения SOA - достичь функциональных аспектов. Необходимы доступные релевантные для бизнеса сервисы, которые могут быть использованы для более эффективного построения новых приложений. Тем не менее многие проекты превышают сроки и заложенные бюджеты, т.к. продолжают решать проблемы технической интеграции. На крупных предприятиях инициативы внедрения SOA часто рассматриваются как провальные. Под неудачей понимается непредставление финальной ценности для бизнеса, несмотря на то, что были сделаны большие шаги на пути повышения доступности корневых бизнес-приложений (system of record). Однако, в небольших компаниях или отдельных подразделениях крупных предприятий SOA часто претендует на реальную успешность для бизнеса, поскольку проблемы интеграции быстро преодолеваются и осуществляется переход к получению функциональных преимуществ.

Рассмотренные два представления о SOA делают сравнение с микросервисами проблематичным.

Как API соотносятся с сервисами SOA


Термин API ранее подразумевал низкоуровневые интерфейсы, реализованные в программном коде. В последние годы термин изменил значение, и сейчас под ним подразумеваются простые интерфейсы, построенные поверх HTTP. Обычно это эквивалентно REST-интерфейсам, которые предоставляют данные в формате JSON (иногда - XML) и используют глаголы HTTP: PUT, GET, POST и DELETE для описания действий "создать", "прочитать", "изменить" и "удалить". Данные протоколы и форматы данных проще в использовании, нежели стандарты веб-сервисов, основанные на SOAP, которые превалировали в ранние времена SOA. Так же они более подходят для таких языков программирования, как JavaScript, которые активно используются для осуществления запросов к API.

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

Повторно используемая SOA

В программе внедрения SOA, выставление сервисов подразумевает обеспечение доступности каждой бизнес-функции таким образом, чтобы она была повторно используемая настолько активно, насколько возможно. В данном случае, каждый новый проект не должен снова и снова проходить через выполнение интеграции с системами корпоративного бэк-офиса. Типичные потребители сервисов - новые внутренние приложения, которые пытаются предоставить современные интерфейсы пользователя к старым корневым системам предприятия. В то же время, интеграция - довольно сложный процесс, требующий значительной порции бюджета всего IT проекта. Если вы сможете сделать все основные функции компании доступными через повторно используемые интерфейсы, то существенно снизите затраты на проект. Таким образом, SOA - это про снижение затрат, не про генерацию нового дохода.

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

Рассвет API management'а

Популярность API взлетела до небес вместе с ростом использования смартфонов. Смартфоны позволяют запускать богатые клиентские приложения, создавая революционный канал для бизнеса. В результате, разработчикам приложений понадобилась возможность простого доступа к функциональности и данным бэк-энда, т.е. им потребовались API. API стали отдельным продаваемым продуктом и их производители конкурируют друг с другом за внимание разработчиков. В центре внимания API лежит не повторное использование или снижение затрат как было с SOA. Нет, основное внимание уделяется легкости использования (consumability) и конкуренции в соответствующей области экономики. API - это продаваемый продукт.

Данное изменение динамично предъявило новые технические требования к API по сравнению с сервисами SOA. Для API требуются сложные порталы, на которых разработчики могли бы находить и экспериментировать с данными программными интерфейсами. Так же требуются механизмы для разработчиков, чтобы регистрироваться и платить за использование API. Провайдерам требуется возможность устанавливать планы оплаты для размещения различных показателей использования API. Поскольку программные интерфейсы выставляются публично, то шлюзы, через которые предоставляется доступ, должны обеспечивать высочайший уровень безопасности. Все данные характеристики должны обеспечивать само-обслуживаемость и, помимо всего, быть простыми. Это создает потребность в новой IT-области, ныне известной как API management.

С данной точки зрения, фокусируясь на API как на чем-то выставленном публично для внешних потребителей, разделяющая API и внутренние сервисы SOA, линия просматривается довольно четко. С ростом уровня зрелости технологии API management'а, программные интерфейсы начали приносить такие преимущества, как легкость использования и само-администрируемость. В результате, многие компании теперь используют технологии и протоколы API для выставления сервисов внутри компании, как отображено на рис. 3. Линия между веб-сервисами SOA и API теперь стала размытая и практически не имеет значения. Данные инициативы имеют разное происхождение, разные группы пользователей, и даже используют разные модели данных, однако многие "сервисы" SOA потенциально могут быть представлены как внутренние API.


Рисунок 3. Предоставление API вовнутрь и вовне

Сегодня термин API часто используется для обозначения любых интерфейсов, которые выставлены как REST (HTTP/JSON) или веб-сервисы (SOAP/HTTP). API обычно подразделяются на разные категории согласно своему охвату, такие как публичные API или API уровня предприятия. На предприятиях, стабильно придерживающихся SOA-инициативы, обычно продолжают использовать термин сервис для внутренних API уровня предприятия. Для более полного понимания разницы между SOA и API, см. работу Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration.

Термином API обозначается развитие такого аспекта SOA, как "выставление сервисов" (service exposure). Речь идет об упрощении протоколов и в то же время обеспечении большей изысканности самого процесса выставления сервиса, включающего порталы разработчиков, управление политиками и само-администрирование.

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


Прежде чем взглянуть на любое сравнение микросервисов и SOA, необходимо понимать, что вообще обозначает понятие "микросервисная архитектура". С фундаментальной точки зрения, микросервисы - это альтернативная архитектура для построения приложений. Они предоставляют лучший путь для отделения друг от друга компонентов в границах приложения. Фактически, если бы "микросервисы" были названы термином "микрокомпоненты", то их истинная природа была четче отражена.

Границы приложения остаются теми же самыми. Как показано на рис. 4, несмотря на то, что приложение внутри разбито на отдельные микросервисные компоненты, снаружи оно продолжает выглядеть точно так же. Количество и гранулярность API, выставляемых основанным на микросервисах приложениям, не должны отличаться от API, построенного как монолит. Префикс "микро" в термине "микросервис" подразумевает гранулярность внутренних компонентов, а не гранулярность выставляемых наружу интерфейсов.


Рисунок 4. Микросервисное приложение выставляет наружу точно такие же интерфейсы, как и монолит

Логическое разделение компонентов внутри приложения не является новой идеей. Множество разных технологий для строгого разделения частей целого приложения разрабатывалось годами. Сервера приложения уже довольно долго могут исполнять внутри себя множество компонентов (приложений), как показано на втором изображении на рисунке 5. Микросервисы идут на шаг вперед, делая изоляцию между такими компонентами абсолютной. Они становятся независимо исполняемыми процессами в сети как показано на третьем изображении на рисунке 5. Чтобы максимально ослабить зависимости между частями приложения, нужно также разделить модель данных на порции, соответствующие конкретным микросервисам.


Рисунок 5. Путь от монолитных приложений к микросервисам

Преимущества микросервисов


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

  • Гибкость и продуктивность. Команда, разрабатывающая микросервис, в состоянии полностью понимать его кодовую базу. Она может собирать, разворачивать и тестировать микросервис независимо от других компонентов в гораздо более быстром цикле разработки. Поскольку микросервис - это всего лишь другой компонент где-то в компьютерной сети, его можно разрабатывать с использованием наиболее подходящего для реализуемой функциональности языка или фреймворка, а так же механизма долговременного хранения.

    Данный подход может существенно уменьшить количество кода, которое требует написать и драматическим образом облегчить его поддержку. Это гарантирует, что команды разработки могут использовать новые технологии или обновленные версии существующих без необходимости ожидать, пока разработчик других частей приложения будут готовы к такому переходу. В некоторых определениях понятия микросервиса подчеркивается, что компонент должен быть настолько простым, чтобы его можно было полностью переписать за одну итерацию, если возникнет такая необходимость.

  • Масштабируемость. Команда разработки микросервиса может масштабировать свой компонент во время исполнения независимо от других микросервисов, тем самым обеспечивая наиболее эффективное использование ресурсов и оперативную реакцию на изменение нагрузки. Теоретически, нагрузка на компонент может быть перенесена на наиболее подходящую для решения задачи платформу. Данная миграция может быть выполнена полностью независимо от остальных компонентов с целью получить преимущество за счет правильного размещения в сети. Хорошо написанные микросервисы предлагают экстраординарные возможности по масштабируемости, что продемонстрированно первыми "ласточками" в данной области. Такие микросервисы так же способны воспользоваться преимуществами эластичности cloud-native окружений, которые имеют очень эффективный с точки зрения цены доступ к огромным ресурсам.

  • Устойчивость. Отельные пространства исполнения немедленно обеспечивают независимую от падений других компонентов системы устойчивость. Вместе с аккуратно выполненным разделением системы на компоненты, в частности если избегается привнесение синхронных зависимостей и с использованием паттернов circuit breaker, каждый микросервисный компонент может быть разработан так, чтобы выполнять требования к собственной доступности без необходимости выставлять требования к другим компонентам приложения. Различные технологии, такие как контейнеры и легковесные среды исполнения, позволяют микросервисам переживать падения быстро и независимо друг от друга без необходимости перезапуска частей, не имеющих отношения к реализации заданной функциональности. В равной степени микросервисы обычно реализуются в модели без сохранения состояния (stateless), так что нагрузка может быть немедленно ребалансирована, а новые экземпляры среды исполнения - внезапно подняты.

Данные примеры преимуществ являются причиной того, почему организации поворачиваются лицом к микросервисам.

Ключевые факторы, влияющие на принятие решения об использовании микросервисов


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


  • Новые технологически паттерны. Микросервисы - это радикально иной подход к построению приложений. Поскольку они основаны на сетевом взаимодействии, то требуют наличия полностью иного множества компонентов в сети предприятия бок о бок с ними. Соответствующие технологии, такие как обнаружение сервисов (service discovery), оркестровка рабочей нагрузки, управление контейнерами и фреймворки для логирования, уже существуют, но их требуется объединить вместе, что требует значительных сил на экспериментирование, обучение и наработку соответствующих навыков. Вам необходимо определить, что составляет наилучший ландшафт для микросервисов для удовлетворения ваших требований, и эти компоненты могут быть иными, нежели подходящие другим предприятиями.


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

    Если не для старых или новых приложений, так для каких же использовать микросервисы? Рекомендацией может быть не использовать микросервисы до тех пор, пока развитие традиционно разрабатываемого приложения не достигнет некоторого порога сложности. Однако, чтобы применить данных подход, приложения должно сразу структурироваться подходящим образом, чтобы в один прекрасный момент можно было осуществить переход к микросервисам.


  • Различные парадигмы дизайна. Микросервисная архитектура приложений требует других подходов к дизайну. Чтобы получить наилучший результат от использования микросервисов может потребоваться следующее:
    • Применить модель согласованности в конечном счете (eventual consistency) взамен традиционного транзакционного взаимодействия.
    • Понимать как работать с приложениями, основанными на источниках событий (event-sourced) без центрального хранилища оперативной информации.

    Также следует обратить внимание на обеспечение:

    • Гарантии того, что логика приложения не зависит от состояния, что необходимо для получения преимуществ от возможности микросервисов неограниченно масштабироваться.

    • Учета коварных возможных побочных эффектов асинхронной коммуникации, что важно, если принято решение уйти от последовательного вызова компонентов.

    • Понимания влияния на логику реализации паттернов circuit breaker.

    • Осознавания ограничений на обработку ошибок, заложенных в коммуникацию посредством HTTP/JSON в отличие от взаимодействия в границах отдельного процесса операционной системы.

    • Рассмотрения влияния латентности сетевого взаимодействия на цепочку вызовов.

  • Зрелость DevOps. Микросервисы требуют довольно зрелых возможностей по своей доставке потребителю. Непрерывная интеграция, развертывание и полностью автоматическое тестирование крайне необходимы. Разработчики, которые пишут код, обязаны отвечать за его работу в продуктиве. Цепочки сборки и развертывания требуют существенных изменений для того, чтобы обеспечивать верное разделение зон ответственности для микросервисного окружения.

Если данные факторы вам подходят, то вы можете получить большие преимущества от использования микросервисной архитектуры.

Место микросервисов на картине SOA и проблем интеграции


В нашей ментальной модели, когда SOA сфокуссирована на интеграционных аспектах, микросервисы являются полностью отдельной идеей. Микросервисы - это альтернативный способ написания программы, к которой интеграционная архитектура лишь пробует подключиться, как показано на рис. 1.

Однако, если наша ментальная модель SOA сфокуссирована на перемещении приложений в более понятные бизнесу "сервисные компоненты", то такие компоненты, отображенные в правой части рис. 2, становятся похожими на микросервисы. Микросервисная архитектура в таком случае может выглядеть как эволюция SOA. Чтобы проиллюстрировать данную точку зрения, давайте сравним два конца данного спектра.

Прежде всего, рассмотрим новую старт-ап компанию, реализующую идею полностью онлайн продукта, такого как социальная сеть или торговая платформа. Поскольку компания стартует без существующие архитектуры, то она должна создать набор новых приложений для создания уникальных аспектов своего бизнеса. Она может выбрать вариант отдать на оутсорсинг те части бизнеса, которые не являются основными генераторами ценности, а также использовать software-as-a-service (SaaS) приложения, например приложение для управления отношениями с клиентами (CRM).

Ландшафт компании может быть в основном создан с чистого листа. Основной фокус может быть сделан на возможности быстро добавить новые функции с минимальным временем простоя в постоянно доступном окружении. Компания может хотеть масштабироваться эластично (при этом как вверх, так и вниз) в соответствии с непредсказуемыми потребностями клиентов. Она может хотеть обеспечивать круглосуточное, устойчивое и высоко доступное присутствие в онлайне.

Микросервисная архитектура при таких условиях является логичным выбором для ландшафта большинства компаний, что показано на рис. 6.


Рисунок 6. Микросервисная архитектура при внедрении с чистого листа

Эти новые приложения могут жить в пределах единого микросервисного фреймворка, обеспечивающего соответствие нефункциональным требованиям, таким как масштабируемость, доступность и управление ресурсами. Можно ожидать минимизации вопросов, касающихся интеграции, поскольку все микросервисные компоненты, как и участвующие SaaS-приложения, используют для связи общепринятые протоколы, например HTTP/JSON. Одной из важных причин выставления SOA ценной функциональности является возможность ее комбинирования и объединения в рамках предприятия. В таком случае, линия между верно-реализованной SOA и микросервисной архитектурой становится размытой. Если представить себе идеальную реализацию SOA, то она может очень сильно походить на представленный пример, однако только новые компании могут создать такое в гомогенной архитектуре.

В рамках данной статьи не рассматривается, является ли "сервисный компонент" SOA эквивалентным по размеру микросервисному компоненту. Гранулярность микросервисных компонентов и как они группируются, является темой совсем другого спора.

Теперь рассмотрим противоположный пример крупного предприятия, которое выращивало и приобретало свой IT-ландшафт десятилетиями. Данное предприятия, которое может являться традиционным банком или страховой компанией, может иметь сотни или даже тысячи важных приложений, построенных на технологиях, прошедших пик своего развития десятилетия назад. Предприятие может иметь строго выделенные подразделения внутри себя, такие как страхование жизни, пенсионное или общее, или розничный и отдельно инвестиционный банкинг. Каждое бизнес-подразделение может иметь независимые приложения, поддерживающие его основной бизнес. Так же подразделения могут иметь приложения, например, для управления персоналом, которые являются общими везде, где это возможно.

Компания развивается путем слияния и поглощения конкурентов. Внутри такого ландшафта можно обнаружить множество дублирования данных между приложениями. Счета клиентов могут быть размазаны по многим системам в зависимости от того, в какой компании они изначально заводились. Прямая корреляция между записями об одном и том же клиенте, но заведенными в разных системах, может отсутствовать. Вообще, такие бэк-энд приложения очень трудно изменять внутри. В данном окружении, SOA имеет гигантские задачи по превращению систем бэк-энда в нечто, что будет более подходящим для реализации требований бизнеса в будущем.

Интеграционная задача так же является сложной. Она может быть делегирована интеграционным утилитам, как показано на рис. 7, с целью обеспечения доступа к данным и функциональности систем бэк-энда несмотря на сложности с протоколами, транспортом или форматами данных. В основном по историческим причинам, данное упражнение часто также называют SOA, хотя оно имеет отношение лишь к половине проблемы построения 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 gateways на рис. 8. Данный слой контроля - это эволюция концепции выставления сервисов из SOA. Данная концепция преобразовалась в более широкое и децентрализованное выставление API.

API gateway и управление API могут являться общим ресурсом предприятия. Они "децентрализованы" в том понимании, что отдельные команды, занимающиеся разработкой приложений, должны иметь возможность самостоятельно публиковать API и подписываться на те API, которые им нужны, без необходимости привлечения какой-то отдельной команды. Вы можете получить преимущества от использования стандартных механизмов управления трафиком, мониторинга, логирования, аудита и безопасности в пределах всего предприятия при сохранении требуемой бизнесу гибкости. Те же самые API gatways могут также помочь обеспечить управляемое взаимодействие с бизнес-партнерами и внешними возможностями SaaS.

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

Традиционные, более разрозненные приложения продолжают быть подходящими для части реализаций. Тем не менее, микросервисы обеспечивают альтернативный подход к построению некоторых классов приложений, предоставляя гибкость, масштабируемость и устойчивость, недостижимую при использовании традиционных приложений. Микросервисные приложения наиболее распространены в слое взаимодействия с пользователем (engagement layer), т.е. там, где их специфические характеристики наиболее необходимы, позволяя создавать новые соответствующие реализуемому каналу взаимодействия возможности и выставленные в Интернет API.

Выводы


Существуют как минимум два различных взгляда на то, для достижения каких целей служила SOA. Прямое сравнение SOA и микросервисной архитектуры по-прежнему сопряжено с трудностями. Концепции SOA присутствуют в современных архитектурах, но развились по разным направлениям. Интеграционные утилиты, паттерны и стандарты
эволюционировали таким образом, что функциональность и данные приложений стало гораздо проще выдавать на поверхность. Выставление сервисов преобразовалось в API, тем самым существенно упростив публикацию, подписку, управление и, в некоторых случаях, монетизацию бизнес-функций. Новые архитектуры приложений, включая микросервисную архитектуру, позволяют разработчикам еще больше сфокусироваться на бизнес-логике, не отвлекаясь на детали окружения, в котором приложения будут работать. Комбинирование данных подходов позволяет строить решения в более гибком стиле и получать преимущества от эластичной масштабируемости и готовности к сбоям совершенно нового уровня.

Благодарности


Автор благодарит своих коллег за помощь в подготовке материалов к данной статье: Andy Garratt, Andy Gibbs, Carlo Marcoli и Brian Petrini.

Ресурсы



Понравилось сообщение - подпишитесь на блог
Темы: , , , , ,

2 комментария:

Pavel Vinogradov комментирует...

Отличная статья, хорошо все расставляет на свои месте.

Мне вот только подумалось, что SOA принесла нам возможность сделать новый фасад над старым зданием и представить что все хорошо. В то время как в самом здании по-прежнему течет крыша, дыры в полу и ветер в щелях. Но снаружи это выглядит как сервисы, а теперь еще и API.

Microservices это как способ переписать существующие приложения с учетом новых трендов, возможностей и паттернов. Что в результате должно позволить лучше использовать возможности предоставляемые современными *aaS.

21 мая 2017 г. в 10:02
Unknown комментирует...

Да, все так, а потом придет новый Со, ой Фаулер, и скажет, что ваши микросервисы - прошлый век и пора делать ренновацию.

21 мая 2017 г. в 13:31

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!

Подписаться на: Комментарии к сообщению (RSS)