Последние пару недель я изучал архитектуру служебной шины, особенно в отношении Azure Service Bus. С момента развертывания наших служб ASP.NET Web API в облаке Azure я хотел обеспечить их отказоустойчивость и масштабируемость. Поэтому я потратил некоторое время на изучение архитектур служебной шины. Как понимание концепций и теории, так и практика.

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

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

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

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

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

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

Я работал с Azure Service Bus и разработал простое доказательство концепции и соответствующие модульные тесты. Работать с ним оказалось на удивление легко. Как и следовало ожидать от Microsoft, все инструменты, необходимые для работы с Azure Service Bus, доступны в экосистеме .NET. Достаточно сказать, что теперь я буду использовать Azure Service Bus, в том числе и в своем текущем проекте.

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