Что такое сервис-ориентированная архитектура?

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

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

Каковы преимущества сервис-ориентированной архитектуры?

Сервис-ориентированная архитектура (SOA) имеет ряд преимуществ перед традиционными монолитными архитектурами, в которых все процессы выполняются как единое целое. Вот некоторые из преимуществ SOA:

Сокращение времени выхода на рынок

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

Эффективное обслуживание

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

Улучшенная адаптивность

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

Какие основные принципы сервис-ориентированной архитектуры?

Не существует четко определенных стандартных рекомендаций по реализации сервис-ориентированной архитектуры (SOA), однако есть некоторые общие основные принципы.

Обеспечение совместимости

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

Слабая взаимозависимость

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

Абстрагирование

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

Степень детализации

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

Из каких компонентов состоит сервис-ориентированная архитектура?

Существует четыре основные компонента сервис-ориентированной архитектуры.

Обслуживание

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

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

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

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

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

Потребитель сервиса

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

Сервисный реестр

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

Как работает сервис-ориентированная архитектура?

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

Протоколы передачи данных

Сервисы взаимодействуют с использованием установленных правил, определяющих передачу данных по сети. Эти правила называются протоколами передачи данных. Некоторые стандартные протоколы для реализации SOA:

• Простой протокол доступа к объектам (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Служба сообщений Java (JMS)

Вы даже можете использовать более одного протокола в своей реализации SOA.

Что такое ESB в сервис-ориентированной архитектуре?

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

Преимущества ESB

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

Каковы ограничения при внедрении сервис-ориентированной архитектуры?

Ограниченные возможности масштабирования

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

Усиление взаимозависимости

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

Единая точка отказа

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

Что такое микросервисы?

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

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

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

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

Сравнение SOA с микросервисами

Архитектура микросервисов – это эволюция архитектурного стиля SOA. Микросервисы устраняют недостатки SOA и делают программное обеспечение более совместимым с современными облачными корпоративными средами. Они являются легко управляемыми и благоприятствуют дублированию данных в противовес обмену данными. Это делает их полностью независимыми с их собственными протоколами связи, которые открываются через облегченные API. По сути потребители должны использовать микросервис через его API, что устраняет необходимость в централизованном ESB.

Как AWS поможет вам реализовать микросервисы?

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

• Создавать, изолировать и запускать безопасные микросервисы в управляемых контейнерах для упрощения операций и снижения накладных расходов на управление.
• Использовать AWS Lambda для запуска ваших микросервисов без инициализации и управления серверами.
• Выбирать из 15 реляционных и нереляционных баз данных AWS, специально созданных для поддержки архитектуры микросервисов.
• Легко отслеживать и контролировать микросервисы, работающие на AWS, с помощью AWS App Mesh.
• Отслеживать и устранять неполадки сложных взаимодействий микросервисов с AWS X-Ray.

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

Сервис-ориентированная архитектура AWS: следующие шаги

Дополнительные ресурсы по продукту
Подробнее о сервис-ориентированной архитектуре 
Зарегистрировать бесплатный аккаунт

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

Регистрация 
Начать разработку в консоли

Начните разработку с использованием AWS в консоли управления AWS.

Вход