Kotlin/Java Developer
Java продолжает наносить ответные удары. В Java 21 релизнулись виртуальные потоки. Теперь есть надежда, что в ближайших версиях двинется к релизу старый и очень ожидаемый JEP-401 aka Project Valhalla. Эта короткая статья описывает проблему, которую решает JEP, и содержит бенчмарк на основе превью фичи из Java 22.
CRaC (Coordinated Restore at Checkpoint) — это проект OpenJDK, разработанный Azul для решения проблемы «медленного» запуска виртуальной машины Java в микросервисной среде.
Когда JVM запускает код вашего приложения, она выполняет такие действия, как интерпретация, компиляция и оптимизация кода, чтобы ваше приложение работало как можно быстрее при заданной рабочей нагрузке. Это здорово, но может занять некоторое время, и особенно при запуске короткоживущих микросервисов, вы не хотите ждать, пока JVM создаст наиболее оптимизированный код.
В механизме восстановления контрольной точки (checkpoint-restore) нет ничего нового, и большинство из вас уже знают и используют его ежедневно.
Если вы работаете на ноутбуке и закрываете крышку, операционная система обнаруживает это и сохраняет текущее состояние на диск. Как только вы снова открываете крышку, операционная система восстанавливает сохраненное состояние с диска.
CRaC предоставляет тот же механизм, но для JVM и вашего запущенного приложения.
Вы запускаете свое приложение, применяете к нему некоторую рабочую нагрузку (чтобы убедиться, что важные части вашего кода будут затронуты и оптимизированы JVM), а затем создаете контрольную точку. Это приведет к закрытию всех открытых ресурсов, таких как открытые файлы и сокетные соединения, а затем сохранит состояние JVM, включая ваше приложение, на диск.
После этого вы сможете восстанавливать состояние JVM, включая состояние вашего приложения, из этой сохраненной контрольной точки так часто, как вам захочется.
Таким образом, CRaC не только решает проблему времени запуска, но и может решить проблему времени разогрева приложения, поскольку вы можете создавать контрольную точку в любое время.
Повтор (retry) операции является старейшим механизмом обеспечения надежности программного обеспечения. Мы используем повторы при выполнении HTTP запросов, запросов к базам данных, отсылке электронной почты и проч. и проч.
Данная статья результат поиска некоего каноничного решения организации безопасности доступа к ресурсам в микросервисной архитектуре, построенной в экосистеме Spring. После прочтения десятка статей по данной тематике, к сожалению, не нашел то, что искал. Spring Security оказался одной из самых недопонятых технологий. Основная проблема у всех - изобретение своего велосипеда поверх стандартного функционала Spring Security. Зачастую, данные статьи сопровождаются комментариями никогда так не делать. И у многих, наверно, возникает вопрос, а как собственно можно делать. Ситуацию несколько прояснила официальная документация. Взяв её за основу, я хочу показать, как можно организовать безопасность микросервисов максимально простым и быстрым способом.
После прочтения заголовка у среднестатистического читателя наверняка возникнет весьма логичный вопрос: «Кто такая эта ваша рефлексия и зачем её ускорять?»
И если первая часть будет волновать только совсем уж откровенных неофитов (ответ тут), то вторая точно нуждается в пояснении.
К текущему моменту рефлексия (и особенно рефлективные вызовы методов) так или иначе используется в прорве самых разных фреймворков, библиотек и просто любых приложениях, по какой-либо причине требующих динамические возможности.
Однако в java рефлексия реализована не самым быстрым (зато надёжным) методом, а именно, через использование JNI-вызовов. JNI (Java Native Interface) – очень полезная штука, позволяющая машине вызывать код из «внешнего мира», библиотек, написанных на C/C++ или ассемблере.
К сожалению, нельзя просто так взять и вызвать потенциально опасный бинарь, во-первых, потенциально несовместимый с внутренним миром машины, а во-вторых, способный без угрызений совести положить всё намертво лёгким взмахом segfault’а. Поэтому непосредственно моменту прямого вызова предшествует тонна инструкций, подготовляющих обе стороны к взаимодействию. Очевидно, не самый быстрый процесс.
Тем не менее, рефлексия работает именно так: машина «выходит наружу», копается в своих внутренностях и «возвращается обратно», доставляя пользователю полученную информацию или вызывая методы/конструкторы.
А теперь представьте примерное быстродействие какого-нибудь фреймворка, который в процессе работы постоянно осуществляет рефлективные вызовы…
Как компилятор Kotlin преобразует suspend код? Что получается в итоге? Разбираемся в машине состояний suspend кода.
Всем привет! Меня зовут Николай Первухин, я Senior Java Developer в Райффайзенбанке. В последнее время я активно занимаюсь BPM-системами Camunda и Zeebe (основа Camunda-cloud). Если вы, как и я, с ходу не можете ответить на вопрос, кто быстрее — Camunda или Zeebe, насколько, и в каких случаях они могут тормозить, то добро пожаловать под кат.
Сразу оговорюсь, что статья объясняет базовые понятия, и если вы уже программируете на Kotlin, то, скорее всего, вы уже все знаете. Большая часть того, что приведено в статье, освещено в официальной документации, поэтому статью можно рассматривать как дополнительный материал к ней.
В статье показано как реализованы функции области видимости, даны примеры и рекомендации по их использованию
Рано или поздно в нагруженном проекте возникает потребность в какой-то специализированной базе данных, кэше или ином хранилище. Причина такой потребности, как правило, погоня за производительностью, низким временем отклика или эффективностью хранения данных.
В своем докладе я расскажу о нашем опыте разработки и эксплуатации специализированной timeseries БД, в основе которой лежит Apache Kafka.
Глубокое погружение в мир аннотации Spring Boot @Conditional с проработанными примерами реализаций классов доступа к БД Mongo и MySQL.
В моем посте «Почему Spring Boot?» было рассмотрено создание Spring Boot приложения, из которого вы едва ли сможете понять, что происходит за кулисами. Возможно, вы хотите понять магию автоконфигурации Spring Boot.
Перед этим вы должны узнать о Spring аннотации @Conditional, от которой зависит вся магия автоконфигурации Spring Boot.
Привет, Хабр.
В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет "обвешивать" всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.
Изначально я разбил создание проекта на несколько шагов:
Создать два сервиса — 'бекенд' (backend) и 'шлюз' (gateway), упаковать их в docker-образы и настроить их совместную работу
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Создание чарта с помощью Helm 3 для более эффективного управления кластером
Ключевые слова: Helm 3, chart deployment
Настройка Jenkins и пайплайна для автоматической доставки кода в кластер
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Каждому шагу я планирую посвятить отдельную статью.
Направленность этого цикла статей заключается не в том, как написать микросервисы, а как заставить их работать в единой системе.
Привет, Хабр! Представляю вашему вниманию перевод статьи "Java Cryptography" автора Jakob Jenkov.
Данная публикация является переводом первой статьи Java Cryptography из серии статей для начинающих, желающих освоить основы криптографии в Java.
Доброго времени суток, Хабр.
Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.
Это перевод только первой статьи, если он зайдет аудитории, я продолжу выпуск переводов.
