Необходимость писать многопоточный код появилась не от хорошей жизни. Мы вынуждены это делать, потому что в свое время человечество столкнулось с серьезными технологическими ограничениями, в связи с чем тактовая частота процессоров перестала расти. Почему? Выше частота — выше тепловыделение, а эффективно охладить CPU с их TDP — непростая задача.

На заре 21 века для решения этой проблемы появились многоядерные процессоры: будем не частоту увеличивать, а число ядер. Однако ядра не берутся из ниоткуда, их нужно было встраивать рядом с уже имеющимся ядром. Как этого достичь? Можно увеличивать число транзисторов на единицу площади (уменьшение техпроцесса), пытаясь обуздать физику p-n перехода и свойства полупроводников. Можно увеличивать размер кристалла, что связано с увеличением брака, или количество самих кристаллов (чиплетная архитектура).

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

Если мы говорим о написании бизнес-кода, то зачастую управление потоками любезно скрыто от нас под капотом удобного API фреймворка или библиотеки. За это хочется сказать отдельное спасибо их мейнтейнерам: при перекладывании json'а 🐵 нам почти не приходится задумываться о том, что мы работаем в многопоточной среде. Почему "почти"? К сожалению, при совместном доступе к разделяемым данным проблемы вроде race condition или data race все еще могут возникнуть. Если ваш бизнес-код взаимодействует с внешними ресурсами (БД, кэшем, файлами и т.д.), то ошибки проектирования могут проявиться даже при использовании высокоуровневых абстракций. И все же написание многопоточного кода стало довольно нишевой штукой, которая чаще всего встречается при разработке самих фреймворков и библиотек.

Разработчики начали понимать, что без базовых знаний, как работать в многопоточной среде не обойтись, хотя на собеседованиях многие все равно недоумевают от вопросов по этой теме. Но жизнь идет и настаёт время новых вызовов. Сейчас в России их два:
1️⃣ крупные компании испытывают проблемы с получением современного железа в желаемом объеме (значительно выросли цены и усложнились логистические цепочки)
2️⃣ рост трафика на внутренние сервисы (ведь доступ к зарубежным ограничен)

В этих условиях от разработчика требуется не только чтобы приложение работало быстро. Оно должно эффективно утилизировать имеющиеся ресурсы. Если говорить о CPU-intensive приложениях, то тут в первую очередь нужно будет работать над реализацией эффективных алгоритмов. Если же говорить о сервисах с большим числом интеграций, то один из способов увеличения пропускной способности — избегать любых блокировок потоков (VPN тут не поможет 😃). Блокирующие операции, такие как ожидание завершения другого потока, ответа от базы данных или очередного микросервиса, приводят к простоям приложения. Избежать этого помогают асинхронные неблокирующие подходы. Делаю предположение, что количество проектов, реализующих такую концепцию, в энтерпрайзе будет только расти.

Как с этим обстоят дела в полях? Мне довелось общаться с Java-разработчиками из разных компаний, и я часто слышал, что Reactor/WebFlux у них не прижился из-за сложности разработки и поддержки написанных на нем приложений. Понятно, почему все так полюбили Go — там асинхронный неблокирующий код относительно легко готовить. В Kotlin асинхронные цепочки спрятаны за корутинами, если вы используете библиотеку kotlinx-coroutines-reactor, что достаточно сильно упрощает бизнесовый, но не библиотечный код.

В новому году посмотрим, сбудется ли мой прогноз. По крайней мере рост числа проектов на Go уже заметен. Посмотрим, что будет с таковыми на Java и Kotlin 😎.

Кажется, на новый год мне пожелали мало здоровья — проболел все праздники 😁 ОРВИ, будь она неладна...

В мои планы на эти длинные каникулы входило разобраться наконец c Istio (Service Mesh в k8s), так как изученного в прошлом году ванильного кубера для решения рабочих задач решительно не хватает. Но, как вы понимаете, этим планам не суждено было сбыться. Вооружившись таблетками и спреями, я лежал на диване у купленного почти три месяца назад, но почти не использовавшегося, 65-дюймового ТВ.

В обычное время я сериалами не увлекаюсь, как-то не до них, но раз выдалось подходящее время, то почему бы не глянуть пару-тройку? Настроение было смотреть сериалы про времена СССР. Интересное настроение, не правда ли 😅?

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

Комитет — про хороший СССР. Бодрый и бойкий сериал о работе и жизни трех друзей КГБшников от НТВ кто бы сомневался😃. Сюжет тянется через года: начали в 1970-ые, а закончили — в нулевые. Менялись политический строй, общество, люди. На этом фоне было увлекательно наблюдать, как друзья проживали такие похожие, но в то же время такие разные судьбы.

Игры — реалистично? про СССР. Сериал про Олимпиаду 80 и события, которые ей сопутствовали. Намешали целый ворох клеше, но странным образом это сработало. Мне было увлекательно и интересно. Я этой истории поверил.

Красная королева — про плохой СССР. Сериал про советскую модель с непростой судьбой от Первого канала. Спойлер: от серии к серии жизнь главной героини становится все невыносимее, причем воспринимается все очень органично. Эту историю было морально тяжело смотреть. Без КГБшников тут не обошлось. Увы, хэппи энда не случилось. Кажется ,что такое лучше не показывать на федеральном канале. Правда, жена сказала, что она с бабушкой по ТВ в детстве только такие сериалы и смотрела .

Чтобы разбавить это историческое трио, я обратился к дуэту про Папу Римского. Тем более хотелось посмотреть что-то более жизнеутверждающее. Молодой Папа и Новый Папа — хорошо показывают, что такое церковь и какой она должна? быть. Мне оказался по душе этот микс сарказма, эпатажа и философских размышлений. Джуд Лоу в роли Пия XIII стал украшением этой работы. Даже захотелось взять себе на вооружение несколько цитат на будущее.

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

Кажется, что после предновогоднего поста можно было бы списать Java со счетов: уж больно сложно на нем писать асинхронный неблокирующий код. Встроенный CompletableFeature имеет существенные архитектурные ограничения в виде невозможности отмены асинхронной таски, а Reactor/WebFlux сложны, да и реактивность не всем нужна.

Для интереса на github выполнил два поисковых запроса: "Flux<" language:Java вернул 158k результатов, а "Mono<List" language:Java — 19k. Ни на что не намекаю 😃

Грусть, печаль и тоска. Так Java уже все или еще нет? Мы же совсем недавно заикались о Project Loom здесь. Идея проекта в том, что JVM научили переключать поток на выполнение чего-то полезного, если он заблокирован, например, IO.

Крупные ребята, вроде Netflix, уже вовсю тестируют силу виртуальных потоков, и огребают, но не по собственной вине, о чем рассказывали у себя блоге. В чем была причина? Если кратко, то виртуальные потоки пока плохо дружат с synchronized методами и блоками, что может приводить к deadlock'ам. В марте в 24-ый релиз Java должны завезти фикс. Если он все же не станет LTS, то придется ждать до сентября, если роадмап не поменяют. Так что пока нужно быть осторожнее, тем более в проде.

Как виртуальные потоки выглядят в коде?

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  var user = executor.submit(() -> userRepository.find(userId));
  var projects = executor.submit(() -> projectRepository.find(userId));
  return new Profile(user.get(), projects.get());
}

Вполне симпатично, почти как в Kotlin:

val Dispatchers.LoomDispatcher: CoroutineDispatcher
    get() = Executors.newVirtualThreadPerTaskExecutor().asCoroutineDispatcher()

...

suspend fun getProfile(userId: String): Profile = withContext(LoomDispatcher) {
    val userDeferred = async { userRepository.find(userId) }
    val projectsDeferred = async { projectRepository.find(userId) }

    Profile(userDeferred.await(), projectsDeferred.await())
}

Даже Structured Concurrency выглядит сносно, хотя scope.join() выглядит криво:

try (var scope = new StructuredTaskScope<>()) {
  var user = scope.fork(() -> userRepository.find(userId));
  var repositories = scope.fork(() -> projectRepository.find(userId));
  scope.join();
  return new Profile(user.get(), repositories.get());
  }
}

В общем не все так плохо. Project Loom — сильная фича, которая почти не потребует роста экспертизы разработчиков, но значительно повысит пропускную способность уже написанных проектов. Kotlin тоже выиграл, так как корутины дружат с виртуальными потоками. Так что с Go мы еще поборемся 🔫

Может я сильно придираюсь? Позвольте мне наехать на процесс восстановления пароля на сайте pochta.ru 🤣

На волне различного рода утечек на всех ресурсах, где это было возможно, я подключил двухфакторную аутентификацию (two-factor authentication, 2FA). Обычно в качестве второго фактора в дополнение к паролю используются sms- или email-коды. Эти факторы могут не сработать, если ваша почта недостаточно защищена или вы потеряете/оставите без внимания смартфон, на котором:
1️⃣не будет установлен пин-код на сим-карте (злоумышленник просто вставит ее в свой смартфон и начнет получать смски). Как его установить?
2️⃣ не настроена блокировка экрана (с паролем/FaceID и т.п.)
3️⃣ не защищены паролем приложения почты и смс-сообщений и уведомления от них

Но на этом настоящие тревожные пирожочки не останавливаются.

На волне мошеннических действий с SMS-кодами я перевел, где это было возможно, 2FA на one-time password (OTP) для лучшей защиты своих аккаунтов.

Почему это актуально? Во-первых, есть такая угроза, как SIM Swapping или SIM-jacking (замена SIM-карты через сотрудника вашего оператора). Во-вторых, я не видел ещё ни одной новости, где жертва передала OTP-код: если с смсками глаз у многих уже замылился, то к OTP пользователи относятся более внимательно.

Конечно, такие меры защиты наиболее актуальны для аккаунтов банков, Госуслуг и других государственных структур. Так вот, если вы начнёте процедуру смены пароля на сайте Почты России, то второй фактор будет выключен (о чем вам сообщит соответствующее письмо выше). Останется только один фактор в виде кода из смс. Выглядит несекурненько.

Какие варианты решения проблемы я вижу?
* использовать email как второй фактор
* использовать заранее выданные проверочные коды (такие, например, Github выдает, когда вы 2FA подключаете)
* использовать для проверки авторизацию через Госуслуги

Надеюсь, что Почта все же залатает эту брешь в нашей с вами безопасности 🎹

Нечасто приходится слушать экспертов, которые и в разработке (софте) понимают и в управлении миллиардным IT-бизнесом. Меня ещё подкупило человеческое отношение Дмитрия к разработчикам. По крайней мере такое впечатление сложилось.

Преимущественно про Мой Офис шел разговор, но также зацепили Астру, Росу, Постгрес. Посмотрел на одном дыхании на 2x, конечно 😎. Приятного просмотра.

Весь прошлый спринт решал интересную рабочую задачу: нужно было настроить маршрутизацию в тестовом кластере k8s с Istio таким образом, что при добавлении в запрос пользователем заголовка X-MOCK трафик бы маршрутизировался на инстанс WireMock вместо своего обычного маршрута. Давайте разбираться по порядку.

Думаю, что такое k8s всем и так понятно, но что такое Istio?

Istio — расширение для k8s, которое реализует концепцию service mesh для управления взаимодействием между сервисами. Оно предоставляет такие возможности, как балансировка нагрузки, мониторинг, управление трафиком, безопасностью и политиками доступа налету, не требуя изменений в коде приложений. Service mesh реализуется как набор прокси-серверов, а именно sidecar-контейнеров с Envoy, которые размещаются рядом с каждым сервисом и перехватывают весь входящий и исходящий трафик.

Под каждым istio-proxy-сайдкаром на прикрепленной монструозной картинке (для простоты istio-proxy отображено схематично, получилось больше похоже на Istio Ambient -- sidecarless Istio) можно посмотреть конфигурацию его VirtualService.

Для чего в описанной схеме WireMock?
* сервисы смежных команд прилегли отдохнуть или вовсе еще не были подняты, но надо продолжать разработку/тестирование
* нужно смоделировать какой-то сценарий, для которого долго/дорого заводить тестовые данные в интеграционные сервисы

Схему, которую реализовал на данный момент, представлена на скрине под заголовком Как стало: для сервисов, которые должны реагировать на наличие заголовка X-MOCK, добавляем маршруты VirtualService для istio-proxy. На wiremock зашиваем нужный нам ответ, который будем отдавать по заданному шаблону запроса. WireMock также умеет проксировать запросы, если например, ни один шаблон не будет задан:

{
    "priority": 99999,
    "request": {
        "method": "ANY",
        "urlPattern": "/internal/cards"
    },
    "response": {
        "proxyBaseUrl": "http://gateway.outbound-apps"
    }
}

Для таких правил задаем низкий приоритет (большое значение priority).

На этом план-минимум выполнен 👏. В качестве задания со ⭐️ мне хочется настроить динамический выбор subset в зависимости от приходящих заголовков, чтобы не прописывать каждое правило в VirtualService явно. Здесь есть две проблемы:
1) синтаксис subset: $dynamic-subset-depend-on-x-feature не поддерживается VirtualService, subset должен быть задан литералом
2) если вычисленный subset не существует, то запрос упадет. Такое поведение возможно, но хотелось перенаправить запрос на заранее выбранный subset, например, default

В Алибабе сделали как раз то, что мне хотелось бы реализовать в целевом решении, а именно динамически вычисляемый subset + fallback для случая, когда нужный subset не найден для сервиса, в который планируем отправить запрос. Проблема в том, что в официальных релизах Istio такой функциональности нет 🤩

Планирую провести несколько встреч с гуру k8s, чтобы реализовать целевое решение. Пожелайте удачи, она мне пригодится 🤩

Это я, отдохнувший за выходные, сфотографировался на карту болельщика, чтобы в конце марта сходить на матч Зенит-Рубин. Оформление хоть и не очень сложное (через отдельное приложение Госуслуг), но требует отсканировать чип действующего загранпаспорта паспорта (это которые на 10 лет оформляются, в пятилетних чипа нет). Первый раз приложение зависло при считывании на 0%, но со второго раза процедура прошла успешно. Прощаю, не пришлось идти в МФЦ 🎉.

Почему недостаточно тех данных, что есть уже есть на Госуслугах — непонятно. Помнится, что взятая дистанционно 5 лет назад ипотека и то проще оформлялась 🤩.

P.S. Если еще не оформили замозапрет на взятие на вас кредитов и займов (защищаемся от мошенников, можно снять в любой момент), то можете сделать это через Госуслуги онлайн. Чувствую, что сейчас по стране прокатится волна звонков от мошенников, которые будут "помогать оформлять самозапрет".

P.P.S. Не шарьте экран своего телефона посторонним людям. Могут попытаться авторизоваться и увидят sms-код, который придет вам в уведомлении. Другие рекомендации описал тут.

P.P.P.S. Еще участились сливы ФИО коллег по работе (не моей, а в принципе). Ссылаясь на ФИО начальника или коллеги к вам могут втереться в доверие. Соблюдайте бдительность 😎