Я не думаю, что вы получите определенный список правил, с которым все согласятся. Основная причина в том, что всегда найдется кто-то, кто назовет свое решение "микросервисами", или любым другим модным паттерном, нарушая при этом большинство идей, лежащих в основе паттерна.
Википедия, кажется, согласна со мной:
С течением времени в отрасли сформировалось консенсусное мнение. Некоторые из определяющих характеристик, которые часто упоминаются, включают:
- Сервисы в микросервисной архитектуре часто представляют собой процессы, которые взаимодействуют по сети для достижения цели с помощью протоколов, не зависящих от технологии, таких как HTTP.Не существует единого определения микросервисов.
- Услуги организованы вокруг бизнес-возможностей.
- Услуги могут быть реализованы с использованием различных языков программирования, баз данных, аппаратных и программных сред, в зависимости от того, что подходит лучше всего.
- Услуги имеют небольшой размер, поддерживают обмен сообщениями, ограничены контекстами, автономно разрабатываются, независимо развертываются, децентрализованы, создаются и выпускаются с помощью автоматизированных процессов.
На мой взгляд, микросервисы - это столько же, или даже больше, организационная модель, сколько и технологическая. Одна из основных идей заключается в том, что она должна сделать команды разработчиков более независимыми друг от друга. Большинство технологий вытекают из этого требования:
Хотя вы, вероятно, можете следовать этому шаблону, даже если вы работаете в одной команде, я думаю, что это потребует исключительной дисциплины. Если вы отвечаете за несколько сервисов, я подозреваю, что существует большой соблазн ввести зависимости между сервисами. Но я не работал ни над одной крупномасштабной микросервисной системой, поэтому не могу претендовать на роль эксперта.
Прикрепляю к посту несколько видео по теме: