Вступление
Принцип «искать нужно там где потерял, а не там где светло» кажется очевидным. И все же приходилось видеть, как участники смежного проекта два года бились в аналитическом параличе, выбрав неподходящие инструменты. Со временем, вопрос «что такое Spring» стал для источником опасений – не приведет ли незнание экосистемы к выбору ошибочного решения и бесполезной трате ресурсов на изучение или использование в проекте.
Перед структурированием компонентов, возник вопрос – на какой источник информации опираться. У Spring с этим творческий беспорядок – проекты в GitHub, реестр стартерных зависимостей, портал Spring Initializr, официальная документация – все источники противоречат друг другу. Решил опираться на документацию. В ней нет снятых с поддержки и экспериментальных проектов. Некоторые из 85 проектов включают несколько Spring-компонентов, поэтому их количество в обзоре – около сотни.
Методика анализа стандартная – выявляем границы системы, компоненты верхнеуровневой структуры и их назначение. Поскольку человек может одновременно оперировать примерно семью сущностями, вводим промежуточную структуру – разделяем компоненты на типы, представленные в КДПВ.
В обзоре собраны краткие описания каждого компонента экосистемы, чтобы дать общее понимание – как выглядит мир Spring, и ориентиры – что из этого стоит изучить глубже и, возможно, применить в проекте.
В разрезе проектов, структура получилась такая:
Компоненты Spring Boot приложений | |
|
1.1 Уровень интеграции компонентов 2. Уровень обмена данными с хранилищами |
Поддержка NoSQL БД 3. Уровень сетевого обмена данными |
Spring Integration |
|
Чтобы увидеть все проекты можно развернуть раздел «Компоненты Spring Cloud приложений», обзор на который будет во второй части.
Компоненты Spring Cloud приложений
Компоненты Spring Cloud приложений | |
|
5. Инфраструктурные сервисы, переносимые между облачными платформами и клиенты подключения Сервис с ролью Gateway |
6. Инфраструктурные сервисы, интегрированные в облачные платформы (только клиенты подключения) 7. Микро-фреймворки для разработки микросервисов |
Компоненты Spring Boot приложений
Уровень интеграции компонентов приложения
1. Spring Boot
Проект содержит пять разнородных компонентов:
1.1 Классы автоконфигурации для всех компонентов Spring.
1.2 Механизм загрузки и переопределения свойств для классов автоконфигурации.
1.3 Родительский POM для maven (spring-boot-starter-parent).
1.4 Плагин для maven (spring-boot-maven-plugin).
1.5 Spring Boot Actuator.
Назначение компонентов:
1.1. Классы автоконфигурации для всех компонентов Spring
Это привычные классы конфигурации, содержащие условные аннотации. Если не выполняется прописанные в аннотациях условия, блокируется запуск bean-методов. Аннотации проверяют:
Есть ли в проекте зависимость, требующая загрузки в контейнер Dependency Injection (DI) бинов этим классом автоконфигурации.
Не отключен ли разработчиком запуск этого класса автоконфигурации, через аннотацию в классе конфигурации.
Не переопределена ли разработчиком загрузка в DI отдельных бинов этого класса автоконфигурации, через ее реализацию в классе конфигурации.
Не переопределены ли разработчиком свойства для настройки бинов, через любой из 12 источников свойств.
И далее, класс автоконфигурации загружает бины в DI-контейнер по принципу «не навреди», отдавая приоритет настройкам разработчика.
1.2. Механизм загрузки и переопределения свойств для классов автоконфигурации
Поддерживаются 12 источников загрузки свойств в порядке приоритета.
В том числе, этот компонент поддерживает третий принцип 12-факторных приложений – «Настройки, зависящие от развертывания, должны храниться вне сервиса». Spring Boot позволяет вынести, в виде properties файлов, до 2600 настроек на сервер конфигураций Spring Cloud Config.
1.3. Родительский POM для maven (spring-boot-starter-parent)
Хранит информацию о версиях транзитивных зависимостей. Снимает необходимость указывать версии зависимостей в POM файле, автоматически подгружая совместимую.
1.4. Плагин для maven (spring-boot-maven-plugin)
В дополнение к формированию стандартных WAR и JAR файлов, он позволяет:
Создавать Fat JAR – включающие встроенный сервер.
Создавать Thin JAR – без библиотек внешних зависимостей. Зависимости подгружаются на сервере, при первом запуске. Множество микросервисов могут переиспользовать зависимости из единого локального maven репозитория.
Создавать Docker образы, в том числе многослойные. Многослойность теоретически позволяет ускорить сборку образа. Заявлено, что «медленно» собрав многослойный образ, далее, при минорных изменениях кода, можно будет быстро обновлять только один слой. Но тесты показывают, выигрыша нет. Второй «быстрый» этап выполняется в 6 раз медленнее, чем сборка полного образа штатными средствами Docker.
Запускать код проекта на исполнение командой run непосредственно из maven, с формированием jar в фоне. Позволяет скачать из Git исходный код с вложенной maven-embedded и запустить в системе, не требуя ничего, кроме установленного JDK.
1.5. Spring Boot Actuator
Реализует функционал JMX через стандартный HTTP протокол. Включает коллекцию преднастроенных точек подключения.
О некорректной терминологии в Spring:
Взглянув на этот список, начинают странно восприниматься многие утверждения. «мы ведем разработку на Spring Boot» звучит как «мы возим тонны кирпичей на ключах от грузовика». Произнесенное с большой значимостью «мы используем Spring без Spring Boot» вызывает вопрос – стоят ли сакрализации лишние полсотни строк в классе конфигурации?
Вопросы исчезают, когда выясняется что использование логически некорректных терминов стало частью маркетинговой стратегии. Они провоцируют поиск глубокого смысла, дают темы для конференций по «спринг-потрошению» и мотивируют создавать интернет-порталы по описанию Spring функциональности на человеческом английском.
Используемые в этой статье термины «Spring Boot/Cloud приложения» тоже формально некорректны, но выбраны как устоявшиеся и продвигаемые разработчиками Spring.
О документации Spring Boot:
Стоит учесть, что в документацию Spring Boot вынесены произвольные части описания каждого из компонентов Spring. Поэтому документацию по компонентам есть смысл читать в комплексе с одноименными разделами Spring Boot. Например, загрузка в БД начальных данных из файлов JSON описана в Spring Data, а из файлов в формате SQL – в Spring Boot.
Также, в документации Spring Boot есть раздел «How-to Guides» с рекомендуемыми шаблонами для использования различных компонентов Spring.
2. Spring Framework – Core
Корневой компонент:
2.1. IoC Container – компонент для внедрения зависимостей (DI - Dependency Injection) и реализации концепции IoC (Inversion of Control, инверсия контроля). На Хабре более устоялся синоним «DI-контейнер».
В этот контейнер Spring Boot загружает преднастроенные бины Spring-компонентов, а разработчик – бины с бизнес-логикой и логикой их взаимной интеграции (внедрения зависимостей). DI-контейнер сам выполняет внедрение зависимостей, обеспечивая «инверсию контроля».
Вспомогательный функционал:
2.2. Resources – унифицированный интерфейс и его имплементации для абстрагирования доступа к низкоуровневым ресурсам через классы JDK – File, Files, Path, InputStream, ByteArrayInputStream и к ресурсам в ServletContext.
2.3. Validation и Spring Type Conversion – набор библиотек для валидации, преобразования типов и локализация форматов.
2.4. SpEL – язык выражений Spring.
2.5. Spring AOP – для организации проксирования методов, – выполнения дополнительной логики перед или после выполнения методов, обернутых прокси-объектами.
В сравнении с полнофункциональными AOP-библиотеками, спроектирован по принципу 10% функциональности, закрывающей 100% типовых потребностей разработчика. Для нетиповых случаев предусvотрено подключение AspectJ.
Использование Spring AOP включает два шага:
Создать класс (прокси) с логикой, которая должна выполняться при вызове методов или возврате ответа из них.
Создать класс сканирования, с условиями при которых методы должны оборачиваться прокси-объектами.
Логика прокси-объекта может преобразовывать передающиеся данные, блокировать их передачу в метод или не затрагивать их, например, засекая время для измерения производительности или логируя факт передачи.
Механизм сканирования позволяет массово применять дополнительную логику к произвольным методам приложения. Пример: авторизация доступа в Spring Security к методам классов бизнес-логики.
2.6. Аннотации для проверки на Null в IDE.
2.7. Кодеки сериализации и буферы данных.
Уровень бизнес-логики
3. Spring Framework – Testing
Функционал для юнит и интеграционного тестирования в Spring.
4. Spring Framework – Languages
Поддержка языков Kotlin, Groovy и семейства Dynamic Language (JSR-223).
5. Spring Shell
Компонент для разработки приложений с интерфейсом командной строки.
6. Spring Statemachine
Компонент для реализации в приложении концепции конечного автомата.
7. Spring Batch
Компонент для однотипной обработки больших массивов данных. Как правило, при запуске приложение считывает набор заданий из источника данных (БД, файлы XML, CSV и т.п.) и сохраняет результат обработки в то же или другое хранилище.
Spring Security
8. Spring Security
Компоненты для авторизации, аутентификации и защиты от эксплойтов.
Авторизация – разрешение или блокировка доступов на трех уровнях:
уровень HTTP запросов,
уровень методов в java классах,
уровень отдельных записей БД.
Аутентификация – проверка, к какой учетной записи и роли относится пользователь.
Варианты реализации:
8.1. Username/Password – идентификация пользователя по логину и паролю.
Form – с отправкой логина и пароля в теле запроса,
Basic – с отправкой логина и пароля в заголовке запроса WWW-Authenticate,
Digest – с отправкой одноразовой хэш-суммы на основе логина и пароля.
8.2. Remember Me – идентификация пользователя в разных сеансах.
с хешированием токенов в cookie,
с хранением токенов в БД или ином хранилище.
8.3. Анонимная аутентификация – позволяет явно задать ресурсы, доступные анонимам, и запретить неавторизованный доступ к оставшимся. Страхует от NullPointerException, когда перехватчик аудита запрашивает SecurityContextHolder чтобы определить, какой принципал отвечает за данную операцию.
8.4. Pre-Authentication – аутентификация внешними системами:
по SSL-сертификату (X.509),
по заголовку HTTP запроса (Siteminder),
на уровне контейнера Java EE.
8.5. JAAS (Java Authentication and Authorization Service) - аутентификация средствами низкоуровневой структуры безопасности Java SE.
8.6. CAS (Central Authentication Service) – SSO-аутентификация (Single Sign-On – технология единого входа) на сервере CAS от компании Apereo.
8.7. X509 – взаимная аутентификация – проверка подлинности узла связи и проверки личности клиента на основе SSL-сертификата.
8.8. Run-As – поддержка выполнения пользователем некоторой логики от имени другого пользователя.
8.9. OAuth2 (компонент включает поддержку OpenID) – поддержка внешнего сервера аутентификации:
OAuth 2.0 (например, GitHub),
OpenID Connect 1.0 (например, Google).
Внешним сервером аутентификации может быть и ваше Spring-приложение (пример). Токены JWT лучше чем логин/пароль подходят для защиты межсистемных запросов.
8.10. SAML2 – протокол SSO-аутентификации на основе XML.
Кроме аутентификации, реализованы:
8.11. Поддержка хранения учетных данных пользователей:
в оперативной памяти,
в реляционной БД,
в LDAP.
LDAP – тип специализированных БД со своим уникальным языком запросов. Они спроектированы для хранения информации о пользователях – логинов, хэшей паролей и пользовательских ролей. Также могут хранить ФИО, должности, адреса, телефоны и прочие данные пользователей.
8.12. Logout - функция для аннулирования аутентификации.
Как организовать двухфакторную аутентификацию, аутентификация по географическому местоположению и т.п. в официальной документации не описано, но есть статьи на Baeldung.com. Только по Spring Security там 180 статей.
9. Spring Security Kerberos
Компонент для беспарольной аутентификации для Windows-пользователей, уже залогиненных под доменной учетной записью. Kerberos – протокол SSO-аутентификации, используемый в Windows Server (Active Directory).
10. Spring Authorization Server
Компонент для создания поставщиков удостоверений OpenID Connect 1.0 и продуктов сервера авторизации OAuth2. Новый проект с версией 0.3.0.
Уровень обмена данными с хранилищами
11. Spring Framework – Data Access
В модуле реализованы:
11.1. Transaction Management – компонент управления транзакциями.
11.2. DAO Support – компонент для перехвата исключений уровня DAO. Активируется аннотацией @Repository.
11.3. Spring JDBC – компонент для работы с реляционными БД через JDBC и jdbcTemplate.
11.4. Spring R2DBC – реактивный аналог Spring JDBC.
11.5. Spring ORM – компонент для работы с реляционными БД через произвольные имплементации JPA, включая Hibernate EntityManager, а также через Hibernate Session.
11.6. Spring OXM (Object-XML Mapping) – компонент для сериализации и десоциализации XML. Также используется синоним – маршаллинг.
12. Spring LDAP
Аналог Spring JDBC для LDAP, с реализацией LdapTemplate (термин LDAP).
Spring Data
13. Spring Data Commons
Общий функционал всех Spring Data компонентов. Предназначен для унифицированного взаимодействия с SQL, NoSQL, LDAP и Grid хранилищами. Позволяет мигрировать между разными типами БД, не затрагивая код, меняя только maven зависимости.
Основной функционал:
13.1. Repositories – включает:
Коллекцию стандартных CRUD-запросов, в том числе с пагинацией.
Единый язык запросов для разных типов БД (SQL, NoSQL, Grid).
Механизм проброса запросов в ORM или БД на специфичном для них языке (JPQL, SQL и т.п.)
Запросы на языке Spring Data формируются путем составления из ключевых слов имен java методов. При этом java методы должны расширять интерфейс CrudRepository или его наследников. Пример:
List<Person> findByLastnameOrderByFirstnameAsc(String lastname);List<Person> findByLastname – найти все Person с заданным значением в поле Lastname,
OrderByFirstname – отсортировать по полю Firstname,
Asc – тип сортировки «по возрастанию».
Подробнее по ссылкам:
Дополнительный функционал:
13.2. Projections – запросы отдельных атрибутов объектов. Запросы могут формироваться тремя способами:
Interface-based Projections – на основе дополнительного интерфейса,
Class-based Projections – на основе DTO,
Dynamic Projections – динамические.
13.3. Query by Example (QBE) – динамические запросы объектов, аналог Criteria.
13.4. Auditing – сбор информации, кто и когда создавал или изменял данные в БД.
Поддержка SQL БД в Spring Data
14. Spring Data JPA
Компонент для работы с любыми реляционными БД.
15. Spring Data Envers
Поддержка Hibernate Envers – аудит, кто и когда создавал или изменял данные в БД.
16. Spring Data REST
Реализация CRUD-операций с реляционными БД через REST API. Достаточно добавить entity-классы, и REST API сформируется для них автоматически. Использует REST запросы в HAL-формате (HAL – один из вариантов реализации HATEOAS).
17. Spring Data JDBC
Компонент для работы с реляционными БД, без поддержки JPA, EntityManager, Lazy и кэширования. Позиционируется как простое решение для простых задач. Поддерживает MyBatis и все еще поддерживает Spring Data Commons. Не путать со Spring JDBC в модуле «Spring Framework – Data Access».
18. Spring Data R2DBC
Компонент для работы с реляционными БД через реактивные драйверы.
19. Spring Data for Apache Solr (устарел)
Apache Solr – платформа полнотекстового поиска. Поддержка прекращена. Рекомендован переход на Elasticsearch. Примечание: устаревшие но поддерживаемые компоненты отражаются в обзоре, чтобы читателю не требовалось тратить время на изучение заведомо ненужных компонентов.
20. Spring Data JDBC Extensions (устарел)
Расширения для поддержки БД Oracle. Поддержка прекращена. Полезный функционал разнесен по другим компонентам Spring.
Поддержка NoSQL БД в Spring Data
21. Spring Data MongoDB
Поддержка MongoDB – классическая NoSQL БД с динамическими схемами. Может хранить записи с произвольным набором атрибутов, без предварительного конфигурирования.
22. Spring Data Elasticsearch
Поддержка Elasticsearch – БД, ориентированная на полнотекстовый поиск.
23. Spring Data Redis
Поддержка Redis – БД, обычно используемая для организации кэша или очередей сообщений (MQ).
24. Spring Data Neo4j
Поддержка Neo4j – графовая БД, одна из самых зрелых и полнофункциональных.
25. Spring Data for Apache Cassandra
Поддержка Cassandra – распределенная БД – масштабируемая и отказоустойчивая.
26. Spring Data Couchbase
Поддержка Cassandra – конкурент MongoDB. MongoDB вышла раньше и занимает большую долю рынка. До 2020 года на Couchbase были жалобы на нестабильность. Какая БД лучше, в интернете много споров с взаимоисключающей информацией.
27. Spring Data LDAP
Аналог Spring LDAP с поддержкой Spring Data Commons.
Поддержка Grid-хранилищ
In-Memory Data Grid (IMDG) или просто Grid – хранит в оперативной памяти непосредственно java объекты, в потокобезопасной Map (HashTable или ConcurrentMap). Такой способ хранения освобождает от необходимости использовать ORM.
Функции Grid-сервера:
Управляет кластерами хранилищ, позволяя их реплицировать, партиционировать (разделять данные по хранилищам в кластере) и сохранять данные на диск.
Является точкой входа как для прямых запросов к Map, так и с помощью языка объектных запросов OQL (Object Query Language).
Обеспечивает распределенные вычисления на основе хранящихся данных. Аналогично хранимым процедурам, PL-SQL и Transact-SQL в реляционных БД.
28. Spring Data for Apache Geode
Поддержка Apache Geode – полнофункциональной In-Memory Data Grid.
29. Spring Data for VMware Tanzu GemFire
Поддержка GemFire – коммерческой версии Apache Geode.
Интеграция с BigData
30. Spring for Apache Hadoop (устарел)
Компонент для интеграции с Apache Hadoop – распределенной файловой системой, с поддержкой распределенных вычислений. Поддержка компонента скоро будет прекращена.
Уровень сетевого обмена данными
Компоненты для обмена по сети данными с другими функциональными модулями:
браузерами,
фронтэнд и мобильными приложениями,
собственными приложениями компании-разработчика, в том числе микросервисами,
коробочными системами, поддерживающими интеграцию,
коммерческими облачными сервисами.
31. Spring Framework – Web MVC (Web Servlet)
Включает компоненты:
31.1. Контроллер HTML – используется в связке с шаблонизаторами для формирования пользовательских web-интерфейсов.
Шаблонизатор – компонент, загружающий данные из Java в HTML-шаблоны страниц пользовательского интерфейса. В документации заявлена поддержка около 15 технологий визуализации, в том числе, реализующие JSR-223.
В Spring, шаблонизатор по умолчанию – Thymeleaf, но поддерживается и React. Учитывая, количество «воды» в документации по Thymeleaf, возникает мысль, не проще ли освоить синтаксис JavaScript и писать сразу на React (пример). В Java 8 движок JavaScript Nashorn, уже встроен. В следующих версиях Java, – Nashorn можно подключить.
31.2. REST контроллер – используется для приема HTTP запросов и отправки ответов.
Основные сценарии использования: обработки запросов фронтенда – приложений SPA (Single Page Application) на JavaScript, мобильных приложений и сайтов на других технологиях. Для не-enterprise систем, может реализовывать связь между микросервисами. Этот подход является базовым для Spring Cloud компонентов на основе Netflix.
31.3. Клиент REST (restTemplate) – используется для отправки HTTP запросов и приема ответов.
Основные сценарии использования: скачивание данных с сайтов и тестирования REST сервисов. Примечание: в документации «Spring Framework – Web MVC», клиент REST только заявлен, но реализован и описан в модуле «Spring Framework – Integration».
31.4. WebSockets – протокол для двухстороннего канала связи на уровне TCP.
Отказ от HTTP снижает накладные расходы, повышая пропускную способность сети. Но его применение обычно ограничено корпоративной сетью, так как требует определенных настроек сетевых устройств на всем пути передачи данных.
31.5. Поддержка устаревших фреймворков: JSF, Struts, Tapestry.
32. Spring Framework – WebFlux (Web Reactive)
Реактивный аналог модуля «Spring Framework – Web MVC».
Включает компоненты:
32.1. Контроллер HTML – реактивный,
32.2. REST контроллер – реактивный,
32.3. REST клиент (WebClient) – реактивный,
32.4. WebSockets,
32.5. RSocket – реактивный аналог WebSockets.
33. Spring Framework – Integration
Включает компоненты:
33.1. Клиент REST (restTemplate) – в документации «Spring Framework – Web MVC» клиент REST только упомянут, но реализован и описан этом модуле (глава REST Endpoints).
33.2. Web Services – базовая поддержка устаревающих, но еще использующихся протоколов обмена данными на основе семейства XML (SOAP, XML-RPC). Активно вытесняется очередями сообщений (MQ – Message Queue).
33.3. EJB – интеграция с Enterprise JavaBeans. Старая, редко используемая технология.
33.4. JMS (Java Message Service) – поддержка брокеров сообщений, использующих протокол JMS для обмена данными через очереди сообщений (MQ). Ограничен поддержкой только java сервисов. Spring рекомендует для протокола JMS использовать брокеры ActiveMQ (classic) или ActiveMQ Artemis. С ними реализована наиболее плотная интеграция – конфигурирование через property файлы для реализации третьего принципа 12-факторных приложений.
33.5. JMX (Java Management Extensions) – протокол управления приложением. Позволяет на работающем приложении вызывать непосредственно методы классов для передачи в них данных (управление) или считывания информации (мониторинг состояния). Spring для его замены рекомендует использовать Spring Boot Actuator.
33.6. Email – компонент для отправки e-mail из Spring.
33.7. Task Execution and Scheduling – поддержка планирования и асинхронного запуска задач через Quartz Scheduler.
33.8. Cache Abstraction – кэш для java методов. Сохраняет в памяти пары значений «параметры вызова java метода и результат выполнения», перехватывает последующие запросы и ищет в памяти «готовый ответ», без выполнения метода. Для хранения пар запрос-ответ поддерживает: ConcurrentMap, Ehcache 2.x, Gemfire, Caffeine и реализации, совместимые с JSR-107 (например, Ehcache 3.x).
34. Spring Web Flow
Организует «поток пользовательских интерфейсов» в виде последовательности шагов. Расширение для контроллеров HTML и шаблонизаторов в модулях Web MVC и WebFlux.
35. Spring HATEOAS
Расширение для Web MVC и WebFlux для поддержки формата сообщений HATEOAS в REST контроллерах. На просторах Хабра не удалось найти людей, умеющих извлекать пользу из этой технологии. Формально она помогает реализовать GRASP паттерн «Low Coupling», за счет усложнения формирования запросов.
36. Spring for GraphQL
Расширение для Web MVC и WebFlux для поддержки формата сообщений GraphQL в контроллерах, WebSocket и RSocket.
GraphQL – язык запросов для API, конкурирующий в REST. Позволяет одним запросом получить ограниченный набор полей из разных объектов предметной области. Это снижает нагрузку на сеть и сервер – уменьшает количество запросов и объем передаваемых данных. Недостатки GraphQL – не поддерживает кэширование и загрузку файлов.
В приложении могут одновременно использоваться и REST, и GraphQL контроллеры. На мой взгляд, большую часть преимуществ GraphQL можно получить, используя только REST в паре с DTO (Data Transfer Object). А безальтернативен GraphQL в тех случаях, которые требуют использования динамических запросов к БД, например через Hibernate Criteria.
37. Spring Web Services
Расширенная поддержка SOAP.
Примечание: базовая поддержка реализована в компоненте «Spring Framework – Integration».
38. Spring REST Docs
Автоматической генерирует документацию Open API (Swagger) для REST API.
MQ (Message Queue)
Очереди сообщений (MQ) – современный способ надежной интеграции функциональных подсистем и обмена данными между микросервисами. От Web Services (SOAP) он отличается снижением трудозатрат на разработку интеграционных взаимодействий, а от REST – надежностью, отвечающей требованиям enterprise приложений.
MQ поддерживают работу в рамках глобальных транзакций, одновременно включающих и JPA запросы к БД. Если в серии MQ и JPA запросов, при взаимодействии микросервисов, произойдет сбой, состояние откатится транзакционными механизмами.
К классу MQ относятся протоколы:
JMS – реализован в «Spring Framework – Integration», поддерживает обмен только между java приложениями.
AMQP – поддерживает приложения, написанные на разных языках.
Kafka (свой уникальный протокол) – поддерживает приложения, написанные на разных языках, отличается высокой производительностью и масштабируемостью.
39. Spring AMQP
AMQP (Advanced Message Queuing Protocol – расширенный MQ протокол). Отличается от JMS поддержкой приложений, написанных на разных языках.
Для протокола AMQP, Spring рекомендует использовать брокер RabbitMQ, с которым реализована наиболее плотная интеграция – конфигурирование через property файлы для реализации третьего принципа 12-факторных приложений.
По отзывам, от Kafka отличается меньшими требованиями к администрированию – при умеренных нагрузках «просто работает, не требуя внимания».
40. Spring for Apache Kafka
Apache Kafka – самый популярный брокер сообщений. Поддерживает приложения, написанные на разных языках. Отличается рекордной производительностью и масштабируемостью.
Фреймворк корпоративной интеграции
41. Spring Integration
Предназначен для связи систем, использующих разные протоколы интеграции, и промежуточного преобразования данных.
Включает библиотеки для:
обработки данных в XML,
организации транзакций,
авторизации доступа,
обработки ошибок,
тестирования,
коллекцию из 30 интеграционных модулей, содержащих 92 адаптера.
Код приложения взаимодействует с адаптерами через абстракцию Message. Роль адаптеров - преобразование Message в сообщение требуемого протокола и обратно.
Поддерживаемые протоколы и типы данных:
|
Web Data |
Messaging Прочее |
По отзывам, борьбу за популярность, этот фреймворк проиграл конкуренту - Apache Camel. В то же время, он стал основой для микро-фреймворка Spring Cloud Stream.
Заключение
В первой части обзора были представлены компоненты Spring Boot и фреймворка корпоративной интеграции. Во второй части будут описаны компоненты Spring Cloud.
Наверняка среди читателей будут те, кто глубоко знает тот или иной компонент. Поправки и уточнения приветствуются.
Владимир Мальзам.
Должности нет, в поиске (java-разработчик, монолит/микросервисы).