Как думать о микросервисах?

Question

Я нахожусь в процессе обучения преобразованию моего монолитного приложения GAE в архитектуру микросервисов.

Я понимаю, что приложение разделено на службы, которые могут взаимодействовать друг с другом.Различные категории запросов обрабатываются различными службами, как указано в файле dispatch.yaml.

Как мы определяем, что сделать в службу?Рассмотрим веб-сайт доски объявлений о работе, который имеет следующие функциональные возможности:

• Существует две роли пользователя: JobSeeker и Company
• Компании могут опубликовать Job сущность
• Соискатели могут создать JobApplication сущность (что соответствует Job)
• Для обеих ролей пользователя может потребоваться проверка подлинности
• Компании управляют своими собственными CompanyProfile
• JobSeekers управляют своим собственным списком JobApplications и своими JobProfiles

Каков руководящий процесс мышления, который идет в разделение нашего приложения на микросервисы?

Answer 1

Некоторые места, в которых микросервисы имеют преимущество перед монолитным приложением:

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

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