А какие доказательства ожидаются? В тексте патента вряд ли будет ссылка на ТРИЗ (с чего бы?). При этом даже я общался с кучей знакомых физиков, которые в начале 200х в Питере делали сложные изобретения на запад и ТРИЗ там был одним из основных инструментов. Да и статья в Forbes про использование TRIZ в Samsung выглядит вполне убедительной. Собственно, набор инструментария в ТРИЗ достаточно простой, освоить его не сложно, после чего многие решения можно считать тризовскими - что инженерные, что разработческие, что управленческие.
Ну, это уже давно не так, сейчас больше двух собседований не бывает. Но процессы найма вообще меняются сложнее всего, увы. А по рабочим местам - нормальная современная компания, ноутбуки, рабочие станции, офис или удаленка и так далее. Много меньше проблем, чем, например, в Яндексе лет 10 назад (про сегодняшний просто не знаю). Некоторые вещи сделаны очень хорошо, некоторые еще нет.
Если я правильно понял amarao, то его смущает использование bad там, где оно не очень к месту. В оригинале действительно просто code smel, без прилагательных - и это правильно. Мне тоже стоило бы не добавлять характеристик, попахивает - и ладно. В конце концов у smell без прилагательных уже достаточно отрицательных коннотаций.
Вот да, это уровень дизайна для джуниора. При этом вообще не понятно, зачем у джуна спрашивать системный дизайн. Но судя и по другим отрывкам из книги, использовать советы оттуда для реального проектирования категорически не рекомендуется. Полезны ли эти советы для интервью - не знаю, у меня бы разработчик с такими ответами интервью не прошел бы.
Я бы искренне посоветовал подумать над общим решением, это же не только для онбординга нужно, а для тех же платежей, да и вообще для множества разных операций (почти для всех, на самом-то деле).
Я скорее про число шагов, которое нужно выполнить в секунду, про скорость восстановления после падения воркера, про число одновременных процессов и т.п. Это те НФТ, которые больше всего влияют на подобные решения.
Когда из одного сценария (саги) нужно вызвать другую, а потом продолжить работу. Частый сценарий, который через простую последовательность шагов уже не реализуется.
Я не понял, как и когда другие воркеры поймут, что конкретные саги "зависли". Только по таймеру?
Насколько я понимаю, нет, ваше решение еще очень далеко от temporal. У вас поддерживается только линейная фиксированная последовательность шагов, а не любые сценарии; нет никакой поддержки версионирования сценариев; нет user-actions; весь ресайленс нужно реализовывать практически вручную; да и вообще, фактически, все нужно делать вручную, нет какого-то удобного фреймворка.
Возможно, я не прав, но решение смотрится не как "мы сделали оркестратор бизнес-транзакций на гошечке", а как "мы реализовали не совсем сагу для парочки конкретных кейсов". Ну или из статьи не видно, какая функциональность у вашего решения есть (зато хорошо заметно, какие проблемы у этого решения будут).
Потому и говорю, что вы еще в начале большого пути )
Конечные автоматы все-таки сложно программировать, особенно когда там сложные циклы внутри, я потому и перешел сначала на акторы, а потом на workflow. Ну а в Озоне, подозреваю, еще в самом начале пути )
Ну, даже если не тащить temporal, то можно было бы сделать свое решение в духе temporal.io, там идеология (не реализация) гораздо удобнее классических саг. Ну или вообще сделать оркестратор как библиотеку, в стиле Haydn4k. Впрочем, не факт, что на go вообще можно написать удобный оркестратор.
Кстати, а какие требования у вас по производительности оркестраций? И по взаимодействию разных сценариев? И не совсем понятно, что происходит при падении воркера, как можно понять, что нужно повторить какие-то операции?
Когда я последний раз смотрел (года четыре назад) мне не хватало разных вариантов обработки ошибки (заблокировать топик, отложить топик, переложить событие в конец топика и так далее - там много вариантов бывает) и смущала схема с одной таблицей. Кстати, интересно, решение от ЯДа когда-то проросло из нашего с Яшей Сироткиным кода или независимо. Но за эти годы оно, конечно, сильно выросло, да и мы делали под Oracle.
А можно поподробнее, в чем именно задача? Как сделать шедулер чисто на kafka, без других хранилищ вообще? Я могу придумать какие-нибудь хитрые механизмы, но они будут довольно странными.
Это два разных доклада. Два года назад я рассказывал про предыдущий проект, там как раз PG и персистентные акторы, а эта статья и доклад на HL2021 - про следующий проект, который я делал. Другой контекст, другие требования, другой я - и, как следствие, другой стек и другие арх.решения. Общего - только домен. Ну и для меня главное в докладе - не про технические детали, а скорее про то, как подходить к архитектуре.
Ну, не всегда нужно уметь масштабировать (да и далеко не все можно горизонтально масштабировать на kafka - то же число партиций). На PG вполне нормально получить несколько тысяч message-per-second на недорогом железе и при этом получить хорошие гарантии и избежать необходимости в CDC и прочих тонкостях взаимодействий СУБД и очередей. Как всегда, все упирается в НФТ
Ну, конкретно решение от Яндекс.Денег меня не всегда устраивает по возможностям, я бы скорее свое сделал (благо там делать особо нечего, два простых запроса и несколько сотен строк кода). Ну и я как-то подробно рассказывал, как делать очереди на Pg или другой БД с skip locked.
Зависит, конечно, от миграций. Если речь идет про "изменили структуру value, нужно избавиться от данных со старой версии структуры" (большинство миграций именно таких), то тут нужно протестировать логику миграции отдельной записи, это достаточно просто (остальное сделает уже migration tool). Для "добавить индекс" есть уже один раз написанный код, там тоже все довольно просто. А вот если какие-то сложные преобразования (объединение "таблиц", изменение связей), то для каждого сценария придумываем набор тестов на разных уровнях. Если честно, не вижу разницы между миграциями на FoundationDB и на PostgreSQL, в любом случае это же будет не update Payments set newPrice = price*2, а обновление небольшими блоками с привязкой к версии структуры.
Они и прошлую модель где-то на полгода протормозили, так что может и выйдет.
Но пока да, платить стремно...
А какие доказательства ожидаются? В тексте патента вряд ли будет ссылка на ТРИЗ (с чего бы?). При этом даже я общался с кучей знакомых физиков, которые в начале 200х в Питере делали сложные изобретения на запад и ТРИЗ там был одним из основных инструментов. Да и статья в Forbes про использование TRIZ в Samsung выглядит вполне убедительной.
Собственно, набор инструментария в ТРИЗ достаточно простой, освоить его не сложно, после чего многие решения можно считать тризовскими - что инженерные, что разработческие, что управленческие.
Но если погуглить пару минут, то можно найти какие-то материалы за пределами РФ:
https://www.researchgate.net/publication/269758536_Case_study_of_SAMSUNG_TFT-LCD_Technology_Innovation_using_TRIZ_method
https://ieeexplore.ieee.org/document/1308166
https://www.osaka-gu.ac.jp/php/nakagawa/TRIZ/eTRIZ/epapers/e2009Papers/eCheongTRIZSymp2008/09eP-Cheong-TRIZSymp2008-090709.pdf
Оценка их адекватности - отдельная и нетривиальная задача.
Ну, это уже давно не так, сейчас больше двух собседований не бывает. Но процессы найма вообще меняются сложнее всего, увы.
А по рабочим местам - нормальная современная компания, ноутбуки, рабочие станции, офис или удаленка и так далее. Много меньше проблем, чем, например, в Яндексе лет 10 назад (про сегодняшний просто не знаю). Некоторые вещи сделаны очень хорошо, некоторые еще нет.
Если я правильно понял amarao, то его смущает использование bad там, где оно не очень к месту. В оригинале действительно просто code smel, без прилагательных - и это правильно. Мне тоже стоило бы не добавлять характеристик, попахивает - и ладно. В конце концов у smell без прилагательных уже достаточно отрицательных коннотаций.
Хм, да, может быть заменить на process smell было бы правильнее. Я подумаю еще и, может быть, заменю.
Вот да, это уровень дизайна для джуниора. При этом вообще не понятно, зачем у джуна спрашивать системный дизайн.
Но судя и по другим отрывкам из книги, использовать советы оттуда для реального проектирования категорически не рекомендуется. Полезны ли эти советы для интервью - не знаю, у меня бы разработчик с такими ответами интервью не прошел бы.
Я бы искренне посоветовал подумать над общим решением, это же не только для онбординга нужно, а для тех же платежей, да и вообще для множества разных операций (почти для всех, на самом-то деле).
Кстати, а в Озоне разве нет общего стандартного решения для оркестрации? Вроде бы микросервисы у вас давно уже?
Я скорее про число шагов, которое нужно выполнить в секунду, про скорость восстановления после падения воркера, про число одновременных процессов и т.п. Это те НФТ, которые больше всего влияют на подобные решения.
Когда из одного сценария (саги) нужно вызвать другую, а потом продолжить работу. Частый сценарий, который через простую последовательность шагов уже не реализуется.
Я не понял, как и когда другие воркеры поймут, что конкретные саги "зависли". Только по таймеру?
Насколько я понимаю, нет, ваше решение еще очень далеко от temporal. У вас поддерживается только линейная фиксированная последовательность шагов, а не любые сценарии; нет никакой поддержки версионирования сценариев; нет user-actions; весь ресайленс нужно реализовывать практически вручную; да и вообще, фактически, все нужно делать вручную, нет какого-то удобного фреймворка.
Возможно, я не прав, но решение смотрится не как "мы сделали оркестратор бизнес-транзакций на гошечке", а как "мы реализовали не совсем сагу для парочки конкретных кейсов". Ну или из статьи не видно, какая функциональность у вашего решения есть (зато хорошо заметно, какие проблемы у этого решения будут).
Потому и говорю, что вы еще в начале большого пути )
Еще немножко материалов по теме:
1) Про реализацию акторов поверх PG : https://pgconf.ru/2017/93989
2) Про workflow: https://habr.com/ru/company/oleg-bunin/blog/588488/
Конечные автоматы все-таки сложно программировать, особенно когда там сложные циклы внутри, я потому и перешел сначала на акторы, а потом на workflow.
Ну а в Озоне, подозреваю, еще в самом начале пути )
Ну, даже если не тащить temporal, то можно было бы сделать свое решение в духе temporal.io, там идеология (не реализация) гораздо удобнее классических саг.
Ну или вообще сделать оркестратор как библиотеку, в стиле Haydn4k. Впрочем, не факт, что на go вообще можно написать удобный оркестратор.
Кстати, а какие требования у вас по производительности оркестраций? И по взаимодействию разных сценариев? И не совсем понятно, что происходит при падении воркера, как можно понять, что нужно повторить какие-то операции?
А, это конечно, тут сложно спорить.
Спасибо. Я вечно теряю эти ссылки.
Когда я последний раз смотрел (года четыре назад) мне не хватало разных вариантов обработки ошибки (заблокировать топик, отложить топик, переложить событие в конец топика и так далее - там много вариантов бывает) и смущала схема с одной таблицей.
Кстати, интересно, решение от ЯДа когда-то проросло из нашего с Яшей Сироткиным кода или независимо. Но за эти годы оно, конечно, сильно выросло, да и мы делали под Oracle.
А можно поподробнее, в чем именно задача? Как сделать шедулер чисто на kafka, без других хранилищ вообще? Я могу придумать какие-нибудь хитрые механизмы, но они будут довольно странными.
Это два разных доклада.
Два года назад я рассказывал про предыдущий проект, там как раз PG и персистентные акторы, а эта статья и доклад на HL2021 - про следующий проект, который я делал. Другой контекст, другие требования, другой я - и, как следствие, другой стек и другие арх.решения. Общего - только домен.
Ну и для меня главное в докладе - не про технические детали, а скорее про то, как подходить к архитектуре.
Ну, не всегда нужно уметь масштабировать (да и далеко не все можно горизонтально масштабировать на kafka - то же число партиций).
На PG вполне нормально получить несколько тысяч message-per-second на недорогом железе и при этом получить хорошие гарантии и избежать необходимости в CDC и прочих тонкостях взаимодействий СУБД и очередей.
Как всегда, все упирается в НФТ
Ну, конкретно решение от Яндекс.Денег меня не всегда устраивает по возможностям, я бы скорее свое сделал (благо там делать особо нечего, два простых запроса и несколько сотен строк кода). Ну и я как-то подробно рассказывал, как делать очереди на Pg или другой БД с skip locked.
Зависит, конечно, от миграций.
Если речь идет про "изменили структуру value, нужно избавиться от данных со старой версии структуры" (большинство миграций именно таких), то тут нужно протестировать логику миграции отдельной записи, это достаточно просто (остальное сделает уже migration tool).
Для "добавить индекс" есть уже один раз написанный код, там тоже все довольно просто.
А вот если какие-то сложные преобразования (объединение "таблиц", изменение связей), то для каждого сценария придумываем набор тестов на разных уровнях.
Если честно, не вижу разницы между миграциями на FoundationDB и на PostgreSQL, в любом случае это же будет не update Payments set newPrice = price*2, а обновление небольшими блоками с привязкой к версии структуры.