Давайте попробуем разобраться в устройстве системы службы уведомлений.

Мы все хорошо знаем об уведомлениях, которые получаем от различных приложений. Мы получаем уведомление о различных действиях/услугах, например, когда мы заказываем что-то у Zomato, MakeMyTrip или Uber на любой подобной платформе. Однако, поскольку этот процесс настолько встроен в систему, мы никогда не удосуживаемся узнать о функциональных возможностях любой такой системы.

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

Требования к системе уведомлений

Таким образом, в нашей службе уведомлений мы должны знать о различных функциях, которые мы хотим реализовать, а также об основных требованиях, которые должна содержать система уведомлений. Итак, давайте обсудим основные возможности такой системы.

Высокая масштабируемость и доступность

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

Ограничитель скорости

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

Отслеживаемость

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

приоритет

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

Система оповещения

Система уведомлений — своего рода обязательная услуга почти в каждом продукте. Если у вас нет надлежащей системы уведомлений, есть большая вероятность, что вы потеряете некоторые из лучших пользовательских интерфейсов, которые могут быть предоставлены клиентам. Эта статья в основном посвящена разработчику программного обеспечения, который хотел бы разработать такую ​​систему, а также может быть кратким пояснением для вашего следующего собеседования по проектированию системы.

Итак, у нас уже есть готовая базовая архитектура. Что касается создания любого сложного продукта, нам нужно четко понимать основы, потому что даже Рим не строился за один день, так как мы можем ожидать того же от нашего продукта.

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

Поскольку у нас есть система уведомлений Saas, конечно, у нас будут разные клиенты. Давайте обсудим все услуги в хронологическом порядке.

Служба внешнего обработчика.

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

Служба управления пользователями и Служба предпочтений уведомлений

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

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

Механизм организации очереди (Rabbit MQ).

Нам нужен какой-то механизм очередей в системе, поскольку у нас будут разные клиенты, которые будут отправлять уведомления снова и снова. Уведомление — это то, что будет иметь разные приоритеты, и мы не можем позволить себе их потерять.

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

Балансировщик нагрузки

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

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

Служба управления уведомлениями

Служба управления уведомлениями является своего рода сердцем всего нашего приложения. Наша служба управления уведомлениями будет взаимодействовать с Rabbitmq, то есть с нашей службой очередей, службой управления пользователями, настройками уведомлений, ограничением скорости и службой.

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

Помимо получения данных, связанных с пользователем, и службы управления уведомлениями также должны знать о предпочтениях уведомлений, которые выбрал пользователь. Например, пользователь мог запросить уведомление по электронной почте с 10:00 до 22:00.

У нас есть данные служб, связанных с пользователями, объединенные со службами управления уведомлениями. Мы готовы к окончательной отправке проанализированных данных в другую очередь. Таким образом, причиной помещения данных в другую очередь является создание нескольких каналов для разных устройств, таких как электронная почта, SMS-уведомления по телефону и т. д.

Информационная служба метаданных уведомлений

Мне нужна информационная служба метаданных уведомлений, которая не что иное, как трекер, который будет хранить критически важную информацию.

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

Имея статистику о том, что конкретный сервис берет на себя большую нагрузку по сравнению с другими сервисами, мы сможем добиться функциональности. Кроме того, сбор метаданных поможет нам лучше спроектировать нашу систему, зная важную информацию, такую ​​как тип уведомлений, которые обычно используются.

Последняя очередь

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

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

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

Последние мысли

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

Очень популярный вариант использования, который slack недавно поделился с помощью блок-схемы, — это когда пользователь входит в систему на разных устройствах. Но часто пользователь хочет получать уведомления только на одном устройстве за раз. Таким образом, такие варианты использования нам нужно обрабатывать.

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

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

Цитата дня.

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

Об авторе

Апурв Томар — разработчик программного обеспечения, входящий в состав Mindroast. Вы можете связаться с ним в Twitter, Linkedin, Telegram и Instagram. Подпишитесь на новостную рассылку, чтобы быть в курсе последних обновлений. Не стесняйтесь сказать Привет на любой платформе, просто указав, где вы нашли мой профиль.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Посетите наш Community Discord и присоединитесь к нашему Коллективу талантов.