SOA и общие базы данных

Я не понимаю SOA (Service-oriented Architecture) и базы данных. Хотя меня привлекает концепция SOA (инкапсуляция многоразовой бизнес-логики в сервисы), я не могу понять, как она должна работать, если таблицы данных, инкапсулированные в службу, требуются другими службами/системами --- или SOA подходит для все в этом сценарии?

Чтобы быть более конкретным, предположим, что у меня есть две службы:

CustomerService: содержит таблицу Customers базы данных и связанную с ней бизнес-логику.
OrderService: содержит мою таблицу Orders и логику.

Теперь что, если мне нужно JOIN таблицы Customers и Orders с выражением SQL? Если в таблицах содержится миллионы записей, неприемлемая производительность будет результатом, если мне придется отправлять данные по сети с использованием SOAP/XML. И как выполнить JOIN?

Проведя небольшое исследование, я нашел несколько предлагаемых решений:

Использовать репликацию, чтобы сделать локальную копию необходимых данных там, где это необходимо. Но тогда нет инкапсуляции, а затем какой смысл использовать SOA? Это обсуждается qaru.site/info/224928/..., но нет четкого консенсуса.
Настройте Главная служба данных, которая инкапсулирует все данные базы данных. Я предполагаю, что он получит размер монстра (по существу, один вызов API для каждой хранимой процедуры) и потребует обновлений все время. Для меня это похоже на концепцию корпоративная шина данных.

Если у вас есть какие-либо данные, сообщите мне.

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

Ответ 1

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

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

Использование единой службы данных - это просто "не делать SOA"; если у вас есть одно место, которое управляет всеми данными, у вас нет независимых сервисов, у вас есть только одна услуга.

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

Вместо того, чтобы думать о необходимости объединить эти два значения вместе в базе данных, подумайте о том, как их собрать вместе по краям:

При рендеринге HTML-страницы для клиента вы можете предоставить HTML из нескольких сервисов и составить их рядом друг с другом визуально: сведения о клиентах поступают из службы клиентов и детали заказа из службы заказа.

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

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

Два, вы можете легко изменить внешность своего приложения. Если у вас небольшие, составные части, вы можете легко добавить переупорядочивать детали по-новому.

Ответ 2

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

Ответ 3

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

Кроме того, этот мой вопрос может быть полезным:

https://softwareengineering.stackexchange.com/info/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa