Знакомство с архитектурой микрослужб
Сегодня термин "микрослужба" у всех на слуху. Микрослужба — это автономный, независимо развертываемый, масштабируемый компонент программного обеспечения.
Они маленькие, сосредоточены на выполнении одной вещи хорошо, и могут работать автономно. Изменения в одной микрослужбе не должны влиять на другие микрослужбы в вашем ландшафте.
Выбирая архитектуру микрослужб, вы создаете ландшафт служб, которые можно разрабатывать, тестировать и развертывать по отдельности. С этим связаны определенные риски и сложности.
Было бы лучше, если вы создали его, чтобы отслеживать интерфейсы и как они взаимодействуют. Кроме того, вам придется поддерживать несколько жизненных циклов приложений вместо одного.
Традиционное приложение зачастую имеет многоуровневую архитектуру.
Это могут быть уровни пользовательского интерфейса, бизнес-логики и служб, а также служб данных.
В некоторых случаях пользовательским интерфейсом и серверной частью занимаются специализированные команды. В таком приложении изменения необходимо производить на всех уровнях.
При переходе к архитектуре микрослужб все эти уровни становятся частью одной микрослужбы.
При этом микрослужба реализует одну конкретную функцию.
Взаимодействие между микрослужбами выполняется асинхронно.
Они не вызывают друг друга напрямую, но используют асинхронные механизмы, такие как очереди или события.
Каждая микрослужба имеет свой жизненный цикл и конвейер непрерывной поставки. Если вы создали их правильно, можно развернуть новые версии микрослужб, не влияя на другие системные части.
Архитектура микрослужб, несомненно, не является обязательным условием для непрерывной доставки, но небольшие компоненты программного обеспечения помогают реализовать полностью автоматизированный конвейер.