В последние несколько десятилетий одной из самых важных целей в программировании систем может быть разделение зависимостей.

Отсюда интерфейсы, абстракции, библиотеки и т.д. и т.п.

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

Что такое очередь сообщений?

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

Парадигма очереди сообщений является родственной моделью издатель/подписчик... Они используют очередь для обмена сообщениями — передачи управления или контента. — https://en.wikipedia.org/wiki/Message_queue

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

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

Мой любимый пример

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

В своей демонстрации я сначала заменил логику отправки квитанции по электронной почте (чертовски много кода!) на отправку простого сигнала в очередь сообщений и сказал: «ага, развертывание готово к работе». Я помню все лица в комнате.

Конечно, развертывание на самом деле еще не готово к работе, далее я объяснил, как сообщение «сохраняется» в очереди, любое приложение, которое слушает эту очередь, может помочь отправить квитанцию ​​по электронной почте (или любым другим способом).

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

Наш новый поток реализации

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

НЕЕЕЕТ!!! Мой дизайн был ИДЕАЛЬНЫМ!!! — Архитектор Coding Cat

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

Короче говоря, сейчас мы разрабатываем компоненты, как будто это какие-то веб-сервисы. Сначала мы определяем, что является входом и выходом для «конечной точки», проверяем, есть ли шанс сделать ее универсальной службой (левая панель: P) (ах… не совсем), затем мы назначаем для нее любого разработчика.

Подождите… Чем это отличается от подхода сборки?

Прежде всего, при игре в .NET все зависимости от ваших сборок также будут включены в ваш проект (любой, кто должен был разрешить привязку версии пакетов NuGet, узнает). Но этого не произойдет с очередью сообщений, когда компонент A даже не знает, есть ли компонент B, как уже упоминалось.

Раньше, когда требовалось обновление сборки, нам нужно было загружать новые файлы на все наши серверы. Это расстраивает, когда вам нужен список серверов под рукой и выполняется загрузка для каждого сервера (и тестирование!). Теперь нам достаточно один раз развернуть новую версию. Поскольку компоненты больше не живут в системе, они живут в экосистеме.

Более того, иногда зависимости сборок конфликтуют, однажды мы столкнулись с большой головной болью, что 2 разные сборки зависят от одной и той же библиотеки, но конфликтуют версии 2. Разделение операций на 2 приложения решило эту проблему как чемпион, угадайте, как они могли общаться друг с другом? — Очередь сообщений.

Подведение итогов

Я не говорю, что очередь сообщений (или SoA) решит все проблемы с программированием/системой, я считаю, что в мире нет серебряной пули. Что я пытаюсь выразить, так это то, что введение очереди сообщений в наши системы действительно помогло определить границы компонентов и упростить разделение проблем компонентов.

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

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