Ответ 1
Я тоже много занимался этой темой (для моей работы для NServiceBus и MessageHandler) и хотел бы высказать свои мысли по этому вопросу. Однако я не определил, какая лучшая модель пока.
Если вы проигнорируете практическую реализацию с ServiceFabric, я бы категоризировал предлагаемый подход в следующем порядке, когда дело доходит до надежности:
- C) Модель хранения и пересылки, вероятно, является лучшей из трех моделей, когда дело доходит до межсервисной связи, все сервисы могут работать независимо друг от друга и никоим образом не подвержены сетевым отключениям (в нижней части дополнительной латентности)
- A) Входная очередь на услугу: каждая услуга, свободная от воздействия сетевых сбоев за свою работу. Однако, когда он хочет отправлять сообщения другой службе, это может быть затронуто перебоями в сети и требует повторной попытки встроить для этого.
- B) Очередь вывода на услугу. Вероятно, это наименее из трех моделей, поскольку каждая служба напрямую зависит от ресурса других, что приводит к значительной зависимости доступности сети между узлами.
Если вы посмотрите на это с точки зрения простоты, я бы классифицировал их следующим образом.
- A) Входная очередь на услугу: поскольку источнику сообщений необходимо активно направлять сообщения в заданную целевую очередь, довольно просто реализовать бизнес-процессы или рабочие процессы (что я предполагаю, что ваш конвейер будет представлять) с использованием шаблона маршрутизации (либо статическая маршрутизация, либо динамическая функция fe с использованием шаблона прокрутки маршрута
- C) Сохранение и переадресация: снова маршрутизация является явной частью вашей реализации, поэтому возможны как статические, так и динамические шаблоны маршрутизации, однако практическая реализация сложнее, так как вам нужно создать и управлять сообщением, которое передает сообщения из передачи очередь (выход) в очередь назначения и связанный с ней необходимость потока контекста из источника сообщения в насос сообщения. (Бесстыдный плагин: NServiceBus - это основа, которая может убрать сложность для вас и сделать этот сценарий простым, как A)
- B) Очередь вывода на услугу: каждая служба должна быть настроена для явного чтения из другой очереди, этот подход позволит использовать статическую маршрутизацию только в том случае, если правила маршрутизации внедрены в том месте, где вы читаете только (это сильно ограничивает вас от функционального перспективы)
Если мы учтем детали реализации ServiceFabric, то предположим, что вы хотите использовать реализацию IReliableQueue? Однако эта реализация имеет некоторые недостатки, которые заставляют меня задуматься, действительно ли эти шаблоны могут быть правильно реализованы в собственной инфраструктуре хранения ServiceFabric.
- Инфраструктура хранения доступна только в службах Statefull, поэтому службы Stateless (такие как Rest API или другие шлюзы завершения протокола) не могут быть частью конвейера (обычно вы хотите, чтобы одна из них была точкой входа).
- Только один поток может одновременно обращаться к надежной очереди, поэтому невозможно одновременно писать и читать из одной очереди. Это серьезно ограничивает пропускную способность очереди.
- Для доступа к надежной очереди требуется локальная транзакция, но эти транзакции ограничены одним разделом. Таким образом, также невозможно масштабировать ваши statefull-сервисы для создания конкурирующего потребительского шаблона.
Учитывая эти недостатки, я все еще склонен использовать другой тип инфраструктуры очередей для SF Services вместо модели сохранения SF, например Azure Service Bus или Azure Storage Queues (что также позволяет NserviceBus).
Короче говоря, я поддерживаю как A, так и C, с небольшим преимуществом для C, но я не уверен в использовании надежных очередей в качестве реализации, пока эти недостатки не будут устранены.