Как правильно реализовать микросервисную архитектуру?

Question

[prizrak39]

Добрый день.

Хочу правильно спроектировать микросервисную архитектуру.
Делаю тестовый бэкенд для мобильного приложения. Получается будет набор различных REST сервисов, например авторизация, получение списка сообщений и т.д. Встал вопрос как эти сервисы должны между собой обмениваться данными. Первый вариант просто "дергать" их как обычный REST (то есть так же как и извне).
Других особо вариантов нет. Возможно можно использовать некую общую шину или отдельное приложение роутер.
Возможно кто-то сможет подсказать архитектурно правильный подход.

Заранее спасибо.

Answer 1

[Сергей Горностаев]

В большинстве случаев правильно её вообще не реализовывать. Вы — не Google.

Comments

[prizrak39]

Тогда не совсем понимаю какую архитектуру правильнее всего использовать в данной ситуации?

[Сергей Горностаев]

prizrak39: почему бы не сделать единый rest-сервис?

[prizrak39]

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

[Сергей Горностаев]

prizrak39: ну, если в учебных целях, то микросервисы могут дёргать друг друга за эндпоинты тем же самым rest. Или обмениваться сообщениями через очередь, например RabbitMQ.

[prizrak39]

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

[Сергей Горностаев]

prizrak39: если кэш свой, то при масштабировании появляется проблема его согласованности. Лучше доверить кэширование специально предназначенным для этого серверам, типа memcached.

[L17217]

prizrak39: и так и так.
Двухуровневый.
Свой кэш быстрее. Но общий - имеет преимущества описанные выше

[semt1]

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

вариант с двухуровневым, что выше упомянул господин L, мне представляется более адекватным.

Answer 2

[L17217]

Во первых. Шина это MQ. Например RabbitMQ

Основная цель микросервисного ПО горизонтальное масштабирование. Из этого и следует второй пункт.

Ну и 3. Всем этим придется рулить. Рекомендую для рулежки использовать Flynn.io.

Comments

[lobbobobby]

Яростно плюсую за flynn. Он у нас уже второй год. Нарадоваться не можем.

Answer 3

[prizrak39]

Хочу немного резюмировать. Каждый микросервис представляется собой REST сервис, которые между собой обмениваются данными через шины (например RabbitMQ или ActiveMQ). Данные кэшируются в распределенном кэше, например memcached или redis.