Spring cloud что это
Spring Cloud в Nutshell
Одной из многих преимуществ запуска приложения в облаке является высокая доступность различных сервисов. Вместо того, чтобы настраивать железо, устанавливать, обслуживать и др., вы просто создаете и устанавливаете сервис одним кликом мыши или командой.
Как получить доступ к приложениям этих сервисов? К примеру, если ваше приложение работает с реляционной базой данных, вам нужно создать объект DataSource этого сервиса. Вот где Spring Cloud помогает вам. Она берет на себя всю работу по настройке доступа и соединения и позволяет сфокусироваться на использовании этих сервисов. Она также предоставляет информацию о приложении(адрес хоста, порт, имя и др.).
Spring Cloud делает это все независимо от вида облака через Cloud Connector. На данный момент предоставляется реализация для Cloud Foundry и Heroku, однако мы можете расширить для своих типов облаков, реализовав интерфейс или используя часть существующего функционала библиотеки. Затем просто добавьте вашу библиотеку расширения в classpath вашего приложения, чтобы не пересобирать Spring Cloud.
Spring Cloud также признает, что невозможна реализация для каждого сервиса каждого облака. Поэтому, пока поддерживаются наиболее используемые сервисы «из коробки», вы можете сами расширить функциональность для своих сервисов. Просто, как обычное расширение облака, вы добавляете jar-файл расширения вашего сервиса в classpath вашего приложения.
В итоге, поддержка Spring(включая Spring Boot) приложениями в Java и XML конфигурациях осуществляется на уровне добавления свойств, т.к. Spring Cloud является сам модулем, основанным на Spring. Другие фреймворки осуществляют поддержку библиотеки подобным образом.
Рассмотрим Spring Cloud в действии.
Spring Cloud в действии
Мы начнем с простого приложения(исходный код), основанном на Spring Boot(обычное Spring MVC приложение также работало бы хорошо, но с немного большим количеством кода). Приложение состоит из бина, который взаимодействует с сервисом, и страницы, на которой отображается информация, полученная от сервиса.
Установка приложения в Cloud Foundry
Теперь нужно собрать и установить:
Теперь, если мы откроем страницу, то увидим информацию об этих четырех сервисах: 
В реальном приложении, вы вероятнее всего включите эти сервисы в служебные бины и включите более полезную информацию о соединении! Пожалуйста, посмотрите Spring Cloud и взгляните на список примеров приложений, которые делают более интересные вещи. Собственно говоря, сам spring.io использует Spring Cloud.
Установка приложения в Heroku
Вы можете установить то же приложение и на Heroku. Вам нужно только добавить пару файлов(ни один из них не относятся к Spring Cloud): system.properties позволяет Heroku использовать Java 7, Procfile — выполняет правильные команды для запуска приложения и активизирует cloud профиль. Мы установим приложение на Heroku следующим образом:
Мы создаем дополнения(похожие на сервисы Cloud Foundry) для MongoDb, Redis и AMQP. Heroku автоматически предоставляет Postgres сервис, поэтому мы его не добавляли. Рабочее окружение приложений Heroku, в отличие от Cloud Foundry, не раскрывает имени приложения, поэтому мы использовали heroku config:set для явного указания(иначе Spring Cloud установит ). Есть ещё несколько отличий в том, как Spring Cloud адаптируется между этими двумя облаками; мы рассмотрим их с следующих статьях.
Это все, что нужно сделать. Когда мы откроем страницу нашего приложения, то увидим информацию обо всех сервисах почти такую же, какую видели в Cloud Foundry. 
Немного по управляем
Использование @ServiceScan делает легким захват всех сервисов и возможность их использования. Но на практике часто нужно делать большее, чем создание соединения, например установка параметров пула. В этом случае вы можете использовать Java или XML-конфигурацию. Внесем изменения в класс CloudConfig :
Spring Cloud абстрагирует соединение к облачному сервису и дает возможность устанавливать одни и те же приложения на разных облачных платформах с минимальным количеством усилий. В этой статье мы слегка затронули то, что предлагает Spring Cloud. В следующей статье мы рассмотрим подробнее о Java и XML-конфигурации, а также как можно использовать основное API в не-Spring приложениях. В дальнейшем, мы будем рассматривать более подробно Spring Cloud.
Spring Cloud
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
Features
Spring Cloud focuses on providing good out of box experience for typical use cases and extensibility mechanism to cover others.
Service registration and discovery
Leadership election and cluster state
Getting Started
Generating A New Spring Cloud Project
The easiest way to get started is visit start.spring.io, select your Spring Boot version and the Spring Cloud projects you want to use. This will add the corresponding Spring Cloud BOM version to your Maven/Gradle file when you generate the project.
Adding Spring Cloud To An Existing Spring Boot Application
If you an existing Spring Boot app you want to add Spring Cloud to that app, the first step is to determine the version of Spring Cloud you should use. The version you use in your app will depend on the version of Spring Boot you are using.
The table below outlines which version of Spring Cloud maps to which version of Spring Boot.
| Release Train | Boot Version |
|---|---|
| Spring Cloud Dalston, Edgware, Finchley, and Greenwich have all reached end of life status and are no longer supported. |
Bug fixes and backwards compatible features are added to each release train via a service release (SR). Once you determine which version of Spring Cloud to use, you should use the latest service release for that release train. You can find the latest service release information on our release notes page.
Now that you know which release train to use and the latest service release for that release train you are ready to add the Spring Cloud BOM to your application.
Just like Spring Boot, many Spring Cloud projects include starters that you can add as dependencies to add various cloud native features to your project. In many cases, many features are enabled purely by adding the starter to your classpath. The starter names are documented within the individual projects. Below is an example of how you would add a Spring Cloud Config Client and a Spring Cloud Netflix Eureka client to your application.
Getting Started Resources
Main Projects
Spring Cloud Config
Centralized external configuration management backed by a git repository. The configuration resources map directly to Spring Environment but could be used by non-Spring applications if desired.
Spring Cloud Netflix
Integration with various Netflix OSS components (Eureka, Hystrix, Zuul, Archaius, etc.).
Spring Cloud Bus
An event bus for linking services and service instances together with distributed messaging. Useful for propagating state changes across a cluster (e.g. config change events).
Spring Cloud Cloudfoundry
Integrates your application with Pivotal Cloud Foundry. Provides a service discovery implementation and also makes it easy to implement SSO and OAuth2 protected resources.
Spring Cloud Open Service Broker
Provides a starting point for building a service broker that implements the Open Service Broker API.
Spring Cloud Cluster
Leadership election and common stateful patterns with an abstraction and implementation for Zookeeper, Redis, Hazelcast, Consul.
Spring Cloud Consul
Service discovery and configuration management with Hashicorp Consul.
Spring Cloud Security
Provides support for load-balanced OAuth2 rest client and authentication header relays in a Zuul proxy.
Spring Cloud Sleuth
Distributed tracing for Spring Cloud applications, compatible with Zipkin, HTrace and log-based (e.g. ELK) tracing.
Spring Cloud Data Flow
A cloud-native orchestration service for composable microservice applications on modern runtimes. Easy-to-use DSL, drag-and-drop GUI, and REST-APIs together simplifies the overall orchestration of microservice based data pipelines.
Spring Cloud Stream
A lightweight event-driven microservices framework to quickly build applications that can connect to external systems. Simple declarative model to send and receive messages using Apache Kafka or RabbitMQ between Spring Boot apps.
Spring Cloud Stream Applications
Spring Cloud Stream Applications are out of the box Spring Boot applications providing integration with external middleware systems such as Apache Kafka, RabbitMQ etc. using the binder abstraction in Spring Cloud Stream.
Spring Cloud Task
A short-lived microservices framework to quickly build applications that perform finite amounts of data processing. Simple declarative for adding both functional and non-functional features to Spring Boot apps.
Spring Cloud Task App Starters
Spring Cloud Task App Starters are Spring Boot applications that may be any process including Spring Batch jobs that do not run forever, and they end/stop after a finite period of data processing.
Spring Cloud Zookeeper
Service discovery and configuration management with Apache Zookeeper.
Spring Cloud Connectors
Makes it easy for PaaS applications in a variety of platforms to connect to backend services like databases and message brokers (the project formerly known as «Spring Cloud»).
Spring Cloud Starters
Spring Boot-style starter projects to ease dependency management for consumers of Spring Cloud. (Discontinued as a project and merged with the other projects after Angel.SR2.)
Spring Cloud CLI
Spring Boot CLI plugin for creating Spring Cloud component applications quickly in Groovy
Spring Cloud Contract
Spring Cloud Contract is an umbrella project holding solutions that help users in successfully implementing the Consumer Driven Contracts approach.
Spring Cloud Gateway
Spring Cloud Gateway is an intelligent and programmable router based on Project Reactor.
Spring Cloud OpenFeign
Spring Cloud OpenFeign provides integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms.
Spring Cloud Pipelines
Spring Cloud Pipelines provides an opinionated deployment pipeline with steps to ensure that your application can be deployed in zero downtime fashion and easilly rolled back of something goes wrong.
Spring Cloud Function
Spring Cloud Function promotes the implementation of business logic via functions. It supports a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).
Release Trains
Spring Cloud is an umbrella project consisting of independent projects with, in principle, different release cadences. To manage the portfolio a BOM (Bill of Materials) is published with a curated set of dependencies on the individual project. Go here to read about the Release Train naming conventions.
Quickstart Your Project
Documentation
| 2021.0.0 CURRENT GA | Reference Doc. |
| 2021.0.1-SNAPSHOT SNAPSHOT | Reference Doc. |
| 2020.0.5-SNAPSHOT SNAPSHOT | Reference Doc. |
| 2020.0.4 GA | Reference Doc. |
| Hoxton.SR12 GA | Reference Doc. |
| Hoxton.BUILD-SNAPSHOT SNAPSHOT | Reference Doc. |
Guides
A few examples to try out:
Get ahead
VMware offers training and certification to turbo-charge your progress.
Get support
Spring Runtime offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.
Upcoming events
Check out all the upcoming events in the Spring community.
Микросервисная архитектура, Spring Cloud и Docker
Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.
Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.
За основу я взял старый забытый проект, бэкенд которого представлял из себя монолит. Приложение позволяет организовать личные финансы: вносить регулярные доходы и расходы, следить за накоплениями, считать статистику и прогнозы.
Функциональные сервисы
Попробуем декомпозировать монолит на несколько основных микросервисов, каждый из которых будет отвечать за определенную бизнес-задачу.
Account service
Реализует логику и валидацию по сохранению доходов, расходов, накоплений и настроек аккаунта.
| Метод | Путь | Описание | Пользователь авторизован | Доступно из UI |
|---|---|---|---|---|
| GET | /accounts/ | Получить данные указанного аккаунта | ||
| GET | /accounts/current | Получить данные текущего аккаунта | × | × |
| GET | /accounts/demo | Получить данные демо аккаунта | × | |
| PUT | /accounts/current | Сохранить данные текущего аккаунта | × | × |
| POST | /accounts/ | Зарегистрировать новый аккаунт | × |
Statistics service
Производит расчет основных статистических параметров аккаунта, приводит их значения к базовой валюте и периоду, сохраняет данные в виде, удобном для последующего анализа. Полученный временной ряд будет использован для отображения пользователю статистики и показателей за прошедшее время и экстраполяции для простейших прогнозов на будущее.
| Метод | Путь | Описание | Пользователь авторизован | Доступно из UI |
|---|---|---|---|---|
| GET | /statistics/ | Получить статистику указанного аккаунта | ||
| GET | /statistics/current | Получить статистику текущего аккаунта | × | × |
| GET | /statistics/demo | Получить статистику демо аккаунта | × | |
| PUT | /statistics/ | Создать/обновить дата-поинт для указанного аккаунта |
Notification service
Хранит настройки уведомлений (частоты напоминаний, периодичность бекапов). По расписанию производит рассылку e-mail сообщений, предварительно собирая и агрегируя нужные данные у первых двух сервисов, если требуется.
| Метод | Путь | Описание | Пользователь авторизован | Доступно из UI |
|---|---|---|---|---|
| GET | /notifications/settings/current | Получить настройки нотификаций для текущего аккаунта | × | × |
| PUT | /notifications/settings/current | Сохранить настройки нотификаций для текущего аккаунта | × | × |
Примечания
Инфраструктурные сервисы
Для обеспечения совместной работы описанных выше сервисов будем использовать набор основных паттернов и практик Микросервисной архитектуры. Многие из них реализованы в Spring Cloud (в частности, посредством интеграции с продуктами Netflix OSS) — на деле это зависимости, расширяющие возможности Spring Boot в ту или иную сторону. Ниже кратко рассмотрен каждый из компонентов.
Config Server
Spring Cloud Config — это горизонтально масштабируемое хранилище конфигураций для распределенной системы. В качестве источника данных на данный момент поддерживаются Git, Subversion и простые файлы, хранящиеся локально. По умолчанию Spring Cloud Config отдает файлы, соответствующие имени запрашивающего Spring приложения (но можно забирать проперти под конкретный Spring profile и из определенной ветки системы контроля версий).
На стороне клиентского приложения теперь не требуются никаких конфигурационных файлов, кроме bootstrap.yml с именем приложения и адресом Config server:
Для этого следует внести правки в конфигурационный файл Config server, а затем выполнить следующий запрос к Notification service :
Этот процесс можно автоматизировать, если использовать загрузку конфигураций из систем контроля версий, настроив вебхук из Github, Gitlub или Bitbucket.
Auth Server
Обязанности по авторизации полностью вынесены в отдельное приложение, которое выдает OAuth2 токены для доступа к ресурсам бэкенда. Auth server используется как для авторизации пользователей, так и для защищенного общения сервис-сервис внутри периметра.
На самом деле, здесь описан только один из возможных подходов. Spring Cloud и Spring Security позволяют достаточно гибко настраивать конфигурацию под ваши нужды (например, имеет смысл проводить авторизацию на стороне API Gateway, а внутрь инфраструктуры передавать запрос с уже заполненными данными пользователя).
В этом проекте я использую Password credential grant type для авторизации пользователей и Client credentials grant type — для авторизации между сервисами.
Spring Cloud Security предоставляет удобные аннотации и автоконфигурацию, что позволяет достаточно просто реализовать описанный функционал как со стороны клиента, так и со стороны авторизационного сервера.
API Gateway
Все три основных сервиса, которые мы обсудили выше, предоставляют для внешнего пользователя некоторый API. В промышленных системах, построенных на Микросервисной архитектуре, число компонентов растет быстро — поговаривают, что в Амазоне в рендеринг страницы вовлечены порядка 150 сервисов.
Гипотетически, клиентское приложение могло бы запрашивать каждый из сервисов самостоятельно. Но такой подход сразу натыкается на массу ограничений — необходимость знать адрес каждого эндпоинта, делать запрос за каждым куском информации отдельно и самостоятельно мерджить результат. Кроме того, не все приложения не бэкенде могут поддерживать дружественные вебу протоколы, и прочее прочее.
Для решения такого рода проблем применяют API Gateway — единую точку входа. Ее используют для приема внешних запросов и маршрутизации в нужные сервисы внутренней инфраструктуры, отдачи статического контента, аутентификации, стресс тестирования, канареечного развертывания, миграции сервисов, динамического управления трафиком. У Netflix если блог-пост об оптимизации своего API за счет асинхронной аггрегации контента из разных микросервисов.
Netflix заопенсорсила свою имплементацию API Gateway — Zuul. Spring Cloud нативно интегрирован с ним и включается добавлением одной зависимости и аннотациии @EnableZuulProxy в Spring Boot приложение. В этом проекте Zuul используется для самых элементарных задач — отдачи статики (веб-приложение) и роутинга запросов.
Пример префиксной маршрутизации для Notification service:
Service discovery
Еще один широко известный паттерн для распределенных систем. Service discovery позволяет автоматически определять сетевые адреса для доступных инстансов приложений, которые могут динамически изменяться по причинам масштабирования, падений и обновлений.
Ключевым звеном здесь является Registry service. В этом проекте я использую Netflix Eureka (но есть еще Consul, Zookeeper, Etcd и другие). Eureka — пример client-side discovery паттерна, что означает клиент должен запросить адреса доступных инстансов и осуществлять балансировку между ними самостоятельно.
Теперь инстанс приложения при старте будет регистрироваться в Eureka, предоставляя мета-данные (такие как хост, порт и прочее). Eureka будет принимать хартбит-сообщения, и если их нет в течении сконфигурированного времени — инстанс будет удален из реестра. Кроме того, Eureka предоставляет дашборд, на котором видны зарегистрированные приложения с количеством инстансов и другая техническая информация: http://localhost:8761
Клиентский балансировщик, Предохранитель и Http-клиент
Следующий набор инструментов тоже разработан в Netflix и нативно интегрирован в Spring Cloud. Все они работают совместно и используются в микросервисах, которым нужно общаться с внешним миром или внутренней инфраструктурой.
Ribbon
Ribbon — это client-side балансировщик. По сравнению с традиционным, здесь запросы проходят напрямую по нужному адресу, что исключает лишний узел при вызове. Из коробки он интегрирован с механизмом Service Discovery, который предоставляет динамический список доступных инстансов для балансировки между ними.
Hystrix
Hystrix — это имплементация паттерна Circuit Breaker — предохранителя, который дает контроль над задержками и ошибками при вызовах по сети. Основная идея состоит в том, чтобы остановить каскадный отказ в распределенной системе, состоящей из большого числа компонентов. Это позволяет отдавать ошибку как можно быстрее, не задерживаясь при запросе к зависшему сервису, давая ему восстановиться.
Помимо контроля за размыканием цепи, Hystrix позволяет определить fallback-метод, который будет вызван при неуспешном вызове. Тем самым можно отдавать дефолтный ответ, сообщение об ошибке, и др.
На каждый запрос Hystrix генерирует набор метрик (таких как скорость выполнения, результат), что позволяет анализировать общее состоянее системы. Ниже будет рассмотрен мониторинг на основе данных метрик.
Feign
Вот пример из Account Service:
Панель мониторинга
Однако в нашем случае сервисов несколько, и было бы здорово видеть все их метрики в одном месте. Для этого существует специальное решение. Каждый из наших сервисов будет пушить свои стримы в AMQP брокер (RabbitMQ), откуда аггрегатор стримов, Turbine, будет преобразовывать их, выставляя единый эндпоинт для Hystrix Dashboard.
Рассмотрим поведение системы под нагрузкой: Account service вызывает Statistics Service, и тот отвечает с варьируемой имитационной задержкой. Пороговое значение времени запроса установлено в 1 секунду.
| | | |
|---|---|---|---|
| задержка 0 мс | задержка 500 мс | задержка 800 мс | задержка 1100 мс |
| Система работает без ошибок. Пропускная способность порядка 22 з/с. Небольшое число активных потоков в Statistics service. Среднее время получения ответа — 50 мс. | Число активных потоков увеличивается. Фиолетовая цифра показывает число отклоненных запросов, соответственно порядка 30-40% ошибок, но цепь все еще замкнута. | Полуоткрытое состояние: процент ошибок более 50%, предохранитель размыкает цепь. После определенного таймаута, цепь замыкается, но снова ненадолго. | 100% запросов с ошибками. Цепь разомкнута постоянно, попытки пропустить запрос спустя таймаут ничего не меняют — каждый отдельный запрос слишком медленный. |
Анализ логов
В инфраструктуре, состоящей из большого количества движущихся частей (каждая из которых может иметь по нескольку экземпляров), очень важно использовать систему централизированного сбора, обработки и анализа логов. Elasticsearch, Logstash и Kibana составляют стeк, с помощью которого можно эффективно решать такую задачу.
Готовая к запуску Docker-конфигурация ELK с Куратором и шаблонами для шипперов доступна на гитхабе. Именно такая конфигурация, с небольшой кастомизацией и масштабированием, успешно работает в продакшене на моем текущем проекте для анализа логов, сетевой активности и мониторинга производительности серверов.
Картинка с официального сайта Elastic, просто для примера
Автоматизация инфраструктуры
Развертывание микросервисной системы с большим количеством движущихся частей и взаимосвязанностью — задача очевидно более комплексная, нежели деплой монолитного приложения. Без автоматизированной инфраструктуры вся история превратится в бесконечную боль и трату времени. Это тема для совершенно отдельного разговора, я лишь покажу простейший Сontinuous delivery воркфлоу, реализованный в этом проекте на бесплатных версиях сервисов:
Запуск
Если вы дочитали до этого места, возможно вам будет интересно запустить все это своими руками. Хочу отметить, что инфраструктура состоит из 8 Spring Boot приложений, 4 инстансов MongoDB и одного RabbitMQ. Убедитесь, что в системе доступны 3-4 Гб памяти. Всегда можно запустить ограничиться самым необходимым функционалом — отказаться от Statistics service, Notification Service и Monitoring.
Прежде чем начать
Production mode
Development mode
Примечания
Всем Spring Boot приложениям в этом проекте для старта необходим доступный Config Server. Благодаря опции fail-fast в bootstrap.yml каждого приложения и опции restart: always в докере, контейнеры можно запускать одновременно (они будут автоматически продолжать попытки старта, пока не поднимется Config Server).
Механизм Service Discovery так же требует некоторого времени для начала полноценной работы. Сервис не доступен для вызова, пока он сам, Eureka и клиент не имеют одну и ту же мета-информацию у себя локально — на это требуется 3 хартбита. По умолчанию период времени между хартбитами составляет 30 секунд.