Микросервис или монолит: выбираем архитектуру при разработке приложения 💻
Мы редко задумываемся о том, как работают окружающие нас сервисы. Например, в магазине мы просто прикасаемся пластиком к терминалу и спустя секунду проходит оплата. Для нас это пара мгновений в течение которых, на самом деле, происходит огромное число взаимодействий между различного рода сервисами/программами/приложениями, обеспечивающих списание денег и зачисление их в так называемый банк-эквайринг. В разработке и дальнейшей поддержке этих сервисов/программ/приложений существуют два базовых подхода: микросервисная и монолитная архитектуры. Давайте на уровне обычного пользователя попробуем разобраться в том, что это за подходы и есть ли между ними разница.
🧱 Монолитная архитектура 🧱
Приложение представляет собой единый модуль, содержащий в себе все необходимые функции. При этом, оно работает автономно, независимо от других приложений. Монолитные приложения обычно состоят из пользовательского интерфейса на стороне клиента, базы данных и серверного приложения. Разработчики создают все эти модули в одной кодовой базе.
Примерами таких сервисов/приложений являются, например, StackOverflow, Slack, Booking, GitHub.
⚙️ Микросервисная (распределенная) архитектура ⚙️
Приложение представляет собой независимые друг от друга, небольшие, слабо связанные и легко изменяемые модули. Каждый такой модуль (микросервис) выполняет одну функцию или один элемент бизнес-логики. Микросервисы взаимодействуют друг с другом через API, а не через встроенные механизмы языка программирования.
Например, у вас есть интернет-магазин, реализованный как набор микросервисов. В таком случае будет сервис, отвечающий за предоставление информации о клиентах, сервис дающий доступ к информации о наличии запасов на складе, отдельный сервис, отвечающий за работу корзины на сайте, также отдельный сервис, который помогает клиентам оплачивать покупки.
❓Может ли быть что-то посередине? ❓
Многие разработчики начинают с монолитной архитектуры, но со временем решают перейти к микросервисам. Например, разработчики национальной платежной системы "МИР" начинали с монолита, но сейчас, из-за активного роста спроса на услуги и числа клиентов, часть функционала переводят в микросервисы. Поэтому, большие и сложные сервисы/приложения используют оба подхода, тщательно балансируя между ними не в ущерб стабильности работы.
🏁 Последний и очень близкий пример 🏁
Завершить этот небольшой рассказ про монолитную и микросервисную архитектуры хотелось бы простым примером, связанным с сайтом проекта. Сейчас он представляет собой монолит - имеется одно приложение, один пользовательский интерфейс, одна база данных. В этом приложений обрабатываются такие операции, как добавление постов, комментариев, лайков, регистрация и авторизация пользователей. Если я захочу перейти на микросервисную архитектуру, то нужно будет сделать приложение на Django для работы с постами, для управления пользовательскими аккаунтами, для сбора различного рода аналитики и пр. Управлять и разворачивать эти все сервисы проще будет с помощью того же Docker, которые позиционируется, как один из важных инструментов для создания и управления микросервисами.
Естественно, у каждой архитектуры есть свои преимущества и недостатки, но описывать их в рамках этой ознакомительной заметки, думаю, не стоит. Главная ее цель - объяснить ключевую разницу между этими подходами к разработке.
Мы редко задумываемся о том, как работают окружающие нас сервисы. Например, в магазине мы просто прикасаемся пластиком к терминалу и спустя секунду проходит оплата. Для нас это пара мгновений в течение которых, на самом деле, происходит огромное число взаимодействий между различного рода сервисами/программами/приложениями, обеспечивающих списание денег и зачисление их в так называемый банк-эквайринг. В разработке и дальнейшей поддержке этих сервисов/программ/приложений существуют два базовых подхода: микросервисная и монолитная архитектуры. Давайте на уровне обычного пользователя попробуем разобраться в том, что это за подходы и есть ли между ними разница.
🧱 Монолитная архитектура 🧱
Приложение представляет собой единый модуль, содержащий в себе все необходимые функции. При этом, оно работает автономно, независимо от других приложений. Монолитные приложения обычно состоят из пользовательского интерфейса на стороне клиента, базы данных и серверного приложения. Разработчики создают все эти модули в одной кодовой базе.
Примерами таких сервисов/приложений являются, например, StackOverflow, Slack, Booking, GitHub.
⚙️ Микросервисная (распределенная) архитектура ⚙️
Приложение представляет собой независимые друг от друга, небольшие, слабо связанные и легко изменяемые модули. Каждый такой модуль (микросервис) выполняет одну функцию или один элемент бизнес-логики. Микросервисы взаимодействуют друг с другом через API, а не через встроенные механизмы языка программирования.
Например, у вас есть интернет-магазин, реализованный как набор микросервисов. В таком случае будет сервис, отвечающий за предоставление информации о клиентах, сервис дающий доступ к информации о наличии запасов на складе, отдельный сервис, отвечающий за работу корзины на сайте, также отдельный сервис, который помогает клиентам оплачивать покупки.
❓Может ли быть что-то посередине? ❓
Многие разработчики начинают с монолитной архитектуры, но со временем решают перейти к микросервисам. Например, разработчики национальной платежной системы "МИР" начинали с монолита, но сейчас, из-за активного роста спроса на услуги и числа клиентов, часть функционала переводят в микросервисы. Поэтому, большие и сложные сервисы/приложения используют оба подхода, тщательно балансируя между ними не в ущерб стабильности работы.
🏁 Последний и очень близкий пример 🏁
Завершить этот небольшой рассказ про монолитную и микросервисную архитектуры хотелось бы простым примером, связанным с сайтом проекта. Сейчас он представляет собой монолит - имеется одно приложение, один пользовательский интерфейс, одна база данных. В этом приложений обрабатываются такие операции, как добавление постов, комментариев, лайков, регистрация и авторизация пользователей. Если я захочу перейти на микросервисную архитектуру, то нужно будет сделать приложение на Django для работы с постами, для управления пользовательскими аккаунтами, для сбора различного рода аналитики и пр. Управлять и разворачивать эти все сервисы проще будет с помощью того же Docker, которые позиционируется, как один из важных инструментов для создания и управления микросервисами.
Естественно, у каждой архитектуры есть свои преимущества и недостатки, но описывать их в рамках этой ознакомительной заметки, думаю, не стоит. Главная ее цель - объяснить ключевую разницу между этими подходами к разработке.