Pull to refresh

Микросервисы со Spring Boot. Часть 1. Начало работы

Reading time 7 min
Views 62K
Original author: Ranga Karanam
Это первая часть серии статей по основам микросервисных архитектур.

В ней вы познакомитеь с концепцией микросервисов и узнаете, как создавать микросервисы с помощью Spring Boot и Spring Cloud.

Это руководство поможет вам изучить основы микросервисных архитектур. Мы также начнем рассматривать базовую реализацию микросервиса со Spring Boot.

Мы создадим пару микросервисов и заставим их общаться друг с другом с помощью сервера имен Eureka (Eureka Naming Server) и Ribbon для балансировки нагрузки на стороне клиента.

Это статья входит в серию статей «Микросервисы со Spring Boot»:



Вы изучите


  • Что такое монолит?
  • Что такое микросервис?
  • Каковы проблемы с микросервисами?
  • Как Spring Boot и Spring Cloud облегчают разработку микросервисов?
  • Как реализовать балансировку нагрузки на стороне клиента с помощью Ribbon?
  • Как реализовать сервер имен (Eureka Naming Server)?
  • Как связать микросервисы с сервером имен и Ribbon?

Обзор ресурсов


В этом руководстве мы создадим ресурс для студентов, предоставляющий три сервиса с использованием соответствующих URI и методов HTTP:

  • Получить список всех студентов — @GetMapping("/students")
  • Получить информацию о конкретном студенте — @GetMapping("/students/{id}")
  • Удалить информацию о студенте — @DeleteMapping("/students/{id}")
  • Создать запись о новом студенте — @PostMapping("/students")
  • Обновить данные о студенте — @PutMapping("/students/{id}")

Обзор микросервисов — общая картина


В этой серии статей мы создадим два микросервиса:

  • Forex Service — сокращенно FS
  • Сервис конвертации валют (Currency Conversion Service) — сокращенно CCS

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

Форекс сервис


Форекс сервис (FS, Forex Service) является поставщиком услуг. Он предоставляет стоимость обмена валюты для различных валют. Давайте предположим, что он общается с Forex Exchange и предоставляет текущую стоимость обмена между валютами. Пример запроса и ответа показан ниже:

GET to http://localhost:8000/currency-exchange/from/EUR/to/INR

{
  id: 10002,
  from: "EUR",
  to: "INR",
  conversionMultiple: 75,
  port: 8000,
}

Ответ на запрос выше является обменным курсом евро к INR. В ответе ConversionMultiple равно 75.
О поле port мы поговорим чуть позже.

Сервис конвертации валют


Сервис конвертации валют (CCS) может конвертировать множество валют в другую валюту. Он использует сервис Forex для получения текущих значений обмена валюты. CCS является потребителем услуг. Пример запроса и ответа показан ниже:

GET to http://localhost:8100/currency-converter/from/EUR/to/INR/quantity/10000

{
  id: 10002,
  from: "EUR",
  to: "INR",
  conversionMultiple: 75,
  quantity: 10000,
  totalCalculatedAmount: 750000,
  port: 8000,
}

Запрос выше позволяет определить стоимость 10000 евро в индийских рупиях.
TotalCalculatedAmount составляет 750000 INR. Диаграмма ниже показывает связь между CCS и FS.



Eureka Naming Server и Ribbon


В зависимости от нагрузки у нас может быть несколько экземпляров Сервиса конвертации валют и Сервиса Форекс.



И количество экземпляров для каждого сервиса может меняться со временем. На рисунке ниже показан конкретный пример, где созданы 5 экземпляров сервиса Forex.



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



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



Что такое монолитное приложение?


Вы когда-нибудь работали в проекте…

  • Который выпускается (запускается в производство) раз в несколько месяцев
  • Который имеет широкий спектр функций и возможностей
  • В которой работает команда из более чем 50 человек
  • Где проблемы отладки — большая проблема
  • Где привнесение новых технологий и новых процессов практически невозможно

Это типичные характеристики монолитных приложений.

Монолитные приложения обычно огромны — более 100 000 строк кода. В некоторых случаях даже более миллиона строк кода.

Монолиты характеризуются следующим:

  • Большой размер приложения
  • Длительные циклы выпуска
  • Большие команды

Типичные проблемы включают:

  • Проблемы масштабируемости
  • Принятие новых технологий
  • Новые процессы — Agile?
  • Сложно автоматизировать тесты
  • Трудно адаптироваться к современным практикам разработки
  • Трудно адаптироваться к быстрому росту проекта

Микросервисы


Микросервисные архитектуры развивались как решение проблем масштабируемости и инноваций с монолитными архитектурами. Имеется ряд определений, предлагаемых для микросервисов.
Небольшие автономные сервисы, которые работают совместно — Сэм Ньюман (Sam Newman)
Разработка отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с облегченными механизмами, часто API-интерфейсом HTTP-ресурсов. Эти сервисы построены на бизнес-возможностях и могут быть развернуты независимо с помощью полностью автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими службами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных — Джеймс Льюис (James Lewis) и Мартин Фаулер (Martin Fowler)

Хотя для микросервисов нет единого принятого определения, имеется несколько важных характеристик:

  • REST — построен вокруг RESTful ресурсов. Связь между сервисами может быть на основе событий или протокола HTTP.
  • Небольшие хорошо выбранные развертываемые блоки — ограниченный контекст
  • Облачные возможности — динамическое масштабирование

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


Вот так будет выглядеть монолит. Одно приложение для всего.



Так будет выглядеть то же приложение при разработке с использованием Microservices Architecture.



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



Преимущества микросервисов


Преимущества:

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

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


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

Давайте рассмотрим некоторые из проблем:

  • Требуется быстрая настройка: вы не можете потратить месяц на настройку каждого микросервиса. Вы должны быть в состоянии быстро создавать микросервисы.
  • Автоматизация: поскольку вместо монолита есть ряд более мелких компонентов, вам необходимо автоматизировать все — сборки, развертывание, мониторинг и т. Д.
  • Видимость: теперь у вас есть несколько небольших компонентов для развертывания и обслуживания. Может быть, 100 или 1000 компонентов. Вы должны быть в состоянии отслеживать и определять проблемы автоматически. Вам нужна отличная видимость вокруг всех компонентов.
  • Ограниченный контекст: определение границ микросервиса — непростая задача. Ограниченный контекст из доменного дизайна — хорошая отправная точка. Ваше понимание домена развивается в течение определенного периода времени. Вы должны убедиться, что границы микросервиса развиваются.
  • Управление конфигурациями: вам необходимо поддерживать конфигурации для сотен компонентов в разных средах. Вам потребуется решение для управления конфигурацией
  • Динамическое увеличение и уменьшение: преимущества микросервисов будут реализованы только в том случае, если ваши приложения могут легко масштабироваться в облаке.
  • Колода карт: Если микросервис в нижней части цепочки вызовов выходит из строя, он может повлиять на все остальные микросервисы. Микросервисы должны быть отказоустойчивыми.
  • Отладка: Когда возникает проблема, требующая изучения, вам может понадобиться изучить несколько служб в разных компонентах. Централизованное ведение журнала и инструментальные панели необходимы для облегчения отладки проблем.
  • Согласованность: у вас не может быть широкого спектра инструментов, решающих одну и ту же проблему. Хотя важно стимулировать инновации, важно также иметь децентрализованное управление языками, платформами, технологиями и инструментами, используемыми для реализации / развертывания / мониторинга микросервисов.

Решения проблем микросервисных архитектур


Spring Boot


Spring Boot позволяет быстро создавать готовые приложения и предоставляет предоставляетследующие нефункциональные возможности:

  • встроенные серверы (простота развертывания с помощью контейнеров)
  • мониторинг метрик
  • мониторинг здоровья
  • внешняя конфигурация

Spring Cloud


Spring Cloud предоставляет решения для облачной активации ваших микросервисов. Он использует и основывается на некоторых облачных решениях, созданных компанией Netflix (Netflix OSS).

Важные модули Spring Cloud


  • Динамическое масштабирование вверх и вниз. Используя комбинацию:

— Сервера имен Eureka
— Ribbon (балансировка нагрузки на стороне клиента)
— Feign (упрощает разработку REST клиентов)

  • Видимость и мониторинг с:

— Распределенная трассировка Zipkin
— Netflix API шлюз

  • Управление конфигурацией с помощью Spring Cloud Config сервера
  • Отказоустойчивость с помощью Hystrix

В этой серии статей мы создадим два микросервиса:
Прим. перев. Автор далее частично повторяет уже сказанное. Сохранена оригинальная редакция (без удаления повторов)

  • Forex Service — сокращенно FS
  • Сервис конвертации валют (Currency Conversion Service) — сокращенно CCS

Диаграмма ниже показывает связь между CCS и FS. Мы установим связь между этими двумя компонентами.



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



И количество экземпляров для каждого сервиса может меняться со временем. На рисунке ниже показан конкретный пример, где созданы 5 экземпляров сервиса Forex.



Реализация решения для динамического масштабирования вверх и вниз требует ответа на два вопроса:

  • Как Служба конвертации валют (CCS) узнает, сколько экземпляров Forex Service (FS) активно?
  • Как Служба конвертации валют (CCS) распределяет нагрузку между активными экземплярами?

Поскольку мы хотим, чтобы это было динамичным, мы не можем жестко закодировать URL-адреса в сервисах FS в CCS. Вот почему мы вводим сервер имен.

Все экземпляры компонентов (CCS и FS) регистрируются на сервере имен Eureka. Когда FS должен вызвать CCS, он запросит Eureka Naming Server об активных экземплярах. Мы будем использовать Ribbon для балансировки нагрузки на стороне клиента между различными экземплярами FS.

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



Далее в этой серии статей:


  • Создание микросервиса Forex. Мы создадим простой REST сервис на основе Spring Boot Starter Web и Spring Boot Started JPA. Мы будем использовать Hibernate для реализации JPA и подключения к базе данных H2.
  • Создание сервиса конвертации валют CCS. Мы создадим простой REST сервис, используя Feign для вызова микросервиса Forex.
  • Использование Ribbon для балансировки нагрузки.
  • Внедрение Eureka Naming Service и подключение FS и CCS через Eureka.
Tags:
Hubs:
+3
Comments 7
Comments Comments 7

Articles