Microsoft Azure Service Bus Темы Рабочий процесс для сохранения в базу

Question

Задача

В настоящее время наш веб-сайт настроен таким образом, что при выполнении действия, требующего отправки электронного письма, наш веб-сайт вызывает сервер SMTP, чтобы попытаться отправить электронное письмо. Проблема заключается в том, что SMTP-сервер отключается по какой-либо причине. Мы не храним никаких исходящих сообщений, поэтому, если отправляемое письмо не удается, оно теряется навсегда (на самом деле это не так просто, как его можно легко восстановить, но у нас нет механизма, позволяющего нам знать, что это не удалось, кроме Azure Application Insights). Хотя у нас также есть веб-сайт, отправляющий разработчикам электронное письмо при возникновении исключений по понятным причинам, мы не будем получать эти электронные письма.

Цель

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

1. Не разрешать веб-сайту отправлять электронные письма
2. Возможность восстановления после временных или побочных проблем / исключений
3. Зарегистрируйте как можно больше действий, связанных с электронной почтой (попытки отправки / неудачи / и т.д.)
4. Возможность восстановления журналов активности от потенциальных временных или побочных проблем / исключений
5. Возможность повторно инициировать отправку электронного письма при необходимости (необязательно)

Решение

Я прочитал статью из 3 частей , которая звучит так, как будто это решит эту проблему, и сейчас я ее разрабатываю.

Я строю процесс, используя Microsoft.Azure.ServiceBus Topics и Subscriptions для управления отправкой электронной почты с нашего веб-сайта. Я прошел через множество сэмплов и смог успешно SendAsync() a Message, ReceiveAsync() a Message и CompleteAsync() или AbandonAsync() соответственно.

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

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

В настоящее время мы пытаемся определить лучший или наиболее подходящий рабочий процесс для этого процесса. Мы полагали, что понадобятся два Topics: один для отправляемых писем EmailTopic , а другой для журналов для записи LogTopic .

Причина LogTopic состоит в том, чтобы обрабатывать любые временные проблемы при попытке сохранить активность журнала в базе данных. Например: Я успешно получаю электронное письмо для отправки. Затем я пытаюсь отправить электронное письмо и зарегистрировать эту попытку. Письмо успешно отправлено. Затем я пытаюсь зарегистрировать это действие, но база данных просто отключилась, и я не смог бы зарегистрировать это действие. Второй Topic должен смягчить это, но что произойдет, если это пойдет на убыль?

Вот наш текущий рабочий процесс:

1. Веб-сайт вставляет данные в базу данных, которая определяет отправляемое электронное письмо (в настоящее время у нас будет поле для Body, которое будет само содержимым электронной почты, другая таблица для хранения Email Templates, которая будет содержать содержимое вокруг поля Body, а также из, в, CC, BCC и вложения файлов)
2. Сайт отправляет небольшой Message на EmailTopic с MessageId вставленной записи
3. A Stateless Service Fabric Service прослушивает сообщения
4. Получите Message, получите все данные из базы данных для записи
5. Создайте SMTPClient и попытайтесь отправить электронное письмо на SMTP-сервер
6. Отправьте Message на LogTopic с MessageId, текущей датой, текущей DeliveryCount и предпринятыми действиями (попытка отправить электронное письмо)
   • В случае успеха CompleteAsync() Message и отправить Message на LogTopic с MessageId, текущей датой, текущей DeliveryCount и предпринятыми действиями: «электронная почта отправлена»
   • В случае неудачи AbandonAsync() Message и отправить Message на LogTopic с MessageId, текущей датой, текущей DeliveryCount и предпринятыми действиями: «электронная почта не отправлена» (после Сообщение 10 попыток будет автоматически помещено в DeadLetterQueue

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

Вопросы

1. Мы думали о том, чтобы просто хранить журналы в базе данных в рамках рабочего процесса, но вопрос "а что, если БД выйдет из строя за это время?" (следовательно, когда Azure Central US вышел из строя на прошлой неделе), мы решили использовать это 2 Topic. Очевидно, что если Service Bus не работает, мы не можем отправить это сообщение, и я не знаю, как его восстановить, за исключением регистрации ETW и проверки их другим способом. Должен ли я сначала попытаться сохранить БД, а если это не удастся, отправить Message на Topic?
2. Слишком много вещей происходит в этом сервисе, и я должен разделить некоторые операции вокруг?
3. Есть ли недостатки или недостающие элементы в самом рабочем процессе, которые мы не учитываем?
4. Должны ли мы использовать 1 Topic и добавить Label к сообщению, чтобы мы знали, что это журнал и электронное письмо для отправки? Может быть, вы используете фильтры (не знаете, как это правильно сделать, или пока это подходит для этого рабочего процесса)?
5. Мы задаем слишком много вопросов в этом 1 SO сообщении и должны разделить каждый вопрос на части?

Answer 1

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

Service Bus Topics поддерживает несколько подписчиков для одного отправителя. Это достижимо с помощью подписок.

Вместо отправки сообщения двум темам можно создать две подписки в теме. См. здесь для фильтрации сообщений в Подписках с использованием Правил.

Вы можете создавать различные правила для подписок. После того, как сообщение отправлено в раздел, пользовательские свойства сообщения проверяются на соответствие правилам каждой подписки. На основании результатов проверки сообщение попадет в Подписку с обязательным условием Правила.

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

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

При получении сообщения службой фабрики обслуживания без сохранения состояния он должен запустить поток для отправки почты.

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

Служба Fabricless Service Fabric Service, которая также прослушивает сообщения из подписки журнала, создаст поток для записи в базу данных по мере поступления сообщения. В случае сбоя при записи в базу данных, сообщение в подписке журнала должно быть без букв.

Вы можете отслеживать количество сообщений о недоставленных письмах в обеих подписках, чтобы убедиться в отсутствии ошибок. Если число больше 0, необходимо вручную вмешаться в повторную отправку сообщений мертвой буквы в тему. На рынке могут быть доступны инструменты для отслеживания и повторной отправки сообщений о недоставленных письмах, или вы также можете разработать собственное приложение для этого.

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