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

Question

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

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

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

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

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

• Используйте репликацию , чтобы при необходимости создать локальную копию необходимых данных. Но тогда нет инкапсуляции, и тогда какой смысл использовать SOA? Это обсуждается в StackOverflow , но нет единого мнения.
• Установите Службу основных данных , которая инкапсулирует все данные базы данных. Я предполагаю, что он получит размер монстра (по сути, с одним вызовом API для каждой хранимой процедуры) и будет постоянно требовать обновления. Мне кажется, это связано с концепцией корпоративной шины данных .

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

---

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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