Анализ интересов клиента выбор вариантов решений конспект

Обновлено: 05.07.2024

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Open with Desktop
View raw
Copy raw contents Copy raw contents

Copy raw contents

Сервисно-ориентированные архитектуры. Анализ интересов клиента. Выбор вариантов решений

Сервис-ориентированная архитектура (SOA)

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

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

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

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

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

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

Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:

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

Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.

Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.

Принцип работы

Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.

Достоинства

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

Недостатки

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

Нужен был надёжный канал связи, поэтому:

Нужно было уменьшить количество удалённых обращений, поэтому:

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

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

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

Достоинства

Недостатки

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

Достоинства

Недостатки

Сервисная шина предприятия (ESB)

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

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

Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.

Главные обязанности ESB:

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

Достоинства

Недостатки

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

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

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

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

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

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

Достоинства

Недостатки

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

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

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

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

Читайте также: