Микросервисы активно набирают популярность в мире разработки. Мы хотим познакомить вас с этим трендом. Для этого мы перевели статью, в которой собраны основные понятия, связанные с этим типом архитектуры.
Насколько тесно должны быть связаны друг с другом части программного кода? Все более популярным ответом становится концепция микросервиса — небольшого, дискретного фрагмента функциональности, который взаимодействует с другими микросервисами, создавая более крупную систему. В этой статье подробно раскрываем специфику работы микросервисов.
Слово «микро» в микросервисах подразумевает, что это небольшие приложения. Их размер позволяет выполнить одну задачу или решить конкретную проблему. Эта проблема должна быть концептуальной, а не технической. По выражению Microsoft, «микросервисы должны быть разработаны вокруг бизнес-возможностей».
Внутренняя функциональность отдельного микросервиса может быть изменена или радикально модернизирована без влияния на остальную систему. Еще одним преимуществом использования микросервисов является простота развертывания. Каждый отдельный сервис можно развернуть быстро и независимо от остальной системы, используя стандартные механизмы CI/CD. Кроме того, четко определенные API делают микросервисы удобными для автотестирования.
«Архитектура микросервисов» включает в себя сами микросервисы, компоненты для управления и обнаружения сервисов, а также шлюз API, который обеспечивает связь между микросервисами и внешним миром.
«Монолитное приложение» — противоположность микросервисам. Это сокращение для обозначения приложения, в котором весь код находится в одном большом двоичном файле. Монолитное приложение сложнее масштабировать и улучшать, но им легче управлять.
Мы уже говорили, что микросервисы должны делать одну конкретную вещь. На практике этого сложно добиться. Анализ домена и проектирование с ориентацией на домен — это подходы, которые помогут вам разделить общую задачу на отдельные проблемы, которые может решить микросервис. Вы создаете абстрактную модель вашей бизнес-задачи и в процессе обнаруживаете ограниченные контексты (границы, определяющие, что может входить в систему и выходить из нее), которые объединяют функции системы.
Например, у вас может быть один ограниченный контекст для доставки и другой — для счетов. Реальный физический объект имеет цену и место, куда он должен попасть, но ограниченные контексты представляют конкретные способы, которыми ваше приложение думает об этих объектах и взаимодействует с ними. Каждый микросервис должен существовать полностью в рамках одного ограниченного контекста, хотя некоторые ограниченные контексты могут включать в себя более одного микросервиса.
Идея совместной работы небольших отдельных программ может напомнить вам о SOA (сервис-ориентированной архитектуре) и веб-сервисах — двух ключевых словах, появившихся в 2000-х годах, когда Web 2.0 был в самом разгаре. Между этими концепциями и микросервисами есть важные различия:
Некоторые из первых работ в области микросервисов возникли в сообществе Java. На конференции по Java в Польше в 2012 году была представлена одна из самых важных ранних презентаций на эту тему, озаглавленная «Микросервисы — Java, путь Unix». В ней рекомендовалось применять принципы, которыми руководствовались при разработке первых приложений Unix в 1970-х годах («Пишите программы, которые делают одно дело и делают его хорошо. Пишите программы для совместной работы»).
В результате этой истории появилось множество Java-фреймворков, позволяющих создавать микросервисы. Одним из самых популярных является Spring Boot, который специально разработан для микросервисов; Boot дополнен Spring Cloud, который, как следует из названия, позволяет развертывать эти сервисы в облаке.
Одной из самых удобных и часто используемых технологий при внедрении микросервисов являются контейнеры. Контейнер представляет собой изолированное пользовательское пространство, которое использует ядро операционной системы хоста, но в остальном код, выполняемый внутри контейнера, остается автономным.
Каждый отдельный микросервис может работать в собственном контейнере, что значительно сокращает расходы на управление сервисами. Существует несколько вариантов реализации концепции контейнеров, но самым популярным является Docker, который обычно используется в паре с Kubernetes в качестве платформы оркестровки.
Большим преимуществом микросервисов является то, что каждый отдельный сервис может быть написан на любом языке, который лучше всего подходит под конкретную ситуацию или с которым разработчикам удобнее всего работать. Сервис может быть полностью переписан на новый язык без ущерба для системы, при условии, что его API не изменяется.
Модели проектирования — это формализованные, абстрактные решения повторяющихся проблем в компьютерной науке, некоторые из них предназначены специально для микросервисов:
Одним из преимуществ использования контейнеров является то, что их можно легко развернуть в облаке, где доступны гибкие вычислительные ресурсы, позволяющие максимально повысить эффективность вашего приложения. Основные поставщики публичных облачных систем стремятся к тому, чтобы вы использовали их платформы для запуска приложений на базе микросервисов.
