Представьте себе коммуналку, где все обитают в одной квартире, и многоквартирный дом, когда у каждого своё жильё. 

Примерно так можно описать виды организации ПО — монолитную и микросервисную архитектуры. В первом случае компоненты приложения связаны друг с другом в единое целое. Во втором — система разделена на независимые модули, которые, словно детали конструктора, можно пересобирать и заменять.    

В своей работе мы используем микросервисы, о них подробнее и расскажем.

Это более гибкая архитектура, позволяющая:

• изменять и дорабатывать отдельно каждый блок;
• упрощать и ускорять апгрейд продукта;
• эффективнее распределять мощности;

разделять обязанности в команде — каждый делает своё и не зависит от остальных.

Наличие модулей. Каждый из них работает самостоятельно и имеет свою базу данных. Если где-то произойдёт сбой, то он не повлияет на всю систему. А при изменении информации в одном блоке, не нужно корректировать другие. Модули небольшие и запрограммированы на выполнение определённой, узкой задачи.

Связь через API. Хотя блоки независимые, они «общаются» друг с другом, передавая информацию по каналам. А система API — Application Programming Interface — помогает отправлять запросы на сервер, обрабатывать информацию, получать ответы. API можно сравнить с официантом, который передаёт ваши заказы повару и приносит готовые блюда.

Использование разных языков. Блоки почти не связаны между собой, поэтому при разработке можно выбирать те языки, которые наиболее удобны. Например, веб-модули часто пишут на JavaScript, нагруженные модули — на C++ и Go, вычисление и аналитику — на Python.  Но тут стоит отметить, что это отчасти усложняет найм универсальных специалистов для поддержки.

Конкретные библиотеки и фреймворки. Если позволяют условия, можно использовать любые, но есть обязательные, поддерживающие координацию всей системы: 

✔️Docker — для контейнеризации или запуска изолированно от общей среды;

✔️Kubernetes — чтобы управлять контейнерами; 

✔️сервисы для контроля и записи лог-файлов;

✔️CI/CD — для непрерывной интеграции и развёртывания;

✔️Service Discovery — чтобы автоматически находить сервисы.

Начнём с преимуществ:

✔️Надёжность. При выходе из строя одного блока, система продолжит работать.

✔️Простота масштабирования. Увеличить мощности можно добавив новые блоки, без перенастройки всей структуры. 

✔️Удобство обновления. Не нужно переписывать приложение с чистого листа, как в случае с монолитом.

✔️Независимое развёртывание — то есть перевод блока из стадии разработки в пользование. 

✔️Большой выбор технологий. Можно использовать любые языки и инструменты.

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

Если говорить о минусах, это:

✔️Сложность контроля. Нужно следить за сотнями, а иногда и тысячами блоков, поэтому много внимания уделяется системам управления и мониторинга.

✔️Разные языки. С одной стороны — это плюс, так как команда при разработке выбирает наиболее удобные и подходящие. Но с другой стороны приходится «соединять» микросервисы между собой, чтобы они работали как единое целое. 

✔️Трудности с развёртыванием — требуются отдельные сервера, а также системы оркестрации и деплоймента.

Микросервисные архитектуры можно использовать везде. Но особенно они востребованы в следующих случаях:

✔️Большой коллектив — группы разрабов занимаются разными микросервисами и нет необходимости синхронизироваться друг с другом.

✔️Объёмный проект — корректировать и обслуживать отдельные блоки гораздо проще, чем монолитную систему.

✔️Продукт с сезонным трафиком — можно быстро масштабироваться, а в непиковое время не платить за дополнительную инфраструктуру.

✔️Приложение, которое требует частого обновления — достаточно наладить только определённый модуль, что экономит время и средства.

Подробнее о микросервисной архитектуре спрашивайте у нашей команды. Честно расскажем и оценим, насколько такая система подходит вам.