что такое сервис ориентированная архитектура
Сервисно-ориентированная архитектура
Се́рвис-ориенти́рованная архитекту́ра (англ. модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами.
В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции.
Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (WSDL, и т. п.)
Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределённых программных комплексов.
Содержание
Определение SOA
OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.
Введение
Для крупных информационных систем, уровня предприятия, и выше:
Принципы SOA
Другие SOA-Концепции
Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как RPC, DCOM, веб-сервисы. SOA может быть реализована используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.
Главное, что отличает SOA, это использование независимых сервисов, с чётко определёнными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например,
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или
Языки высокого уровня, такие как порталов.
См. также
Ссылки
Разработка программного обеспечения
Модели разработки: Гибкая методология разработки • Cleanroom • Итеративная разработка • RUP • Scrum • MSF • Спиральная модель • Модель водопада • XP • : CMMI • Модель данных • Function model • UML
деятели
статьи
Полезное
Смотреть что такое «Сервисно-ориентированная архитектура» в других словарях:
Сервисно-ориентированная архитектура баз данных — Сервис ориентированная архитектура баз данных развитие архитектуры SOA. База данных является хранилищем сообщений, промежуточных состояний, метаинформации об очередях сообщений и сервисах. Отправка сообщений в очередь и прием сообщений из… … Википедия
1С:Сеть — является EDI сервисом компании 1С, встроенным в программные продукты 1С и представляет собой попытку решения дилеммы EDI: легкость подключения выгода от эксплуатации. Идея сервиса 1С:Сеть состоит в том, чтобы встроив подключение к EDI в каждую… … Википедия
СОА — Сервис ориентированная архитектура (англ. модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами. В основе SOA лежат принципы многократного использования… … Википедия
ООАП — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия
Объектно-ориентированный подход — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия
TQM — Всеобщее управление качеством (англ. Total Quality Management, TQM) общеорганизационный метод непрерывного повышения качества всех организационных процессов. Содержание 1 История 2 Что такое Всеобщее управление качеством 3 … Википедия
Soft — Запрос «Software» перенаправляется сюда. Cм. также другие значения. Программное обеспечение (произношение обеспечение не рекомендуется[1][2][3], точнее, не рекомендовалось[4]) наряду с аппаратными средствами, важнейшая составляющая информационных … Википедия
Software — Запрос «Software» перенаправляется сюда. Cм. также другие значения. Программное обеспечение (произношение обеспечение не рекомендуется[1][2][3], точнее, не рекомендовалось[4]) наряду с аппаратными средствами, важнейшая составляющая информационных … Википедия
Total Quality Management — Всеобщее управление качеством (англ. Total Quality Management, TQM) общеорганизационный метод непрерывного повышения качества всех организационных процессов. Содержание 1 История 2 Что такое Всеобщее управление качеством 3 … Википедия
Компьютерное программное обеспечение — Запрос «Software» перенаправляется сюда. Cм. также другие значения. Программное обеспечение (произношение обеспечение не рекомендуется[1][2][3], точнее, не рекомендовалось[4]) наряду с аппаратными средствами, важнейшая составляющая информационных … Википедия
Лучшая архитектура для MVP: монолит, SOA, микросервисы или бессерверная. Часть 1
В ноябре OTUS запускает новую образовательную программу «Архитектор ПО», в связи с этим подготовили серию публикаций для будущих студентов курса и читателей нашего блога.
Создание нового продукта всегда связано с риском. И выбор правильной архитектуры — важный шаг на пути успеху. Если вы выбираете между монолитной, сервис-ориентированной, микросервисной и бессерверной архитектурой, этот пост поможет вам сделать правильный выбор.
Монолитная архитектура
Монолит — это древнее слово, обозначающее огромный каменный блок. Хотя этот термин широко используется сегодня, представление остается одинаковым во всех областях. В программной инженерии монолитная модель относится к единой неделимой единице. Концепция монолитного программного обеспечения заключается в том, что различные компоненты приложения объединяются в одну программу на одной платформе. Обычно монолитное приложение состоит из базы данных, клиентского пользовательского интерфейса и серверного приложения. Все части программного обеспечения унифицированы, и все его функции управляются в одном месте. Давайте посмотрим на структуру монолитного программного обеспечения в деталях.
Монолитная архитектура удобна для работы небольших групп, поэтому многие стартапы выбирают этот подход при создании приложения. Компоненты монолитного программного обеспечения взаимосвязаны и взаимозависимы, что помогает программному обеспечению быть самодостаточным. Эта архитектура является традиционным решением для создания приложений, но некоторые разработчики считают ее устаревшей. Тем не менее, мы считаем, что монолитная архитектура является идеальным решением при некоторых обстоятельствах.
Несмотря на то, что у нас был положительный опыт использования микросервисов в Google, мы [в Scaylr] пошли по монолитному маршруту, потому что наличие одного монолитного сервера предполагает меньше работы для нас как для двух инженеров.
Стивен Червински, руководитель отдела проектирования в Scaylr
Чтобы выяснить, подходит ли это решение для вашего бизнеса, давайте рассмотрим его плюсы и минусы.
Плюсы монолитной архитектуры
Упрощенная разработка и развертывание
Есть много инструментов, которые вы можете интегрировать для облегчения разработки. Кроме того, все действия выполняются с одним каталогом, что упрощает развертывание. Благодаря монолитному ядру разработчикам не нужно развертывать изменения или обновления по отдельности, поскольку они могут сделать это сразу и сэкономить много времени.
Меньше сквозных проблем
Большинство приложений зависят от множества межкомпонентных задач, таких как контрольные журналы, ведение логов, ограничение скорости и т. д. Монолитные приложения гораздо легче учитывают эти вопросы благодаря своей единой кодовой базе. К этим задачам проще подключать компоненты, когда все работает в одном приложении.
Лучшая производительность
При правильной сборке монолитные приложения обычно более производительны, чем приложения на основе микросервисов. Например, приложению с микросервисной архитектурой может потребоваться выполнить 40 вызовов API для 40 различных микросервисов чтобы загрузить каждый экран, что, очевидно, приводит к снижению производительности. Монолитные приложения, в свою очередь, обеспечивают более быструю связь между программными компонентами благодаря общему коду и памяти.
Минусы монолитной архитектуры
Кодовая база со временем становится громоздкой
С течением времени большинство продуктов продолжают разрабатываться и увеличиваются в объеме, а их структура становится размытой. Кодовая база начинает выглядеть действительно громоздко и становится трудной для понимания и изменения, особенно для новых разработчиков. Также становится все труднее находить побочные эффекты и зависимости. С ростом кодовой базы ухудшается качество и перегружается IDE.
Сложно внедрять новые технологии
Если в ваше приложение необходимо добавить какую-то новую технологию, разработчики могут столкнуться с препятствиями для на пути внедрения. Добавление новой технологии означает переписывание всего приложения, что является дорогостоящим и требует много времени.
Ограниченная гибкость
В монолитных приложениях каждое небольшое обновление требует полного повторного развертывания. Таким образом, все разработчики должны ждать, пока это не будет сделано. Когда несколько команд работают над одним проектом, гибкость может быть значительно снижена.
В итоге
Монолитная модель не устарела, и в некоторых случаях она по-прежнему прекрасно работает. Некоторые гигантские компании, такие как Etsy, остаются монолитными, несмотря на сегодняшнюю популярность микросервисов. Архитектура монолитного программного обеспечения может быть полезной, если ваша команда находится на начальной стадии, вы создаете непроверенный продукт и не имеете опыта работы с микросервисами. Монолит идеально подходит для стартапов, которым необходимо как можно быстрее запустить продукт в эксплуатацию. Однако некоторые проблемы, упомянутые выше, идут рука об руку с монолитной архитектурой.
Сервис-ориентированная архитектура (далее SOA — service-oriented architecture) — это стиль архитектуры программного обеспечения, который предполагает модульное приложение, состоящее из дискретных и слабосвязанных программных агентов, которые выполняют конкретные функции. SOA разделяет компоненты по двум основным ролям: поставщик и потребитель сервисов. Обе эти роли могут играть программные агенты. Концепция SOA заключается в следующем: приложение может быть спроектировано и построено таким образом, что его модули легко интегрируются и могут быть легко использованы повторно.
Плюсы SOA
Повторное использование сервисов
Из-за автономной и слабо связанной природы функциональных компонентов в сервис-ориентированных приложениях эти компоненты можно повторно использовать в нескольких приложениях, без влияния на другие сервисы.
Легкость в сопровождении
Поскольку каждая служба программного обеспечения является независимой единицей, ее легко обновлять и поддерживать, не затрагивая другие службы. Например, крупными корпоративными приложениями легче управлять, когда они разбиты на службы.
Более высокая надежность
Службы легче отлаживать и тестировать, чем огромные куски кода, как в монолитах. Это, в свою очередь, делает продукты на основе SOA более надежными.
Параллельная разработка
Поскольку сервис-ориентированная архитектура разбита на прослойки, она поддерживает параллелизм в процессе разработки. Независимые сервисы могут разрабатываться параллельно и быть завершены одновременно.
Минусы SOA
Сложность в управлении
Основным недостатком сервис-ориентированной архитектуры является ее сложность. Каждый сервис должен обеспечивать своевременную доставку сообщений. Количество этих сообщений может превышать миллион за один раз, что затрудняет управление всеми службами.
Высокие инвестиционные затраты
Разработка SOA требует значительных предварительных инвестиций в человеческие ресурсы, технологии и разработку.
Дополнительная нагрузка
В SOA все входные данные проверяются до того, как один сервис взаимодействует с другим сервисом. При использовании нескольких сервисов это увеличивает время отклика и снижает общую производительность.
В итоге
SOA лучше всего подходит для сложных корпоративных систем, например банковских. Банковскую систему чрезвычайно сложно разделить на микросервисы. Но монолитный подход также не годится для банковской системы, так как одна часть может повредить все приложение. Лучшее решение — использовать подход SOA и организовать сложные приложения в изолированные независимые сервисы.
На этом мы завершаем первую часть перевода, а о микросервисах и бессерверной архитектуре поговорим во второй части материала.
Сервис-ориентированная архитектура (SOA)
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
Общая архитектура брокера объектных запросов (CORBA)
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Принцип работы
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
Достоинства
Недостатки
Веб-сервисы
Хотя сегодня можно найти применение для CORBA, но мы знаем, что нужно было уменьшить количество удалённых обращений, чтобы повысить производительность системы. Также требовался надёжный канал связи и более простая спецификация обмена сообщениями.
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
— Microsoft 2004, Understanding Service-Oriented Architecture
Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.
Но нужно понимать, что в рамках SOA веб-сервисы — не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила. SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
— Microsoft 2004, Understanding Service-Oriented Architecture
Достоинства
Недостатки
Очередь сообщений
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения, сколько их и даже что они собой представляют. Однако все эти приложения должны использовать один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:
Запрос/Ответ
Все эти паттерны можно отнести к либо к pull- (polling), либо к push-подходу:
Достоинства
Недостатки
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
Создавая структуры связи между разными процессами, мы видели много продуктов и подходов, в которых применяются очень развитые механизмы связи. Хороший пример — сервисные шины предприятий, часто включающие в себя сложные средства маршрутизации сообщений, хореографии, преобразования и применения бизнес-правил.
— Martin Fowler 2014, Microservices
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.
Достоинства
Недостатки
Микросервисы
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений, чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат», и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту — уменьшению потребности в интеграции.
[Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
— Sam Newman 2015, Principles Of Microservices
Главным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной связи между микросервисами до сих пор применяется очередь сообщений, но это лишь канал для передачи сообщений, не более того. Или можно вспомнить шлюз экосистемы микросервисов, через который проходит весь внешний обмен данными.
Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры. Это:
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
— Martin Fowler 2014, Microservices
Достоинства
Недостатки
Антипаттерн: архитектура равиоли (Ravioli Architecture)
Архитектурой равиоли обычно называют антипаттерн микросервисной архитектуры. Равиоли получаются, если микросервисов слишком много, они слишком мелкие и не отражают доменных концепций.
Заключение
В последние десятилетия SOA сильно эволюционировала. Благодаря неэффективности прежних решений и развитию технологий сегодня мы пришли к микросервисной архитектуре.
Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.
Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развёртывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.
Повторюсь, что всё дело в слабой взаимозависимости и высокой связности, причём размер компонентов должен быть больше прежнего. Необходимо прагматично оценить свои потребности: используйте SOA, лишь когда это необходимо, поскольку она сильно увеличивает сложность. И если на самом деле вы можете обойтись без SOA, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.