SpringOne 2018 и Реактивность всюду

Один-ноль-один Ютуб! Ой, это не то шоу. Ну, давайте тогда просто поговорим за прошедную конференцию SpringOne 2018, и доклады с неё, которые уже, кстати, выложили — https://www.youtube.com/user/SpringSourceDev/videos.

На мой взгляд, на этом СпрингВане было несколько больших тем, по которым можно разбить доклады. Это реактивность. Это новые фишечки и рюшечки Спринга, которые помогут вам стать более продуктивным. Это Котлин. И это Спринг в разрезе облаков (как с этим жить, что стоимт использовать и т.д.). Сейчас предлагаю остановится только на Реактивности, которая, наверное, действительно затронет каждого из нас.

Реактивность в Спринге завезли уже, как год, вместе с приходом Spring 5. Там появился большой модуль — WebFlux, который вкупе с Project Reactor позволяет писать реактивный код, используя внутри себя какой-нибудь Netty вместо старого Apache Tomcat. Однако год назад было довольно много проблем, которые постепенно решились. И на этой кофнеренции как раз таки подводились промежуточные итоги всего этого дела.

Главная мысль, которую вынес я — не нужно писать реактивный код безусловно, не думая своей головой, нужно тут это или нет. Если вы разрабатываете систему на основе хранимых процедур Oracle, а ещё вам нужно сделать десяток запросов в синхронные API банков-партнёров, то, наверное, реактивность — это не то, что вам нужно. А вот если ваша система — это высоконагруженный продукт, у вас есть Хранилище, которое поддерживает реактивность (Redis, MongoDb, Apache Cassandra, а теперь и PostgreSQL), а ещё у вас куча гетерогенных клиентов, которые желают постоянно получать новые данные, то да, реактивная система — это то, куда стоит смотреть.

Давайте коротененько пройдём по докладам, которые, на мой взгляд, наиболее близки к теме Реактивности. Но сначала приведу ссылку на статью, похожую этому посту, от Josh Long — The Reactive Revolution at SpringOne Platform 2018 (part 1/N).

R2DBC — Библиотека для реактивных реляционных БД (сейчас только PostgreSQL)

R2DBC — это эксперимент от компании Pivotal. Это не Production ready! Цель эксперимента — посмотреть, какое можно было бы спроектировать API для взаимодействия с базой данных, если бы не было старого легаси JDBC. Идеальный финал эксперимента — в Java появляется условно JDBC 2.0, который бы имел нативный реактивный API. Но если сообщество будет против внедрения такогов в Java, то R2DBC будет развиваться паралелльно, предоставляя миру правильный API.

Вот то видео, где рассказывали про эту либу:

RSocket — Протокол для реактивного взаимодействия различных систем

RSocket — это, в некотором роде, конкурент gRPC. RSocket — это бинарный протокол 7-ого уровня, который может использовать разные транспортные протоколы внутри себя (TCP, WebSocket, Aeron, или HTTP/2). Протокол полнстью Language agnostic. Уже сейчас есть реализации под Java, C++ и даже под JavaScript (Причём, это не только серверная Node.JS; RSocket можно благополучно использовать и на клиенте, благодаря WebScoket — это главное отличие от gRPC).

RSocket предоставляет сразу 4 модели работы:

  • Классическая вебная модель — Request-Response. Вы послали запрос, вам послали ответ.
  • Fire-and-forget — вы послали запрос, и вам пофиг, получил ли его сервер. Отлично подходит для сбора какой-нибудь статистики с клиентов, где можно терять часть данных.
  • Запрос — стрим ответов — ну, тут вроде всё понятно. Вы шлёте запрос, и получаете 0, 1, или множество ответов.
  • Канал — клиент и сервер устанавливают между собой канал, куда каждая сторона может произвольно лить разные данные.

Почему RSocket — это круто? Во-первых, он бинарный, а поэтому тут всё происходит быстрее, чем в текстовых протоколах. Во-вторых, RSocket нет дела, какие вы передаёте через него данные. Это может быть, как Json, так и условный Protobuf.

Мультеплексируемость — это ещё одна очень важная особенность RSocket. Протокол не будет создавать множество соединений, для того чтобы пропустить через систему некоторый набор данных. Условвно говоря, будет одна TCP-сессия, в рамках которой будут передаваться несколько пакетов. У каждого из пакетов будет свой идентификатор (streamId), что позволит значительно сэкономить в ресурсах.

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

Главное видео, которое было по RSocket —

А если вам не охото хардкора и кишков, то на Кейноуте тоже было про RSocket —

Netifi proteus — абстракция поверх RSocket

Netifi proteus — это самая неоднозначная для меня вещь из всего этого. Это, условно говоря, сахар + платформа поверх RSocket. То есть, компания Netifi взяла спринг, взяла RSocket, написала мониторинг, Дашборд, ещё какой-то инфраструктурный код и назвала всё это дело продуктом (Netifi Proteus is a cloud-native application platform). Есть, как бесплатная версия, так и платная. Но я пока не могу рекомендовать ставить на это свой бизнесс — кажется пока платформа сырая.

Докладчики сделали небольшой доклад про эту платформу, в рамках которого рассказывали про свою Демку. Её можно скачать и посмотреть тут — https://github.com/netifi/springone-demo. А вот и само видео:

В общем, на мой взгляд получилась крайне крутая конференция. Интересно, что ребята из Спринг Ван не боятся выкладывать доклады спустя 5 дней после конференции. Ещё бы парни с Jug.RU так начали делать…

Год назад я не очень-то верил в реаткивность. Больно уж код становится сложным, да и не было понятно, что делать с блокирующими внешними синхронными API, а также, что более важно с — реляционными Базами данных. За год с БД проблема начала решаться. Ну, а внешние синхронные API можно завернуть в отдельные независимые пулы потоков.

Категории: Программирование