Микросервис или монолит: выбираем архитектуру при разработке приложения 💻

Мы редко задумываемся о том, как работают окружающие нас сервисы. Например, в магазине мы просто прикасаемся пластиком к терминалу и спустя секунду проходит оплата. Для нас это пара мгновений в течение которых, на самом деле, происходит огромное число взаимодействий между различного рода сервисами/программами/приложениями, обеспечивающих списание денег и зачисление их в так называемый банк-эквайринг. В разработке и дальнейшей поддержке этих сервисов/программ/приложений существуют два базовых подхода: микросервисная и монолитная архитектуры. Давайте на уровне обычного пользователя попробуем разобраться в том, что это за подходы и есть ли между ними разница.

🧱 Монолитная архитектура 🧱

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

Примерами таких сервисов/приложений являются, например, StackOverflow, Slack, Booking, GitHub.

⚙️ Микросервисная (распределенная) архитектура ⚙️

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

Например, у вас есть интернет-магазин, реализованный как набор микросервисов. В таком случае будет сервис, отвечающий за предоставление информации о клиентах, сервис дающий доступ к информации о наличии запасов на складе, отдельный сервис, отвечающий за работу корзины на сайте, также отдельный сервис, который помогает клиентам оплачивать покупки.

❓Может ли быть что-то посередине? ❓

Многие разработчики начинают с монолитной архитектуры, но со временем решают перейти к микросервисам. Например, разработчики национальной платежной системы "МИР" начинали с монолита, но сейчас, из-за активного роста спроса на услуги и числа клиентов, часть функционала переводят в микросервисы. Поэтому, большие и сложные сервисы/приложения используют оба подхода, тщательно балансируя между ними не в ущерб стабильности работы.

🏁 Последний и очень близкий пример 🏁

Завершить этот небольшой рассказ про монолитную и микросервисную архитектуры хотелось бы простым примером, связанным с сайтом проекта. Сейчас он представляет собой монолит - имеется одно приложение, один пользовательский интерфейс, одна база данных. В этом приложений обрабатываются такие операции, как добавление постов, комментариев, лайков, регистрация и авторизация пользователей. Если я захочу перейти на микросервисную архитектуру, то нужно будет сделать приложение на Django для работы с постами, для управления пользовательскими аккаунтами, для сбора различного рода аналитики и пр. Управлять и разворачивать эти все сервисы проще будет с помощью того же Docker, которые позиционируется, как один из важных инструментов для создания и управления микросервисами.

Естественно, у каждой архитектуры есть свои преимущества и недостатки, но описывать их в рамках этой ознакомительной заметки, думаю, не стоит. Главная ее цель - объяснить ключевую разницу между этими подходами к разработке.