Микросервисная архитектура

В микросервисной архитектуре приложение разбивается на ряд независимо развертываемых сервисов, которые взаимодействуют с помощью API-интерфейсов. Благодаря такому подходу каждый отдельный сервис можно развертывать и масштабировать независимо от других. В результате команды могут быстрее и чаще поставлять объемные и сложные приложения. В отличие от монолитного приложения, с микросервисной архитектурой команды могут быстрее внедрять новые возможности и вносить изменения, при этом им не приходится переписывать большие фрагменты существующего кода.

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

Современные веб-приложения запускаются в браузерах и нередко предоставляются через сеть распространения контента (CDN). Сеть CDN может доставлять веб-приложения на серверы по всему миру, чтобы их можно было быстро загрузить с помощью веб-браузеров. Сети CDN часто используют для предоставления мультимедийных ресурсов, таких как изображения, аудиозаписи и видеофайлы. Например, в этой системе через CDN предоставляются видеоролики и изображения товаров для продажи.

Приложения взаимодействуют с микросервисами через API-интерфейсы REST, которые публикует каждый микросервис. Приложения обращаются к API-интерфейсам микросервисов через API-шлюз, который также позволяет заменять одни микросервисы другими с тем же API.

Каждый микросервис состоит из сервиса и базы данных. Сервисы работают с API-интерфейсами REST, реализуют бизнес-логику и сохраняют информацию в базе данных. Ресурсы микросервисов, такие как базы данных и очереди, изолируются в соответствии с соглашением о 12-факторных приложениях.

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

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

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

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

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

Узлы в распределенной системе обеспечивают резервирование, поскольку при отказе любого узла его заменят другими. Каждый узел можно масштабировать по горизонтали и вертикали, чтобы повысить производительность. В случае большой нагрузки на систему можно добавить дополнительные узлы, которые помогут с ней справиться.

Docker — это коммерческая платформа контейнеризации и среда выполнения, с помощью которой разработчики могут создавать, развертывать и запускать контейнеры. Хотя Docker эффективно упаковывает и распределяет контейнерные приложения, запускать контейнеры и управлять ими в нужном масштабе, используя только Docker, — непростая задача.

Kubernetes — это популярная платформа с открытым исходным кодом для оркестрации контейнерных систем среды выполнения в кластере сетевых ресурсов. Ее можно использовать с платформой Docker или отдельно. Docker — это контейнерная среда выполнения, а Kubernetes — платформа для запуска контейнеров и управления ими в нескольких контейнерных средах выполнения.

Управление конфигурацией программного обеспечения — это процесс организации, отслеживания, мониторинга изменений в конфигурационных метаданных программных систем, а также управления такими изменениями. Этот процесс обычно используется совместно с системами контроля версий и инфраструктурой CI/CD.

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