🖐 Приходите на доклады и мастер-классы, которые начинаются в 16:00
⠀
🏰 «00 Зал - Башня». Как мигрировать тысячи сервисов между любыми дистрибутивами Kubernetes без единой правки чего-либо. Максим Чудновский (СберТех)
Постараемся обойтись без спойлеров: Максим и команда получили на вход очень сложную и тяжёлую задачу и успешно её решили, причём крайне остроумным способом. В конце доклада вас ждёт open source-анонс.
⠀
🔘 Зал «08 Шатер Голубой». Как сделать тесты надежными: property-based-тестирование и fuzzing на практике. Николай Климов (VK, ВКонтакте)
Property-based-тестирование существует уже более 20 лет, но используется довольно редко. А зря, ведь этот подход может избавить от необходимости придумывать кучу тест-кейсов для юнит-тестов. Николай расскажет, чем этот подход отличается от фаззинга и как его применить в вашем проекте.
⠀
🔹 «03 Зал Синий». Мастер-класс «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Психологический возраст кибербезопасности. Антон Бочкарев (Третья сторона)
Внимание к кибербезопасности сегодня повышенное и невозможно обойти стороной такую её сторону, как готовность организации. Обычно оценивают технологии с помощью опросов и аудита. Антон пошёл дальше и расскажет, как всё это работает и как определить психологическую зрелость кибербеза в компании.
⠀
🟢 «06 Зал Зеленый». Выбор стримингового фреймворка в 2024 году. Максим Буйлин (Т-Банк)
Spark, Flink, Nifi или что-то другое — какой стриминговый фреймворк выбрать в текущем году? Из доклада вы узнаете основные критерии для выбора, на что обращать особое внимание. И все это на основе практического опыта.
⠀
🔵 Зал «09 Шатер Фиолетовый». Мастер-класс «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
🔸 Зал «07 Шатер Оранжевый». Механизм пререндера в браузерах. Алексей Кузнецов (Chromium contributor и энтузиаст)
Highload — это не только бэкенд, но и браузеры, отображающие наши сайты. Алексей расскажет, как на низком уровне в современных браузерах организован «пререндер» — механизм, с помощью которого браузеры делают вид, что наши сервисы быстрее, чем на самом деле.
⠀
🏰 «00 Зал - Башня». Как мигрировать тысячи сервисов между любыми дистрибутивами Kubernetes без единой правки чего-либо. Максим Чудновский (СберТех)
Постараемся обойтись без спойлеров: Максим и команда получили на вход очень сложную и тяжёлую задачу и успешно её решили, причём крайне остроумным способом. В конце доклада вас ждёт open source-анонс.
⠀
🔘 Зал «08 Шатер Голубой». Как сделать тесты надежными: property-based-тестирование и fuzzing на практике. Николай Климов (VK, ВКонтакте)
Property-based-тестирование существует уже более 20 лет, но используется довольно редко. А зря, ведь этот подход может избавить от необходимости придумывать кучу тест-кейсов для юнит-тестов. Николай расскажет, чем этот подход отличается от фаззинга и как его применить в вашем проекте.
⠀
🔹 «03 Зал Синий». Мастер-класс «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Психологический возраст кибербезопасности. Антон Бочкарев (Третья сторона)
Внимание к кибербезопасности сегодня повышенное и невозможно обойти стороной такую её сторону, как готовность организации. Обычно оценивают технологии с помощью опросов и аудита. Антон пошёл дальше и расскажет, как всё это работает и как определить психологическую зрелость кибербеза в компании.
⠀
🟢 «06 Зал Зеленый». Выбор стримингового фреймворка в 2024 году. Максим Буйлин (Т-Банк)
Spark, Flink, Nifi или что-то другое — какой стриминговый фреймворк выбрать в текущем году? Из доклада вы узнаете основные критерии для выбора, на что обращать особое внимание. И все это на основе практического опыта.
⠀
🔵 Зал «09 Шатер Фиолетовый». Мастер-класс «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
🔸 Зал «07 Шатер Оранжевый». Механизм пререндера в браузерах. Алексей Кузнецов (Chromium contributor и энтузиаст)
Highload — это не только бэкенд, но и браузеры, отображающие наши сайты. Алексей расскажет, как на низком уровне в современных браузерах организован «пререндер» — механизм, с помощью которого браузеры делают вид, что наши сервисы быстрее, чем на самом деле.
👍1
Forwarded from mtsepkov (Maxim Tsepkov)
#Highload Чему нас учит черный квадрат и причем здесь программирование. Это была идея Олега Бунина: расширить сознание и посмотреть на другую область. Основной рассказ вел Александр Кибасов (Doctrina et Nobiles), а Олег и Вирна Штерн давали реплики и повросы. А тема Малевича была выбрана потому, что онтико использует стиль супрематизма в оформлении презентаций, а с этого года еще начала делать сувенирку - матрешки, расписанные в этом стиле как приз за лучшие вопросы, докладчикам и членам ПК.
Мысль Олега состоит в том, что разработчики похожи на художников и других людей искусства: они создают новое, меняют реальность силой мысли. И организаторы ивентов это делают. Впрочем, у Александра были другая идея. Я сейчас кратко изложу его тезисы, как сам понял, а дальше, отдельно - будет мое отношение к этому. И хотя я так специально разделяю, не факт, что в изложении тезисов Александра я верно передам смысл, потому что любое изложение - интерпретация.
Итак, тезисы Александра о Малевиче, супрематизме и искусстве в целом. Отмечу, что он в лекции не разделял явно то, что Малевич говорил явно от позднейших интерпретаций.
* До Малевича искусство - это голые или обнаженные женщины, пейзажи или сюжеты с пресонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
* Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это - правильно. Идея бессмысленного жеста - спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
* Искусство без смысла, для созерцания - слом мира мещан, которые везде искали смысл, потому что так принято.
* Черный квадрат сломал элитарность художников: черный квадрат может нарисовать любой, он не требует мастерства. При том, что у Малевича мастерство - было.
* В те времена Петербургская и Московская академии каждый год выпускали художников с классическим подходом, их было много. Черный квадрат ломал традицию.
* Были последователи, ученики и те, кто тоже творил и творит в том стиле. Есть художник, который рисует синие картины, просто закрашивает одним цветом, есть - кто черные, устраивают выставки.
* Кандинский - как Малевич, но для тех, кто любит цвета. Вкусы различны, одним нравится кока, другим - пепси. У него еще была бредовая конструкция, как его картины работают и какие эмоции вызывают.
* После Малевича было еще три соразмерных события. Фонтан Мишеля Дюшана (1917) - нестандартно повешенный писсуар: главное, идея, а создавать предмет не обязательно, можно взять готовый, мастерство не нужно вообще. Один и три стула Джозева Кошута (1965) - инсталляция: стул, его описание и его фото; идея - язык - не рабочая структура, он не передает смыслы, провал коммуникации. И Дерьмо художника Пьетро Мандзони (1961) - вообще подвешивает сферу искусства как таковую.
Мысль Олега состоит в том, что разработчики похожи на художников и других людей искусства: они создают новое, меняют реальность силой мысли. И организаторы ивентов это делают. Впрочем, у Александра были другая идея. Я сейчас кратко изложу его тезисы, как сам понял, а дальше, отдельно - будет мое отношение к этому. И хотя я так специально разделяю, не факт, что в изложении тезисов Александра я верно передам смысл, потому что любое изложение - интерпретация.
Итак, тезисы Александра о Малевиче, супрематизме и искусстве в целом. Отмечу, что он в лекции не разделял явно то, что Малевич говорил явно от позднейших интерпретаций.
* До Малевича искусство - это голые или обнаженные женщины, пейзажи или сюжеты с пресонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
* Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это - правильно. Идея бессмысленного жеста - спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
* Искусство без смысла, для созерцания - слом мира мещан, которые везде искали смысл, потому что так принято.
* Черный квадрат сломал элитарность художников: черный квадрат может нарисовать любой, он не требует мастерства. При том, что у Малевича мастерство - было.
* В те времена Петербургская и Московская академии каждый год выпускали художников с классическим подходом, их было много. Черный квадрат ломал традицию.
* Были последователи, ученики и те, кто тоже творил и творит в том стиле. Есть художник, который рисует синие картины, просто закрашивает одним цветом, есть - кто черные, устраивают выставки.
* Кандинский - как Малевич, но для тех, кто любит цвета. Вкусы различны, одним нравится кока, другим - пепси. У него еще была бредовая конструкция, как его картины работают и какие эмоции вызывают.
* После Малевича было еще три соразмерных события. Фонтан Мишеля Дюшана (1917) - нестандартно повешенный писсуар: главное, идея, а создавать предмет не обязательно, можно взять готовый, мастерство не нужно вообще. Один и три стула Джозева Кошута (1965) - инсталляция: стул, его описание и его фото; идея - язык - не рабочая структура, он не передает смыслы, провал коммуникации. И Дерьмо художника Пьетро Мандзони (1961) - вообще подвешивает сферу искусства как таковую.
Forwarded from mtsepkov (Maxim Tsepkov)
Теперь мои комментарии, тоже в виде тезисов.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.
На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.
А, еще в ответах на вопросы было про нейросеть, которая может создать любую абстракцию. Позиция Александра: нейросеть не может быть автором произведения, только производителем. А автор - тот кто впишет это в историю искусства. В общем, это логично, если в произведении главное - идея, то автор - тот кто написал промпт, а потом смог объяснить, а нейросеть - инструмент.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.
На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.
А, еще в ответах на вопросы было про нейросеть, которая может создать любую абстракцию. Позиция Александра: нейросеть не может быть автором произведения, только производителем. А автор - тот кто впишет это в историю искусства. В общем, это логично, если в произведении главное - идея, то автор - тот кто написал промпт, а потом смог объяснить, а нейросеть - инструмент.
Livejournal
Wokeism: идеология
Достойный юзер redstarcreative написал несколько комментариев, где кратко охарактеризовал историю и нынешнее состояние господствующей в свободном мире идеологии. Тема для многих крайне актуальная, а такого краткого и ясного изложения еще поискать. Этот юзер…
🖐 Не пропустите доклады, которые начинаются в 17:10
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)
Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)
Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)
История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)
Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)
Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)
Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)
Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)
История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)
Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)
В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.
👍3
Forwarded from mtsepkov (Maxim Tsepkov)
#Highload Филипп Дельгядо. Enterprise deploy: почему это больно. Рассказ о технике повышения безопасности деплоя. Особенно важно это для enterprise-решений, которые разворачиваются у клиента: мы не контролируем процесс обновлений и их использование.
Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.
Надо уметь писать безопасные скрипты обновления с миграцией данных. Если мы хотим поменять тип данных в поле, то безопасное решение - новое поле с новым типом, при этом заполнение его по старому - отдельный скрипт, работающий в фоне и не нагружающим базу. И в переходный период надо уметь работать с объектами, когда только старое поле заполнено. А опасные изменения - это когда мы меняем семантику, добавляем side-эффект. Все теоретически знают, что это делать не нужно, а практически достаточно часто делают. Идет эволюция, и вместо основного телефона клиента становится два: для нотификация с подтверждением и для экстренных обращений, и вопрос безопасности таких изменений - сложный.
Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов
Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.
А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.
Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.
Надо уметь писать безопасные скрипты обновления с миграцией данных. Если мы хотим поменять тип данных в поле, то безопасное решение - новое поле с новым типом, при этом заполнение его по старому - отдельный скрипт, работающий в фоне и не нагружающим базу. И в переходный период надо уметь работать с объектами, когда только старое поле заполнено. А опасные изменения - это когда мы меняем семантику, добавляем side-эффект. Все теоретически знают, что это делать не нужно, а практически достаточно часто делают. Идет эволюция, и вместо основного телефона клиента становится два: для нотификация с подтверждением и для экстренных обращений, и вопрос безопасности таких изменений - сложный.
Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов
Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.
А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.
🖐 Друзья, в 18:20 мы ждём вас на заключительных докладах Saint HighLoad++ 2024:
⠀
🏰 «00 Зал - Башня». Как мы шли к 5000 RPS на запись. Ян Силов (Ozon)
Хорошая история повышения нагрузки на запись и борьбы с ней. Вместе с докладчиком погрузимся в анализ проблем и оптимизацию.
⠀
🔘 Зал «08 Шатер Голубой». Как воспитать себе помощника: применение локального ИИ для разработки. Алексей Цветков (Независимый эксперт)
Трудно делать содержательный доклад на горячую тему: ожидания высоки, готовность аудитории низкая. И Алексей справился блестяще! Это интересный и полезный доклад, рекомендован всем, кого интересует практическое применение AI в повседневной работе.
⠀
🟣 «04 Зал Красный». Как мы монгу физически бэкапили. Владимир Гошев (Yandex Cloud)
Рассказ о том, как Яндекс учился бэкапить кластеры MongoDB для своих клиентов: чтобы бэкапы занимали адекватное количество места, с ними было легко работать, а главное — чтобы из них можно было восстановить консистентный кластер!
⠀
🏰 «00 Зал - Башня». Как мы шли к 5000 RPS на запись. Ян Силов (Ozon)
Хорошая история повышения нагрузки на запись и борьбы с ней. Вместе с докладчиком погрузимся в анализ проблем и оптимизацию.
⠀
🔘 Зал «08 Шатер Голубой». Как воспитать себе помощника: применение локального ИИ для разработки. Алексей Цветков (Независимый эксперт)
Трудно делать содержательный доклад на горячую тему: ожидания высоки, готовность аудитории низкая. И Алексей справился блестяще! Это интересный и полезный доклад, рекомендован всем, кого интересует практическое применение AI в повседневной работе.
⠀
🟣 «04 Зал Красный». Как мы монгу физически бэкапили. Владимир Гошев (Yandex Cloud)
Рассказ о том, как Яндекс учился бэкапить кластеры MongoDB для своих клиентов: чтобы бэкапы занимали адекватное количество места, с ними было легко работать, а главное — чтобы из них можно было восстановить консистентный кластер!
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Первая в России PostgreSQL Pre-Commitfest Party: итоги!
✔️100+ слушателей на публичном ревью патчей в PostgreSQL 18
✔️900+ гостей в шатре Postgres Professional!
✔️4 демонстрации BiHA и Shardman
✔️600+ участников квиза
✔️15 коробок разыгранного мерча
Спасибо всем, кто провел с нами эти два дня и до встречи на следующей вечеринке российского постгрес-сообщества!
Вместе мы – Postgres!
✔️100+ слушателей на публичном ревью патчей в PostgreSQL 18
✔️900+ гостей в шатре Postgres Professional!
✔️4 демонстрации BiHA и Shardman
✔️600+ участников квиза
✔️15 коробок разыгранного мерча
Спасибо всем, кто провел с нами эти два дня и до встречи на следующей вечеринке российского постгрес-сообщества!
Вместе мы – Postgres!
❤4👍3🔥2❤🔥1