Отчет о мировом турне SpringOne в Тель-Авиве

29 ноября 2022 г.

Мой доклад был принят SpringOne в Сан-Франциско. Я никогда не был на этой конференции и очень ждал ее. Этот год, вероятно, будет удивительным благодаря выпускам Spring 6.0 и Spring Boot 3.0. Столько революционных изменений. К сожалению, мой бюджет на поездку в Lightrun был урезан, и в конце концов я уехал. Это означало, что мне пришлось отменить поездку, я бы заплатил за проезд, но Сан-Франциско далеко и непомерно дорого. Мне нужно взять дождевик.

Это не совсем замена, но скелет Spring Team находится в «мировом турне», которое на прошлой неделе достигло Тель-Авива, и я присутствовал. Это место, где я никогда не был, Центр инноваций Переса. Это на пляже Яффо, и вы можете буквально видеть, как волны бьются о пляж с главной сцены. Посмотрите на фотографии ниже, на некоторых из них вы буквально видите людей на пляже. Это фантастическое место. Единственным недостатком является удаленность от центра Тель-Авива, где я живу. Но это ничто по сравнению с расстояниями в штатах…

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

Прежде чем мы продолжим, я хочу сказать пару слов о Twitter. За последний месяц я перешел на Mastodon, и это очень здорово. Есть даже Java Bubble, в котором перечислены видные члены сообщества Mastodon. Foojay добавил собственный экземпляр, и интерес к нему высок.

Я не вижу причин оставаться в Твиттере. Он токсичен и становится все более опасным с каждой секундой. У меня все еще есть учетная запись и мост, который отправляет твиты моих постов Mastodon. Так что если вы последуете за мной там, вы ничего не пропустите. Но я не буду туда заходить так часто и постараюсь не писать там. Все ссылки в этом посте и будущих постах будут относиться к другим сетям, будь то LinkedIn или Mastodon.

Юрген Хеллер — Представляем Spring Framework 6

Spring Framework 6 — это перестройка фреймворка. Юрген тщательно отбирал свои работы, уделяя особое внимание консервативному характеру версий Spring и совместимости с предыдущими версиями. Spring Framework 5.3.x во многом основан на JDK 8. Он связан с Java EE и старым пространством имен javax. Он поддерживается с открытым исходным кодом до 2024 года, а это значит, что нам необходимо составить планы миграции...

В Spring Framework 6.x изменилось несколько вещей:

• JDK 17+
• Jakarta EE вместо пространства имен Java EE и javax
• Поддержка AOT
• Виртуальные потоки (ткацкий станок)

Это будет основой для Spring Boot 3.x. Самой большой проблемой, которую я предвижу, является требование JDK 17. Это может вызвать некоторые миграции. По мере выполнения этих миграций мы, вероятно, будем контейнеризировать больше. В идеале это значительно облегчит будущие миграции. Однако у JDK 17 есть несколько фантастических функций. Юрген много внимания уделял функциям языка, но есть несколько замечательных улучшений сборщика мусора для контейнеров, которые делают обновление целесообразным на предприятии.

Переход на Jakarta API – неизбежное зло, поскольку пакеты для старых API больше не обновляются. Это будет проблемой миграции, но это неизбежно. Это потребует от всех, кто зависит от этих API, переместить этот код. Вся экосистема Java перешла на быстрые циклы выпуска, и обновления таких фреймворков, как Tomcat, происходят гораздо быстрее. Юрген рекомендует пропустить Jakarta EE 9 и перейти сразу к 10.

Spring Framework 6.1 по-прежнему будет поддерживать JDK 17, но также будет добавлена ​​поддержка JDK 21, которая должна быть доступна к тому времени. Предпочтительной платформой для этой версии будет Jakarta EE 10.

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

Статические изображения OpenJDK (проект Leyden). Стратегия Spring AOT согласуется со стратегией Leyden JVM. Начиная с прогретого образа JVM (CRaC), также многообещающий вариант для быстрой загрузки приложения Spring. Первоклассная поддержка CRaC ожидается в Spring Framework 6.1.

Project Loom — это предварительная функция в JDK 19, обеспечивающая высокую пропускную способность для потоков Java. Они ожидают значительных преимуществ масштабируемости для веб-приложений, управляемых базами данных. Он также идеально подходит для приложений для обмена сообщениями и планирования. Это означает, что WebFlux и реактивный стиль больше не предназначены в первую очередь для масштабируемости, поскольку Loom предоставляет их «бесплатно».

Другие функции включают быстрое определение свойств компонента. Полный форк CGLIB с поддержкой захвата сгенерированных классов. Сканирование classpath на основе NIO. Первоклассное сканирование модулей и дальнейшая поддержка модульной системы (возможно) в 6.1. Клиенты интерфейса HTTP на основе сервиса @HttpExchange. Интеграция JDK HttpClient с WebClient, но мне больше всего интересна наблюдаемость на основе микрометров для RestTemplate и WebClient.

В перерыве я успел поговорить с Олегом Шелаевым и Юргеном. Сначала речь шла о будущем CRaC. Юрген был очень оптимистичен в отношении ее шансов в качестве будущей возможности JVM и возможности интеграции ее в разумный рабочий процесс. Я спросил его о восприятии GraalVM, и на данный момент интерес к новым версиям сосредоточен на других функциях. Есть волнение по поводу GraalVM, но это не убийственная функция. Пока что. У меня есть некоторые мысли по этому поводу, которыми я поделюсь в конце поста.

ДаШон Картер — Представляем Spring Boot 3.0

DaShaun продемонстрировал живую демонстрацию сборки с помощью GraalVM и сравнил время запуска меньше секунды, обеспечиваемое собственным образом в GraalVM. Затем он показал, что объем оперативной памяти составляет треть полноразмерного образа JVM. Другая часть демонстрации показала, что привод работает, как и ожидалось, что хорошо, поскольку собственный образ GraalVM не поддерживает API-интерфейсы агента в текущей версии.

Аудитория попросила показать размер изображения, который был вдвое меньше исходного изображения. Демонстрация была хороша, но в прошлом я использовал GraalVM на Spring Boot, так что это не было для меня чем-то новым. Я спросил о восприятии и популярности собственного образа GraalVM. Многие разработчики ждали перехода Spring Boot на GraalVM, и мне любопытно, видят ли они это уже в статистике Spring Initializer. Я хотел знать, наблюдают ли ребята из Spring поток интереса. ДаШон сказал, что он бы не поехал, если бы не GraalVM. Но он пригласил меня поговорить позже. В итоге я поговорил с Юргеном и получил ответ, который «хотел».

После этого он указал на https://calendar.spring.io/, о котором я не знал (или забыл) . Масштабы релизов за ноябрь поражают.

Cora Iberkleid — защитите свои микросервисы с помощью Spring Cloud Gateway

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

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

Cora показала конфигурацию маршрутизации в YAML и взвешенную маршрутизацию к веб-службе. Затем она перешла к разрыву цепи с помощью ограничителя запросов. Ограничитель частоты запросов основан на Redis и может ограничивать количество запросов, отправляемых в API, с частотой пополнения и пропускной способностью, чтобы блокировать чрезмерное использование API. Это очень полезно для ограничения злоупотреблений и ограничения пробных пользователей.

До сих пор все делалось с использованием чистых конфигураций YAML. Демонстрация завершилась настраиваемым фильтром маршрутов, который динамически изменяет запросы.

Доктор. Дэвид Сайер — Запуск ненадежного кода в Spring с помощью WebAssembly

Есть много случаев, когда мы можем захотеть запустить ненадежный код. Есть много способов сделать это, и, как Dr. Сайер говорит, что WebAssembly — один из лучших способов сделать это. Хотя браузеры поддерживают размещение WebAssembly, речь пойдет о размещении на стороне сервера.

WebAssembly — многоязычная среда, что делает ее очень привлекательной в некоторых случаях. Вы можете поэкспериментировать с WASM прямо на игровой площадке Mozilla в MDN. В своем выступлении он рассказал о различных компиляторах, которые можно использовать для создания WASM из компиляторов C в AssemblyScript и т. д. См. https://github.com. /dsyer/hello-as

Он предоставил интересную ссылку на проект по размещению WASM в Java:https://github.com/kawamuray/wasmtime-java. .

Обмен данными с WASM кажется болезненным и чем-то вроде возврата к передаче и копированию данных туда и обратно. Он предоставил две интересные ссылки: https://github.com/dsyer/spring-wasm-demo https://github. com/dsyer/async-wasm

После разговора у меня было время немного поговорить с доктором Сайером, который был очень мил. Моя фундаментальная проблема заключается в том, что я так и не «получил» WASM. Чем это лучше, чем запуск Java в песочнице? Он упомянул два варианта использования: запуск ненадежного кода во встроенных и периферийных вычислениях. Как парня, который работал в подразделении мобильных и встраиваемых систем в Sun/Oracle, это немного жалит. Я понимаю, почему это то место, где мы находимся «в», но у нас были JVM, работающие в очень ограниченных средах с MVM и возможностями Java. Он по-прежнему актуален, просто никогда не получал такой популярности, как WASM.

Другим аспектом является поддержка Polyglot. Возможность сделать это для кода C или Rust. Но это не так интересно для меня и для большинства случаев использования, которые я могу придумать. Очевидно, что у нас есть хорошие возможности Polyglot для JVM, но в основном для языков GC более высокого уровня и не так много для таких языков, как Rust или C. С другой стороны, у нас есть много других возможностей, таких как GC, глубокая нативная интеграция, сложная модель памяти, и т. д.

Я обсуждал это со многими умными людьми, которые видят большой потенциал в WASM на сервере. Обратите внимание, что речь идет не о браузере, в котором WASM имеет допустимый вариант использования. Это может быть успешным просто из-за обмена мнениями, но в нынешнем виде кажется, что WASM на пару десятилетий отстает от того, что есть в мире JVM.

Наконец-то

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

Мне нужно больше таких вещей. Кажется, я знаю больше людей, когда летаю за границу на конференцию, чем когда посещаю конференцию в моей стране. Как я уже говорил. У меня есть некоторые мысли о том, почему GraalVM не берет на себя все в одночасье. Есть несколько важных причин.

Это работа

Переход на GraalVM требует от разработчиков большой работы. Меньше, чем время идет. Но еще многое нужно изменить. Отладка сложнее. Нам нужно генерировать сборки в CI, и мы не можем запускать их локально на некоторых машинах. Это боль.

Добавление медленного процесса сборки делает этот процесс еще более болезненным.

Сомнительная выгода

Как разработчики, мы устанавливаем требования к памяти и хранилищу. У DevOps есть стимулы для снижения затрат, которые могут извлечь выгоду из GraalVM, но они не могут просто интегрировать ее. Им нужны разработчики для работы. В корпоративной среде облачные отходы уже астрономические. Отправка разработчика для миграции на новую виртуальную машину, чтобы команда DevOps могла получить «кредит для экономии затрат». Это не то, за чем может стоять руководство отдела исследований и разработок.

Поощрения в корпоративной среде проблематичны. Возможно, команда Spring сможет организовать вирусный маркетинг, помогая Twitter сократить расходы на облачные вычисления. Я уверен, что некоторые из их микросервисов основаны на Spring.

Наблюдаемость

Хотя Spring Boot включает в себя некоторые инструменты мониторинга даже с GraalVM. Уровень наблюдаемости на GraalVM на данный момент ниже (нет функций агента). Само по себе это могло быть нормально, но в сочетании со всем остальным это могло стать проблемой.

Мы не используем бессерверные технологии

Разработчики Java не очень хорошо разбираются в бессерверных технологиях. Там GraalVM имеет смысл и уже делает большие успехи. Но бессерверные технологии не так распространены в нашем сообществе (и это правильно), поэтому ценность GraalVM не так очевидна.

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

:::информация Первоначально опубликовано здесь.

:::

---

Оригинал