Найти в Дзене

Современная архитектура веб-приложений. Эти ваши микросервисы. Часть 1

Современная разработка нацелена на ускорение работы разработчиков и оптимизацию бизнес-процессов. Раньше приложения делали монолитными (большой цельный кусок, который разработчики всех мастей делали вместе в одном репозитории), а сейчас один проект дробят на много разных и независимых друг от друга кусочков, которые могут взаимодействовать друг с другом по определённой логике.
Ты спросишь, зачем же это нужно, ведь тогда придётся нанимать узкоспециализированных высокоплачиваемых специалистов, чтобы вести разработку. Это аргумент, но с течением времени эти затраты окупаются, потому что не нужно тратиться на поддержку целого монолита, разработка ведётся легче, а специалисты могут быть легко заменены.
Условимся, что монолит/микросервисная архитектуране являются панацеей, стандартом, гомеопатическим средством. Это всего лишь разные подходы к разработке. Давай же скорее посмотрим, как работают микросервисы, мой нетерпеливый друг!
При таком подходе, как я уже говорил, приложение состоит из

Современная разработка нацелена на ускорение работы разработчиков и оптимизацию бизнес-процессов. Раньше приложения делали монолитными (большой цельный кусок, который разработчики всех мастей делали вместе в одном репозитории), а сейчас один проект дробят на много разных и независимых друг от друга кусочков, которые могут взаимодействовать друг с другом по определённой логике.

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

Условимся, что монолит/микросервисная архитектуране являются панацеей, стандартом, гомеопатическим средством. Это всего лишь разные подходы к разработке. Давай же скорее посмотрим, как работают микросервисы, мой нетерпеливый друг!

При таком подходе, как я уже говорил, приложение состоит из нескольких независимых друг от друга частей. Это значит, что каждая часть является отдельным мини-приложением, которая выполняет определённый процесс, имеет свою базу данных, а возможно даже и свою инфраструктуру. А ещё это мини-приложение может разрабатываться отдельной командой, исходный код хранится в отдельном репозитории. И вообще, в идеале это может быть вполне себе самостоятельное приложение.

Кажется, пора рассмотреть это на каком-нибудь примере. Допустим, у нас есть интернет-магазин. У магазина есть каталог товаров и корзина для оформления заказа. И всё, больше ничего нет. У нас ведь простой магазин, не правда ли?

Как ты понимаешь, условный проект можно разделить как минимум на две части: бэк (back, backend) и фронт (front, frontend). Бэк - серверная часть, то, что обрабатывает запросы, взаимодействует с базой данных, обращается к другим сервисам. Фронт - клиентская часть, то, что видит пользователь в браузере и то, что взаимодействует с бэком.

Так вот, в нашем интернет-магазине есть этот самый фронт (между прочим, фронт это отдельный проект, отдельный репозиторий и отдельная команда, которая всё это пилит). Он представлен каталогом и корзиной. А есть бэк:
- сервис, возвращающий список продуктов в каталоге;
- сервис, отвечающий за оформление заказа.

Все они могут взаимодействовать друг с другом, например, путём отправки HTTP-запросов (см. сетевые запросы). Хотя, в целом, существуют и другие протоколы взаимодействия, но мы остановимся на HTTP.