Только архитектурный стиль или независимость БД никак не связаны с низкой связностью компонент. Связность зависит от анализа, а не от монолита или SOA.
Вот да, там очень хорошо показана бесполезность термина "микросервис" ) Я предпочитаю использовать формулировки Фаулера (как одного из основных популяризаторов), так как у Ньюмана в разных книжках используются разные формулировки )
Интересно, почему автор считает, что он разбирается в микросервисах? Пока лишь видно, что плохо разбирается в RPC, REST, SOAP, HTTP, виртуализации и в паттернах распределенных систем.
Хм, писать фронт в 2025ом на ReactNative и Swift? Проще уж взять один общий Flutter и уменьшить стоимость разработки фронта процентов на 30, еще и сразу получив рынок андроида.
Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис. Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.
Хм, и в чем проблема? Даже приложение на спринге упаковывают в 64MB памяти и это без GraalVM. После появления модульности появилась возможность очень сильно уменьшать расходы на системные библиотеки, а в остальном все зависит от подхода к разработке. Да, обычно это нафиг никому не нужно, нет разницы между 64 или 128MB и задачи оптимизировать модули нет. Но никаких принципиальных проблем нет.
Ну, вообще очень давно JIT дает более оптимальный код, чем AOT, в чем проблема-то? Данных при выполнении больше, поэтому больше оптимизаций доступно. Да, в JIT сложно с глобальными оптимизациями, но их и в AOT мало кто делает (да и время компиляции взлетает неимоверно).
Понятно, что это не про всякий JIT, но JVMовский долго вылизовали и денег туда вбухано неимоверно.
Ну вот JIT - это оптимизации PGO, только выполняемые прямо во время исполнения и подстраивающиеся при изменении профиля. Ну и с некоторыми дополнительными фенечками, которые в статике сложно реализовать. А что так поздно PGO появился в GO? В GraalVM он еще с 19го года, как раз чтобы хоть как-то JIT догнать по производительности. Ну и не так давно в Hotspot тоже добавили профилирование JIT на старте (а в других-то JVMках оно было очень давно).
Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны. Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее. Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику. Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД. Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно. Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких. Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.
Хм, а как выглядело "свалить"? Один процесс, одно ядро, ограничение памяти - как остальные запросы-то страдали?
Есть куча возможностей ограничить ресурсы на одного клиента.
Это исключительно особенности настройки БД, не какой-то рокет-сайнс.
Ну и, заметим, шансов плохим запросом убить все сервисы, которые в нем участвуют (при каком-нибудь джойне, реализованном ручками на API GW) не меньше.
Хм, мультимастеров не существует )
Ну невозможны они теоретически.
Хм, почему БД ложиться? Одно соединение тормозит - и все.
А почему shared database - антипаттерн? Почему интеграция через БД - плохо, а интеграция через kafka - нет (хотя это та же самая интеграция через БД)?
Вообще, любые паттерны или антипаттерны не имеют смысла без описания граничных условий и ограничений.
Только архитектурный стиль или независимость БД никак не связаны с низкой связностью компонент.
Связность зависит от анализа, а не от монолита или SOA.
Вот да, там очень хорошо показана бесполезность термина "микросервис" )
Я предпочитаю использовать формулировки Фаулера (как одного из основных популяризаторов), так как у Ньюмана в разных книжках используются разные формулировки )
Интересно, почему автор считает, что он разбирается в микросервисах?
Пока лишь видно, что плохо разбирается в RPC, REST, SOAP, HTTP, виртуализации и в паттернах распределенных систем.
Хм, на рынке таких уже давно весьма много, в чем проблема?
Да и переучить с Swift или Kotlin не проблема.
Хм, писать фронт в 2025ом на ReactNative и Swift? Проще уж взять один общий Flutter и уменьшить стоимость разработки фронта процентов на 30, еще и сразу получив рынок андроида.
Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис.
Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.
Хм, и в чем проблема? Даже приложение на спринге упаковывают в 64MB памяти и это без GraalVM. После появления модульности появилась возможность очень сильно уменьшать расходы на системные библиотеки, а в остальном все зависит от подхода к разработке.
Да, обычно это нафиг никому не нужно, нет разницы между 64 или 128MB и задачи оптимизировать модули нет. Но никаких принципиальных проблем нет.
Ну, вообще очень давно JIT дает более оптимальный код, чем AOT, в чем проблема-то? Данных при выполнении больше, поэтому больше оптимизаций доступно. Да, в JIT сложно с глобальными оптимизациями, но их и в AOT мало кто делает (да и время компиляции взлетает неимоверно).
Понятно, что это не про всякий JIT, но JVMовский долго вылизовали и денег туда вбухано неимоверно.
Ну вот JIT - это оптимизации PGO, только выполняемые прямо во время исполнения и подстраивающиеся при изменении профиля. Ну и с некоторыми дополнительными фенечками, которые в статике сложно реализовать.
А что так поздно PGO появился в GO? В GraalVM он еще с 19го года, как раз чтобы хоть как-то JIT догнать по производительности.
Ну и не так давно в Hotspot тоже добавили профилирование JIT на старте (а в других-то JVMках оно было очень давно).
Полного актуального списка я за пять минут не нашел, можно посмотреть на https://advancedweb.hu/profile-based-optimization-techniques-in-the-jvm/
Но это для довольно старой версии JVM, с тех пор еще что-то добавили.
Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны.
Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее.
Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику.
Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД.
Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно.
Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких.
Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.