При проектировании микросервисной архитектуры нам необходимо решить уже всем знакомые вопросы:
— Как построить Service Mesh?
— Как реализовать балансировку нагрузки?
— Как отлаживать и деплоить релизы?

Представьте, что необходимо, чтобы ваше решение базировалось не в одном ЦОДе, а имело возможность масштабироваться на сотни, тысячи и более. Уметь работать в условиях плохого канала связи, иногда в оффлайне и при этом решение должно быть необслуживаемым, легким и умело High Availability (HA).
Классический подход REST API требует реализовать инфраструктуру поддержки Service Mesh. Всегда есть риск получения “мертвых” endpoints, timeouts и retry. Что делать, когда мы хотим в динамике перехватить сообщения между сервисами, не модифицируя код и не “пропиливая” кучу дыр в инфраструктуре?
Решение есть! NATS, поддерживающий pattern request/reply, — это почти классический REST API, но решает проблемы балансировки, очень легкий и практически не требует обслуживания.
NATS поддерживает Header и есть возможность встроить в проект, к примеру, OpenTelemetry/Jaeger.
Nats обеспечивает также persistent message (JetStream), поддерживает технологию hub/leaf, умеет из коробки mirror и source, key value и object storage с поддержкой event-driven модели.
И все же, есть вопросы которые необходимо знать:
— С шиной тоже не все гладко. Можно сказать, что это единая точка отказа, и сервисам все-таки надо знать, как минимум, где находится шина. Чтобы снизить риск единой точки отказа, можно собрать кластер (2/3/5 нод).
— JetStream — не так быстр как Kafka, и это не замена Kafka. Это разные решения для разных задач. К слову, NATS прекрасно интегрируется с Kafka, есть шлюз.