Spring cloud что это

Spring cloud что это

Spring Cloud

Spring Cloud упрощает подключение к сервисам и получение возможностей окружения в облачных платформах, таких как Cloud Foundry и Heroku. Особая поддержка Spring-приложений через Java и XML конфигурации делает подключение к облачным сервисам тривиальной задачей. Вы можете использовать существующие облачные коннекторы(Cloud Foundry и Heroku) или написать собственный для вашей облачной платформы. Пока что «из коробки» поддерживаются наиболее популярные сервисы(реляционные СУБД, MongoDB, Redis, Rabbit), но также возможно расширение для ваших сервисов. Ни один из сервисов не требует изменения самого Spring Cloud, достаточно просто добавить необходимую вам jar-библиотеку в область видимости classpath.

Введение

• Cloud Connector: Интерфейс, через который можно реализовать облачный провайдер, чтобы дать возможность библиотекам работать с облачной платформой
• Service Connector: Объект, подобный javax.sql.DataSource, представляющий собой соединение как сервис
• Service information: Информация о сервисе — хост, порт, параметры доступа
• Application information: Информация о приложении и сведения о подключенных библиотеках

Возможности

Spring Cloud ориентирован на предоставлении необходимого функционала «из коробки» в большинстве случаев, а также механизм раширений для других. Существуют два пути расширения:

• Java и XML конфигурация для Spring-приложений: Простые пути создания бинов для сервисов в приложении
• Расширение облачной платформы: Используя Cloud Connector, возможно расширение Spring Cloud для других облачных платформ
• Service Information и расширение Connector: Spring Cloud позволяет соединяться с различными типами сервисов настолько долго, пока есть возможность получать информацию о соединении из приложений операционной системы и, при неоходимостти, преоразовать в service connector

Проект состоит из:

• Spring Cloud Core: Основная библиотека, которая не зависит от облака и Spring
• Spring Cloud Service Connector for Spring: Библиотека, которая предоставляет коннекторы для создания javax.sql.DataSource объектов и различные «фабрики» для Spring-проектов
• Cloudfoundry Connector: Коннектор для Cloud Foundry
• Heroku Connector: Коннектор для Heroku
• Cloudfoundry User-Provided Service Connector: Расширение Cloud Foundry Connector для поддержки пользовательских сервисов

Что такое Spring Cloud и как его готовить – интервью с Евгением Борисовым и Кириллом Толкачёвым

Вам нужно вести разработку с использованием микросервисной архитектуры. Все советуют Spring Cloud, но почему? Достаточно ли он обкатан? Как он устроен внутри, какой логикой руководствовались разработчики, насколько удобно всё это применять?

На эти и другие вопросы ответили в интервью редакции JUG Ru Group спикеры конференции Joker 2017 — Евгений Борисов и Кирилл Толкачёв.

Евгений Борисов работает в Naya Technologies. Он разрабатывает на Java с 2001 года, и принял участие в большом количестве Enterprise-проектов. Пройдя путь от простого программиста до архитектора и устав от рутины, он стал свободным художником. Сегодня Женя пишет и проводит курсы, семинары и мастер-классы для различной аудитории: live-курсы по J2EE для офицеров израильской армии, Spring — по WebEx для румын, Hibernate через GoToMeeting для канадцев, Troubleshooting и Design Patterns для украинцев.

Кирилл Толкачёв работает в Альфа-Лаборатории. Он разрабатывает различные банковские API. Формирует принципы и наборы инструментов для работы с микросервисной архитектурой. Большой поклонник Groovy, Gradle, Spring и стека технологий Netflix-а. Постоянный резидент подкаста «Разбор Полётов». Методологию DevOps знает не понаслышке и имеет почти двухлетний опыт её применения.

— Spring Cloud — довольно новая вещь, можешь рассказать, для чего она предназначена? Насколько я понимаю, это доп. архитектура, позволяющая проще деплоить микросервисы в облака.

Евгений: Да, действительно. Spring Cloud — вещь новая. Года два назад он только начал входить в обиход, но уже очень быстро распространяется. Для чего он предназначен? Spring Cloud — это модуль Spring, в котором есть много всего разного для разработки микросервисной архитектуры. Там есть куски инфраструктуры и другие полезные плюшки. Одна из основных вещей, которые там есть — это Service Discovery. Одна из насущных задач, существующих в мире микросервисов — это максимально автоматизировать механизм обнаружения друг другом таких микросервисов, которые не знают о местонахождении друг друга. Они знают, что в принципе существуют какие-то другие микросервисы, к которым можно обращаться и что-то от них получать, но они не знают, куда обращаться, потому что сегодня мы это запускаем на одном кластере, завтра — на другом, послезавтра мы это запускаем на Amazon, потом ещё где-то. Примером модуля, входящего в мир Spring Cloud, является Service Discovery, через который все микросервисы могут узнать о местонахождении друг друга.

То есть, существуют какие-то имена, про которые они знают, и могут узнать настоящие url-ы. Например, один микросервис знает всё про юзеров системы, а другой — всё про сериалы. Вы обращаетесь к первому микросервису и спрашиваете, есть ли юзер с таким-то id, понравится или нет ему «Игра Престолов»? Соответственно, первый микросервис, который отвечает за юзеров, лезет в свою базу данных, вытаскивает информацию конкретно об этом юзере, смотрит, какие у него есть вкусы, и теперь ему нужно будет уточнить информацию про «Игру Престолов», сравнить и понять, подходит это или нет. Соответственно, он должен пойти в другой микросервис. Он знает, что есть микросервис, который называется «Игра Престолов», но не знает, где именно тот находится. Наш микросервис, при помощи Service Discovery, говорит: «Дай мне, пожалуйста, URL, по которому я смогу обратиться к нужному мне микросервису». И после этого он может обращаться к нему по REST после того, как он этот URL получит. Это если совсем в двух словах. Кстати, модуль Spring Cloud не подразумевает обязательную работу в облаке. Он именно служит помощником для разработчиков микросервисной архитектуры в своём проекте. А то, что чаще всего, вся построенная система запускается именно в облаке, и породило название Spring Cloud. Но на самом деле нет никакой проблемы иметь весь кластер микросервисов на одной локальной машине. От этого смысл не изменится. Ведь микросервис и так не знает, где он запустится.

У тебя может быть локальная система в локальной сетке, или даже на одной машине. Ты поднял 10 разных микросервисов, которые хотят иногда обращаться друг к другу. Они не знают, на каком IP или URL сидит каждый микросервис, потому что это всегда может измениться. Мы ещё чуть позже поговорим о том, что у каждого микросервиса может быть много копий для перформанса. На секунду это оставим. Допустим, есть одна копия у каждого отдельного микросервиса, но всё равно — это же неправильно — хардкодить, прописывать URL в какой-нибудь property-файл, чтобы они там через RestTemplate или ещё что-то обращались друг к другу, потому что завтра ты возьмешь свою систему микросервисов из тестовой среды и перенесёшь это в продакшн: там у тебя другие URL, другие IP — и там у тебя ничего не работает. Ты это опять всё задеплоил, наладил, потратил кучу времени, у тебя это в продакшене заработало. Потом ты это отдал другому клиенту или вы подняли это в Amazon, там опять всё другое — другие порты, URL, и опять ничего не работает. А Service Discovery в Spring Cloud предоставляет это из коробки. Всё очень просто: ты инжектишь определённый сервис, в который все зарегистрированы, и через него ты можешь сказать «дай мне URL микросервиса, который называется вот так». И всё. Делается это очень просто: ставится на каждом микросервисе в главном Main-е в главной конфигурации аннотация Spring Cloud, которая говорит о том, что я хочу зарегистрироваться, и тогда он поднимается, сам находит один единственный центральный сервис, который должны знать все, говорит: «Меня зовут так-то, вот мой URL, вот мой IP, я сижу вот здесь». И есть кто-то один, кто знает всё про всех. Переодически он их пингует, чтобы знать кто сейчас available. С другой стороны, каждый может проинжектить себе некий сервис, у которого потом можно спрашивать, кто зарегистрирован под таким-то именем, какой у него URL, и когда у тебя уже есть эти данные, ты можешь по REST к этим микросервисам обращаться. Это конкретно та фишка, которую я лично юзал в Spring Cloud. Как видишь, это не обязательно связано с облаком. Это просто называется так — Spring Cloud, но он представляет собой много всяких разных штук. Я рассказал про сервис Discovery, Кирилл может добавит ещё что-нибудь или поправит меня.

Кирилл: Spring Cloud — это целый набор модулей, живущий по своим законам и порой даже «подламывающий» механизмы Spring Boot.

Евгений: Как я и сказал, Spring Cloud предоставляет целый инструментарий, связанный с миром облаков, микросервисов и т.д.

Кирилл: Сам по себе Spring Cloud, как называют это сами разработчики, — это Release Train, содержащий набор зависимостей/модулей, версии которых согласованы между собой и рассчитаны на конкретную версию Spring Boot. Про один из модулей ты уже сказал — это Spring Cloud Discovery. Service Discovery обычно бесполезен отдельно от Load Balancer, и в Spring Cloud для этого есть Spring Cloud Netflix — проект с имплементацией Discovery для Eureka Server и клиентским балансировщиком — Ribbon и Feign. Spring Cloud Starter Ribbon — интеграция клиентского балансировщика Ribbon в привычный стек Spring MVC (RestTemplate) и связка его с Service Discovery. Spring Cloud Starter OpenFeign — декларативный клиент для того, чтобы делать клиенты в стиле RPC, для удобного общения сервисов через HTTP. Само собой, он имеет интеграцию с упомянутыми ранее решениями (Ribbon/Discovery).

Как и сказал Женя, для использования Spring Cloud «облако» (о Господи, да всё разное понимают под этим словом) вам в общем-то и не нужно. Мой позыв простой: Зачем вы делите своё решение на разные сервисы? Если есть возможность не делить и спокойно работать с одним, то лучше так и делать, потому что это проще. Как только вы разделили «монолит» на кучку «микросервисов» — вы получили сложную распределённую систему, вместо предсказуемой и понятной монолитной. У вас появились проблемы, о которых вы до этого даже не думали, а некоторые проблемы всплыли на уровень инфраструктуры. Приходится манипулировать совсем другим списком ошибок, и это при том, что старые никуда не делись.

Но всё ли так плохо? Действительно, часть трудностей берёт на себя Spring Cloud (например, реализация балансировки и клиентское обнаружение). Так, целую пачку новых вызовов привносят совершенно обычные, с точки зрения разработки, вещи. Приходится смотреть на типичные вещи под углом функционирования системы в целом (а я напомню, в случае монолитного приложения это было просто супер). Например, теперь недостаточно написать сообщение об ошибке в лог, нужно позаботиться о прозрачности его нахождения, добавляя к нему метаинформацию для сквозного поиска вызовов, участвующих в ошибочном запросе. Для этого есть решения типа Spring Cloud Sleuth, которые добавляют различную метаинформацию в логи, позволяют получать «сквозные» логи по ошибкам, производят семплинг запросов и отправляют их на Zipkin-сервер. С помощью интерфейса Zipkin уже можно удобно искать «топ самых медленных запросов», вычислять «грязных утят» — конкретные тормозящие сервисы, быстро оценивать ситуацию и локализовывать проблему.

И как многое в распределённых системах, всё вышесказанное — это лишь вершина айсберга. Огромная вариативность стека заставляет непрерывно выбирать подходы, принимать решения. Например, тот же Zipkin может получать сэмплы (информация о внутренних процессах приложения – в основном различные замеры времени) для формирования TOP N медленных запросов, через очереди или по HTTP API. Обозреваемые приложения так же настраиваются на сброс информации либо в очередь (kafka/rabbitmq) либо в HTTP API Zipkin.

Сам «сэмпл» запроса, состоящий, по сути, из времён ответов разных систем, поучаствовавших в каком-то запросе, после получения также может храниться по-разному:

Каждое решение приемлемо в разных условиях, и хорошо, если ваши условия совпали с существующим решением, иначе приходится делать своё.

Очередь тоже можно выбрать разную, в Spring Cloud есть поддержка Kafka и RabbitMQ.

И выбор любого решения — это огромная ответственность, так как чем «круче» и сложнее, тем больше потом кому-то придётся поддерживать, обновлять и развивать. Так что задумайтесь, когда вместо ConcurrentLinkedQueue в своём аккуратном и монолитном приложении вы захотите сделать микросервисы и Kafka.

Для работы с Kafka/RabbitMQ и создания «message-driven» микросервисов, в Spring Cloud также есть модуль — Spring Cloud Stream (основанный на других модулях Spring Boot).

Из-за такого обилия возможностей часто страдает качество конечных решений. Не всё хорошо стыкуется при необходимости использования разные версии (например Kafka 0.9 плохо дружит с новыми Spring Cloud Stream из-за встроенной версии драйвера для 0.11). Частично это нивелируется «готовым стеком». То есть берём Release Train Spring Cloud Dalston.SR4 + Kafka 0.11 + …, действуем по документации, в сторону не шагаем – работает. Но граблей всё же хватает, хотя это уже совсем другая история.

— Как вообще Spring Cloud встраивается в инфраструктуру Spring/Spring Boot? Насколько просто на всё это переехать, если ты уже плотно сидишь на Boot?

Кирилл: Как я и говорил до этого — если есть возможность не переезжать, не переезжайте. Spring Cloud — это сабсет различных модулей уже, скорее, над Spring Boot, потому что абстракция немного другого уровня, она затрагивает инфраструктурный уровень ещё больше. Получается, что в Spring — это уровень фреймворка, различные MVС/JPA/Data/ES-модули и так далее. Spring Boot — это уже связка между инфраструктурой и библиотеками, где различные модули склеиваются между собой, начинают дружить с вашей инфраструктурой (embedded Tomcat/настройки/env property sources/etc), и всё это в экстазе может запуститься в виде systemd-сервиса на Linux-сервере буквально с полпинка. Spring Cloud — это уже клей между различными сервисами, которые запускаются отдельно: например, два Spring Boot-приложения, которые интегрируются между собой. Всё на этом основано и построено.

При этом Spring Cloud X может и не являться простой библиотекой, как, например, Spring Cloud Eureka Server и Spring Cloud Config Server, которые по сути своей могут быть полноценными Spring Boot-приложениями, реализующими функциональность сервера обнаружения (Discovery Server) и сервера конфигураций (Config Server).

— Зачем это всё делается? В чём идея микросервисов?

Евгений: Идея микросервисов — в том, что мы пишем маленькие кусочки приложения, которые разговаривают друг с другом, вместо того, чтобы писать один огромный монолит. Соответственно, возникает вопрос – а как они будут разговаривать друг с другом? Можно прописать связку между ними хардкодом, но тогда это, по большому счёту, не так уж сильно отличается от монолитного приложения, которое просто состоит из многих разных модулей, в которых «всё гвоздями прибито». Мы ведь хотим более гибкую связь между ними. И это ещё до того, как мы говорим о шардировании внутри каждого микросервиса. В какой-то момент мы хотим перформанса, и у нас появляется Load Balancer.

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

— Какие преимущества есть у решений Spring Cloud? Есть ли какие-то альтернативы?

Кирилл: Это изначально набор различных решений, стеков других компаний, например, многое взято из стека Netflix. spring-cloud-netflix — довольно важная часть Spring Cloud.

Но в тоже время, Spring Cloud не привязывает вас жёстко к стеку Netflix, нет, он говорит, хочешь — используй Consul от Hashicorp в роли Discovery Server, и даже предлагает имплементацию, хочешь — что-то другое (но везде есть нюансы, кхе-кхе).

Думаю, Spring Boot многое черпал из Dropwizard, сейчас же у него даже с ним есть какие-то интеграции. Есть, по-моему, фреймворк Axon, у которого тоже есть различные подвязки для того, чтобы делать CQRS-сервисы с интеграцией, там есть какая-то Discovery. В общем, фреймворки есть, называть их особо смысла нет, потому что Spring Boot уже засосал в себя более-менее популярные. Особняком стоит разве что Bootique, тоже приятный фреймворк, но не такой масштабный, конечно. Исповедует концепцию статической конфигурации, в отличие от подхода Spring. Про него можно даже доклад с Joker/Jpoint послушать.

— Про минусы мы, я так понимаю, уже сказали: если можно не делать микросервисы, то лучше их не делать.

Кирилл: Это действительно сложно. Микросервисы — это усложнение, усложнение как самой инфраструктуры бизнес-приложений, так и усложнение систем поддержки (мониторинг/логирование). Делать их нужно, только если есть весомые аргументы, которые перевешивают все минусы.

Как правило, эти аргументы про масштабирование, высокие нагрузки, реже про «процессное масштабирование» для сегрегации технологий/команд. Когда у тебя много команд, и тебе нужно эти команды как-то друг от друга изолировать, придумать формат их общения. Если хотите подробнее посмотреть то, про что говорил Евгений (и про хардкод, и про различные паттерны, представленные Spring Cloud) — на одном из первых JUG-ов я и Александр Тарасов выступали с докладом «WILD microSERVICES». В докладе есть часть с демкой как раз про то, о чём мы сейчас говорили, но есть и теоретическая часть со слайдами и картинками, на которых, отчасти, мы попытались пояснить, как и зачем по этому пути шли мы 🙂

— Я правильно понимаю, что у Spring Cloud нет применения для монолитной архитектуры?

Евгений: Он даёт инструменты, которые помогают микросервисам. Всё. Соответственно, монолитная архитектура тут ни при чём.

— Spring Boot — это про «магию». В Spring Cloud тоже «магия» есть, в Spring вообще много «магии». Появляются такие инструменты, которые создают много высокоуровневой инфраструктуры для разработчика. Это хорошо или плохо, на ваш взгляд?

Евгений: Это хорошо, потому что это позволяет людям намного быстрее выйти в продакшн. Тебе не надо пилить свой велосипед, тебе не нужна своя инфраструктура с нуля, ты можешь взять уже готовую платформу и начинать заниматься своей бизнес-логикой, вместо того, чтобы продумывать, а как технически это всё реализовать. Вам всё дают из коробки.

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

Евгений: Это коробка, в которой есть набор сервисов и готовых инструментов, которые можно юзать. И это очень удобно. Это стандартные вещи, которые нужны всем. Это всё равно, что спорить о том, ORM — это хорошо или плохо? Хочешь, запускай и клади в базу данных, потом начинай перегонять из ResultSet результат в объекты и так далее, но это нужно всем, поэтому придумали ORM, чтобы это у всех одинаково происходило по каким-то определённым конвенциям. Конвенции дают бенефит. Всё просто. Так же и здесь. Так, в принципе, развивается мир программирования: в любом направлении появляются популярные вещи, появляется фреймворк, который передаёт из коробки стандартный набор вещей, которые нужны всем, кто в эту область залез.

— Допустим, есть некая компания, в которой все работают на Spring Cloud или на Spring Boot, и тут приходит кто-то и говорит: «Я не хочу писать на Spring Boot, сам буду пилить велосипеды на Java 7. И стримы мне не нравятся, ничего мне не нравится». Таких сотрудников обычно переучивают или выпинывают? Или же им дают работать, как они хотят?

Евгений: Я таких ретроградов просто на работу не беру. В свою компанию я сам набираю работников и очень внимательно проверяю, чтобы они либо были готовы учиться, либо уже знали о современных технологиях. А те, кто знает только то, что было когда-то, и не хочет учиться новому — мне такие просто не нужны. Я с ними просто не успею вовремя сдать проект. Тут цена вопроса. Представь себе человека, который только знает ассемблер. И он говорит: «Я очень круто знаю ассемблер, я не готов учить Java, потому что на ассемблере можно сделать всё. Да, там немножко долго, но зато всё, и у меня полностью есть контроль». Сколько таких людей нужно?

Кирилл: У нас люди приходят, всем не нравятся разные вещи, это нормально. Главное, что у людей есть возможность всё это поменять и делать как-то по-другому, привести остальных в светлое будущее. К нам вообще не стоит идти, если не готов отстаивать свои идеи и корпеть над трансформацией процесса в лучшую сторону. В конечном итоге, любое решение — это некоторый компромисс между одним, вторым и третьим.

— В анонсе вашего тренинга вы говорите, что начнёте писать микросервисный проектик. «Для тех, кто хочет понимать, какие проблемы будут при переходе на микросервисную архитектуру, так пропагандируемую Spring Cloud, уметь бороться с ними, а также просто быть в курсе этого динамично развивающегося стека». Где возникают основные проблемы, в каких моментах?

Кирилл: Проблемы, кхм, обычно как только ты начинаешь масштабно использовать какое-то решение, внедрять её в свою инфраструктуру, в свои процессы, то сразу натыкаешься на огромное количество багов и проблем. Например, для упрощения процессов доставки нам нужно было упаковывать приложения в Docker (после, правда, мы нашли компромисс!). Docker частично инкапсулирует сеть от приложения. Приложение, в свою очередь, радостно регистрируется на Discovery Сервере под внутренним адресом Docker, и делает вид, что так и должно быть. Само собой, другие приложения работать по этому адресу с ним не могут, приходится делать различные манипуляции для определения правильного адреса, ещё хуже, когда приложения вынуждены работать через reverse proxy. Проблема, в основном, в тех местах, в которых остались белые пятна для фреймворков. Они все хорошо работают на простых примерах или заготовленных PaaS типа PCF (хотя и тут есть нюансы), в более сложных условиях сразу начинаются нестыковки, что логично, ведь нельзя сделать ПО на все случаи жизни, ещё и удобное для всех команд.

Есть много пятен, которые приходится закрывать либо собственными силами, либо идти по пути наименьшего сопротивления — например, иметь стек, очень похожий на какой-нибудь Pivotal Cloud Foundry, возможно даже покупать платную версию. В Spring Boot есть шероховатости, конечно, далеко не всегда всё задокументировано. Тот же Spring Boot куда более популярен, чем Spring Cloud, и видно, что пишут его люди разного уровня. Там есть всяких сортов говнокод. В Spring Cloud же с этим ещё хуже. Там интегрировано много различных наработок других компаний, например Netflix, и у каждой такой интеграции – своё легаси, из-за которого какая-нибудь абстракция да начинает течь (благо, модель «магических аннотаций» позволяет хоть как то дышать разработчикам).

— Мы плавно подошли к следующему вопросу: я сегодня зашёл на сайт Spring Cloud, увидел, что там целая куча всяких модулей, каких-то коннекторов, есть Netflix-модуль, есть Consul-модуль, есть модуль для RabbitMQ с Kafka, есть модуль для инфраструктуры Amazon и так далее. Допустим, под мою инфраструктуру модуля нет. Что мне лучше делать: переехать на новую инфраструктуру, запилить собственный коннектор или ждать, пока вендор моей инфраструктуры сделает коннектор под Spring? Просить Spring Cloud об этом, писать письма?

Кирилл: Писать письма точно бесполезно. Ты можешь сделать свой проект с нужной реализацией, которую потом можно легко использовать, или даже интегрировать своё поделие как официальный Spring Boot при наличии запросов от коммьюнити. Становление «частью» Spring Cloud — весьма вероятный исход для популярных решений, но в тоже время для непопулярных решений такой расклад маловероятен.

— То есть либо попытаться самому пилить, либо ждать от вендора какого-то решения, при этом непонятно, будет оно или нет.

Кирилл: Да как и во всём — либо делать самому, либо ждать. Ждать можно сколько угодно времени, и совершенно не факт, что желаемое произойдёт.

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

— То есть ты всё-таки за переезд?

Евгений: Я считаю, что когда ты начинаешь новый проект, то очень важно проверить, что уже существует, и очень важно поставить на правильную лошадь, потому что если ты идёшь с какой-то отмирающей технологией, то в какой-то момент ты можешь оказаться в полной жопе, и будешь продолжать клепать костыли, страдать, мучиться и ненавидеть свою работу. А весь мир будет тебя обгонять, и, пока ты допилишь свой проект, будет уже 100500 альтернативных, которые благодаря более правильному выбору технологии давно тебя обогнали, хотя, может быть, ты начинал первым.

— Расскажите про мониторинг и логирование: как я понимаю, здесь могут быть проблемы, связанные с тем, что если у нас запущены какие-то микросервисы, а они существуют в каких-то контейнерах, то с мониторингом и логированием совершенно очевидная проблема, которая заключается в том, что эти все системы крутятся в своих машинах. Например, Docker — замкнутый, к нему надо достучаться и так далее. Spring Cloud как-то помогает вообще мониторить и логировать вот эти контейнеры, виртуальные машины и так далее?

Кирилл: Как я уже говорил, одна из сложностей — иметь сквозной идентификатор, по которому можно смотреть логи в рамках внешнего запроса по всем задействованным в нём сервисам. Spring Cloud Sleuth помогает нам добавить метаинформацию в логируемые сообщения.

Он может действовать довольно жёстко, инструментируя какую-то часть кода, отвечающую за внешнее взаимодействие, добавляя туда необходимую метаинформацию (сквозные идентификаторы, времена ответов, и т.д.) Также из коробки можно получить интеграцию с инструментом OpenZipkin, который аккумулирует различную информацию по отправленным ему трейсам и обнаруживает самые проблемные запросы, которые длятся долго, падают, ретраятся и ещё что-нибудь такое. И уже встаёт вопрос о распространении этой информации для больших систем: есть варианты через очереди предоставлять информацию Zipkin, можно напрямую писать, можно хранить это дело в разных источниках. Тут много вариаций.

Кажется, что эти инструменты даже решают поставленные проблемы, но, как я и сказал, сейчас это скорее белое пятно в не очень продакшн-виде. Есть ещё множество различных решений, помогающих мониторить состояние системы, например, Hystrix dashboard, который отображает работоспособность отдельных компонент в системе. Turbine, который позволяет агрегировать различные маленькие дашбордики в один большой, показывает состояние всей системы в целом. Но, как правило, там тоже есть очень много нюансов. Просто так это не развернёшь и не установишь, это довольно сложно интегрируется. С тем же reverse proxy это не дружит, авторизацию необходимо делать свою, и т.д. В общем, для крупной компании использование таких инструментов — это довольно большой труд.

— Ребята, спасибо большое!

Кстати, если хотите пообщаться с Евгением и Кириллом — приходите на нашу конференцию Joker 2017. Они приезжают с докладом «Boot yourself, Spring is coming» (это большой серьёзный доклад, состоящий из двух частей, каждая из которых длится один час).

Если же хочется более глубокого погружения, они проведут два специальных тренинга:

• Writing full stack microservice application with Spring Boot
• Spring Boot & Spring Cloud

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

Обращаем внимание, что каждый из них занимает весь день (с 10 до 18 часов). Желательно иметь ноутбук со следующим ПО: IntelliJ IDEA, Docker, Docker Compose, Java 8. Тренинги пройдут 1-2 ноября, то есть до Joker, таким образом, вы сможете взглянуть на доклады Евгения и Кирилла сквозь призму приобретенных знаний и навыков.

• Блог компании JUG Ru Group
• Java

Обзор Spring-компонентов. Часть 2 – Spring Cloud

В обзоре собраны краткие описания каждого компонента экосистемы, чтобы дать понимание – как выглядит мир Spring, и ориентиры – что из этого стоит изучить глубже и применять в проекте.

Вступление

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

Но возникает проблема, – потребитель сервисов не умеет работать с множеством экземпляров. Для связи прикладных сервисов в целостное приложение, необходимы инфраструктурные сервисы.

Подсистема Spring Cloud состоит из:

1. Зависимостей, адаптирующих Spring Boot приложения к облачной среде.
2. Инфраструктурных сервисов, в виде готовых Spring-приложений, переносимых​ между облачными платформами​.
3. Клиентов сетей Service Mesh, реализующих инфраструктурные сервисы.
4. Клиентов облачных платформ, реализующих инфраструктурные и коммерческие сервисы.
5. Микро-фреймворков для разработки микросервисов и их оркестровки.

Термины

Чтобы ориентироваться в тексте, важно понимать отличие нового термина «инфраструктурные сервисы» от «облачных платформ» и «прикладных сервисов».

Прикладные сервисы — реализуют бизнес-логику распределенного приложения.

Инфраструктурные сервисы – координируют взаимодействие экземпляров прикладных сервисов.

• Маршрутизация – распределение запросов между типами сервисов;
• Балансировка – распределение запросов между экземплярами сервисов;
• Проброс пользовательской аутентификации из шлюза в сервисы;
• Защита межсервисных запросов от взлома и повреждения техническими сбоями;
• Механизмы отказоустойчивости;
• Реализация манифеста 12-факторных приложений.

Облачные платформы – распределяют по физическим серверам docker-контейнеры или поды (pod).

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

• Инфраструктурные сервисы;
• Коммерческие сервисы.
  (встроенные MQ-брокеры, базы данных, сервисы отправки SMS и т.п.)

Под (pod) – минимальный юнит развертывания в Kubernetes, содержит произвольное количество docker-контейнеров.

Список компонентов и ссылки на главы обзора

Для общего видения, ниже представлено распределение проектов Spring по типам. Некоторые проекты Spring Cloud-раздела не содержат в названии Cloud, но осмысленные варианты использования их в монолитных системах не были найдены.

Компоненты из первой части обзора – «Spring Boot и фреймворк интеграции»

Компоненты Spring Boot приложений

1.1 Уровень интеграции компонентов
Spring Boot
Spring Framework – Core
1.2 Уровень бизнес-логики
Spring Framework – Testing
Spring Framework – Languages
Spring Shell
Spring Statemachine
Spring Batch
Spring Security
Spring Security
Spring Security Kerberos
Spring Authorization Server

2. Уровень обмена данными с хранилищами
Spring Framework – Data Access
Spring LDAP
Spring Data
Spring Data Commons
Поддержка SQL БД
Spring Data JPA
Spring Data Envers
Spring Data REST
Spring Data JDBC
Spring Data R2DBC
Spring Data for Apache Solr (устарел)
Spring Data JDBC Extensions (устарел)

Поддержка NoSQL БД
Spring Data MongoDB
Spring Data Elasticsearch
Spring Data Redis
Spring Data Neo4j
Spring Data for Apache Cassandra
Spring Data Couchbase
Spring Data LDAP
Поддержка Grid-хранилищ
Spring Data for Apache Geode
Spring Data for VMware Tanzu GemFire
Интеграция с BigData
Spring for Apache Hadoop (устарел)

3. Уровень сетевого обмена данными
Spring Framework – Web MVC (Web Servlet)
Spring Framework – WebFlux (Web Reactive)
Spring Framework – Integration
Spring Web Flow
Spring HATEOAS
Spring for GraphQL
Spring Web Services
Spring REST Docs
MQ (Message Queue)
Spring AMQP
Spring for Apache Kafka

4. Фреймворк корпоративной интеграции

Компоненты Spring Cloud приложений

5. Адаптация Spring Boot приложений к облачной среде
Spring Cloud
Spring Cloud Commons
Spring Cloud OpenFeign
Spring Cloud Circuit Breaker
Spring Cloud Security
Spring Cloud Schema Registry
Spring Cloud Sleuth
Spring Cloud Contract
Spring Cloud Cluster
Spring Session
Spring Session Core
Session-репозитории
Spring Session Data Redis
Spring Session MongoDB
Spring Session JDBC
Spring Session Hazelcast
Spring Session for Apache Geode

6. Инфраструктурные сервисы, переносимые​ между облачными платформами​
Сервис с ролью Gateway
Spring Cloud Gateway
Сервисы с ролью Config Server
Spring Cloud Config
Spring Cloud Vault
Spring Cloud Bus
Сервисы с ролью Service Discovery
Spring Cloud Netflix (Eureka)
Spring Cloud Zookeeper
Интеграция с Service Mesh
Spring Cloud Consul

7. Инфраструктурные сервисы, интегрированные​ в облачные платформы​ (клиенты подключения)
Spring Cloud Alibaba
Spring Cloud Kubernetes
Spring Cloud for Amazon Web Services
Spring Cloud Azure (Microsoft)
Spring Cloud GCP (Google)
Spring Cloud for Cloud Foundry
Spring CredHub
Spring Vault
Spring Cloud Connectors
Администрирование приложений в облачных платформах
Spring Cloud CLI
Spring Cloud Skipper
Spring Cloud Pipelines (устарел)
Сервисы администрирования
с ролью Open Service Broker
Spring Cloud App Broker
Spring Cloud Open Service Broker
Spring Cloud – Foundry Service Broker (устарел)

8. Микро-фреймворки для разработки микросервисов
Spring Cloud Function
Spring Cloud Stream
Spring Cloud Stream Applications
Spring Cloud Task
Spring Cloud Task App Starters
Оркестровка конвейеров из Stream и Task сервисов
Spring Cloud Data Flow
Spring Flo

Компоненты Spring Cloud приложений

Адаптация Spring Boot приложений к облачной среде

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

Адаптация приложений выполняется встраиванием maven зависимостей, реализующих клиентский LoadBalancer, паттерн «предохранитель» (Circuit Breaker), аутентификацию клиентов и межсервисных запросов в распределенной системе и пр.

1. Spring Cloud

Это раздел вступительной документации, не описывающий какой-либо конкретный компонент.

Из полезной информации, он содержит описание 850 properties настроек Cloud компонентов. Логически, эти настройки дополняют документацию к следующему компоненту «Spring Cloud Commons».

2. Spring Cloud Commons

Транзитивная зависимость, не требующая явной загрузки. Расширяет Spring Boot, содержит две библиотеки:

2.1. Spring Cloud Context – клиент для загрузки properties файлов с Config Server и загрузки в DI-контейнер бинов, специфичных для Spring Cloud компонентов. Поддерживает шифрование, при передаче properties файлов.

2.2. Spring Cloud Commons (Commons в Commons, да) – для настройки абстракций Service Discovery, Circuit Breaker, LoadBalancer и ServiceRegistry независимо от имплементации.

LoadBalancer – абстракция «клиентского» балансировщика запросов.
Ribbon – его базовая имплементация.

Клиентский балансировщик используется, когда ваш прикладной сервис обращается к другим сервисам напрямую, в обход Gateway. Логика работы – запрашивает в Service Discovery ip-адреса подходящих запросу экземпляров сервисов и обеспечивает «веерную» рассылку запросов – каждый следующий запрос передается на следующий в списке ip и далее по кругу.

LoadBalancer задокументирован только в «Spring Cloud Commons».
Документация для Ribbon, возможно по ошибке, удалена из содержания портала, но еще гуглится.

3. Spring Cloud OpenFeign

Декларативный REST клиент – позволяет одной-двумя аннотациями организовать отправку HTTP запросов. Добавляется в прикладные сервисы как maven зависимость.

Используется для взаимодействия с инфраструктурными и прикладными микросервисами. Поддерживает интеграцию с Service Discovery, Circuit Breaker и LoadBalancer.

Недостаток: может принимать только текстовые данные, но не двоичные, – загружать файлы не получится.

4. Spring Cloud Circuit Breaker

Компонент для повышения отказоустойчивости сервисов, путем временного прерывания отправки запросов. Добавляется в прикладные сервисы как maven зависимость.

При перегрузке вызываемого сервиса, когда запросы завершаются ошибкой «превышен таймаут ожидания ответа», Circuit Breaker временно прерывает повторную отправку исходящих запросов, чтобы вызываемый сервис мог восстановить работоспособность. Также экономятся ресурсы отправляющего запросы сервиса.

Является универсальным API для имплементаций: Netfix Hystrix, Alibaba Sentinel, Spring Retry, Resilience4J.

5. Spring Cloud Security

Расширение Spring Security, реализует:

• Единый вход OAuth2, с ретрансляцией токенов (проброс токенов извне, через Gateway).
• Защиту ресурсов токенами OAuth2.

6. Spring Cloud Schema Registry

Компонент для форматно-логического контроля сообщений Kafka на уровне библиотеки сериализации Apache Avro.

Подробнее о сериализации в Kafka

При работе с Kafka, из приложения-отправителя передаются java классы, и приложение-потребитель получает те же java классы. Сам Kafka хранит только массивы байтов. Поэтому, при передаче классов, используется сериализация – извлечение из классов полезных данных и преобразование в массив байтов. А при получении классов из Kafka, обратный процесс – десериализация.

Apache Avro – популярная библиотека сериализации для Kafka, с поддержкой схем форматно-логического контроля. Может на этапе сериализации валидировать сообщения на соответствие схеме – проверять имена атрибутов, типы, структуру вложенности, наличие обязательных атрибутов и прочие параметры.

7. Spring Cloud Sleuth

Реализует трассировку и логирование запросов для анализа проблем в распределенной системе.

8. Spring Cloud Contract

Зонтичный проект для реализации подхода Consumer Driven Contracts. Пока содержит один подпроект:

• Spring Cloud Contract Verifier – поддержка разработки потребительских контрактов (CDC) для приложений на основе JVM.

9. Spring Cloud Cluster

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

Spring Session

10. Spring Session Core

Компонент для межсервисного обмена данными об аутентификации и другими атрибутами HTTP сессии. Поддерживает несколько сессий в одном браузере и отправку сессий в заголовке.

Репозитории Session

Надстройки к «Spring Session Core» для хранения атрибутов сессий в БД.

11. Spring Session Data Redis

Стандартный и реактивный репозитории сессий для Redis.

12. Spring Session MongoDB

Репозиторий сессий для MongoDB.

13. Spring Session JDBC

Репозиторий сессий для JDBC.

14. Spring Session Hazelcast

Репозиторий сессий для Hazelcast.
Hazelcast – In-Memory Data Grid, облегченный за счет вынесения функционала распределенных вычислений в отдельный модуль Hazelcast Jet.

15. Spring Session for Apache Geode

Репозиторий сессий для Apache Geode.
Apache Geode – полнофункциональный In-Memory Data Grid.
Отличия Grid от БД описаны в первой части обзора.

Инфраструктурные сервисы, переносимые​ между облачными платформами​

Сервис с ролью Gateway

16. Spring Cloud Gateway

Сервис для маршрутизации входящих запросов между микросервисами и балансировки между экземплярами микросервисов.
Заменяет устаревший Zuul и, в отличии от Zuul, поддерживает реактивность и WebSockets.

Сервисы с ролью Config Server

Сервисы с ролью Config Server (сервер конфигураций) являются внешним хранилищем настроек всех сервисов приложения для реализации третьего принципа 12-факторных приложений. Настройки хранятся в виде текстовых properties файлов, которые рассылаются сервисам по запросу.

17. Spring Cloud Config

Сервер конфигураций по умолчанию.

18. Spring Cloud Vault

Обертка над Spring Vault для использования коммерческого хранилища секретов HashiCorp в роли сервера конфигураций.

18. Spring Cloud Bus

Механизм доставки конфигураций через брокеры Kafka или AMQP.
Позволяет организовать централизованное хранение конфигураций в GitHub и других источниках.

Сервисы с ролью Service Discovery

Бывают ситуации, когда некоторые контейнеры не работают. На это может быть несколько причин:

1. На хост-сервере занята память и Linux, в рамках штатного поведения, удалил один из процессов для ее высвобождения;
2. Сервисы облачной платформы, в рамках штатного поведения, удалили неработоспособный или устаревший сервис и еще не запустили новый экземпляр.

Service Discovery отслеживает доступность сервисов, их ip-адреса, роли и предоставляет эту информацию другим компонентам распределенного приложения.

20. Spring Cloud Netflix (Eureka)

Сервис с ролью Service Discovery. Унаследован от Netflix и рекомендован по умолчанию.

21. Spring Cloud Zookeeper

Клиент интеграции для Zookeeper.

Zookeeper это Service Discovery по умолчанию для Apache Kafka. Если в проекте используется Kafka с Zookeeper, отдельный Service Discovery не требуется, достаточно подключиться к уже используемому.

Интеграция с Service Mesh

Service Mesh – комплекс инфраструктурных сервисов, реализованный как самостоятельное ПО, не привязанное ни к облачным платформам, ни к фреймворкам разработки.

22. Spring Cloud Consul

Клиент для использования Config Server и Service Discovery, встроенных в Consul.
Consul – одна из реализаций концепции Service Mesh.

Примечание: в главах 24.9 и 24.10 отражены клиенты интеграции с Istilo, – еще одной реализаций концепции Service Mesh.

Инфраструктурные сервисы, интегрированные​ в облачные платформы​ (клиенты подключения)

23. Spring Cloud Alibaba

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

• Инфраструктурные сервисы от Alibaba, переносимые​ между облачными платформами.
• Клиенты для коммерческих сервисов в облаке Alibaba.

Инфраструктурные сервисы:

23.1. Nacos Config – сервис с ролью Config Server;

23.2. Nacos Discovery – сервис с ролью Service Discovery;

23.3. Sentinel – сервис с ролью Circuit Breaker;

23.4. Dubbo – RPC фреймворк для взаимодействия сервисов по протоколам: Dubbo, RMI, Hessian, HTTP, Web Service, Thrift, Memcached, Redis.
Поддерживает: четыре стратегии балансировки нагрузки и пять стратегий отказоустойчивости.

23.5. RocketMQ Binder – клиент интеграции с RocketMQ.

Клиенты для коммерческих сервисов в облаке Alibaba:

23.6. Cloud ANS (Application Naming Service) – Service Discovery;

23.7. Cloud ACM (Application Configuration Management) – Config Server;

23.8. Cloud OSS (Object Storage Service) – хранилище данных;

23.9. Cloud SchedulerX – планировщик заданий;

23.10. Cloud SMS – отправка и прием SMS.

24. Spring Cloud Kubernetes

Клиенты подключения Spring приложений к инфраструктурным сервисам, интегрированным в Kubernetes. Не являются обязательными для развертывания приложения Spring Boot в Kubernetes.

Роль LoadBalancer:

24.1 LoadBalancer for Kubernetes – клиент для использования Load Balancer встроенного в Kubernetes.

Роль Config Server:

24.2 Kubernetes PropertySource – реализация роли Config Server на основе ConfigMap и PropertySource.
24.3 Spring Cloud Kubernetes Config Server – расширение инфраструктурного сервиса «Spring Cloud Config» с поддержкой хранения конфигурации в Kubernetes Config Maps и Secrets.
24.4 Spring Cloud Kubernetes Configuration Watcher – компонент для обновления настроек сервисов без их перезапуска.

Роль Service Discovery:

24.5 DiscoveryClient for Kubernetes – клиент для использования Service Discovery встроенного в Kubernetes.
24.6 Spring Cloud Kubernetes Discovery Server – инфраструктурный сервис с ролью Service Discovery и поддержкой поиска сервисов в кластере Kubernetes.

Интеграция с Spring Boot Actuator:

24.7 Pod Health Indicator – передает информацию о работоспособности сервисов в Spring Boot Actuator.
24.8 Info Contributor – передает информацию о подах в Spring Boot Actuator.

Интеграция с Istilo:

Istilo – одна из реализаций концепции Service Mesh.

24.9 Kubernetes native service discovery – клиент для передачи данных в Istilo из Service Discovery, встроенного в Kubernetes.
24.10 Kubernetes Ecosystem Awareness – передает информацию о кластере в Istilo.

Прочее:

24.11 Leader Election – API выбора лидера Spring Integration с использованием Kubernetes ConfigMap.
24.12 Service Account – зависимости для доступа к кластеру на основе ролей.

25. Spring Cloud for Amazon Web Services

Клиенты подключения Spring приложений к инфраструктурным сервисам в AWS.

25.1 Spring Cloud AWS Core – клиент для базовой настройки безопасности и конфигурации через «Amazon EC2» и «AWS CloudFormation».

25.2 Spring Cloud AWS Context – клиент для сервисов:

• Amazon S3 (Simple Storage Service) – загрузка ресурсов через абстракцию загрузчика ресурсов Spring.
• Amazon Simple Email Service – отправка почты через абстракцию почты Spring.
• Amazon ElastiCache – декларативное кэширование через абстракцию кэширования Spring.

25.3 Spring Cloud AWS JDBC – клиент для автоматического поиска и настройка источника данных в «Amazon RDS» (Relational Database Service).

25.4 Spring Cloud AWS Messaging – клиент для обмена сообщениями через:

• Amazon SQS (Simple Queue Service) – точка-точка,
• Amazon SNS (Simple Notification Service) – издатель-подписчик.

25.5 Spring Cloud AWS Parameter Store Configuration – клиент для использования в роли Config Server, сервиса «Amazon SMPS» (Systems Manager Parameter Store).

25.6 Spring Cloud AWS Secrets Manager Configuration – клиент для использования в роли Config Server, сервиса «Amazon Secrets Manager».

26. Spring Cloud Azure

Клиенты подключения приложений Spring к инфраструктурным сервисам в Microsoft Azure.

Клиентов много, они представлены в виде maven зависимостей и не выделены в именованные компоненты. Maven зависимости могут иметь несколько вариантов использования. Документация к «Spring Cloud Azure» достаточно качественная, чтобы изучать возможности проекта непосредственно по ней, как минимум по составу глав документации.

Прим. Одной из причин появления этого материала была предельно некачественная документация по большинству компонентов Spring.

Кроме того, в облачной платформе Microsoft Azure есть сервис «Azure Spring Apps», именуемый в Spring-документации «Azure Spring Cloud». Сервис создан и поддерживается командой проекта «Spring Cloud Azure» и рекомендован к использованию по умолчанию.

27. Spring Cloud GCP

Клиенты подключения приложений Spring к инфраструктурным сервисам в Google Cloud Platform.

Клиентов много, они представлены в виде maven зависимостей и не выделены в именованные компоненты. Maven зависимости могут иметь несколько вариантов использования. Документация к «Spring Cloud GCP» достаточно качественная, чтобы изучать возможности проекта непосредственно по ней, как минимум по составу глав документации.

28. Spring Cloud for Cloud Foundry

Реализует три maven зависимости:

1. Клиент службы единого входа (SSO – Single Sign On) для привязки учетных данных Cloud Foundry к функциям Spring Boot.
2. Клиент для использования Service Discovery, встроенного в Cloud Foundry.
3. 13 properties настроек, специфичных для Cloud Foundry.

29. Spring CredHub

Клиент интеграции с CredHub.
CredHub – сервер учетных данных в Cloud Foundry.

30. Spring Vault

Клиент интеграции с HashiCorp Vault.
HashiCorp Vault – защищенный сервер для хранения конфиденциальной информации. Компонент также интегрирован в «Spring Cloud Vault», в роли Config Server с шифрованием.

31. Spring Cloud Connectors (развитие планируется в рамках другого проекта)

Компонент для автоматического подключения к службам в облаке. Поддерживает облака: Cloud Foundry и Heroku. Для других облачных платформ, имеет 7 community-версий.

Проект в статусе поддержки без развития, – планируются обновления безопасности, но не функционала. Развитие функционала планируется в рамках нового проекта Java CFEnv.

Администрирование приложений в облачных платформах

32. Spring Cloud CLI

Приложение командной строки под Linux, Mac и Windows для развертывания, запуска и автонастройки микросервисов скриптами YAML, Groovy и командами CLI.

33. Spring Cloud Skipper

Компонент для обнаружения Spring приложений в облачных платформах, их обновления и отката между разными версиями без необходимости повторно собирать приложения из исходного кода. Может использоваться в CI/CD как версионный «единый источник достоверной информации».

Разрабатывался для «Spring Cloud Data Flow», но может использоваться для других Cloud приложений. Поддерживает платформы: Local, Cloud Foundry и Kubernetes.

34. Spring Cloud Pipelines (устарел)

Клиент интеграции с CI/CD системами Jenkins и Concourse.
Устарел, не рекомендован к использованию.

Сервисы администрирования с ролью Open Service Broker

Open Service Broker – сервис с REST API с ограниченной функциональностью по администрированию микросервисов в облачной платформе.

Реализует:
1. Регистрацию сервисов в каталоге облачной платформы.
2. Создание и удаление экземпляров сервиса в облачной платформе.
3. Привязку вашего клиентского приложения к сервисам в облаке и отвязку его.

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

• Администратор со стороны клиента может скриптами «динамически собирать» приложения из множества сервисов, генерируя набор HTTP запросов. Функции администрирования выполняются за секунды.
• Администраторы коммерческого облака разгружаются от большого объема работы, облачные сервисы становятся дешевле по себестоимости. Исключены проблемы, связанные с недопониманием при передаче запросов на выполнение этих функций, так как нет самих запросов в техподдержку.

35. Spring Cloud App Broker

Готовый сервис, реализующий API Open Service Broker.
Поддержка облачных платформ пока ограничена Cloud Foundry.

36. Spring Cloud Open Service Broker

Набор зависимостей для разработки сервиса, реализующего API Open Service Broker (OSB). Требует ручного программирования логики OSB (пример). Позволяет расширить функциональность брокера, если у вас частное облако. Поддерживает все облачные платформы, реализующие клиент для OSB: Cloud Foundry, Kubernetes и OpenShift и т.п.

37. Spring Cloud – Cloud Foundry Service Broker (устарел)

Набор зависимостей для разработки сервиса, реализующего API Open Service Broker (OSB).
Устарел, дальнейшее развитие перенесено в описанный выше проект «Spring Cloud Open Service Broker».

Микро-фреймворки для разработки микросервисов

38. Spring Cloud Function

Микрофреймворк для разработки переносимых между облаками сервисов, с автогенерацией REST (опционально RSocket) интерфейсов.

Позволяет сосредоточиться на бизнес-логике. Для этого реализован механизм автоматического оборачивания REST-интерфейсами бинов, реализующих функциональные интерфейсы Supplier, Function или Consumer. Для этого, бины должны быть созданы одним из двух способов:

1. @Component класс метода реализует функциональный интерфейс Supplier, Function или Consumer;
2. Ответ @Bean метода оборачивается в тип функционального интерфейса Supplier, Function или Consumer.

Поддерживает реактивный, императивный и комбинированный стили программирования. Может запускать сервисы – «Spring Cloud Stream».

Поддерживает платформы: Local, AWS Lambda, Microsoft Azure, Google Cloud Functions, Apache OpenWhisk.

39. Spring Cloud Stream

Микрофреймворк для разработки переносимых между облаками сервисов, с автогенерацией MQ-интерфейсов (Kafka или AMQP). Допускает встраивание в конвейеры средствами компонента «Spring Cloud Data Flow».

Позволяет сосредоточиться на бизнес-логике. Для этого реализован механизм автоматического оборачивания MQ-интерфейсами бинов, реализующих функциональные интерфейсы Supplier, Function или Consumer.

Stream сервисы могут быть трех типов:

1. Source – получает данные из внешних ресурсов и передает в MQ-канал.
2. Processor – получает данные из «входного» MQ-канала, обрабатывает их и передает в «выходной» MQ-канал.
3. Sink – получает данные из MQ-канала и передает во внешние ресурсы.

Конвейеры данных – представляют множество Stream сервисов, выстроенных в цепочку и связанные MQ-интерфейсами для пошагового преобразования данных. Конвейер может иметь один Source-сервис, произвольное количество Processor-сервисов и один Sink-сервис.

Может вызываться из сервисов – Spring Cloud Function.
Может запускать сервисы – Spring Cloud Task.

Поддерживает MQ брокеры для взаимодействия в рамках конвейера: RabbitMQ, Apache Kafka, Kafka Streams, RocketMQ, Amazon Kinesis, AWS SQS, AWS SNS, Azure Event Hubs, Azure Service Bus, Google PubSub, Solace PubSub+.

40. Spring Cloud Stream Applications

Коллекция из 57 готовых сервисов Spring Cloud Stream (список), с поддержкой около 30 протоколов взаимодействия с внешними ресурсами.

Кроме базовой функциональности, проект содержит сервисы обработки видео:

• Image Recognition – нейронная сеть для анализа графических изображений;
• Semantic Segmentation – сегментирует графические изображения по модели DeepLab Tensorflow;
• Object Detection – идентифицирует объекты на графических изображениях.

41. Spring Cloud Task

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

Жизненный цикл сервиса состоит из старта, выполнения задачи и завершения работы. Сервис сам опрашивает источник данных (БД, CSV, XML и т.п.) и сохраняет результат в этот или другой источник.
Поддерживает Spring Batch для выполнения пакета однотипных задач.
Поддерживает источники данных: File, JDBC, Kafka, AMQP.

• из сервисов «Spring Cloud Stream»,
• на сервере администрирования «Spring Cloud Data Flow».

Поддерживает платформы: Local, Spring Cloud Data Flow (разворачивает сервисы в Cloud Foundry и Kubernetes), Cloud Foundry.

42. Spring Cloud Task App Starters

Коллекция из двух готовых сервисов Spring Cloud Task:

• Timestamp Task – печатает метку времени в stdout. Предназначен в первую очередь для тестирования.
• Timestamp Batch Task – выполняет 2 Task, каждое печатает имя задания и метку времени в stdout. Предназначен в первую очередь для тестирования.

Оркестровка конвейеров из Stream и Task сервисов

43. Spring Cloud Data Flow

Инструментарий для развертывания конвейеров данных из сервисов Spring Cloud Stream и Spring Cloud Task, на платформах Cloud Foundry, Kubernetes или локально (пример).

Поддерживает проектирование и развертывание конвейеров тремя способами:

• В графическом интерфейсе. Графический интерфейс также поддерживает мониторинг с использованием Wavefront, Prometheus, Influx DB или других систем.
• DSL командами,
• Через REST API.

«Spring Cloud Data Flow» и «Spring Cloud Skipper» проектировались для совместного использования:

44. Spring Flo

Графический интерфейс, встроенный в «Spring Cloud Data Flow», для создания и мониторинга конвейеров данных.

Заключение

Это была заключительная часть обзора. Рассмотрены 85 проектов, включающие 156 компонентов. Поправки и уточнения приветствуются.

Spring cloud что это

* Для физических лиц действует скидка 10% Закажите корпоративное обучение с учетом ваших потребностей

Описание

Spring Cloud – это проект, который позволяет создавать распределенные приложения с микросервисной архитектурой.

Использование Spring Cloud упрощает подключение к сервисам и получение возможностей окружения в облачных платформах.

На курсе вы познакомитесь с множеством доступных компонентов, детально изучите архитектуру и широкие возможности Spring Cloud, узнаете о возможностях Spring Cloud и его компонентах. В ходе выполнения практических упражнений научитесь использовать компоненты Spring Cloud для решения рутинных задач.

После прохождения курса выдается
удостоверение о повышении квалификации государственного образца

Цели

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