Close

Microservices: understanding what it is and its benefits

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

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

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

Что такое микросервисы?


Микросервисная архитектура (или просто «микросервисы») — это подход к созданию приложения в виде набора независимо развертываемых сервисов, которые являются децентрализованными и разрабатываются независимо друг от друга. Эти сервисы слабо связаны, независимо развертываются и легко обслуживаются. Монолитное приложение создается как единое и неделимое целое, тогда как в микросервисной архитектуре его разбивают на множество независимых модулей, каждый из которых вносит свой вклад в общее дело. Микросервисы неразрывно связаны с DevOps, поскольку лежат в основе методики непрерывной поставки, благодаря которой команды могут быстро адаптироваться к требованиям пользователей.

Рисунок: микросервисная архитектура

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

При использовании микросервисной архитектуры разработчики могут разделиться на небольшие команды, которые будут работать над разными сервисами, использовать разные стеки и независимо выполнять развертывания. Например, в основе Jira лежит множество микросервисов, каждый из которых предоставляет определенные возможности: поиск задач, просмотр сведений о задачах, комментирование, изменение состояния задач и многое другое.

Характеристики микросервисной архитектуры


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

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

Преимущества микросервисной архитектуры


Microservices provide many advantages. They simplify development and project management. Sometimes, they may eliminate the need for separate operations teams since developers can handle operations for the microservices they build. 

Some other benefits of microservices include:

Рисунок: весы

Гибкое масштабирование

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

Рисунок: Agile

Agility

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

Рисунок: ящик для инструментов

Гибкая технология

При использовании микросервисной архитектуры от команд не требуют строго следовать определенному подходу и работать с одним пакетом инструментов. Они могут свободно выбирать ПО с учетом своих предпочтений.

Рисунок: детали конструктора

Частые релизы

Одним из основных преимуществ микросервисной архитектуры являются частые и быстрые циклы релизов. Благодаря микросервисной архитектуре, которая выступает ключевым элементом непрерывной интеграции и непрерывной поставки (CI/CD), команды могут экспериментировать с новыми возможностями, а если что-то пойдет не так — выполнить откат и вернуться к предыдущей версии. Это упрощает обновление кода и ускоряет вывод новых возможностей на рынок.

Проблемы микросервисной архитектуры


Microservices-based architecture has many benefits, but it also comes with challenges. 

One challenge of microservices is that the independent services generate their logs. This is a disadvantage compared to monoliths' centralized logs, which provide a single source of truth for developers and operations teams. Monitoring and infrastructure management are also more complicated since many moving pieces exist. Testing and debugging are challenging because, unlike monoliths, no integrated development environment (IDE) exists.

Atlassian's Compass can help with all these challenges. Compass facilitates collaboration and allows companies to manage the complexities of distributed architectures as they scale. It does this by bringing the disconnected information together in a central, searchable location.

Разрастание процесса разработки

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

Неопределенность в вопросах владения

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

Экспоненциальный рост расходов на инфраструктуру

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

Дополнительные организационные расходы

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

Отладка

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

Реагирование на инциденты

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

Микросервисы и DevOps — одного поля ягоды


Учитывая повышенную сложность и зависимости между микросервисами, методы DevOps при развертывании, мониторинге и автоматизации управления жизненным циклом становятся неотъемлемой частью микросервисных архитектур. Поэтому микросервисную архитектуру часто считают первым шагом к внедрению культуры DevOps, которая дает следующие преимущества:

  • Автоматизация
  • Улучшенная масштабируемость
  • Управляемость
  • Agility
  • Ускоренная поставка и развертывание

Ключевые технологии и инструменты для микросервисной архитектуры


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

В связи с распространением сервисов и контейнеров возникла необходимость в оркестрации больших групп контейнеров и управлении ими. Docker — это популярная платформа контейнеризации и среда выполнения, с помощью которой разработчики могут создавать, развертывать и запускать контейнеры. Однако с помощью только лишь Docker сложно запускать контейнеры и управлять ими в большом масштабе. Решить проблему контейнеризации при любом масштабе помогают Kubernetes и другие решения: Docker Swarm, Mesos, HashiCorp Nomad и др.

Контейнеризация и развертывание контейнеров — это новая модель распределенной инфраструктуры. С помощью Docker и Kubernetes сервис упаковывают в полнофункциональный контейнер, который можно быстро развернуть или удалить. Эти инфраструктурные инструменты дополняют микросервисную архитектуру. Микросервисы можно помещать в контейнеры, без труда развертывать, а также управлять ими с помощью системы управления контейнерами.

Что такое микросервисы?


Микросервисная архитектура (или просто «микросервисы») — это подход к созданию приложения в виде набора независимо развертываемых сервисов, которые являются децентрализованными и разрабатываются независимо друг от друга. Эти сервисы слабо связаны, независимо развертываются и легко обслуживаются. Монолитное приложение создается как единое и неделимое целое, тогда как в микросервисной архитектуре его разбивают на множество независимых модулей, каждый из которых вносит свой вклад в общее дело. Микросервисы неразрывно связаны с DevOps, поскольку лежат в основе методики непрерывной поставки, благодаря которой команды могут быстро адаптироваться к требованиям пользователей.

Рисунок: микросервисная архитектура

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

При использовании микросервисной архитектуры разработчики могут разделиться на небольшие команды, которые будут работать над разными сервисами, использовать разные стеки и независимо выполнять развертывания. Например, в основе Jira лежит множество микросервисов, каждый из которых предоставляет определенные возможности: поиск задач, просмотр сведений о задачах, комментирование, изменение состояния задач и многое другое.

Будущее микросервисов


What tools do people commonly use in microservices?

Businesses often use containerization tools such as Kubernetes and Docker. They also frequently use API gateways between microservices and their clients. These gateways perform API traffic functions such as authentication, access control, and load balancing.

How do microservices differ from monolithic architecture?

Monoliths are large codebases that function as one system. They require system downtime for updates and debugging. Microservices architectures are distributed applications with smaller, independent chunks of functionality. Developers can upgrade, improve, and debug these modules without taking the entire application offline. This simplifies scaling and aids development velocity.

How do microservices impact DevOps?

Those who understand DevOps know that continuous integration and continuous delivery (the DevOps CI/CD pipeline) are the mainstays of DevOps methodologies. The modular nature of microservices aligns perfectly with this approach. Microservices empower developers to swiftly create, test, and deploy small, frequent releases.

Join the Atlassian Community for more microservices articles and discussions.

Навигация по микросервисам с помощью Compass

При работе с микросервисной архитектурой можно использовать Atlassian Compass для управления сложностью масштабируемой распределенной архитектуры. Это расширяемая платформа для разработчиков, которая объединяет разрозненные сведения о совместной работе команд и результатах разработки в одном центре с возможностью поиска. Решение Compass поддержит вас в борьбе с разрастанием микросервисов благодаря каталогу компонентов. Кроме того, с его помощью можно внедрить рекомендации, оценить работоспособность программного обеспечения по картам оценки, а также распространить данные и аналитику по всему пакету инструментов DevOps с помощью расширений на платформе Atlassian Forge.

Рисунок: микросервисы в Compass