c # — В сервис-ориентированной архитектуре (SOA) каждый сервис должен иметь свои собственные данные?
В рамках Сервис-ориентированной архитектуры (SOA) меня интересует вопрос о том, должна ли служба владеть своими собственными данными или нет.
Одним из ограничений является то, что в случае сбоя чего-либо в любой момент мы должны иметь возможность откатить состояние всей системы до прежнего состояния, чтобы мы могли повторить или возобновить операцию.
Если каждый сервис имеет свои собственные данные, то означает ли это, что система лучше справляется с изменениями с точки зрения программистов?
Однако, если каждая служба владеет своими собственными данными, существуют ли какие-либо механизмы для возврата всей системы к предыдущему состоянию, чтобы неудачная операция могла быть возобновлена или повторена?
Решение
Похоже, что детализация того, что вы называете услугами, может быть неправильной. Одиночная служба может иметь несколько конечных точек (используя одинаковые или разные протоколы), и если сообщение, полученное в одной конечной точке, требует отката состояния, которое было получено в другой, оно все еще является внутренней транзакцией в пределах границы службы.
Если рассмотреть упрощенный пример заказа и обслуживания клиентов. Службы заказа могут иметь контракты с сообщениями, относящимися ко всему заказу или к строке заказа, и отмена заказа отменит состояние, на которое повлияли оба. Обычно изменение адреса в службе поддержки клиентов не будет отменено с этим.
Иногда действия службы связаны друг с другом в более длительном бизнес-процессе. Чтобы продолжить на примере выше, давайте также добавим службу выставления счетов. поэтому, когда мы отменяем заказ, мы также хотим отменить счет. Однако важно отметить, что бизнес-правила в сфере службы выставления счетов-фактур могут вести себя по-разному, например, а не «откатываться», например. Отмена заказа с опозданием может потребовать платы за отмену. Этот вид длительного взаимодействия — это то, что я называю сага (вы можете увидеть черновик этого шаблона Вот)
Также обратите внимание, что распределенные транзакции между сервисами обычно не очень хорошая идея по нескольким причинам (например, удержание блокировок для сторонней организации, которой вы не обязательно доверяете), вы можете прочитать об этом подробнее Вот
Другие решения
Проблема, которую вы подняли, частично решена протоколом двухфазной фиксации (см. статья в википедии)
Чтобы избежать реализации этого сложного алгоритма, вы можете выделить один из сервисов архитектуры для управления данными. Если вам нужна синхронизация данных между различными базами данных, попробуйте сделать это на самом нижнем уровне (то есть системе или СУБД).
Система SOA определяет больше сервисов в одной системе. Это может предоставить больше автономных сервисов, чтобы каждый сервис мог быть размещен на другом компьютере.
Но это не означает, что вы не можете предоставить единый постоянный уровень для всех (доменных) моделей, которые могут указывать на одну простую бизнес-транзакцию хранения>, когда вся система распределена по нескольким компьютерам, или транзакция для одной системы.
Модель автономного домена полезна помимо прочего во время рефакторинга, чтобы избежать ситуации, когда изменение в одной модели вызывает изменение в другой службе => глобальные изменения во всем приложении.
Вкратце: Нет. Сервисы не «владеют» данными.
Данные являются правдой о мире, и неявно долговечны и делятся. Логические сервисы (API) не всегда сопоставляются с реальными данными 1-1. Физические сервисы (код) являются реализациями, которые очень рефактивны, что противостоит долговременной природе данных.
Когда вы разделяете данные, вы теряете описательную силу и аналитическое понимание. Но где это действительно убивает, это честность. Данные не могут быть согласованы между бункерами при масштабировании. Для сложных данных вам нужны эти внешние ключи.
Другими словами, у платформы есть только одна «логическая» БД (для каждой среды), потому что существует только одна вселенная. Существует много веских причин для разрушения БД, таких как ограничения HW, производительность, координация, репликация и соответствие. Но относитесь к ним как к необходимому злу, используемому только когда это необходимо.
Но я думаю, что вы, возможно, задаете другой вопрос: «Должна ли долгосрочная транзакция на основе данных управляться одним авторитетным сервисом?» И, как правило, этот ответ: да. Эта служба транзакций может реализовать несколько шагов для упорядочения потока по своему усмотрению, например, двухфазное принятие. Все остальные сервисы должны использовать этот сервис транзакций для выполнения транзакции.
НО! Эта служба транзакций должна взаимодействовать с БД как общим ресурсом, используя только атомарную семантику. Это включает все состояния транзакции (намерение, затем действие, затем результат), так что возможны восстановление и откат. База данных должна быть уполномочена поддерживать целостность в случае неисправностей. Я не могу подчеркнуть это достаточно: все, всегда должно быть разложено на атомарные операции с БД, если вы хотите отказоустойчивости.