Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье. Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно. Но это очень небольшая часть логики обновления сложного продукта.
Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться). Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
Ээ, в чем проблема в алгоритме бинарного поиска, какие там баги изобретатель отыскивал? Может, простую идею поиска в отсортированном массиве спутали с чем-то еще?
Лучше тогда брать не саги (особенно в реализации из этой статьи), а тот же Temporal или подобные подходы. Какие-то я даже рассказывал в https://www.youtube.com/watch?v=0_ziFXXEW_M
Ну, кстати, для межсервисного взаимодействия часто достаточно не саг, а "пробуем дожать, если не получилось, просим разобраться оператора". В нормальной системе, где сервисы не падают каждый день на час, ситуация "не получилось дожать" крайне редкая и ручной разбор проблем не вызывает проблем и не требует затрат. Да, есть отдельные бизнес-сценарии, где такой подход не проходит и там приходится придумывать что-то еще. Но таких сценариев на удивление мало.
Я нигде не предлагал поставить Cadence или Temporal, я спрашиваю только про использование подхода Cadence к реализации workflow, гораздо более удобный и универсальный, нежели показаные в статье саги. Если уж делать свое решение - то почему бы не взять более удачные подходы и идеи?
Ну и "транзакционность в распределенной системе" никак не связана с наличием или отсутствием компенсаций. В любом случае саги не дают ACID (нет изоляции и атомарности), саги обеспечивают только eventual consistency, которую можно получить разными способами, отнюдь не только компенсациями к каждому шагу.
А почему использовали такой подход, а не подход Cadence/Temporal? Сценарии при этом получаются гораздо более удобные и понятные и не нужно думать лишний раз о компенсациях (которые вообще не очень обязательны в сагах и сильно усложняют использование, особенно если в компенсации случилась ошибка).
Не совсем корректно говорить, что в Kafka нет подтверждения доставки. Как раз гарантии доставки в Кафка есть, сообщение будет доставлено до consumer (если таковой вообще существует). Нет гарантии обработки, но их нет и в RabbitMQ и, насколько знаю, в NATS.
Возможно, стоило бы еще и сказать про реальную призводительность и надежность, где Kafka много лучше и RabbitMQ и NATS.
Гарантий доставки exactly once не существует. В Kafka так называется автоматическая дедупликация между producer и broker, но фактически consumer может читать данные много раз. В NATS, подозреваю, так же (так как exactly once физически нереализуемо в распределенных систем).
Ну и, насколько я понимаю, в таблице 3 млн. событий в секунду для NATS указано для режима без persistance, что делает эти числа бесполезными.
P.S. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач. И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов. Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.
Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Ну, если уж совсем занудствовать, то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно. То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
А можешь пояснить, что именно "академично"? Все-таки и ТРИЗ и Щедровицкий - это не про содержание доклада, а про "внеклассное чтение", про источники вдохновения для решения конкретных проблем. Ну и у меня в голове сложно сочетается "академично", "Щедровицкий" и "по поверхности". Кажется, что какие-то из слов тут лишние.
Я, скорее, хотел показать, что автор статьей не совсем понял тот код, который комментирует. Иначе не сказал бы про O(n) для HashMap. Впрочем, статья изначально бесполезная.
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье.
Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
Ну, во многих реальных ситуациях, увы, можно сделать только массогабаритный макет.
Впрочем, обычно его и достаточно )
Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно.
Но это очень небольшая часть логики обновления сложного продукта.
Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться).
Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
Ээ, в чем проблема в алгоритме бинарного поиска, какие там баги изобретатель отыскивал? Может, простую идею поиска в отсортированном массиве спутали с чем-то еще?
Ну, понятие "хайлоад" сейчас довольно расплывчатое. 50k rps - может быть и очень мало и очень много, смотря какие запросы.
Лучше тогда брать не саги (особенно в реализации из этой статьи), а тот же Temporal или подобные подходы. Какие-то я даже рассказывал в https://www.youtube.com/watch?v=0_ziFXXEW_M
Ну, кстати, для межсервисного взаимодействия часто достаточно не саг, а "пробуем дожать, если не получилось, просим разобраться оператора". В нормальной системе, где сервисы не падают каждый день на час, ситуация "не получилось дожать" крайне редкая и ручной разбор проблем не вызывает проблем и не требует затрат.
Да, есть отдельные бизнес-сценарии, где такой подход не проходит и там приходится придумывать что-то еще. Но таких сценариев на удивление мало.
Я нигде не предлагал поставить Cadence или Temporal, я спрашиваю только про использование подхода Cadence к реализации workflow, гораздо более удобный и универсальный, нежели показаные в статье саги.
Если уж делать свое решение - то почему бы не взять более удачные подходы и идеи?
Ну и "транзакционность в распределенной системе" никак не связана с наличием или отсутствием компенсаций. В любом случае саги не дают ACID (нет изоляции и атомарности), саги обеспечивают только eventual consistency, которую можно получить разными способами, отнюдь не только компенсациями к каждому шагу.
А почему использовали такой подход, а не подход Cadence/Temporal? Сценарии при этом получаются гораздо более удобные и понятные и не нужно думать лишний раз о компенсациях (которые вообще не очень обязательны в сагах и сильно усложняют использование, особенно если в компенсации случилась ошибка).
Не совсем корректно говорить, что в Kafka нет подтверждения доставки. Как раз гарантии доставки в Кафка есть, сообщение будет доставлено до consumer (если таковой вообще существует). Нет гарантии обработки, но их нет и в RabbitMQ и, насколько знаю, в NATS.
Возможно, стоило бы еще и сказать про реальную призводительность и надежность, где Kafka много лучше и RabbitMQ и NATS.
Гарантий доставки exactly once не существует. В Kafka так называется автоматическая дедупликация между producer и broker, но фактически consumer может читать данные много раз. В NATS, подозреваю, так же (так как exactly once физически нереализуемо в распределенных систем).
Ну и, насколько я понимаю, в таблице 3 млн. событий в секунду для NATS указано для режима без persistance, что делает эти числа бесполезными.
P.S. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач.
И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов.
Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.
Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Хм, это плохая задача, так как приучает к копипасте вместо нормальной разработки (воткнуть генерацию метрик прямо в фреймворк).
О, а что за история про самый копируемый код?
Ну, если уж совсем занудствовать,
то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно.
То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
А можешь пояснить, что именно "академично"? Все-таки и ТРИЗ и Щедровицкий - это не про содержание доклада, а про "внеклассное чтение", про источники вдохновения для решения конкретных проблем.
Ну и у меня в голове сложно сочетается "академично", "Щедровицкий" и "по поверхности". Кажется, что какие-то из слов тут лишние.
Я, скорее, хотел показать, что автор статьей не совсем понял тот код, который комментирует. Иначе не сказал бы про O(n) для HashMap.
Впрочем, статья изначально бесполезная.