Вопросы, относящиеся к микросервисной архитектуре - PullRequest
Новая
       9

Вопросы, относящиеся к микросервисной архитектуре

0 голосов
/ 20 января 2020

У меня есть пара вопросов, связанных с архитектурой микро-сервисов, например, беру следующие сервисы:

заказов , аккаунт , связь & management

Вопрос 1: Из того, что я прочитал, я понимаю, что каждый сервис предполагает владение данными, относящимися к этому сервису, поэтому у заказов будет база данных заказов. Насколько важно владение данными? Имеют ли смысл микро-сервисы, если все они звонят из одной традиционной базы данных, так что все данные, относящиеся к сервисам, будут находиться в одной базе данных? Если так, есть ли последствия структурирования услуг таким образом.

Вопрос 2. Службы должны иметь возможность общаться друг с другом. Чем это утверждение будет отличаться от простого скручивания существующего API? и основываешь логи c на этом ответе? Вызов службы более эффективен, чем простое скручивание API?

Вопрос 3: Стоит ли это того? Теперь я понимаю, что это массовое обобщение, и оно основано на потребностях бизнеса. Но когда было проведено это обсуждение, стоило ли его перестраивать? и с какими трудностями вы можете столкнуться

1 Ответ

0 голосов
/ 20 января 2020

Я постараюсь ответить на все вопросы.

  1. Уважение ко всем сервисам, использующим одну и ту же базу данных. Если вы это сделаете, у вас есть две основные проблемы. Сначала база данных станет узким местом, потому что все запросы будут go к одной и той же точке. И во-вторых, вы свяжете все свои службы, поэтому, если база данных выйдет из строя или ее потребуется обновить, все ваши службы будут затронуты. (База данных станет единой точкой отказа)

  2. Связь между службами может быть любой, в которой нуждаются ваши службы (синхронная, асинхронная, через передачу сообщений (посредник сообщений) и т. Д. c ..) все зависит от вариантов использования, которые вы должны поддерживать. Рекомендуемый способ избежать временной развязки - использовать брокер сообщений, такой как kafka, при этом ваши службы не должны знать друг друга, и в случае, если некоторые из них go отключат другие, все равно будут работать. И когда они снова встают, они могут продолжать обрабатывать сообщения, ожидающие обработки. Однако, если ваши службы должны отвечать синхронно, вы можете определить синхронную связь между службами и использовать автоматический выключатель для правильного поведения в случае сбоя службы вызываемого абонента.

  3. Архитектура микросервисов гораздо сложнее заставить его работать, контролировать и отлаживать, чем традиционная монолитная архитектура, поэтому, это будет целесообразно, если у вас будут очень большие требования к масштабируемости и доступности и / или если система очень большая и для этого потребуется несколько команд работать в разных частях системы, и рекомендуется избегать зависимостей между ними. Таким образом, каждая команда может работать в своем темпе, разворачивая свои собственные услуги

...