Roman Dynnik's Professional Blog

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

by Roman Dynnik 23 min read

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

Опубликовано 21 января 2016 года
Автор: Ким Кларк
Перевод: Роман Дынник
«««< HEAD Статья является моим вариантом перевода одноименной статьи Кима Кларка
Microservices, SOA, and APIs: Friends or enemies?”
A comparison of key integration and application architecture concepts for an evolving enterprise

В заключении, основываясь на материалах этой статьи и других источниках, а также на личном опыте, я представляю собственные выводы и видение касательно развития и совместного использования этих подходов применительно к банковской отрасли (см. Заключение от переводчика). ======= Эта статья является моим вариантом перевода одноименной статьи Кима Кларка
Microservices, SOA, and APIs: Friends or enemies?”
A comparison of key integration and application architecture concepts for an evolving enterprise В конце, основываясь на материалах этой статьи и других источников / авторов и личном опыте, я представляю собственные выводы и видение касательно совместного использования этих подходов в банковской отрасли (см. Заключение от переводчика).

Update 2017-07-07-microservices-soa-api.md

Содержание

Введение
Сверх упрощенное представление
Двойственная природа SOA-инициатив
Как API соотносится с выставленными SOA-сервисами
Микросервисы: альтернативная архитектура
Преимущества микросервисов
Ключевые факторы, которые следует учитывать при выборе микросервисного подхода
Как микросервисы соответствуют структуре SOA и задачам интеграции
Комбинирование микросервисов, SOA и API в будущем
Заключение
Заключение от переводчика
Благодарности
Ресурсы

Введение

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

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

Сверх упрощенное представление

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

Рассмотрим следующие простые определения:

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

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

На Рисунке 1 представлены эти определения. SOA представляется как задание границ предприятия, где приложения обмениваются данными друг с другом. SOA выставляет сервисы через стандартизированные интерфейсы между приложениями. Архитектура микросервисов проявляется как задание границ для приложения, с уделением особого внимания структуре и компонентам в приложении.

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

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

Двойственная природа SOA-инициатив

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

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

Первое представление включает в себя необходимость глубокой интеграции существующих систем поверх их сложных и часто проприетарных форматов данных, протоколов и транспорта. Затем необходимо выставить их, используя стандартизированные механизмы (например, SOAP / HTTP или модные JSON / HTTP), чтобы упростить их повторное использование в новых приложениях. Это представление показано в левой части Рисунка 2. Некоторое или все эти представления часто упоминаются как шаблон Enterprise Service Bus (ESB). Однако этот термин используется без разбора, что обесценивает его.

Необходимость сделать глубокую интеграцию (через интеграционный хаб и адаптеры), а также выставить возможности как сервисы или API стандартизированным способом (через внешний шлюз) здесь наиболее важна. Этот аспект показывает все что связано с проблемами интеграции и мало связано с дизайном приложения. Следовательно, он, по-видимому, мало связан с микросервисной архитектурой приложений.

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

Второе представление - это точка зрения бизнеса. Вызывает беспокойство то, что интерфейсы существующих систем в значительной степени бесполезны. Они не имеют смысла для бизнеса, и они не обеспечивают то, что необходимо для приложений следующего поколения. Они могут быть слишком гранулярными, выставляя слишком много сложных моделей данных(контрактов), используемых внутри систем. Необходимые данные могут распространяться на несколько систем. Модели данных могут не соответствовать терминологии, используемой бизнесом. Необходим функциональный рефакторинг чтобы выявить то, что бизнес может действительно использовать при построении будущих решений. Этот рефакторинг требует создания новых приложений чтобы связать вместе запросы к существующим учетным системам (system of record). В эталонной архитектуре SOA эти приложения часто назывались сервисными компонентами (справа на Рисунке 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-программах выставление сервиса заключалось в том, чтобы выставить каждую бизнес-функцию так, чтобы ее можно было повторно использовать в максимально возможной степени. Таким образом, каждый новый проект не должен был испытывать снова боль, связанную с повторной интеграцией с бэкенд системой. Типичными потребителями были внутренние приложения, которые пытались “натянуть” новые пользовательские интерфейсы на старые учетные системы (system of record). В это время интеграция была сложной и занимала значительную часть бюджета IT-проекта. Если бы вы могли сделать все основные функции компании доступными через интерфейсы многократного использования, вы могли бы значительно сократить затраты на проект. Идея SOA была о сокращении затрат, а не о получении нового дохода.

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

Появление управления API

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

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

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

Рисунок 3. Выставление(публикация) внутреннего и внешнего API

Сегодня термин API обычно используется для обозначения любого интерфейса, который выставлен поверх REST (HTTP / JSON) или веб-сервиса (SOAP / HTTP). API-интерфейсы обычно классифицируются по их границам, таким как публичный API или корпоративный API. Предприятия, поддерживающие инициативы SOA, иногда сохраняют термин «сервис» для внутренних, общекорпоративных API. Дополнительные сведения о различиях между SOA и API см. в разделе Архитектура Интеграции: Cравнение Web API с сервис-ориентированной архитектурой и интеграцией корпоративных приложений.

Термин API представляет собой эволюцию аспекта «выставление сервиса» SOA. Он использует более простые протоколы и обеспечивает большее совершенство вокруг самой экспозиции, что включает портал для разработчиков, средства управления политиками и самообслуживание.

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

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

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

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

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

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

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

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

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

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

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

Отказоустойчивость: Разделение среды времени исполнения сразу же обеспечивает отказоустойчивость, которая не зависит от сбоев в других компонентах. Благодаря аккуратному слабосвязаному дизайну, такому, который позволяет избегать синхронных зависимостей и использованию шаблона Circuit Breaker (автоматический прерыватель), каждый компонент микросервиса может быть написан так, чтобы соответствовать своим требованиям по доступности без навязывания этих требований всему домену приложения. Технологии, такие как контейнеры и легковесная среда времени исполнения, позволили микросервисным компонентам быстро и независимо завершаться (и перезапускаться), вместо того чтобы “тушить” целые области несвязанной функциональности. Также, они написаны так, что не хранят состояния (stateless), поэтому они могут немедленно перераспределять рабочую нагрузку и почти мгновенно поднимать новые среды времени исполнения.

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

Ключевые факторы, которые следует учитывать при выборе микросервисного подхода

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

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

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

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

Различные парадигмы дизайна. Архитектура микросервисного приложения требует различных подходов к проектированию. Чтобы получить наилучшие результаты от микросервисного подхода, вам может потребоваться:

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

Вам также необходимо:

  • Убедиться, что ваша прикладная логика освобождена от хранения состояния (stateless), если ей необходимо воспользоваться преимуществами быстрой масштабируемости.
  • Быть знакомым с неуловимыми потенциальными побочными эффектами асинхронной связи, если вы отвяжете себя от нижележащих компонентов
  • Понять логические последствия реализации шаблона автоматического прерывателя (Circuit Breaker).
  • Признать ограничения обработки ошибок в сообщениях HTTP / JSON по сравнению с внутри процессным взаимодействием.
  • Принять во внимание сетевые задержки в цепочках взаимодействия.

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

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

Как микросервисы соответствуют структуре SOA и задачам интеграции

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

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

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

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

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

Рисунок 6. Архитектура микросервисов в зоне “чистого поля” / “green field”

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

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

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

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

Задача интеграции также сложна. Она может использовать инструменты интеграции, как показано Рисунке 7, чтобы обеспечить доступ к данным и функциям из внешних приложений, несмотря на сложности с протоколами, транспортом и форматами данных. По историческим причинам это интеграционное упражнение часто обозначается как «SOA», хотя оно сосредоточено только на половине проблем SOA. Оно обозначается как SOA, поскольку интеграция - это первая область которой занимаются большинство инициатив SOA. Во многих случаях это все чего она (SOA инициатива) достигает с помощью имеющегося финансирования.

Рисунок 7. Крупное предприятие с микросервисами как часть ландшафта

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

Привлекательность использования архитектуры микросервисов для этих новых приложений легко увидеть. Как показано на Рисунке 7, первоначальное использование микросервисов на крупных предприятиях сосредоточено на новых приложениях, связанных с вовлечением (system-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-шлюзы могут также использоваться для управления взаимодействием с бизнес-партнерами и внешними возможностями SaaS.

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

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

Заключение

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

Заключение от переводчика

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

Микросервисный подход – это эволюция SOA, а не революция.

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

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

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

Префикс «микро» в микросервисе относится к гранулярности внутренних компонентов, а не к гранулярности выставляемых(открытых) интерфейсов.

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

Оркестровку внутри границ микросервисного приложения (между микросервисными компонентами одного приложения) или технологическими микросервисными компонентами, эффективнее будет переложить на прямые REST-вызовы или специализированные фреймворки типа OpenWhisk, NodeRed, в то время как оркестровка четко выделенных бизнес-интерфейсов в бэкенде остается задачей решений класса ESB или ESB+BPM ввиду необходимости интеграции поверх множества различных протоколов и транспортов (XML, SOAP, JMS, MQ …), используемых зрелыми решениями от поставщиков банковского ПО, а также для обеспечения заданного уровня SLA в рамках ITSM-процессов.

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

Исключением является слой канальных приложений (system of engagement), за разработку и поддержку которых в настоящее время все чаще отвечают внутренние подразделения банков. Здесь целиком применим и оправдан микросервисный подход как для разработки (декомпозиции)/рефакторинга этих приложений, так и для оркестровки их возможностей в рамках бизнес-сценария и развертывания в специализированной PaaS-среде. Связь канальных приложений с бэкэндом все также будет осуществляться через шлюзы безопасности и транспорт на основе очередей сообщений.

Можно выделить два типа систем, предоставляющих внешние бизнес-интерфейсы, условно называемые мной Internal Managed Application и External Managed Application. Принцип, который можно сформировать в этом контексте звучит следующим образом:

Если сквозной бизнес-сценарий, ограниченный некоторым слоем, например слоем канальных приложений, не предполагает использования бизнес-возможностей, разрабатываемых и управляемых внешним поставщиком (External Managed Application), то есть все бизнес-возможности предоставляются приложениями типа Internal Managed Application, то оркестровка такого бизнес-сценария может быть выполнена целиком в рамках микросервисного подхода, в том числе и в бэкенде. При этом, при принятии решения, следует учитывать потенциальное требование замены некоторой бизнес-возможности (так например, потенциально, со стороны бизнеса или архитектурным коммитетом, может быть принято решение о замене возможностью от внешнего поставщика, то есть приложением типа External Managed Application).

Полностью микросервисный подход также применим для интеграции бизнес-возможностей канальных приложений с внешними по отношению к банку SaaS-решениями. Хотя по определению SaaS-решение можно отнести к External Managed Application, здесь по природе, как правило, уже существует необходимая среда и используются только простые протоколы взаимодействия (без сложной трансформации и маршрутизации) на основе REST.

Необоснованное же, непродуманное и неограниченное никакими рамками и архитектурными принципами использование микросервисного подхода может стать “адом” для служб поддержки и эксплуатации.

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

Теперь взгляните еще раз на рисунок в заголовке моего поста – он выбран не случайно. Листья внутри, подобно микросервисным приложениям, имеют сложную проводящую систему, но они не срастаются вместе. Вместо этого они имеют черешок (наподобие внешнего бизнес-интерфейса), через который получают питательные вещества от нижележащей системы ветвей и ствола (наподобие решений ESB и BPM, уже используемых в SOA). Все это позволяет этой сложной системе расти и процветать. Однако, вы можете попробовать сорвать эти листья и связать их вместе в букет, и он, возможно, даже простоит у вас дней пять.

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

Спасибо следующим людям за их вклад и ревью материала этой статьи: Энди Гаррату, Энди Гиббсу, Карло Марколи и Брайану Петрини.

Ресурсы

Информация о микросервисах, API и SOA от developerWorks :