Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

В продолжение темы я задумал написать такую статью, которую мне самому хотелось бы прочитать перед тем, как мы начали миграцию на Temporal. Всё изложенное проверено на практике: процессинг заказов Яндекс Еды уже почти год работает целиком на Temporal. Об общих принципах работы с Temporal я уже рассказал в предыдущей статье, а здесь я поделюсь полезными советами, выведенными из нашего опыта.

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

Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы Temporal: почему мы его выбрали как основу нового процессинга, в чём его сильные стороны и как изменилась наша жизнь после перехода. 

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

Всем привет, меня зовут Миша, и я разрабатываю платформу Яндекс Еды. Первые компоненты были написаны почти 10 лет назад (когда Еда ещё была стартапом Foodfox), и у нас накопилось много кода, который просто хорошо работает, а иногда даже «работает — не трогай». Но в процессе развития и устоявшиеся части системы нужно трогать, про что мои коллеги уже писали — как мы повышали версию PHP, пилили монолит и снимали нагрузку с БД. 

Наконец настал черёд рассказать про процессинг заказов доставки еды из кафе и ресторанов (а также продуктов из магазинов и многого другого). За годы эволюционного развития он значительно разросся, что стало заметно затруднять дальнейшее развитие — например, изменения, связанные с выходом на новые рынки, — а также влиять на надёжность. 

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

Как разработчик я ежедневно сталкиваюсь с большим количеством данных, которые нужны для принятия каких‑либо решений. Логи, конфиги, данные профилирования, аналитические выгрузки из БД и даже сведения о том, когда был написан данный код — это всё данные. Иногда бывает достаточно посмотреть глазами, и картина станет ясной. Но чем больше данных, тем меньше помогает «метод пристального взгляда», и тем нужнее какие‑то инструменты анализа.

Иногда можно собрать нужную информацию, просто скомбинировав несколько линуксовых команд пайпом (cat data.log | grep … | awk … | sort | uniq -c | sort -r | head), иногда пригодятся электронные таблицы, иногда проще написать небольшую программку для анализа данных. Но когда я освоился с языком R и его экосистемой, то всё это стало ненужным.

Однажды много лет назад один немолодой профессор задал мне задачку о перестановке стрелок часов. Точной формулировки за давностию лет я не помню, но поиск в интернете привёл меня к «Занимательной алгебре» Я. И. Перельмана, которая была впервые опубликована в 1933 году:

Возьмём положение стрелок в 12 часов. Если бы в этом положении большая и малая стрелки обменялись местами, они дали бы всё же правильные показания. Но в другие моменты, — например, в 6 часов, — взаимный обмен стрелок привёл бы к абсурду, к положению, какого на правильно идущих часах быть не может: минутная стрелка не может стоять на 6, когда часовая показывает 12. Возникает вопрос: когда и как часто стрелки часов занимают такие положения, что замена одной другою дает новое положение, тоже возможное на правильных часах?

Что любопытно, эта формулировка восходит к книге Александра Мошковского «Альберт Эйнштейн: беседы с Эйнштейном о теории относительности и общей системе мира», опубликованной в 1921 году на немецком языке, и уже в следующем году (!) переведённой на русский язык (и, судя по каталогу РГБ, с тех пор её и не переиздавали; доступен английский перевод).

Fail2ban — утилита чрезвычайно полезная во многих случаях. Думаю, многие используют её для того, чтобы в автоматическом режиме блокировать особенно назойливых «посетителей». К сожалению, если входящий поток становится слишком большим, fail2ban теряет все свои полезные свойства, потому что разбор лога безнадёжно отстаёт от реальности.

Лог nginx из 100 тысяч строчек fail2ban при самых простых настройках разбирает порядка 45 секунд. Нехитрыми манипуляциями его можно ускорить раз в 6, но этого оказалось недостаточно. Наивная реализация на аналогичного фильтра на Rust уже обеспечила требуемую производительность, но если уж взялся за оптимизацию, то остановиться трудно.

* только необходимую часть функционала

Зачем нужен статический анализ кода, кажется, никому объяснять сегодня уже не нужно. Но одно дело — поддерживать код «чистым» с первого коммита, и совсем другое — встраивать новый инструмент в проект, который за несколько лет успел разрастись и пережить несколько итераций глобального рефакторинга. Мы работаем с большим количеством плохо документированных источников данных, а статический анализ кода помогает учитывать самые разные граничные случаи.

И ещё один момент: Rusprofile почти целиком написан на PHP, языке со слабой динамической типизацией. Статический анализ кода на PHP уже несколько лет набирает популярность, сказывается здесь и движение самого языка в сторону более строгой типизации. Но мы опасались, что без предварительной подготовки кода пользы от него мало. Аннотировать типами весь код в реальных бизнес-условиях тоже нереально. Сильно медлить с внедрением в рабочий процесс тоже нельзя: чем дальше, тем сложнее что-то кардинально улучшать. Поэтому нужно было оперативно запускаться, чем-то пожертвовав.

Сейчас множество всяких наборов данных в разных областях выкладывают под лицензией OpenData, то есть скачивай и используй (но не искажай). Но, конечно же, раз эти данные открытые, то все их создают как им угодно. Отсюда — множество проблем при обработке, начиная с получения и заканчивая интерпретацией. Мы работаем с открытыми данными последние пять лет, и за весь опыт работы накопилось немало интересных случаев. Под катом — основные проблемы и примеры ребусов, путешествий во времени и прочей чертовщины, с которой мы ежедневно боремся.

Сравнение с популярными программами