Служба B опирается на данные в Службе A: дублировать данные или получать по требованию? - PullRequest
Новая
       47

Служба B опирается на данные в Службе A: дублировать данные или получать по требованию?

0 голосов
/ 29 ноября 2018

Это вопрос проектирования микросервиса, который представляет собой упрощение реальной проблемы, которую я хотел бы решить.

Служба A имеет объекты, которые могут быть активными или неактивными. 

[
    {
       id: "a46e6cc7-97ca-4570-b3f3-2be00ca9dab5",
       name: "foo",
       active: true
    },
    {
       id: "eb1ced31-eccc-4ad6-a695-5c6c76cab7a5",
       name: "bar",
       active: false
    },
    {
       id: "ef332044-9e66-4a0b-91ed-c16a2537e848",
       name: "baz",
       active: true
    }
]

Сервис B имеет задания, связанные с объектами Сервиса A, и должен запускаться, только если объекты активны (согласно бизнес-правилу).

Вариант 1: СервисВ не хранит информацию о том, должны ли задания выполняться. 

[
    {
       id: "39cf3321-34d1-4557-b1c4-ca628c191b92",
       entityId: ""a46e6cc7-97ca-4570-b3f3-2be00ca9dab5",
       start: "Thu Nov 29 2018 08:40:27 GMT-0800 (Pacific Standard Time)",
       ended: null,
       recurrence: "hourly"
    },
    {
       id: "77296d22-564f-4289-8327-f23bceb1d400",
       entityId: "a46e6cc7-97ca-4570-b3f3-2be00ca9dab5",
       start: "Tu Nov 27 2018 15:56:01 GMT-0800 (Pacific Standard Time)",
       ended: null,
       recurrence: "hourly"
    },
    {
       id: "2916a920-13a3-46f6-9ffd-d7629163924a",
       entityId: "eb1ced31-eccc-4ad6-a695-5c6c76cab7a5",
       start: "Wed April 01 2018 00:00:00 GMT-0800 (Pacific Standard Time)",
       ended: Thu April 01 2019 00:00:00 GMT-0800 (Pacific Standard Time),
       recurrence: "daily"
    },
]

Когда запланировано выполнение задания, оно проверяет 

if Service A has j.entityId = true
   run j

с использованием API-интерфейса службы А.

Вариант 2: Служба B хранит информацию о том, должна ли работа выполняться 

[
    {
       id: "39cf3321-34d1-4557-b1c4-ca628c191b92",
       entityId: ""a46e6cc7-97ca-4570-b3f3-2be00ca9dab5",
       active: true,
       start: "Thu Nov 29 2018 08:40:27 GMT-0800 (Pacific Standard Time)",
       ended: null,
       recurrence: "hourly"
    },
    {
       id: "77296d22-564f-4289-8327-f23bceb1d400",
       entityId: "a46e6cc7-97ca-4570-b3f3-2be00ca9dab5",
       active: true,
       start: "Tu Nov 27 2018 15:56:01 GMT-0800 (Pacific Standard Time)",
       ended: null,
       recurrence: "hourly"
    },
    {
       id: "2916a920-13a3-46f6-9ffd-d7629163924a",
       entityId: "eb1ced31-eccc-4ad6-a695-5c6c76cab7a5",
       active: false,
       start: "Wed April 01 2018 00:00:00 GMT-0800 (Pacific Standard Time)",
       ended: Thu April 01 2019 00:00:00 GMT-0800 (Pacific Standard Time),
       recurrence: "daily"
    },
]

Ее хранилище обновляется с помощью уведомления от Службы A: 

Entity e changes => publish e => Service B updates accordingly

Вот аргументы, которые я вижу в пользу каждого варианта.

Аргументы варианта 1:

  • Меньшая стоимость хранения, поскольку данные не дублируются
  • Когда запланировано выполнение задания, оно всегда имеет самую свежую информацию о том, является ли онодолжен быть активным (больше «согласованности»?)
  • Не нужно иметь дело со сложностью синхронизации данных между службами.В этом примере есть только Служба B, которая полагается на данные из A, но представьте себе сложность, если бы существовали службы X0, ..., X1000, которые все должны были знать, активен ли объект.

Аргументы варианта 2:

  • Сервисы действительно независимы: если A не запущен, B все еще может запускать
  • Меньше разговорных сервисов (меньше стоимость передачи по сети)
  • Хотя, возможно, и более сложная, сложность дублирования / распространения данных вынуждает службы делиться ничем или небольшим

Ответы [ 2 ]

0 голосов
/ 30 ноября 2018

Давайте попробуем создать реальную жизненную ситуацию, чтобы лучше понять:

Мы работаем над YouTube.

  1. Служба A управляет объектом, который является пользователем
  2. Служба B запускает задание для каждого пользователя - если пользователь активно обновляет настройки пользователя, используя AI.

В этом случае имеет смысл просто просто прочитать данные из Службы A (даже при сохранениине дорого).

Мы должны пойти с этим, поскольку это очень просто выполнить.Также, если служба A не работает, временно это задание не будет работать, что также хорошо для бизнеса.

Теперь в другом экономическом случае:

Давайте попробуем создать некоторую реальную жизненную ситуацию, чтобы лучше понять:

Мы работаем над YouTube.

  1. Служба A управляет объектом, который является пользователем
  2. Служба B - если пользователь становится неактивным, отправьте уведомление по электронной почте.

Это, безусловно, я хотел бы реализовать с помощью событий.

Теперь моя основная задача - вообще использовать события, когда вы хотите реагировать на выполнение некоторых операций, а зависимости малы.В противном случае считывайте данные из основной службы, поскольку она проста, и управление данными в другой службе (которая вскоре может стать несколькими службами B) создаст проблему при управлении

0 голосов
/ 30 ноября 2018

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

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

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

Так что в вашем случае я предпочту делать вызовы API (и ставитьSLA для службы A, чтобы быстро реагировать, кэшировать или что-либо еще), но я бы не стал кэшировать некоторые другие данные в моей системе.Однако бывают случаи, когда ваша служба B вызывается, скажем, n раз в минуту, а n увеличивается, тогда вы можете быть склонны к подходу b (но это все равно будет серая зона и будьте осторожны, так как это может осложнить вам жизньв зависимости от того, как serviceA развивается со временем)

...