SOA и общие базы данных
Я не понимаю SOA (сервис-ориентированную архитектуру) и базы данных. Хотя меня привлекает концепция SOA (инкапсуляция бизнес-логики многократного использования в сервисы), я не могу понять, как она должна работать, если таблицы данных, инкапсулированные в сервисе, требуются другими сервисами / системами --- или подходит ли SOA вообще в этом сценарии?
Чтобы быть более конкретным, предположим, что у меня есть две службы:
CustomerService: содержит мою таблицу базы данныхCustomersи связанную бизнес-логику.OrderService: содержит мою таблицуOrdersи логику.
Что делать, если мне нужно ПРИСОЕДИНЯТЬСЯ к таблицам Customers и Orders с помощью оператора SQL? Если таблицы содержат миллионы записей, это приведет к неприемлемой производительности, если мне придется отправлять данные по сети с использованием SOAP / XML. И как выполнить JOIN ?
Проведя небольшое исследование, я нашел несколько предлагаемых решений:
- Используйте репликацию , чтобы сделать локальную копию требуемых данных там, где это необходимо. Но тогда нет инкапсуляции, и тогда какой смысл использовать SOA? Это обсуждается на StackOverflow , но нет четкого консенсуса.
- Настройте службу основных данных , которая инкапсулирует все данные базы данных.Я предполагаю, что он будет размером с монстра (по сути, с одним вызовом API для каждой хранимой процедуры) и все время потребует обновлений. Мне кажется, это связано с концепцией корпоративной шины данных .
Если у вас есть какие-либо комментарии по этому поводу, пожалуйста, дайте мне знать.
Править: Прошел год, и мой интерес к SOA уменьшился, как и популярность концепции в целом. В настоящее время люди, похоже, вместо этого хотят сосредоточиться на сервисах RESTful.
2 ответа
Один из определяющих принципов «службы» в этом контексте заключается в том, что она, безусловно, владеет данными в области, за которую отвечает, а также операциями с этими данными.
Копирование данных с помощью репликации или любого другого механизма снимает с себя эту ответственность. Либо вы тоже копируете бизнес-правила, либо в конечном итоге окажетесь в ситуации, когда вам понадобится другой сервис, обновленный для изменения ваших внутренних правил.
Использование одного сервиса данных - это просто «не делай SOA»; если у вас есть единственное место, которое управляет всеми данными, у вас нет независимых служб, у вас есть только одна служба.
Я бы предложил вместо этого третий вариант: использовать композицию для объединения этих данных, полностью избегая операции JOIN на уровне базы данных.
Вместо того, чтобы думать о необходимости объединения этих двух значений в базе данных, подумайте о том, как объединить их вместе по краям:
Когда вы отображаете HTML-страницу для клиента, вы можете предоставить HTML из множественные услуги и визуально составьте их рядом друг с другом: сведения о клиенте поступают из службы поддержки, а сведения о заказе - из службы заказа.
Аналогично электронной почте со счетом: визуально составляйте данные, предоставленные несколькими службами, без необходимости объединения в базу данных.
Это имеет два преимущества: во-первых, вы избавляетесь от необходимости присоединяться к базе данных и даже от необходимости хранить данные в базе данных того же типа. Теперь каждый сервис может использовать любое хранилище данных, наиболее подходящее для их нужд.
Во-вторых, вы можете легко изменить внешний вид своего приложения. Если у вас есть маленькие, компонуемые детали, вы можете легко добавлять их в новое расположение.
В приведенном вами вопросе SO разные люди утверждают, что для службы можно получить доступ к данным других служб, поэтому служба заказов может иметь функцию GetAllWithCustomer, которая будет возвращать все заказы вместе с информацией о клиенте для этого заказа. ,
Кроме того, этот мой вопрос может быть полезным: