Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны. Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее. Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику. Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД. Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно. Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких. Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.
Согласно RFC 7519, JWT могут шифроваться. Если хочется скрыть информацию в токене, то кто мешает использовать стандартное для этого решение с зашифрованным payload.
Вообще, в статье путается управление сессиями, стандарты аутентификации и формат упаковки данных. JWT легко может храниться в куке и содержать sessionId и еще какие-то параметры, как стандартный и удобный контейнер.
А вот стоит ли для авторизации приложения в браузере использовать OAuth2 или что-то другое - совершенно отдельный вопрос. На мой взгляд, для авторизации и аутентификации можно и нужно строить схемы из нескольких токенов, часть из которых хранится в http-only куках на специальном поддомене. Но это уже про довольно сложную схему из трех токенов, частой смены access-token (нужной для обнаружения компрометации, а не для защиты) и не самую тривиальную логик проверки. Но зато это горадо надежнее хранения sessionId
Ага. Я долго смотреть на Zf, но понял, что без грипа он крайне неудобен, а с накладным грипом становится слишком громоздким и лучше уже брать что-то постарше. Так и сижу со своим D750, ничего заметно лучше пока нет (
Странно, что люди используют REST для создания API и ссылаются на Филдинга, который явно писал, что REST - это подход для гипермедиа систем, а не для проектирования API. Собственно, в большей части проектов выбор REST (уровня зрелости 2 и выше) является архитектурной ошибкой. Тем более для взаимодействия внутри системы.
Забавно, что автор при этом не знает азов скрама, хотя и рассуждает о работе скрам-мастера. Про аджайл, кстати, тоже не знает, хотя и говорит о каких-то аджайл-метриках.
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для 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. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач. И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов. Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.
Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны.
Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее.
Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику.
Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД.
Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно.
Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких.
Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.
Согласно RFC 7519, JWT могут шифроваться. Если хочется скрыть информацию в токене, то кто мешает использовать стандартное для этого решение с зашифрованным payload.
Вообще, в статье путается управление сессиями, стандарты аутентификации и формат упаковки данных.
JWT легко может храниться в куке и содержать sessionId и еще какие-то параметры, как стандартный и удобный контейнер.
А вот стоит ли для авторизации приложения в браузере использовать OAuth2 или что-то другое - совершенно отдельный вопрос. На мой взгляд, для авторизации и аутентификации можно и нужно строить схемы из нескольких токенов, часть из которых хранится в http-only куках на специальном поддомене. Но это уже про довольно сложную схему из трех токенов, частой смены access-token (нужной для обнаружения компрометации, а не для защиты) и не самую тривиальную логик проверки. Но зато это горадо надежнее хранения sessionId
Так куча вариантов. RPC в виде json-over-http (например, в стиле REST Level 1 по Ричардсону), GRPC (если есть подходящий мэш).
Ага. Я долго смотреть на Zf, но понял, что без грипа он крайне неудобен, а с накладным грипом становится слишком громоздким и лучше уже брать что-то постарше.
Так и сижу со своим D750, ничего заметно лучше пока нет (
Странно, что люди используют REST для создания API и ссылаются на Филдинга, который явно писал, что REST - это подход для гипермедиа систем, а не для проектирования API.
Собственно, в большей части проектов выбор REST (уровня зрелости 2 и выше) является архитектурной ошибкой. Тем более для взаимодействия внутри системы.
Забавно, что автор при этом не знает азов скрама, хотя и рассуждает о работе скрам-мастера.
Про аджайл, кстати, тоже не знает, хотя и говорит о каких-то аджайл-метриках.
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для 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. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач.
И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов.
Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.