При построении архитектуры микросервисов один из самых важных вопросов, на который нужно ответить, — это то, как различные сервисы будут взаимодействовать.
Два наиболее фундаментальных шаблона (есть ли другие?):
- RPC/RPI — удаленный вызов процедуры/удаленный вызов процедуры; это именно то, на что это похоже, и это синхронный стиль взаимодействия запрос/ответ, с которым мы все знакомы.
- Обмен сообщениями — асинхронная передача сообщений между разными службами; иногда транслируя или публикуя эти сообщения в нескольких службах одновременно.
Оба шаблона были с нами задолго до того, как микросервисы стали чем-то особенным. MSMQ, например, восходит к концу 90-х и, я уверен, просто расширяет другие идеи и концепции, существовавшие ранее.
Я думаю, что при создании современных облачных микросервисов есть явное преимущество в использовании архитектуры, ориентированной на сообщения, вместо архитектуры, ориентированной на RPC.
- Масштабируемость. позволяет различным службам масштабироваться независимо и в соответствии с их собственными профилями производительности, а не синхронно нести затраты на части приложения с разной пропускной способностью.
- Отказоустойчивость — использование обмена сообщениями позволяет системам выполнять буферизацию в случае неправильного поведения какой-либо части системы. Обмен сообщениями — в отличие от синхронного RPC — обычно имеет встроенный механизм повторной попытки (путем повторной доставки сообщения).
- Отвязка — использование сообщений позволяет полностью отделить различные службы. Каждой службе нужно знать только, что она отвечает за отправку сообщения, после чего любое количество служб может использовать это сообщение. Это позволяет службам избежать жесткой связи и позволяет добавлять службы в будущем без дополнительной связи.
Однако есть и проблемы, которые необходимо преодолеть:
- Сложность — а именно, система обмена сообщениями становится еще одним уровнем для эксплуатации, управления и обслуживания. Тем не менее, это помогает решить другую проблему сложности с RPC: обнаружение службы.
- Задержка —архитектуры, ориентированные на сообщения, как правило, имеют большую задержку, поскольку сообщения перемещаются по сети и должны быть сериализованы и десериализованы, поставлены в очередь и удалены из очереди.
- Связность — (из-за отсутствия лучшего термина) есть что сказать о высокой наглядности, отслеживаемости и «связности» прямых вызовов RPC, которые позволяют легко пройти путь от начала до конца. Напротив, архитектура, ориентированная на сообщения, может потребовать больше документации, чтобы лучше понять, кто такие производители и кто все потребители, и как они зависят от производителей.
- Сигнализация клиента. Во многих случаях действие, инициированное пользователем, может потребовать ответа; не все может быть запущено и забыто. В архитектуре, ориентированной на сообщения, это должно быть преодолено с помощью некоторого механизма для сигнализации клиенту о завершении действия. Если система интерактивная, то больше внимания нужно уделить дизайну взаимодействия с пользователем (у меня есть будущая статья и видео, посвященные этому вопросу).
Я думаю, что с внедрением облачных управляемых служб обмена сообщениями от Google, Amazon и Microsoft самая большая проблема сложности была решена путем предоставления полностью управляемых, масштабируемых и высокопроизводительных служб обмена сообщениями.
Давайте посмотрим, как работать с сервисом Google Cloud Pub/Sub и как мы можем настроить локальную разработку и тестирование.
Google Pub/Sub предоставляет эмулятор командной строки с помощью команды gcloud, но мы также можем получить контейнер с уже настроенным для нас:
Чтобы использовать это изображение, мы можем просто выполнить:
docker run --rm -ti -p 8681:8681 -e PUBSUB_PROJECT1=gps-demo,test-pub:test-sub messagebird/gcloud-pubsub-emulator:latest
И у нас будет полностью настроенный и работающий эмулятор с темой test-pub и настроенным для нас подписчиком test-sub.
Это отличный инструмент и механизм для изолированной разработки архитектуры, ориентированной на сообщения, чтобы вы могли протестировать поведение и обработку ошибок прототипа, отслеживаемость и другие аспекты дизайна системы без риска (я действительно хотел бы, чтобы Microsoft предложила аналогичную возможность). с служебной шиной Azure, но я обходился тем, что использовал темы с пространством имен напрямую в служебной шине).
Чтобы опубликовать сообщение, мы можем создать простой издатель:
И подписчик:
В обоих случаях коду не нужно создавать тему или подписку, потому что запуск контейнера уже предоставляет их для нас.
Я создал репозиторий-песочницу с полностью настроенной настройкой, которая позволяет вам быстро экспериментировать с различными сценариями обмена сообщениями с помощью Google Cloud Pub/Sub.
GitHub — CharlieDigital/gcloud-pubsub-dotnet6: проект «Песочница, демонстрирующий, как использовать Google Cloud…
Проект Песочница, демонстрирующий, как использовать Google Cloud Pub/Sub с .NET 6. Посмотрите пошаговое руководство на YouTube. - GitHub…github.com»
С такой настройкой действительно легко тестировать различные сценарии взаимодействия с ориентированным на сообщения подходом к микросервисам. В следующей статье я хочу создать более сложный пример, используя Google Cloud Run и локальный механизм для имитации того, как триггеры Google Cloud Run интегрируются с Pub/Sub.
Ваше здоровье!
Для разработки на кремнии Apple M1 вам также понадобится эта собственная библиотека gRPC (уже упакованная в зависимости в репозитории):
