Согласно всезнающей википедии, микросервисы — это архитектурный стиль, при котором сложное приложение разбивается на мелкие, независимые процессы, взаимодействующие через методы API, независимых от языка. Далеко не самое выдающееся определение, которое исчерпывающе бы определило понятие! Поэтому довольно часто помимо формального определения используется ряд свойств, чтобы причислить архитектуру приложения к разряду микросервисов. Вот некоторые из них:
В замечательной статье М. Фаулер и Дж. Луис описывают и другие свойства архитектуры, построенной на микросервисах, но мне кажется, что они логично вытекают из вышеперечисленного.
Проектируя программное приложение, необходимо пытаться сузить границы распределения кода до минимально возможных пределов, и там, где распределения не миновать, уделять этим границам самое пристальное внимание. М.Фаулер.
На мой взгляд, микросервисы — это своеобразный SOLID-принцип на уровне приложений. Вполне логично, что каждый микросервис решает задачи, связанные с единственным или несколькими неразделимыми объектами домена (The Single Responsibility Principle). Также любой сервис, по своей природе, открыт для расширения, но его трудно модифицировать, особенно не имея доступа к исходному коду (The Open Closed Principle). В силу того, что сервисы взаимодействуют между собой по контракту, то имеется возможность заменять одну реализацию сервиса, на другую (The Liskov Substitution Principle), конечно, если он соответствует контракту. При проектировании микросервисов, также как и в объектно-ориентированном программировании, имеет смысл по возможности разделять сервисы на более мелкие, тем самым реализуя принцип разделения интерфейсов (Interface segregation principle). Ну и безусловно наши микросервисы не должны зависеть от реализации ни самого микросервиса, ни других используемых компонент (The Dependency Inversion Principle)
Например, на ранних порах разработчики системы могут решить использовать «архитектуру микрослужб», посчитав, что такая архитектура значительно облегчает разработку, потому что компоненты имеют четко очерченные границы, а интерфейсы относительно устойчивы. Однако когда дело доходит до развертывания системы, они могут обнаружить, что количество микрослужб оказалось слишком велико, настройка соединений между ними и синхронизация их запуска могут оказаться неисчерпаемым источником ошибок. Роберт Мартин.
Согласно CCP : если два класса изменяются вместе по одной и той же причине, они должны входить в один пакет.
В настоящее время в сообществе бытуют два мнения о том, как построить приложение, используя микросрвисную архитектуру и не допустив в ней грубых ошибок:
Хотя при построении микросервисов мне ближе второй подход, вопрос о том, какой путь использовать, определяется необходимостью получения преимуществ микросервисной архитектуры: принцип YAGNI никто не отменял.
В целом же, выбор той или иной архитектуры зависит от многих конкретных обстоятельств, и это — тема, скорее, для отдельной книги, нежели статьи. Но я надеюсь, что теперь в вашем арсенале появится ещё один один архитектурный стиль, основанный на микросервисах.