На самом ли деле состав сервисов SOA работает на практике?

Одним из основных принципов разработки сервисов SOA является принцип составности сервисов ( https://en.wikipedia.org/wiki/Service_composability_principle ).

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

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

Во-первых, вам действительно нужно решить проблему транзакций, прежде чем вы сможете создавать какие-либо нетривиальные сервисы. Конечно, если в примере есть сервисы "findCurrentTime ()" и "writeLogMessage ()", легко не беспокоиться о транзакциях, но не при наличии реальных примеров, таких как "depositMoney ()" и "drawMoney () ".

Я знаю два варианта:

1. Реализация реальных транзакций с помощью WS-Atomic Transaction или подобных
2. Внедрить решение на основе компенсации, которое компенсирует вызов A с помощью метода "cancelA ()" или, например, в случае сбоя вызова B

Оба из них кажутся мне очень проблематичными / почти непригодными для использования:

• WS-Атомная транзакция
  • много сложности, большинство совета , который я нашел только предупреждает «боль в заднице, не делает это»
  • поддержка ограничена, например, если вы берете ESB с открытым исходным кодом, основные альтернативы ServiceMix, Mule или WSO2 не поддерживают его
• компенсации
  • реализация обработки компенсаций кажется мне очень сложной. Что мы делаем, если служба A преуспевает, и мы никогда не получаем ответ от службы B и не знаем, провалилась ли она или преуспела? Ручная обработка такой логики (как реализации сервисов компоновки) заставляет меня хотеть разрезать мои запястья - это та работа, которую какой-то инструмент должен сделать для меня !.
  • Я также не понимаю, как у вас могут быть методы компенсации в нетривиальных услугах. Скажем, ваш сервис A - это «depositMoney ()», и он успешно выполняется, какое-то другое действие быстро переводит деньги в другое место, и затем мы получаем «undateDepositMoney () », что нам теперь делать? Похоже, большая банка червей.

Мне кажется, что состав сервисов является настолько фундаментальным принципом SOA, что вы действительно не получаете преимуществ SOA, если не можете (удобно) создавать сервисы . Какова реальность? 90% пользователей SOA используют "SOA" с грифом без реальной поддержки сервиса? Или большинство пользователей на самом деле используют состав услуг, и я преувеличиваю сложность этого?

Краткий ответ - да!

Я видел это в нескольких крупных финансовых организациях, и это сработало хорошо.

Проблемы транзакций являются сложными, но обычно решаются с помощью (дорогого) промежуточного программного обеспечения, такого как Oracles WebLogic EAI или IBM Websphere ESB.

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

Чтобы ответить на некоторые из ваших более конкретных проблем ...

Вы можете использовать транзакции:

1. WS-TX - это PITA, и я бы этого избегал.
2. Все ваши службы могут работать на одном сервере приложений, и в этом случае вы можете объединить их все с помощью транзакции XA. Вот почему были изобретены такие вещи, как серверы приложений.

Учитывая подход, основанный на компенсации:

Компенсационные действия необходимо рассматривать только в случае сбоя. Имеется ли у инструмента композиции услуг флаг, которым он может управлять, который очищается при первом запуске шага рабочего процесса, но устанавливается при последующих вызовах? Как возможный флаг повторной отправки в JMS. Затем вы можете использовать так называемую 1,5-фазную фиксацию, что в основном означает «идти вперед», если флаг снят, но если флаг установлен, сначала сделайте вызов, чтобы проверить, обновлено ли состояние и нужно ли делать его второй раз. , Это все еще требует ручной обработки ошибок и может быть сложным или даже невозможным, как вы указали.

В некоторых ситуациях это не имеет значения:

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

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

Вы можете использовать асинхронный обмен сообщениями, чтобы разбить транзакции на более мелкие части:

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

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

В качестве альтернативы вы можете использовать этот шаблон, но с 1,5 фазовой фиксацией в базе данных и JMS. ИЛИ вы можете запустить JMS без транзакций, но сделайте его более надежным путем кластеризации.

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

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

1. Очень крепкое сцепление. Если один сервис был изменен, вам необходимо протестировать всю систему.
2. Такие услуги очень мелкозернистые, поэтому существует много внутренних коммуникаций.
3. В результате того, что все детально, существует множество услуг. Систему становится все труднее понять, запросы все труднее отслеживать.
4. Entity-сервисы плохо инкапсулированы: ни одно из бизнес-правил там не проверено, эта логика находится в сервисных сервисах. Таким образом, любая служба может вызывать любую сущность-службу и обновлять свои данные с помощью общего запроса на обновление, который присутствует в его интерфейсе. Такого рода сервисы сущностей часто называют ориентированными на данные - в отличие от ориентированных на процессы, ориентированных на поведение.
5. Врожденная природа связи между этими службами является синхронной. Таким образом, есть вероятность, что выбранный транспорт будет http. Отсюда и все его недостатки, о которых я расскажу чуть позже.

Есть еще более неправильные подходы к сервисной архитектуре . Так что будь осторожен.