Микросервисы. Ваш следующий выбор

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

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

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

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

Внутренняя функциональность отдельного микросервиса может быть изменена или радикально модернизирована без влияния на остальную систему. Еще одним преимуществом использования микросервисов является простота развертывания. Каждый отдельный сервис можно развернуть быстро и независимо от остальной системы, используя стандартные механизмы CI/CD. Кроме того, четко определенные API делают микросервисы удобными для автотестирования.

Микросервисы vs Монолит

«Архитектура микросервисов» включает в себя сами микросервисы, компоненты для управления и обнаружения сервисов, а также шлюз API, который обеспечивает связь между микросервисами и внешним миром.

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

Микросервисы и ограниченный контекст

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

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

Микросервисы vs сервис-ориентированная архитектура vs веб-сервисы

Идея совместной работы небольших отдельных программ может напомнить вам о SOA (сервис-ориентированной архитектуре) и веб-сервисах двух ключевых словах, появившихся в 2000-х годах, когда Web 2.0 был в самом разгаре. Между этими концепциями и микросервисами есть важные различия:

  • В сервис-ориентированной архитектуре отдельные компоненты часто совместно используют такие ресурсы, как хранилище, и взаимодействуют через специализированное программное обеспечение, называемое корпоративной шиной хранения данных. Микросервисы более независимы, используют меньше ресурсов и взаимодействуют через более легковесные протоколы. Микросервисы возникли в среде SOA, и иногда их считают разновидностью SOA или преемником этой концепции.
  • Веб-сервис это общедоступный набор функций, к которым другие приложения могут получить доступ через Интернет; самым распространенным примером являются карты Google Maps, которые могут быть встроены в сайт ресторана для предоставления маршрутов клиентам. Это более слабая связь, чем в архитектуре микросервисов.

Микросервисы, Java, Spring Boot и Spring Cloud

Некоторые из первых работ в области микросервисов возникли в сообществе Java. На конференции по Java в Польше в 2012 году была представлена одна из самых важных ранних презентаций на эту тему, озаглавленная «Микросервисы Java, путь Unix». В ней рекомендовалось применять принципы, которыми руководствовались при разработке первых приложений Unix в 1970-х годах («Пишите программы, которые делают одно дело и делают его хорошо. Пишите программы для совместной работы»).

В результате этой истории появилось множество Java-фреймворков, позволяющих создавать микросервисы. Одним из самых популярных является Spring Boot, который специально разработан для микросервисов; Boot дополнен Spring Cloud, который, как следует из названия, позволяет развертывать эти сервисы в облаке.

Микросервисы и контейнеры: Docker, Kubernetes и не только

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

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

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

Модели проектирования микросервисов

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

  • Service Registry: для подключения клиентов к доступным экземплярам микросервисов.
  • Circuit Breaker: для предотвращения повторного вызова отказавших служб.
  • Fallback: для обеспечения альтернативы отказавшему сервису.
  • Sidecar: для обеспечения вспомогательного сервиса для основного контейнера, например, для ведения логов, синхронизации сервисов или мониторинга.
  • Adapter: для стандартизации или нормализации интерфейса между основным контейнером и внешним миром.
  • Ambassador: для подключения основного контейнера к внешнему миру, например, для проксирования соединений локального хоста на внешние соединения.

Микросервисы и облако: AWS и Azure

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

 

Микросервисы. Ваш следующий выбор