архитектура spring boot приложения
Учимся разворачивать микросервисы. Часть 1. Spring Boot и Docker
В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет «обвешивать» всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.
Изначально я разбил создание проекта на несколько шагов:
Создать два сервиса — ‘бекенд’ (backend) и ‘шлюз’ (gateway), упаковать их в docker-образы и настроить их совместную работу
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Ключевые слова: Helm 3, chart deployment
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Каждому шагу я планирую посвятить отдельную статью.
Направленность этого цикла статей заключается не в том, как написать микросервисы, а как заставить их работать в единой системе. Хоть все эти вещи обычно лежат за пределами ответственности разработчика, думаю, что все равно полезно быть знакомым с ними хотя бы на 20% (которые, как известно, дают 80% результата). Некоторые безусловно важные темы, такие как обеспечение безопасности, будут оставлены за скобками этого проекта, так как автор в этом мало что понимает система создается исключительно для личного пользования. Я буду рад любым мнениям и конструктивной критике.
Создание микросервисов
Сервисы были написаны на Java 11 с использованием Spring Boot. Межсервисное взаимодействие организовано с использованием REST. Проект будет включать в себя минимальное количество тестов (чтобы потом было, что тестировать в Jenkins). Исходный код сервисов доступен на GitHub: бекенд и шлюз.
Чтобы иметь возможность проверить состояние каждого из сервисов, в их зависимости был добавлен Spring Actuator. Он создаст эндпойнт /actuator/health и будет возвращать 200 статус, если сервис готов принимать траффик, или 504 в случае проблем. В данном случае это довольно фиктивная проверка, так как сервисы очень просты, и при каком-то форсмажоре они скорее станут полностью недоступны, чем сохранят частичную работоспособность. Но в реальных системах Actuator может помочь диагностировать проблему до того, как об нее начнут биться пользователи. Например, при возникновении проблем с доступом к БД, мы сможем автоматически на это среагировать, прекратив обрабатывать запросы сломанным экземпляром сервиса.
Сервис Backend
Сервис бекенда будет просто считать и отдавать количество принятых запросов.
Тест на контроллер:
Сервис Gateway
Шлюз будет переадресовывать запрос сервису бекенда, дополняя его следующей информацией:
Микросервисы со Spring Boot. Часть 1. Начало работы
Это первая часть серии статей по основам микросервисных архитектур.
В ней вы познакомитеь с концепцией микросервисов и узнаете, как создавать микросервисы с помощью Spring Boot и Spring Cloud.
Это руководство поможет вам изучить основы микросервисных архитектур. Мы также начнем рассматривать базовую реализацию микросервиса со Spring Boot.
Мы создадим пару микросервисов и заставим их общаться друг с другом с помощью сервера имен Eureka (Eureka Naming Server) и Ribbon для балансировки нагрузки на стороне клиента.
Это статья входит в серию статей «Микросервисы со Spring Boot»:
Вы изучите
Обзор ресурсов
В этом руководстве мы создадим ресурс для студентов, предоставляющий три сервиса с использованием соответствующих URI и методов HTTP:
Обзор микросервисов — общая картина
В этой серии статей мы создадим два микросервиса:
Не беспокойтесь, если вам будут не ясны некоторые вещей. Идея состоит в том, чтобы дать вам общую картину, прежде чем мы начнем разработку и шаг за шагом создадим микросервисы.
Форекс сервис
Форекс сервис (FS, Forex Service) является поставщиком услуг. Он предоставляет стоимость обмена валюты для различных валют. Давайте предположим, что он общается с Forex Exchange и предоставляет текущую стоимость обмена между валютами. Пример запроса и ответа показан ниже:
Ответ на запрос выше является обменным курсом евро к INR. В ответе ConversionMultiple равно 75.
О поле port мы поговорим чуть позже.
Сервис конвертации валют
Сервис конвертации валют (CCS) может конвертировать множество валют в другую валюту. Он использует сервис Forex для получения текущих значений обмена валюты. CCS является потребителем услуг. Пример запроса и ответа показан ниже:
Запрос выше позволяет определить стоимость 10000 евро в индийских рупиях.
TotalCalculatedAmount составляет 750000 INR. Диаграмма ниже показывает связь между CCS и FS.
Eureka Naming Server и Ribbon
В зависимости от нагрузки у нас может быть несколько экземпляров Сервиса конвертации валют и Сервиса Форекс.
И количество экземпляров для каждого сервиса может меняться со временем. На рисунке ниже показан конкретный пример, где созданы 5 экземпляров сервиса Forex.
Что должно произойти в вышеуказанной ситуации, так это то, что нагрузка должна быть равномерно распределена между этими 5 экземплярами.
В этой серии статей мы будем использовать Ribbon для балансировки нагрузки и сервер имен Eureka для регистрации всех микросервисов.
Что такое монолитное приложение?
Вы когда-нибудь работали в проекте…
Монолитные приложения обычно огромны — более 100 000 строк кода. В некоторых случаях даже более миллиона строк кода.
Монолиты характеризуются следующим:
Микросервисы
Небольшие автономные сервисы, которые работают совместно — Сэм Ньюман (Sam Newman)
Разработка отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с облегченными механизмами, часто API-интерфейсом HTTP-ресурсов. Эти сервисы построены на бизнес-возможностях и могут быть развернуты независимо с помощью полностью автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими службами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных — Джеймс Льюис (James Lewis) и Мартин Фаулер (Martin Fowler)
Хотя для микросервисов нет единого принятого определения, имеется несколько важных характеристик:
Как выглядит микросервисная архитектура?
Вот так будет выглядеть монолит. Одно приложение для всего.
Так будет выглядеть то же приложение при разработке с использованием Microservices Architecture.
Микросервисные архитектуры включают несколько небольших, хорошо спроектированных компонентов, взаимодействующих с помощью сообщений.
Преимущества микросервисов
Проблемы микросервисных архитектур
Хотя разработка нескольких небольших компонентов может показаться легкой, существует ряд присущих ей сложностей, связанных с архитектурами микросервисов.
Давайте рассмотрим некоторые из проблем:
Решения проблем микросервисных архитектур
Spring Boot
Spring Boot позволяет быстро создавать готовые приложения и предоставляет предоставляетследующие нефункциональные возможности:
Spring Cloud
Spring Cloud предоставляет решения для облачной активации ваших микросервисов. Он использует и основывается на некоторых облачных решениях, созданных компанией Netflix (Netflix OSS).
Важные модули Spring Cloud
Прим. перев. Автор далее частично повторяет уже сказанное. Сохранена оригинальная редакция (без удаления повторов)
Мы хотели бы иметь возможность динамически увеличивать и уменьшать количество экземпляров каждого из этих сервисов.
И количество экземпляров для каждого сервиса может меняться со временем. На рисунке ниже показан конкретный пример, где созданы 5 экземпляров сервиса Forex.
Реализация решения для динамического масштабирования вверх и вниз требует ответа на два вопроса:
Все экземпляры компонентов (CCS и FS) регистрируются на сервере имен Eureka. Когда FS должен вызвать CCS, он запросит Eureka Naming Server об активных экземплярах. Мы будем использовать Ribbon для балансировки нагрузки на стороне клиента между различными экземплярами FS.
Ниже приведена высокоуровневая диаграмма последовательности того, что будет происходить при запросе от CCS к FS.
Разработка Spring Boot-приложений с применением архитектуры API First
В этом материале я приведу практический пример реализации архитектуры API First с применением спецификации OpenAPI. А именно, сначала расскажу о том, как создал определение API, а затем — о том, как, на основе этого определения, создал серверную и клиентскую части приложения. В процессе работы у меня возникли некоторые сложности, которых я тоже коснусь в этом материале.
Преимущества архитектуры API First
По мере того, как всё сильнее распространяется подход к разработке приложений, основанный на микросервисах, определённую популярность набирает и архитектура API First. У этой архитектуры имеется довольно много сильных сторон.
▍Чёткое определение контрактов
Благодаря применению архитектуры API First можно создавать точные определения контрактов, которые позволяют чётко описывать возможности, которыми должны обладать приложения. Эта архитектура, кроме того, помогает отделять интерфейс системы, предоставляемый внешним пользователям посредством API, от деталей реализации возможностей этой системы.
▍Хорошее документирование API
Применение архитектуры API First способствует тому, что разработчик, создавая API, следует правилам, изложенным в хорошо структурированной, понятной документации. Это помогает тем, кому нужно работать с API, обрести чёткое понимание особенностей интерфейса, который представлен этим API.
▍Создание благоприятных условий для распараллеливания работы над проектами
Это — одна из моих любимых возможностей, получаемых тем, кто применяет архитектуру API First. Если в проекте имеется чёткое описание API, то тот, кто занимается разработкой самого API, и тот, кто пользуется возможностями этого API, могут работать параллельно. В частности, пользователь API, ещё до того, как сам API готов к работе, может, основываясь на уже согласованных контактах, создавать моки и заниматься своей частью работы над проектом.
Теперь, когда мы обсудили сильные стороны архитектуры API First, перейдём к практике.
Практика использования архитектуры API First
Я начал работу с посещения ресурса, дающего доступ к Swagger Editor, и с создания определения моего API. Я, при описании API, пользовался спецификацией OpenAPI 3. Определения API можно создавать и с применением многих других инструментов, но я выбрал именно Swagger Editor из-за того, что у меня есть опыт создания документации для Java-проектов с использованием этого редактора. Swagger Editor мне нравится и из-за того, что он поддерживает контекстно-зависимое автодополнение ввода ( Ctrl + Пробел ). Эта возможность очень помогла мне при создании определения API.
Правда, я не могу сказать, что свободно владею техникой определения API, поэтому я, описывая свой API, опирался на пример petstore.
Для начала я создал весьма минималистичное определение API, описывающее создание учётной записи пользователя системы с использованием POST-запроса.
Генерирование кода
После того, как подготовлено определение API, можно заняться созданием сервера и клиента для этого API. А именно, речь идёт о Spring Boot-приложении. Обычно я создаю такие приложения, пользуясь Spring Initializr. Единственной зависимостью, которую я добавил в проект, стал пакет Spring Web.
После этого я воспользовался Maven-плагином OpenAPI Generator, который позволяет создавать серверный и клиентский код.
▍Генерирование серверного кода
Содержимое конфигурационного файла для генерирования серверного кода
Среди настроек, которые я внёс в этот файл, хочу отметить указание имени пакета, которое будет использоваться при создании классов API и модели. Тут, в общем-то, имеется довольно много настроек, полное описание которых можно найти здесь. В частности, в подобном файле можно задать префикс имён классов модели
Коду, который генерируется плагином, нужны ещё несколько зависимостей, обеспечивающих его успешную компиляцию. Мне удалось найти минимальный набор таких зависимостей:
А теперь — самое интересное: генерирование кода. После выполнения команды mvn clean verify в нашем распоряжении оказываются несколько классов, сгенерированных плагином.
Результат работы генератора серверного кода
Теперь сервер готов к работе, а значит — пришло время поговорить о клиенте.
▍Генерирование клиентского кода
Содержимое конфигурационного файла для генерирования клиентского кода
Нам, кроме того, понадобятся дополнительные зависимости:
Результат работы генератора клиентского кода
После того, как код будет сгенерирован, в нашем распоряжении окажутся классы, позволяющие организовать взаимодействие клиента с сервером. Тут же имеются и реализации механизмов базовой аутентификации.
На этом работа над клиентской частью проекта завершена. Теперь можно проверить совместную работу клиента и сервера.
Проблемы, выявленные в ходе реализации проекта
В последней версии плагина (5.0.1), которой я и пользовался, имеются некоторые проблемы.
В этом репозитории вы можете найти код проекта, который мы обсуждали.
Применяете ли вы в своих проектах архитектуру API First?
Начало работы с микросервисами в Spring Boot
В этой статье мы продемонстрируем основные компоненты для создания RESTful микросервисов, используя реестр служб Consul, Spring Boot для всего скаффолдинга, инжекции зависимостей, Maven для сборки, а также Spring REST и Jersey/JaxRS API Java RESTful.
Основные преимущества микросервисов:
За последние два десятилетия предприятие стало очень гибким в нашем SDLC-процессе, но наши приложения, как правило, по-прежнему остаются монолитными, с огромными jar-ами, поддерживающими все разнообразные API и версии на рынке. Но в настоящее время существует стремление к более Lean, DevOps-ным процессам, а функциональность становится «безсерверной». Рефакторинг в микросервисы может уменьшить зацепленность кода и ресурсов, сделать сборки меньше, релизы безопаснее, а API более стабильными.
В этой статье мы создадим простое приложение для управления портфелем на фондовом рынке, которое клиенты могут вызывать для оценки своего портфеля акций (биржевые тикеры и величины). Микросервис портфеля будет извлекать портфель клиента, отправлять его в микросервис ценообразования для применения последних цен, а затем возвращать полностью оцененный и субтотализированный портфель, демонстрируя все это посредством rest-вызова.
Прежде чем мы начнем работу над созданием наших микросервисов, давайте подготовим нашу среду, настроив Consul.
Загрузите Consul
Мы будем использовать Hashicorp Consul для обнаружения сервисов, поэтому перейдите на www.consul.io/downloads.html и загрузите Consul для Windows, Linux, Mac и т.д. Это предоставит вам исполняемый файл, который нужно добавить к своему пути.
Запустите Consul
В командной строке запусктие Consul в режиме dev:
Чтобы убедиться, что он запущен, перейдите в браузер и получите доступ к интерфейсу консула http://localhost:8500. Если все будет хорошо, консул должен сообщить, что он жив и здоров. Нажав на службу консула (слева), вы получите дополнительную информацию (справа).
Если на данный момент есть какие-либо проблемы, убедитесь, что вы добавили Consul к пути выполнения, и доступны порты 8500 и 8600.
Создайте приложение SpringBoot
Мы будем использовать Spring Initializr, который интегрирован в большинство IDE, для скаффолдинга наших SpringBoot приложений. Скриншоты ниже используют IntelliJ IDEA.
Выберите «File/New Project», чтобы открыть новый шаблон проекта, и затем «Spring Initializr».
Вообще, вы можете настроить скаффолдинг без IDE, заполнив онлайн-форму через веб-страницу SpringBoot Initializr start.spring.io, которая создаст zip-файл вашего пустого проекта, готовый для загрузки.
Нажмите «Next» и заполните метаданные проекта. Используйте следующую конфигурацию:
Нажмите «Next», чтобы выбрать зависимости, и введите «Jersey» и «Consul Discovery» в поиске зависимостей. Добавьте эти зависимости:
Нажмите «Next», чтобы указать название проекта и его расположение. Сохраните имя по умолчанию «portfolio» и укажите предпочтительное расположение проекта, затем нажмите «finish», чтобы создать и открыть проект:
Мы можем использовать сгенерированные application.properties, но SpringBoot также распознает формат YAML, что немного легче визуализировать, поэтому давайте переименуем его в application.yml.
Назовем микросервис «portfolio-service». Мы можем указать порт или использовать порт 0, чтобы приложение использовало доступный порт. В нашем случае мы будем использовать 57116. Если вы разместите эту службу в качестве контейнера Docker, вы сможете сопоставить ее с любым выбранным вами портом. Назовите приложение и укажите наш порт, добавив следующее к нашему application.yml:
Чтобы сделать наш сервис доступным, добавим аннотацию к нашему классу приложений SpringBoot. Откройте приложение PortfolioApplication и добавьте @EnableDiscoveryClient над объявлением класса.
Подтвердите импорты. Класс должен выглядеть следующим образом:
(Чтобы продемонстрировать, как микросервисы могут состоять из независимых платформ, мы будем использовать Jersey для этого сервиса и Spring REST для следующего).
Чтобы настроить веб-службу RESTful на Jersey, нам нужно указать класс конфигурации ResourceConfig. Добавьте класс JerseyConfig (для демонстрации мы сохраним его в том же пакете, что и наш класс приложения). Это должно выглядеть так, плюс правильный пакет и импорт:
Обратите внимание, что он наследуется от ResourceConfig, чтобы обозначить его как класс конфигурации Jersey. Атрибут @ApplicationPath («portfolios») определяет контекст вызова, а это означает, что вызовы должны начинаться с элемента пути «portfolios». (Если вы его опустите, контекст по умолчанию «/»).
Класс PortfolioImpl будет обслуживать два запроса: portfolios/customer/
Ваша IDE попросит вас создать PortfolioImpl; сделайте это сейчас. Для демонстрации добавим его в тот же пакет. Введите код ниже и подтвердите все импорты:
Аннотация Component обозначает это как класс компонента Spring и предоставляет его как эндпоинт. Аннотации Path о объявлении класса объявляют, что к классу обращаются через элемент пути “/”, а два поддерживаемых вызова api доступны через portfolios/customer/
(Для нашего демо мы возвращаем захардкоженные значения. Конечно, на практике реализация будет запрашивать базу данных или другую службу или источник данных вместо хардкода.)
Теперь создайте проект и запустите его. Если вы используете IntelliJ, он создаст исполняемый файл по умолчанию, поэтому просто нажмите зеленую стрелку «run». Вы также можете использовать
Теперь мы должны увидеть этот сервис в Consul, поэтому давайте вернемся к нашему браузеру, загрузите http://localhost:8500/ui/#/dc1/services (или обновите, если вы уже там).
Хм, мы видим там наш сервис, но он отображен как неудавшийся. Это потому, что Consul ожидает «здорового» heartbeat-сигнала от нашей службы.
Чтобы генерировать heartbeat-сигналы, мы можем добавить зависимость от службы Spring «Actuator» к pom нашего приложения.
В то время как мы находимся в pom-е, обратите внимание, что существует конфликт версий с Jersey между Consul-стартером и Jersey-стартером. Чтобы сгладить это, назначьте Jersey-стартер первой зависимостью.
Теперь ваш pom должен содержать следующие зависимости:
Перезапустив Consul, служба Portfolio отображает счастливое:
Теперь в portfolio-service есть два передающих узла: один из них — наша реализация портфельного сервиса, а другой — heartbeat.
Давайте проверим порт, который был назначен. Вы можете видеть, что в выводе приложения:
Вы также можете увидеть порт непосредственно в пользовательском интерфейсе Consul. Нажмите «customer-service», затем выберите ссылку «Service ‘customer-service’ check link», в которой отображается служебный порт, в данном случае 57116.
Наш первый микросервис открыт для бизнеса!
Сервис ценообразования
Далее мы создадим наш сервис ценообразования, на этот раз используя Spring RestController вместо Jersey.
Служба ценообразования будет принимать в качестве параметров идентификатор клиента и идентификатор портфеля и будет использовать RestTemplate для запроса услуги портфеля, получения тикеров и акций и возврата текущих цен. (Мне не нужно говорить вам, что эти значения — это поддельные новости, поэтому не используйте их для принятия торговых решений!)
Создайте новый проект, используя следующую информацию:
На этот раз выберите зависимости Web, Consul Discovery и Actuator:
Оставьте название проекта по умолчанию «pricing» и создайте проект в выбранном вами каталоге.
На этот раз мы будем использовать application.properties вместо application.yml.
Задайте имя и порт в application.properties как:
Аннотируйте PricingApplication с @EnableDiscoveryClient. Класс должен выглядеть так, плюс пакет и импорт.
Затем мы создадим класс PricingEndpoint. Здесь я приведу более подробный пример, поскольку он демонстрирует несколько важных функций, включая обнаружение сервисов (поиск портфельной службы) и использование RestTemplate для запроса:
Чтобы найти портфельный сервис, нам необходимо иметь доступ к DiscoveryClient. Его легко получить с помощью аннотации Spring’s Autowired.
Этот экземпляр DiscoveryClient затем используется для поиска службы в вызове:
После того, как служба найдена, мы можем использовать ее для выполнения нашего запроса, который мы составляем в соответствии с вызовом api, созданным в нашем портфельном сервисе.
Наконец, мы используем RestTemplate для выполнения нашего GET-запроса.
Обратите внимание, что для Rest-контроллеров (как и для Spring MVC Request Controller) переменные пути извлекаются с помощью аннотации PathVariable, в отличие от Jersey, который, как мы видели, использует PathParam.
На этом мы завершаем наше ценообразование с помощью Spring RestController.
Документация
Мы решили все эти проблемы, чтобы создать наши микросервисы, но они не будут приносить достаточно пользы, если мы не дадим миру знание о том, как их использовать.
Для этого мы используем удобный и простой в использовании инструмент Swagger, который не только документирует наши вызовы API, но также предоставляет удобный веб-клиент для их вызова.
Во-первых, давайте укажем Swagger в нашем pom:
Затем нам нужно указать Swagger, какой из наших классов мы хотим документировать. Давайте представим новый класс SwaggerConfig, содержащий спецификацию Swagger.
Посмотрим, что делает этот класс. Сначала мы обозначили это как конфигурацию Swagger с аннотацией @ EnableSwagger2.
Затем мы создали компонент Docket, который сообщает Swagger, какие API-интерфейсы должны отображаться. В приведенном выше примере мы сказали Swagger продемонстрировать любой путь, начинающийся с «/pricing». Альтернативой было бы указать классы для документирования, а не для путей:
Перезапустите ценовой микросервис и вызовите из браузера http://localhost:57216/swagger-ui.html
Нажмите «List Operations», чтобы подробно просмотреть операции сервиса.
Нажмите «Expand Operations», чтобы создать запрос на основе формы. Задайте некоторые параметры, нажмите «Try it out!» и дождитесь ответа:
Вы можете добавить намного больше цветов, добавив аннотации Swagger к вашим методам.
Например, украсьте существующий метод PricingImpl.getPricedPortfolio, используя аннотацию @ApiOperation, как показано ниже:
Перезагрузите и обновите swagger-ui, чтобы увидеть новую уточненную документацию:
И это далеко не все, что вы можете сделать с Swagger, поэтому ознакомьтесь с документацией.
Еще больше о работе Spring Boot вам расскажет Юрий Дворжецкий, преподаватель нашего курса «Разработчик на Spring Framework»: