Содержание


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

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

Comments

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

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

Упрощенная картина

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

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

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

Эти определения наглядно продемонстрированы на рисунке 1 .Область охвата SOA — это это все предприятие, где происходит взаимодействие между приложениями. SOA предоставляет сервисы для приложений посредством стандартизированных интерфейсов . Архитектура микросервисов ориентирована на структуру и компоненты отдельного приложения .

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

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

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

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

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

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

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

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

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

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

Рисунок 2. Представление SOA с технической и функциональной точек зрения
Представление SOA с технической и функциональной точек зрения
Представление 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
Внутренний и внешний экспорт API
Внутренний и внешний экспорт API

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

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

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

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

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

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

Логическое разделение компонентов внутри приложения не является новой идеей. Со временем появилось множество различных технологий, обеспечивающих строгое разделение отдельных частей целого приложения. На серверах приложений в течение долгого времени может выполняться несколько компонентов приложения, как показано на второй схеме рисунка 5.Микросервисы пошли еще дальше, обеспечивая абсолютную изоляцию между этими компонентами приложения. На правой схеме рисунка 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
Комбинация микросервисов, SOA и API
Комбинация микросервисов, 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.

Ресурсы


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


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1050558
ArticleTitle=Микросервисы, SOA и API: друзья или враги?
publish-date=10032017