Как правильно реализовать микросервисную архитектуру?
Добрый день.
Хочу правильно спроектировать микросервисную архитектуру.
Делаю тестовый бэкенд для мобильного приложения. Получается будет набор различных REST сервисов, например авторизация, получение списка сообщений и т.д. Встал вопрос как эти сервисы должны между собой обмениваться данными. Первый вариант просто "дергать" их как обычный REST (то есть так же как и извне).
Других особо вариантов нет. Возможно можно использовать некую общую шину или отдельное приложение роутер.
Возможно кто-то сможет подсказать архитектурно правильный подход.
Можно сделать единый. Просто хочется понять как правильно строить микросервисную архитектуру и например на будущее переиспользовать некоторые сервисы в других проектах.
prizrak39: ну, если в учебных целях, то микросервисы могут дёргать друг друга за эндпоинты тем же самым rest. Или обмениваться сообщениями через очередь, например RabbitMQ.
prizrak39: если кэш свой, то при масштабировании появляется проблема его согласованности. Лучше доверить кэширование специально предназначенным для этого серверам, типа memcached.
prizrak39, микросервисы придуманы, чтобы их можно было раскинуть по разным машинам.
так что у них по определению общий кэш не эффективный, большая нагрузка на сеть.
вариант с двухуровневым, что выше упомянул господин L, мне представляется более адекватным.
Хочу немного резюмировать. Каждый микросервис представляется собой REST сервис, которые между собой обмениваются данными через шины (например RabbitMQ или ActiveMQ). Данные кэшируются в распределенном кэше, например memcached или redis.
