Привет, Вы узнаете о том , что такое сервис-ориентированная архитектура, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое сервис-ориентированная архитектура, soa, saga , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределенных, слабо связанных^[en] заменяемых компонентов, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

SOA и DDD-это две концепции, которые отлично работают вместе.DDD - это способ разработать единицу развертывания (отдельное приложение). SOA - это способ склеить несколько единиц развертывания.

SOA :

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

DDD - это:

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

DDD предназначен для построения логики предметной области в рамках общих сервисов SOA

"Сервис – это видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией".

На форуме Open Group Architecture Forum (TOGAF) есть два определения архитектуры в зависимости от контекста:

1. "Формальное описание или подробный план системы на уровне компонентов для руководства в процессе ее создания.
2. Структура компонентов, их взаимосвязи, принципы и направления развития, определяющие их разработку и эволюцию."

DDD vs SOA какие отличия и что общего?

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

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

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

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

Получила распространение в конце 1990-х — начале 2000-х годов. С середины 2010-х годов обрела популярность микросервисная архитектура — вариант сервис-ориентированной архитектуры, нацеленный на применение насколько это возможно минимально связанных модулей.

Ключевые идеи, которые за понятием сервиса:

• Ориентация на бизнес: сервисы ориентируются не на возможности ИТ, а на нужды бизнеса. Ориентация сервисов на бизнес поддерживается анализом сервиса и техникой проектирования.
• Инструкции: сервисы самодостаточны и описываются в терминах интерфейсов, операций, семантики, динамических характеристик, политик и свойств сервиса.
• Повторное использование: повторное использование сервисов обеспечивается их модульным планированием.
• Соглашения: сервисные соглашения заключаются между сущностями, именуемыми поставщиками и пользователями. Эти соглашения основываются на сервисных инструкциях и не влияют на реализацию самих сервисов.
• Размещение и видимость: в течение своего жизненного цикла сервисы размещаются и становятся видимы благодаря сервисным метаданным, реестрам и хранилищам.
• Агрегация: на слабо связанных сервисах строятся объединяющие бизнес-процессы и сложные приложения для одного или нескольких предприятий.

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

Принципы

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

Стандартный договор на обслуживание

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

Автономность ссылок на сервисы (аспект слабой связи)

Взаимосвязь между сервисами сведена к минимуму до уровня, на котором они знают только о своем существовании.

Прозрачность местоположения услуги (аспект слабой связи)

Службы можно вызывать из любого места в сети, где бы они ни находились.

Долговечность службы

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

Абстракция службы

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

Автономность обслуживания

Сервисы независимы и контролируют инкапсулируемые ими функции как во время разработки, так и во время выполнения.

Безгражданство услуги

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

Детализация сервиса

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

Нормализация обслуживания

Сервисы декомпозируются или консолидируются (нормализуются) для минимизации избыточности. В некоторых случаях это невозможно. Это те случаи, когда требуются оптимизация производительности, доступ и агрегирование. ^[15]

Возможность компоновки сервисов

Сервисы могут использоваться для создания других сервисов.

Обнаружение службы

Сервисы дополняются коммуникативными метаданными, с помощью которых они могут быть эффективно обнаружены и интерпретированы.

Возможность повторного использования сервиса

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

Инкапсуляция службы

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

Технологии реализации

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

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

Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005

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

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

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

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестровки, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований.

Рисунок 1. Эталонная модель SOA foundation

Критика

SOA была объединена с веб-сервисами ; ^[30] однако веб-службы - это только один из вариантов реализации шаблонов, составляющих стиль SOA. В отсутствие собственных или двоичных форм удаленного вызова процедур (RPC) приложения могут работать медленнее и требовать большей вычислительной мощности, что увеличивает затраты. Большинство реализаций несут эти накладные расходы, но SOA можно реализовать с использованием технологий (например, Java Business Integration (JBI), Windows Communication Foundation (WCF) и службы распределения данных (DDS)), которые не зависят от удаленных вызовов процедур или трансляции через XML или JSON. В то же время появляющиеся технологии синтаксического анализа XML с открытым исходным кодом (такие как VTD-XML) и различные XML-совместимые двоичные форматы обещают значительно улучшить производительность SOA. ^{[31] [32] [33]}

Службы с отслеживанием состояния требуют, чтобы и потребитель, и поставщик совместно использовали один и тот же специфичный для потребителя контекст, который либо включен, либо упоминается в сообщениях, которыми обмениваются поставщик и потребитель. Это ограничение имеет недостаток, заключающийся в том, что оно может снизить общую масштабируемость поставщика услуг, если поставщику услуг необходимо сохранить общий контекст для каждого потребителя. Это также увеличивает взаимосвязь между поставщиком услуг и потребителем и затрудняет переключение между поставщиками услуг. ^[34] В конечном итоге некоторые критики считают, что сервисы SOA все еще слишком ограничены приложениями, которые они представляют. ^[35]

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

Еще одна серьезная проблема, с которой сталкивается SOA, - это отсутствие единой среды тестирования. Не существует инструментов, обеспечивающих необходимые функции для тестирования этих сервисов в сервис-ориентированной архитектуре. Основные причины затруднений: ^[37]

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

Подходы к реализации , Расширения и варианты

Сервис-ориентированная архитектура может быть реализована с помощью веб-сервисов или микросервисов . ^[21] Это сделано для того, чтобы функциональные строительные блоки были доступны через стандартные Интернет-протоколы, которые не зависят от платформ и языков программирования. Эти службы могут представлять либо новые приложения, либо просто оболочки существующих устаревших систем, чтобы сделать их доступными для работы в сети. ^[22]

Разработчики обычно создают SOA, используя стандарты веб-сервисов. Одним из примеров является протокол SOAP , получивший широкое признание в отрасли после рекомендации версии 1.2 от консорциума W3C ^[23] (World Wide Web Consortium) в 2003 году. Эти стандарты (также называемые спецификациями веб-служб ) также обеспечивают большую совместимость и некоторую защиту от привязка к проприетарному программному обеспечению поставщиков. Однако можно также реализовать SOA, используя любую другую сервисную технологию, такую ​​как Jini , CORBA , REST или gRPC .

Архитектуры могут работать независимо от конкретных технологий и поэтому могут быть реализованы с использованием широкого спектра технологий, в том числе:

• Веб-сервисы на основе WSDL и SOAP
• Обмен сообщениями, например, с ActiveMQ, JMS, RabbitMQ
• RESTful HTTP с передачей репрезентативного состояния (REST), составляющей его собственный архитектурный стиль на основе ограничений.
• OPC-UA
• WCF (реализация веб-сервисов Microsoft, являющаяся частью WCF)
• Apache Thrift
• gRPC
• SORCER

Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берет свое начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько ее реализаций. Но, по сути, SOA можно свести к нескольким идеям, причем архитектура не диктует способы их реализации:

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

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

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

• Общая архитектура брокера объектных запросов (CORBA).
• Веб-сервисы.
• Очередь сообщений.
• Сервисная шина предприятия (ESB).
• Микросервисы.

Общая архитектура брокера объектных запросов (CORBA)

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

Стандарт CORBA был реализован несколькими вендорами. Об этом говорит сайт https://intellect.icu . Он обеспечивает:

• Не зависящие от платформы вызовы удаленных процедур (Remote Procedure Call).
• Транзакции (в том числе удаленные!).
• Безопасность.
• События.
• Независимость от выбора языка программирования.
• Независимость от выбора ОС.
• Независимость от выбора оборудования.
• Независимость от особенностей передачи данных/связи.
• Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).

Сегодня 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) вызывает локальную процедуру, реализованную заглушкой.

1. Заглушка проверяет вызов, создает сообщение-запрос и передает его в ORB.
2. Клиентский ORB шлет сообщение по сети на сервер и блокирует текущий поток выполнения.
3. Серверный ORB получает сообщение-запрос и создает экземпляр скелета.
4. Скелет исполняет процедуру в вызываемом объекте.
5. Вызываемый объект проводит вычисления и возвращает результат.
6. Скелет пакует выходные аргументы в сообщение-ответ и передает его в ORB.
7. ORB шлет сообщение по сети клиенту.
8. Клиентский ORB получает сообщение, распаковывает и передает информацию заглушке.
9. Заглушка передает выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.

Достоинства

• Независимость от выбранных технологий (не считая реализации ORB).
• Независимость от особенностей передачи данных/связи.

Недостатки

• Независимость от местоположения: клиентский код не имеет понятия, является ли вызов локальным или удаленным. Звучит неплохо, но длительность задержки и виды сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то приложение не может выбрать подходящую стратегию обработки вызовов методов, а значит, и генерировать удаленные вызовы внутри цикла. В результате вся система работает медленнее.
• Сложная, раздутая и неоднозначная спецификация: ее собрали из нескольких версий спецификаций разных вендоров, поэтому (на тот момент) она была раздутой, неоднозначной и трудной в реализации.
• Заблокированные каналы связи (communication pipes): используются специфические протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты). Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-соединения только через 80-й порт, блокируя обмены данными CORBA.

Веб-сервисы

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

И для решения этих задач в конце 1990-х начали появляться веб-сервисы.

• Нужен был надежный канал связи, поэтому:
  • HTTP стал по умолчанию работать через порт 80.
  • Для обмена сообщениями начали использовать платформо-независимый язык (вроде XML или JSON).
• Нужно было уменьшить количество удаленных обращений, поэтому:
  • Удаленные соединения стали явными, так что теперь мы всегда знаем, когда выполняется удаленный вызов.
  • Вместо многочисленных удаленных вызовов объектов мы обращаемся к удаленным сервисам, но гораздо реже.
• Нужно было упростить спецификацию обмена сообщениями, поэтому:
  • Первый черновик SOAP появился в 1998-м, стал рекомендацией W3C в 2003-м, после чего превратился в стандарт. SOAP вобрал в себя некоторые идеи CORBA, вроде слоя для обработки обмена сообщениями и «документа», определяющего интерфейс с помощью языка описания веб-сервисов (Web Services Description Language, WSDL).
  • Рой Филдинг в 2000-м описал REST в своей диссертации «Architectural Styles and the Design of Network-based Software Architectures». Его спецификация оказалась гораздо проще SOAP, поэтому вскоре REST обогнал SOAP по популярности.
  • Facebook разработал GraphQL в 2012-м, а публичный релиз выпустил в 2015-м. Это язык запросов для API, позволяющий клиенту строго определять, какие данные сервер должен ему отправить, не больше и не меньше.

[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
— Microsoft 2004, Understanding Service-Oriented Architecture

Благодаря микросервисам мы перешли в парадигме SOA от удаленного вызова методов объекта (CORBA) к передаче сообщений между сервисами.

Но нужно понимать, что в рамках SOA веб-сервисы — не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила. SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.

С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
— Microsoft 2004, Understanding Service-Oriented Architecture

Достоинства

• Независимость набора технологий, развертывания и масштабируемости сервисов.
• Стандартный, простой и надежный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов доменов (Domain contexts).

Недостатки

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

Очередь сообщений

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

Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:

• Запрос/Ответ

  • Клиент шлет в очередь сообщение, включая ссылку на «разговор» («conversation» reference). Сообщение приходит на специальный узел, который отвечает отправителю другим сообщением, где содержится ссылка на тот же разговор, так что получатель знает, на какой разговор ссылается сообщение, и может продолжать действовать. Это очень полезно для бизнес-процессов средней и большой продолжительности (цепочек событий, sagas).
• Публикация/Подписка
  • По спискам
    Очередь поддерживает списки опубликованных тем подписок (topics) и их подписчиков. Когда очередь получает сообщение для какой-то темы, то помещает его в соответствующий список. Сообщение сопоставляется с темой по типу сообщения или по заранее определенному набору критериев, включая и содержимое сообщения.
  • На основе вещания
    Когда очередь получает сообщение, она транслирует его всем узлам, прослушивающим очередь. Узлы должны сами фильтровать данные и обрабатывать только интересующие сообщения.

Все эти паттерны можно отнести к либо к pull- (polling), либо к push-подходу:

• В pull-сценарии клиент опрашивает очередь с определенной частотой. Клиент управляет своей нагрузкой, но при этом может возникнуть задержка: сообщение уже лежит в очереди, а клиент его еще не обрабатывает, потому что не пришло время следующего опроса очереди.
• В push-сценарии очередь сразу же отдает клиентам сообщения по мере поступления. Задержки нет, но клиенты не управляют своей нагрузкой.

Достоинства

• Независимость набора технологий, развертывания и масштабируемости сервисов.
• Стандартный, простой и надежный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.

Недостатки

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

Сервисная шина предприятия (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.

Достоинства

• Независимость набора технологий, развертывания и масштабируемости сервисов.
• Стандартный, простой и надежный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Единая точка для управления версионированием и преобразованием.

Недостатки

• Ниже скорость связи, особенно между уже совместимыми сервисами.
• Централизованная логика:
  • Единая точка отказа, способная обрушить системы связи всей компании.
  • Большая сложность конфигурирования и поддержки.
  • Со временем можно прийти к хранению в ESB бизнес-правил.
  • Шина так сложна, что для ее управления вам потребуется целая команда.
  • Высокая зависимость сервисов от ESB.

Микросервисы

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

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

То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат», и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).

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

[Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
— Sam Newman 2015, Principles Of Microservices

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

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

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

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

Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
— Martin Fowler 2014, Microservices

Достоинства

• Независимость набора технологий, развертывания и масштабируемости сервисов.
• Стандартный, простой и надежный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Синхронность обмена сообщениями помогает управлять производительностью системы.
• Полностью независимые и автономные сервисы.
• Бизнес-логика хранится только в сервисах.
• Позволяют компании превратиться в сложную адаптивную систему, состоящую из нескольких маленьких автономных частей/команд, способную быстро адаптироваться к переменам.

Недостатки

• Высокая сложность эксплуатации:
  • Нужно много вложить в сильную DevOps-культуру.
  • Использование многочисленных технологий и библиотек может выйти из-под контроля.
  • Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
  • Использование «согласованности в конечном счете» (eventual consistency) может привести к серьезным последствиям, которые нужно учитывать при разработке приложения, от бэкенда до UX.
  • Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.

микросервисная архитектура — частный случай SOA:

Другими словами, микросервисная архитектура — всего лишь набор более строгих правил и соглашений, как писать все те же сервисы SOA

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

Вот различия между SOA и микросервисами:

SOA	Микросервисы
Модель SOA имеет единый уровень хранения данных, который используется всеми службами в этом приложении.	Приложения микросервисов в основном выделяют базу данных или другое хранилище для сервисов, которые в этом нуждаются.
Связь между различными сервисами в приложении SOA использует простые и понятные подходы.	Микросервисы используют сложные API.
Ориентирован на максимальное повторное использование сервисов приложений.	Больше внимания уделяем развязке.
Систематическое изменение требует модификации монолита.	Систематическое изменение поможет вам создать новую услугу.
DevOps и непрерывная доставка становятся популярными, но еще не стали мейнстримом.	Сильный акцент на DevOps и непрерывной доставке
Монолитный по своей природе	Полный стек в природе
Поддерживает несколько протоколов сообщений.	Использует легкие протоколы, такие как HTTP, REST или Thrift API.
Он предназначен для совместного использования ресурсов между службами.	Он предназначен для размещения служб, которые могут работать независимо.
Часто включает совместное использование компонентов	Как правило, это не включает совместное использование компонентов
Предполагает совместное использование хранилища данных между сервисами	Каждая служба может иметь независимое хранилище данных.
Лучше для крупномасштабной интеграции	Лучше для небольших и веб-приложений.
Обменивается данными через ESB	Общайтесь через уровень API
Полагается на совместное использование ресурсов	Для связи полагается на ограниченный контекст.
Меньшая гибкость в развертывании	Быстрое и простое развертывание.
Стек технологий SOA ниже по сравнению с Microservice.	Стек микросервисных технологий может быть очень большим.
Бизнес-единицы зависимы.	Бизнес-единицы независимы друг от друга.
Приложение SOA, состоящее из двух или трех служб.	Приложение Microservices может иметь десятки сервисов.
Приложения SOA созданы для выполнения множества бизнес-задач.	Они созданы для выполнения одной бизнес-задачи.
Развертывание - это трудоемкий процесс.	Развертывание несложно и требует меньше времени.
Компоненты бизнес-логики хранятся внутри простых проводных протоколов (HTTP с XML JSON) в домене с одним сервисом. API управляется с помощью пакетов SDK / клиентов.	Бизнес-логика может существовать во всех доменах служебной шины предприятия, как отдельные уровни между службами.
Использует служебную шину предприятия (ESB) для связи	Он использует менее сложную и простую систему обмена сообщениями.
Размер программного обеспечения больше, чем у любого обычного программного обеспечения	Размер ПО в микросервисах невелик.
Многопоточность с множеством накладных расходов для обработки ввода-вывода	Однопоточные в основном используются с функциями Event Loop для неблокирующей обработки ввода-вывода.
Систематическое изменение, необходимое для модификации монолита.	В микросервисах систематическое изменение заключается в создании новой службы.
Сосредоточьтесь на максимальном увеличении возможности повторного использования сервисов приложений.	Акцент на развязку.
Единое управление и стандарты.	Расслабленное управление, поскольку оно больше ориентировано на сотрудничество людей и свободу выбора.
Процесс развертывания занимает много времени.	Развертывание выполняется легко и требует меньше времени.
Менее масштабируемая архитектура.	Высоко масштабируемая архитектура.

Антипаттерн: архитектура равиоли (Ravioli Architecture)

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

Заключение

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

Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.

Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развертывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.

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

Паттерн: SAGA

Почему в SOA не поощряются длинные транзакции, а вместо них предлагается использовать Saga?

Контекст

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

Проблема

Как реализовать транзакции, охватывающие услуги?

• 2PC не вариант

Решение

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

Есть два способа согласования саг:

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

Пример: Saga, основанная на хореографии.

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

1. Order ServiceПолучает POST /ordersзапрос и создает Orderв PENDINGсостоянии
2. Затем он испускает Order Createdсобытие
3. В Customer Service«ю.ш. попытки обработчика событий для резервного кредита
4. Затем он генерирует событие, указывающее результат.
5. В OrderServiceобработчик события «S либо одобряет или отклоняетOrder

Пример: Saga, основанная на оркестровке.

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

1. Order ServiceПолучает POST /ordersзапрос и создает Create Orderсага Orchestrator
2. Оркестратор саги создает Orderв PENDING состоянии
3. Затем он отправляет Reserve Creditкоманду на Customer Service
4. В Customer Serviceпопытках резервного кредита
5. Затем он отправляет ответное сообщение с указанием результата.
6. Организатор саги либо одобряет, либо отклоняет Order

Результирующий контекст

Этот шаблон имеет следующие преимущества:

• Это позволяет приложению поддерживать согласованность данных в нескольких сервисах без использования распределенных транзакций.

Это решение имеет следующие недостатки:

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

Также необходимо решить следующие проблемы:

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

• Клиент, который инициирует сагу, которая является асинхронным потоком, используя синхронный запрос (например, HTTP POST /orders), должен иметь возможность определить его результат. Есть несколько вариантов, каждый из которых имеет свои компромиссы:

  • Служба отправляет ответ после завершения саги, например, после получения события OrderApprovedили OrderRejected.
  • Служба отправляет ответ (например, содержащий orderID) после запуска саги, и клиент периодически опрашивает (например GET /orders/{orderID}), чтобы определить результат
  • Служба отправляет ответ (например, содержащий orderID) после запуска саги, а затем отправляет событие (например, веб-узел, веб-перехват и т.д.) клиенту после завершения саги.

Связанные шаблоны

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

Вау!! 😲 Ты еще не читал? Это зря!

• архитектура программного обеспечения
• REST
• SOASP
• микросервис , архитектура микросервиса , microservices ,

• Событийно-ориентированная архитектура (EDA)
• Многоэтапная событийно-ориентированная архитектура (SEDA)
• Интерфейс прикладного программирования
• Слабая связь
• Эталонная модель SOA OASIS
• Принцип детализации сервиса
• Управление SOA
• Архитектура программного обеспечения
• Сервисно-ориентированная связь (SOC)
• Сервисно-ориентированная разработка приложений
• Сервис-ориентированные распределенные приложения
• DDD
• недостатки ооп , альтернатива ооп , ddd , архитектура программного обеспечения ,

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