SOA: объединение данных между несколькими сервисами

Question

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

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

Мой вопрос такой: как с этой архитектурой я могу отобразить список заказов и сведения о продукте на «той же» странице?

Насколько я понимаю, я должен получить список OrderItems от OrderService.Каждый OrderItem имеет ProductID.Теперь, если я сделаю отдельный вызов ProductService для получения подробной информации о каждом продукте, это будет очень неэффективно.

Как бы вы подошли к этой проблеме?

Приветствия, Мош

Answer 1

Я провел некоторое исследование и нашел 2 разных решения для этого.

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

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

Надеюсь, это поможет другим, кто сталкивался с этой проблемой.

Мош

Answer 2

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

слабая связь, инкапсуляция разделение интересов

Служба должна быть (чтобы заработать это имя) полностью независимой, а именно:

1. он не должен полагаться на других для обеспечения согласованности и согласованности своих данных
2. он не должен полагаться на других в обеспечении безопасности своих данных
3. он не должен зависеть от внешних реализаций (только интерфейсы)

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

Тот факт, что вы «контролируете» обе службы, совершенно не имеет значения. Сегодня вы контролируете ... завтра вы можете отдать на аутсорсинг или заменить одну из услуг. Это должно быть так же просто, как и обеспечить правильные интерфейсы.

Представьте себе обе службы, которые совместно используют таблицу с некоторым полем (varchar) в ней. Теперь одна служба должна изменить это поле на числовое ... bang, другая служба перестает работать - слабая связь исчезает.

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

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

Answer 3

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

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

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

Answer 4

К сожалению, все это обсуждение ухудшается в квесте с заявлением «могу ли я использовать общую базу данных или нет в SOA», который совершенно не имеет отношения к делу и вообще не помогает ответить на исходный вопрос.

Чаще всего в реальной ситуации данные уже хранятся в разных системах для начала. Например, данные о клиенте поступают из CRM, данные о продукте из SAP, данные контракта из другого источника.

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

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

Answer 5

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

Answer 6

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