Русский
Русский
English
Статистика
Реклама

Бекенд

Pet-проект для джуна. Или зачем и как выбрать pet project. (личный опыт)

23.02.2021 14:15:47 | Автор: admin

Предисловие

Привет Хабр! Эта публикация написана джуном для джунов (но возможно и специалисты более высокого уровня что-то найдут для себя / своих падаванов).

Зачем нужны pet проекты?

Для саморазвития как разработчика и закрепления изученного материала.

Если Вы днями на пролёт "штурмуете" теорию: читаете посты, смотрите туториалы, но при этом не применяете изученное на практике, то времени на освоение выбранной Вами темы понадобится в разы больше.

Для работающего разработчика pet проект отличная возможность абстрагироваться от рабочих задач и погрузиться в интересную тему. Чаще всего на разработку домашних проектов нет много времени из-за чего код нужно писать быстро и много, а информацию искать по существу не отвлекаясь на лишнее.

Для джуна без постоянного места работы, pet проект заменяет тут самую работу (со стороны разработки). Вы ставите себе задачу/цель и делаете всё возможное что бы её выполнить. При разработке Вы ещё глубже погружаетесь в тему, а иногда находите новые объекты для изучения.

Суммируя pet проекты нам нужны для:

  • изучения / закрепления нового материала;

  • получения удовольствия от разработки чего-то интересного лично Вам;

  • пополнения своего портфолио;

  • (bonus) есть шанс что Ваш pet проект может кому-то приглянуться и тогда из этого можно получить финансовую выгоду.

Как выбрать и на что обратить внимание?

Я рассматривал этот вопрос со стороны фронтенд разработчика и возможно для других отраслей приведенные ниже тезисы будут не валидны.

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

Технологии

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

Дизайн

Тут все зависит от человека и ситуации. Есть два варианта:

  1. Запариться и сделать крутейший дизайн.

    Плюсы:

    • lvl up как дизайнера;

    • обычно свой дизайн очень приятен;

    • так как это собственный макет Вы в нём хорошо ориентируетесь и ещё на этапе дизайна продумываете некоторые фичи.

    Минусы:

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

  2. Найти готовый дизайн и работать с ним.

    Плюсы:

    • быстро (хотя поиск может затянуться, об этом ниже);

    • не нужно отвлекаться на дизайн.

    Минусы:

    • не всегда можно найти дизайн для Вашей задумки, особенно если она не типичная;

    • готовые бесплатные макеты не всегда красивые.

Идея

Если авторские идеи не Ваше то на просторах интернета существуют множество тем проектов в которых можно использовать любые нужные Вам технологии.

Вот пару вечно актуальных примеров:

  • список задач;

  • список задач;

  • менеджер покупок;

  • сайт портфолио;

  • кино сайт;

  • калькулятор;

  • блог;

  • магазин чего-либо.

Личный опыт

В этом блоке я раcскажу как придумывались / создавались мои pet проекты.

Начало (AniList)

Шёл июль 2020 года. Спустя семестр изучения JavaScript'а в колледже я решил изучить какой-то фреймворк. Выбор пал на React. Через пару дней ознакомления с фреймворком я наткнулся на серию видеороликов по разработке веб-приложения пиццерии на ютуб канале Archakov Blog. И решил сразу же применять изученное в видео на реальном проекте, но просто переписывать код из видео в IDE было не интересно. По этому я решил делать аниме список.

Выше я писал про два варианта получения дизайна для проекта. Какой же из вариантов выбрал я при создании макета? Оба. Для начала я зашёл на уже существующие сайты с такой-же тематикой потом пролистал Behance и собрал своего "франкенштейна" из собственных идей и кусков уже готовых дизайнов.

Скриншот проекта из FigmaСкриншот проекта из Figma

По готовому макету я понял что мне нужно будет где-то брать информацию об аниме (API, AJAX), где-то хранить её (Redux), а также как-то организовать авторизацию и хранение информации о пользователях (Firebase) + работа с версиями файлов(GIT, GitHub). В итоге мне предстояло ознакомиться как минимум с 5 новыми технологиями помимо React.

И в этом я считаю один из плюсов pet проектов. Начиная учить что-то одно, а в конце осваиваешь намного больше чем ожидал.

ToDo list

Дизайн ToDo appДизайн ToDo app

Следующим проектом должен был стать todo list. Мой одногруппник (тоже начинающий фронтендер) должен был делать frontend на Angular, а я (неожиданно) backend. Тут мне пристояло погрузиться в мир backend'а и может не изучить, но хорошо так ознакомиться с NodeJS, Express, MongoDB, mongoose, cors, dotenv, способами авторизации, деплоем на Heroku и ещё глубже понять работу API.

По итогу вышло так что и я и мой товарищ каждый для себя писали back и front end.

Остальное

Потом было ещё пару проектов. Вкратце напишу что для себя я вынес из них.

Приложение погоды:

  • рисование на canvas'е;

  • работа с геолокацией;

  • анимация React компонентов.

Shedaily (front & back end) - приложение которое парсило расписание из сайта колледжа где я учусь и приводило его в приятный вид:

  • парсинг информации из сайта;

  • работа с Excel таблицами в NodeJS.

Terminal website - вдохновившись сайтом dodo.dev создал сайт с контактами:

  • SCSS;

  • Gulp.

Менеджер подписок:

  • MobX;

  • переключение темы.

Магазин аксесcуаров (backend) (в разработке):

  • более глубоко познал MongoDB + mongoose;

  • GraphQL.

Портфолио (на стадии дизайна):

  • JAM stack;

  • Gatsby;

  • создание кастомного курсора.

Заключение

Недавно меня постигла идея переписать свой первый pet project (Аниме список), но теперь с новыми навыками: backend на NodeJS, Express, GraphQl вместо Firebase, и frontend React + Apollo Client, ну и дизайн по красивше сделать. Эта мысль является результатом моего прогресcа который я постиг благодаря pet проектам.

Всякое дело совершенствуется овладением техники. Всякий навык достигается упражнением. - Гиппократ

Подробнее..

Конец вечного противостоянияsnake_keysVScamelKeys наводим порядок встилях написания переменных

31.05.2021 20:20:52 | Автор: admin

Привет,Хабр!Меня зовут Владимир, работаю в Ozon, занимаюсьфронтендом.

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

Представим ситуацию:начинаетсяработа надсайтом, разработчикитёмной и светлой сторон встречаются обсудить насущные вопросы. Один из таких вопросовсвязан с передачей данных.

Бекенд отдает и принимает данные в виде:

{ user_name: "user1", main_title: "Title", } 

Фронтенд:

{ userName: "user1", mainTitle: "Title", } 

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

В этой статье мы попробуемрешитьэтупроблемупреобразовать все данныебэкендав данныефронтендаи наоборот.Воспользуемся для этогоJavaScript.

Надеюсь,статьябудет полезнаначинающимразработчикам, а остальным лишний раз напомнитознакомых приёмах по добавлению комфорта в разработку.

Шаг 1. Преобразование строки

Нам поможет встроенная функцияreplace. Онаумеетзаменятькаждое вхождение заданного регулярного выраженияс помощью функциимаппера, которую мы передаём вторым аргументом.

# Преобразованиеsnake_keysстроки вcamelKeys:

const snakeToCamel = str => {     return str.replace(/([_][a-z])/g, letter => {         return letter                 .toUpperCase()                 .replace('_', '')     }) } 

# ПреобразованиеcamelKeysстроки вsnake_keys:

const camelToSnake = str => {     return str.replace(/[A-Z]/g, letter => {         return '_' + letter.toLowerCase()     }) } 

Шаг 2. Работа с объектами

# Возьмем пример с начала статьи { user_name: "user1", main_title: "Title", } 

Пройдёмся по ключам объекта и заменим их с помощью уже реализованной функцииsnakeToCamel.

constsimpleKeysTransform=value=>{returnObject.entries(value).reduce((acc, [key,value]) => {constnewKey=snakeToCamel(key)        return{...acc, [newKey]:value}}, {})}

Давайте теперь сделаем универсальную функцию преобразования и будем принимать на вход ещёпеременную, отвечающую за изначальный вид стиля ключей объекта.

const keysTransform1 = (value, isInitialSnake = true) => {     const chooseStyle = isInitialSnake ? snakeToCamel : camelToSnake     return Object.entries(value).reduce((acc, [key, value]) => {         const newKey = chooseStyle(key)         return {...acc, [newKey]: value}     }, {}) } 

Шаг 3. Что делать с вложенными объектами

# Например {   user_info: {     first_name: "User",     last_name: "Userin   } } 

Применимрекурсию.Обернём основную логику в функцию и в ней будем проверять:является ли наше значение объектом. Если да, то будем вызывать нашу функцию снова и снова.

const keysTransform2 = (input, isInitialSnake = true) => {     const chooseStyle = isInitialSnake ? snakeToCamel : camelToSnake     const recursiveTransform = value => {         if (value && typeof value === 'object') {             return Object.entries(value).reduce((acc, [key, value]) => {                 const newKey = chooseStyle(key)                 const newValue = recursiveTransform(value)                 return {...acc, [newKey]: newValue}             }, {})         }         return value     }     return recursiveTransform(input) } 

Шаг 4. Что делать с массивами

# Например {   users: [     {       first_name: "user1",       phone_number: 8996923     },     {       first_name: "user2",       phone_number: 12312312     }   ]   } 

Всёдо безобразия просто. Добавим проверку на массив и на каждыйегоэлемент навесим нашу рекурсивную функцию.

const keysTransform = (input, isInitialSnake = true) => {     const chooseStyle = isInitialSnake ? snakeToCamel : camelToSnake     const recursiveTransform = value => {         if (Array.isArray(value)) {             return value.map(recursiveTransform)         }         if (value && typeof value === 'object') {             return Object.entries(value).reduce((acc, [key, value]) => {                 const newKey = chooseStyle(key)                 const newValue = recursiveTransform(value)                 return {...acc, [newKey]: newValue}             }, {})         }         return value     }     return recursiveTransform(input) } 

Перемирие

Давайте посмотрим, что получилось: мы реализовали алгоритм преобразования ключей объектов изsnake_keysвcamelKeysи наоборот.Чуть-чуть меньше раздора междуфронтендоми бэкендом неплохо же!

Существуютидругиестили написания составных слов(PascalKeys,kebab-keys, UPPER_SNAKE_KEYS).При надобности, вы уже сами сможете с ними справиться.

Подробнее..

Путь IVI от монолита к микросервисам

08.04.2021 16:21:10 | Автор: admin

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

Как и многие другие, IVI начинал свой путь в разработке с монолита. Изначально сервис был b2b-решением, которое предоставляло фильмы для размещения на других площадках. Одной из таких площадок был и собственный сайт IVI, который работал с нашим монолитом. И этот монолит отвечал за раздачу информации о контенте, ссылки на контент, подбор рекламы, загрузку и кодирование новых фильмов.

В 2011 году мы поняли, что запросов к сервису становится много и необходимо масштабировать наше решение. Причём основную массу составляли запросы от пользователей к монолиту за ссылками на фильмы и за рекламой. И не было необходимости масштабировать всё остальное. Мы решили вынести минимальную функциональность в микросервис и сделать некий лёгкий сервис. Так мы воспользовались первым преимуществом микросервисной архитектуры лёгкостью масштабирования микросервисов.

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

Затем мы решили вынести из монолита систему управления контентом. Тут уже использовалась независимая кодовая база, оставалась только связь со схемой базы данных и средствами описания этой схемы. И примерно в то же время мы начали показывать фильмы на различных устройствах, для которых потребовался некий программный интерфейс. Так родился сервис, отвечающий за интерфейс общения с мобильными приложениями (MAPI). Он был совсем независимым, со своей кодовой базой и хранилищем, которое специальные скрипты синхронизировали с основным хранилищем.

Тут мы столкнулись с другой проблемой, которую, в том числе, позволяют решать микросервисы, правда мы этим не воспользовались. Название этой проблеме монорепозиторий. С ростом команды разработка в одном репозитории становилась проблемой. Росло количество тестов, и нам пришлось усложнять CI, чтобы распараллелить запуск тестов различных независимых частей репозитория. Но даже это не сильно спасало. Дело в том, что из-за активной разработки скапливалась очередь задач на слияние веток, и разрабатываемая тобой ветка могла быть слита только через пол дня. Если повезёт и кто-то другой не объединит раньше тебя ветку, которая ломает твои тесты.

Поэтому следующие наши микросервисы создавались уже в отдельных репозиториях. И тут мы начали осознавать другое преимущество микросервисов: на них можно пробовать новые технологии, новые языки программирования, новые СУБД. Мы уже не были привязаны к монолиту. Так, например, в нашу разработку ворвался язык Go.

Но в это же время мы столкнулись и со множеством недостатков микросервисов. Первым таким недостатком была сложность разработки. Да, выше мы писали, что микросервисы когда-то позволили нам упростить разработку, так как сервис, отвечающий за маленький кусочек бизнес логики, проще понять, доработать и протестировать. Но микросервисы не работают сами по себе. Они работают в связке с другими микросервисами. И чтобы доработать какой-то один, нужно развернуть локально несколько других. Да и тестировать тоже стало сложно, потому что было несколько тестовых стендов, на которые очень быстро выстраивалась очередь из желающих протестировать доработку в том или ином микросервисе. Для решения этой проблемы мы собрали систему, предоставляющую каждому разработчику или тестировщику свой кластер со всеми необходимыми микросервисами свой маленький IVI. Эта система позволяла создать такой кластер и быстро развёртывать в нём нужные версии микросервисов. И разработчикам уже не нужно было развёртывать всё локально, достаточно было создать разрабатываемый сервис и ходить из него в свой виртуальный кластер.

Другой проблемой микросервисов стали распределённые транзакции. Так, например, на IVI есть процедура объединения аккаунтов. Когда пользователь открывает только что установленное приложение, у него уже есть аккаунт, привязанный к устройству. И он может смотреть фильмы, добавлять их в очередь просмотра, оценивать. Но через некоторое время пользователь вспоминает, что у него есть зарегистрированный на сайте аккаунт, и он авторизуется под ним на устройстве. Наша задача объединить пользовательские оценки, очереди со старого и нового аккаунта. Объединение этой информации происходит во множестве микросервисов, и, в теории, должно происходить или везде, или нигде. То есть нужны распределённые транзакции, которые привносят очень большие сложности в бизнес-логику и в разрабатываемую систему. Решать эту проблему мы в итоге не стали: максимально обезопасили критическую для пользователя информацию (его покупки), а если при работе с другими данными возникнут ошибки, то их обнаружат или скрипты валидации данных, или сам пользователь придёт с жалобой в поддержку и ему там помогут.

И ещё одной проблемой стала сложность добавления нового сервиса в production. Средства CD позволяли быстро обновлять существующие сервисы, но это не касалось первоначальной установки. Она подразумевала необходимость установить новые машины в ДЦ или создать виртуалки, установить всё необходимое ПО, настроить CD. И это был небыстрый процесс, а новые доработки обычно требовались довольно срочно. Да, в будущем будут появляться различные средства для решения этой проблемы, но в то время их ещё не было. Хотя даже когда у нас начали появляться средства виртуализации, контейнеризации, оркестрации и эта проблема стала исчезать, на смену пришла другая сложность эксплуатации. Уже нельзя справиться с десятками сервисов без автоматизации доставки новых версий приложений. Сложность эксплуатации также возрастает в связи с повышением требований к мониторингу и управлению большим количеством сервисов. Решение таких эксплуатационных проблем требует множества навыков и инструментов.

Всё это очень сильно поубавило пыл в написании новых микросервисов. При реализации новых задач мы старались это сделать в рамках уже существующих сервисов. И выделяли микросервисы только в случае крайней необходимости, или если требования к реализуемой задаче совсем не укладывались ни в один из существующих сервисов.

Но компания развивалась, появлялись новые направления разработки, и среди прочего появились сервисы для аналитики. Тут мы столкнулись ещё с одной проблемой микросервисов согласованность данных. Для различной аналитической обработки требуются данные из множества сервисов. И поддерживать их согласованность очень сложно. Например, мы формируем и отправляем пользователям письма с персональными рекомендациями, предложениями посмотреть тот или иной фильм. Но поскольку данные не согласованы, то может получиться так, что пользователь этот фильм уже посмотрел, и письмо будет неактуальным. Несогласованность данных усложняет бизнес-процессы для работы с этими данными. Например, мы должны были непосредственно перед отправкой проверять в оригинальном хранилище, посмотрел ли пользователь уже этот фильм или ещё нет.

Помимо появления новых микросервисов у нас активно дорабатывались старые микросервисы, туда добавляли больше функциональности, больше различной бизнес-логики. Некоторые сервисы настолько разрастались, что стали походить на монолиты, превратились в своего рода big ball of mud, с большой энтропией кода, сильной связанностью между различными частями сервиса, сложностью масштабирования.

Происходило это из-за того, что продукт активно развивался, в него интенсивно добавляли новые функции, и при этом не было какой-либо единой ответственности, не было небольшой группы человек, отвечающих за архитектуру сервиса, через которых проходили бы все правки. В результате в таких сервисах нередко появлялось дублирование реализации какой-либо функциональности. Например, в одном из сервисов мы нашли три различных варианта работы с AB-тестами.

При этом и наша компания разрасталась, менялась её структура, появлялись команды, развивавшие конкретные направления. И тут мы осознали ещё один недостаток монолитов и преимущество микросервисов разграничение ответственности. Для каждого микросервиса у нас появились свои ответственные команды. Чего нельзя сказать о разросшихся в размерах сервисах: за них отвечали все и одновременно никто. Стали происходить диалоги вида: Кто отвечает за сервис X? Команда A. У меня вопрос по функциональности F. А, за этим тебе надо идти в команду B..

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

Другой проблемой стала сложность поддержки актуального стека технологий. Уже давно закончилась поддержка второго Python, но один из наших сервисов до сих пор на нём работает. А другой сервис мы полгода переводили на третий Python. Да и в целом любой рефакторинг сервисов с большой кодовой базой это очень сложная задача, которая требует больших усилий для организации плавного перехода на новые технологии, или может потребовать feature freeze на длительный период. К тому же после написания всего необходимого кода очень долгое время занимает тестирование таких изменений. Тогда как микросервисы переводились на Python 3 за пару дней и очень быстро тестировались.

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

И несмотря на то, что у нас активно развиваются всё новые и новые микросервисы, их количество превысило 50 штук, у нас остаётся проблема с осознанием того, что некоторые новые куски бизнес-логики лучше выделить в отдельный микросервис, а не добавлять к уже существующим. Обычно это аргументируется тем, что создавать новый сервис долго, а доработки нужны уже сейчас. Мы даже как-то провели небольшой эксперимент и показали, что реализовать новый сервис, настроить его CI, добавить манифесты для Kubernetes и выгрузить в dev-кластер можно за несколько часов, что не сильно дольше, чем пытаться добавить эту же функциональность в уже существующий сервис.

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

Подробнее..

Как мы просто сократили объем входящего в дата-центр трафика на 70

03.02.2021 22:16:57 | Автор: admin

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

Единственное, о чем мы пожалели что не применили это решение раньше.

Наша команда придерживается принципов Data-Driven, то есть решения о развитии продуктов принимаются на основе метрик, а внедрение любых новых фич начинается с проверки гипотез. Для этого мы собираем и агрегируем колоссальное количество данных о том, что происходит внутри.

Два года назад, когда мы переходили с RedShift на ClickHouse, количество собираемых аналитических событий (приложение открылось, приложение запросило ленту контента, пользователь просмотрел контент, пользователь поставил смайл (лайк) и так далее) составляло около 5 млрд в сутки. Сегодня это число приближается к 14 млрд.

Это огромный объём данных, для хранения и обработки которого мы постоянно придумываем решения и лайфхаки, а сервис, их агрегирующий один из самых сложных среди всех наших инфраструктурных сервисов.

Но перед тем, как агрегировать, сохранить и обработать столько данных, их надо сначала принять и с этим есть свои проблемы. Часть описана в статье о переходе на ClickHouse (ссылка на неё была выше), но есть и другие.

Например, несколько раз, когда агрегирующий сервис начинал работать с перебоями, клиентские приложения начинали накапливать события и пытаться повторять отправку. Это приводило к эффекту снежного кома, в итоге практически блокируя нам входящие каналы в дата-центре.

Во время брейншторма по поводу одного из таких инцидентов прозвучала идея: раз мы создаём этими событиями такой колоссальный объём трафика, может быть нам начать его сжимать на клиентских устройствах? Отличная идея, но она была отвергнута как неконструктивная. Ведь это не избавит нас от катастрофы, а лишь оттянет её на какое-то время. Поэтому идея отправилась в специальный ящичек для неплохих идей.

Но ближе к лету непростого 2020 года ей нашлось применение.

Протокол HTTP, помимо сжатия ответов (о котором знают все, кто когда-либо оптимизировал скорость работы сайтов), позволяет использовать аналогичный механизм для сжатия тела POST/PUT-запросов, объявив об этом в заголовке Content-Encoding. В качестве входящего обратного прокси и балансировщика нагрузки мы используем nginx, проверенное и надёжное решение. Мы настолько были уверены, что он сумеет ко всему прочему ещё и на лету распаковать тело POST-запроса, что поначалу даже не поверили, что из коробки он этого не умеет. И нет, готовых модулей для этого тоже нет, надо было как-то решать проблему самостоятельно или использовать скрипт на Lua. Идея с Lua нам особенно не понравилась, зато это знание развязало руки в части выбора алгоритма компрессии.

Дело в том, что давно стандартизированные алгоритмы сжатия типа gzip, deflate или LZW были изобретены в 70-х годах XX века, когда каналы связи и носители были узким горлышком, и коэффициент сжатия был важнее, чем потраченное на сжатие время. Сегодня же в кармане каждого из нас лежит универсальный микрокомпьютер первой четверти XXI века, оборудованный подчас четырёх- и более ядерным процессором, способный на куда большее, а значит алгоритм можно выбрать более современный.

Выбор алгоритма

Требования к алгоритму были простыми:

  1. Высокая скорость сжатия. Мы не хотим, чтобы приложения тормозили из-за второстепенной функции.

  2. Небольшое потребление процессорной мощности. Не хотим, чтобы телефоны грелись в руках пользователей.

  3. Хорошая поддержка, доступность для основных языков программирования.

  4. Permissive лицензия.

Сразу отбросили Brotli, предназначенный для одноразового сжатия статического контента на стороне сервера. По схожей причине решили отказаться от bzip, также ориентированного на статику и большие архивы.

В итоге остановились на алгоритме Zstandard, по следующим причинам:

  • Высокая скорость сжатия (на порядок больше, чем у zlib), заточенность на небольшие объёмы данных.

  • Хороший коэффициент сжатия при щадящем уровне потребления CPU.

  • За алгоритмом стоит Facebook, разрабатывавший его для себя.

  • Открытый исходный код, двойная лицензия GPLv2/BSD.

Когда мы увидели первым же в списке поддерживаемых языков JNI, интерфейс вызова нативного кода для JVM, доступный из Kotlin мы поняли, что это судьба. Ведь Kotlin является у нас основным языком разработки как на Android, так и бэкенде. Обёртка для Swift (наш основной язык разработки на iOS) завершила процесс выбора.

Решение на бэкенде

На стороне бэкенда задача была тривиальная: увидев заголовок Content-encoding: zstd, сервис должен получить поток, содержащий сжатое тело запроса, отправить его в декомпрессор zstd, и получить в ответ поток с распакованными данными. То есть буквально (используя JAX-RS container):

// Обёртка над Zstd JNIimport org.apache.commons.compress.compressors.zstandard.ZstdCompressorInputStream;// ...if (  containerRequestContext    .getHeaders()    .getFirst("Content-Encoding")    .equals("zstd")) {  containerRequestContext    .setEntityStream(ZstdCompressorInputStream(      containerRequestContext.getEntityStream()    ))}

Решение на iOS

Решили сначала попробовать сжатие аналитических событий на iOS. Команда разработки была свободнее, ну и клиентов на iOS у нас несколько меньше. На всякий случай закрыли этот функционал при помощи feature toggle с возможностью плавной раскатки.

import Foundationimport ZSTDfinal class ZSTDRequestSerializer {    private let compressionLevel: Int32    init(compressionLevel: Int32) {        self.compressionLevel = compressionLevel    }    func requestBySerializing(request: URLRequest, parameters: [String: Any]?) throws -> URLRequest? {        guard let mutableRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else {            return nil        }        // ...        mutableRequest.addValue("zstd", forHTTPHeaderField: "Content-Encoding")        if let parameters = parameters {            let jsonData = try JSONSerialization.data(withJSONObject: parameters, options: [])            let processor = ZSTDProcessor(useContext: true)            let compressedData = try processor.compressBuffer(jsonData, compressionLevel: compressionLevel)            mutableRequest.httpBody = compressedData        }        return mutableRequest as URLRequest    }}

Осторожно включив фичу на 10% клиентов прямо в процессе раскатки очередной версии, затаив дыхание, стали смотреть в логи, метрики, индикатор крашей и прочие инструменты. Проблем не обнаружилось, полёт был нормальный.

Впрочем, и снижение объёма трафика было не сильно заметно. Дождавшись, пока новая версия клиента раскатится пошире, мы врубили сжатие на 100% аудитории.

Результат нас, мягко говоря, удовлетворил:

График падения трафика на iOSГрафик падения трафика на iOS

Входящий трафик упал аж на 25%. На графике представлен весь входящий в наш дата-центр трафик, включающий и штатные запросы клиентов, и закачиваемые ими картинки и видео.

То есть мы на четверть сократили весь объём.

Решение на Android

Воодушевлённые, мы запилили сжатие для второй платформы.

// Тут перехватываем отправку события через interceptor и подменяем оригинальный body на сжатый если это запрос к eventsoverride fun intercept(chain: Interceptor.Chain): Response {   val originalRequest = chain.request()   return if (originalRequest.url.toString()               .endsWith("/events")) {      val compressed = originalRequest.newBuilder()            .header("Content-Encoding", "zstd")            .method(originalRequest.method, zstd(originalRequest.body))            .build()      chain.proceed(compressed)   } else {      chain.proceed(chain.request())   }}// Метод сжатия, берет requestBody и возвращает сжатыйprivate fun zstd(requestBody: RequestBody?): RequestBody {   return object : RequestBody() {      override fun contentType(): MediaType? = requestBody?.contentType()      override fun contentLength(): Long = -1 //We don't know the compressed length in advance!      override fun writeTo(sink: BufferedSink) {         val buffer = Buffer()         requestBody?.writeTo(buffer)         sink.write(Zstd.compress(buffer.readByteArray(), compressLevel))      }   }}

И тут нас ждал шок:

График падения на AndroidГрафик падения на Android

Так как доля Android среди нашей аудитории больше, чем iOS, падение составило ещё 45%. Итого, если считать от исходного уровня, мы выиграли суммарно 70% от, напомню, всего входящего трафика в ДЦ.

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

В этот момент мы только могли пожалеть, что не нашли время на внедрение такой рационализации раньше.

Также стало видно, что наши опасения относительно батарейки не оправдались. Наоборот, потратив немного процессорной мощности телефона на сжатие данных, мы экономим намного больше электричества на передаче этих данных в эфир, как на Wi-Fi, так и по сотовой сети.

Два слова, что ещё можно улучшить

У Zstandard есть очень интересная возможность использования предобученного словаря. Если взять достаточно большой объём типичных данных и прогнать по нему сжатие, то можно получить на выходе словарь наиболее высокочастотных вхождений, который затем использовать и при сжатии, и при распаковке.

При этом коэффициент сжатия увеличивается от 10-15% на текстах до 50% на однообразных наборах строк, как у нас. А скорость сжатия даже несколько увеличивается при размере словаря порядка 16 килобайт. Это, конечно, уже не приведёт к такому впечатляющему результату, но всё равно будет приятно и полезно.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru