Ну, у SO очень грамотная монолитная архитектура. Решение на микросервисах потребовало бы на порядок больше железа и раза в два больше сотрудников, еще и более дорогих - зачем это надо? МСА нужно довольно в редких случаях, к которым не относится большая часть проектов. Кстати, раньше поиск Яндекса был нефига не микросервисным )
Ну, отправку можно делать через TransactionOutbox, но это дорого. И при этом все равно именно транзакцию (с атомарностью, хотя бы, я уж не говорю про изоляцию) чисто на kafka сделать крайне сложно и это будет очень много сообщений. Так что лучше брать движки workflow типа Temporal и делать бизнес-транзакции на них.
Хм, а при чем тут монорепа? Взяли ветку, забрали туда мастер, прогнали тесты, смерджили - где тут может быть ошибка компиляции? Только в момент между "забрали мастер" и "смерджели", но та же фигня может быть и в мультирепе, никакой разницы.
Хм, а в чем тут проблема с CD? И с монорепой? Ну сломала команда что-нибудь - так это выяснится на тестах до мержа в монолит и до выкладки и даже до тестов уровня монолита. Еще и проверить быстрее.
Хм, кафка никак не решает проблемы распределенных транзакций, только добавляет еще проблем с транзакционностью отправки сообщений. Ну и бизнесу обычно как раз нужны гарантии выполнения бизнес-операций (хотя бы в конечном итоге), так как бизнес обычно думает в категориях как раз распределенных транзакций. Да, эти проблемы решаются, но 90% имеющихся решений ужасны, а оставшиеся 10% - дорогие в использовании и эксплуатации.
Практически - легко. Модули, библиотеки, ArchUnit - очень много разных инструментов для гарантий отсутствия неявных связей. И, собственно, так обычно и писали монолиты в приличных компаниях. Я видел огромные проекты на чистом SQL с жестко расписанными интерфейсами между разными модулями, так что дело только в качестве программистов.
Ну, EAV - это, скорее, антипаттерн для работы с БД. Реализацию кастомизации можно сделать и кучей других способов, не так роняющих производительность. От jsonb до просто SQL
Я все-таки не понял, откуда 300k rps нагрузки на этот сервис? Или каждый товар на странице ozon всегда приводит к запросу на сервис, т.е. если из поиска показывается, например, 100 товаров, то это дает 100 запросов? Впрочем, откуда 3000 страниц поиска в секунду в среднем - тоже не очень понятно (да и обычно там гораздо меньше 100 товаров). Хм, а улучшение поиска как метод борьбы с нагрузкой не рассматривалcя? На порядок-два количество просмотров точно можно уменьшить.
Хм, гораздо больше шансов, что я уйду с Озона на ЯМ просто потому, что Озон где-то потерял мои деньги (стандартная ситуация для микросервисов) или вообще плохо оптимизировал поиск (так как увлекся микросервисами и все ресурсы потратил на написание своего драйвера к кафке, а не на реализацию нормального продукта). А так как микросервисы, в среднем, менее надежны, нежели монолит - то и шансов у "микросервисного" Озона упасть гораздо больше, чем у "монолитного".
Микросервисы вообще не про надежность, не про гибкость и не про масштабируемость.
Эээ, и при чем тут микросервисы? Если разработчики могут писать микросервисы (со всеми их сложностями), то написать модульный монолит с нормальным архконтролем для них не проблема.
Нет никаких проблем написать монолит с нормальным тестированием, нормальной выкладкой и нормальной внутренней логикой - и это гораздо проще, нежели сделать аналогичное решение на микросервисах.
Микросервисы нужны - но довольно редко и совсем не описанным причинам. И бизнес тут вообще не при чем.
Но микросервисы, в среднем, усложняют и удлиняют процесс доставки фич, а не наоборот. Микросервисные решения сложнее разрабатывать, сложнее модифицировать, сложнее выкладывать, сложнее тестировать - все это очень печально сказывается на скорости поставки. В 90% случаев выбор МСА - это ошибка архитектора.
Но микросервисы вообще никак не связаны с бизнесом, никаким образом. То, что написано в статье - произвольный набор слов, не связанный ни с микросервисами, ни с монолитами.
После прочтения статьи сложилось устойчивое ощущение, что автор не разбирается ни в REST API, ни в GraphQL. Плюсы и минусы к реальности не имеют никакого отношения, про json-rpc автор, похоже, вообще не слышал, про проблемы мутаций составных объектов даже не догадывается, в каждом абзаце - фактическая ошибка. Для технического писателя это нормально, но зачем технический писатель вообще пишет подобные статьи самостоятельно? Интересно, а в МТС догадываются, как именно подобные статьи влияют на бренд компании? Я бы побоялся даже как пользователь связываться с компанией с таким уровнем публичных статей, про работать я даже не говорю....
Ну, у SO очень грамотная монолитная архитектура. Решение на микросервисах потребовало бы на порядок больше железа и раза в два больше сотрудников, еще и более дорогих - зачем это надо?
МСА нужно довольно в редких случаях, к которым не относится большая часть проектов. Кстати, раньше поиск Яндекса был нефига не микросервисным )
Это же ирония, да? А то в тексте не очень точно считывается )
А быстро - это сколько? У меня монолит стартовал за одну секунду в 2012 году, это достаточно быстро?
Java, но никакого спринга, конечно.
Ну, отправку можно делать через TransactionOutbox, но это дорого.
И при этом все равно именно транзакцию (с атомарностью, хотя бы, я уж не говорю про изоляцию) чисто на kafka сделать крайне сложно и это будет очень много сообщений.
Так что лучше брать движки workflow типа Temporal и делать бизнес-транзакции на них.
Хм, а при чем тут монорепа?
Взяли ветку, забрали туда мастер, прогнали тесты, смерджили - где тут может быть ошибка компиляции? Только в момент между "забрали мастер" и "смерджели", но та же фигня может быть и в мультирепе, никакой разницы.
Хм, а в чем тут проблема с CD? И с монорепой?
Ну сломала команда что-нибудь - так это выяснится на тестах до мержа в монолит и до выкладки и даже до тестов уровня монолита. Еще и проверить быстрее.
Хм, кафка никак не решает проблемы распределенных транзакций, только добавляет еще проблем с транзакционностью отправки сообщений. Ну и бизнесу обычно как раз нужны гарантии выполнения бизнес-операций (хотя бы в конечном итоге), так как бизнес обычно думает в категориях как раз распределенных транзакций.
Да, эти проблемы решаются, но 90% имеющихся решений ужасны, а оставшиеся 10% - дорогие в использовании и эксплуатации.
Практически - легко.
Модули, библиотеки, ArchUnit - очень много разных инструментов для гарантий отсутствия неявных связей. И, собственно, так обычно и писали монолиты в приличных компаниях. Я видел огромные проекты на чистом SQL с жестко расписанными интерфейсами между разными модулями, так что дело только в качестве программистов.
Ну, EAV - это, скорее, антипаттерн для работы с БД.
Реализацию кастомизации можно сделать и кучей других способов, не так роняющих производительность.
От jsonb до просто SQL
Jooq все-таки уже добавляет лишнюю абстракцию и еще один "язык написания запросов".
SpringJDBCTemplate, на мой взгляд, дает лучшую абстракцию.
А что еще за языки и платформы?
А почему на уровне file.d не происходит маскировка найденных секретов?
Раз уж выяснили, что в логи попадает что-то не то, почему бы сразу не спрятать?
Да ладно, в протобафе есть Any и несовместимость между версиями, это еще хуже.
Я все-таки не понял, откуда 300k rps нагрузки на этот сервис?
Или каждый товар на странице ozon всегда приводит к запросу на сервис, т.е. если из поиска показывается, например, 100 товаров, то это дает 100 запросов?
Впрочем, откуда 3000 страниц поиска в секунду в среднем - тоже не очень понятно (да и обычно там гораздо меньше 100 товаров).
Хм, а улучшение поиска как метод борьбы с нагрузкой не рассматривалcя? На порядок-два количество просмотров точно можно уменьшить.
Хм, гораздо больше шансов, что я уйду с Озона на ЯМ просто потому, что Озон где-то потерял мои деньги (стандартная ситуация для микросервисов) или вообще плохо оптимизировал поиск (так как увлекся микросервисами и все ресурсы потратил на написание своего драйвера к кафке, а не на реализацию нормального продукта).
А так как микросервисы, в среднем, менее надежны, нежели монолит - то и шансов у "микросервисного" Озона упасть гораздо больше, чем у "монолитного".
Микросервисы вообще не про надежность, не про гибкость и не про масштабируемость.
Эээ, и при чем тут микросервисы?
Если разработчики могут писать микросервисы (со всеми их сложностями), то написать модульный монолит с нормальным архконтролем для них не проблема.
Нет никаких проблем написать монолит с нормальным тестированием, нормальной выкладкой и нормальной внутренней логикой - и это гораздо проще, нежели сделать аналогичное решение на микросервисах.
Микросервисы нужны - но довольно редко и совсем не описанным причинам. И бизнес тут вообще не при чем.
Но микросервисы, в среднем, усложняют и удлиняют процесс доставки фич, а не наоборот.
Микросервисные решения сложнее разрабатывать, сложнее модифицировать, сложнее выкладывать, сложнее тестировать - все это очень печально сказывается на скорости поставки.
В 90% случаев выбор МСА - это ошибка архитектора.
Но микросервисы вообще никак не связаны с бизнесом, никаким образом.
То, что написано в статье - произвольный набор слов, не связанный ни с микросервисами, ни с монолитами.
После прочтения статьи сложилось устойчивое ощущение, что автор не разбирается ни в REST API, ни в GraphQL. Плюсы и минусы к реальности не имеют никакого отношения, про json-rpc автор, похоже, вообще не слышал, про проблемы мутаций составных объектов даже не догадывается, в каждом абзаце - фактическая ошибка.
Для технического писателя это нормально, но зачем технический писатель вообще пишет подобные статьи самостоятельно?
Интересно, а в МТС догадываются, как именно подобные статьи влияют на бренд компании? Я бы побоялся даже как пользователь связываться с компанией с таким уровнем публичных статей, про работать я даже не говорю....
А что такое fluent? Смотреть кино и C2 не всегда хватает. Заказать пиво в баре или поговорить про работу - и B1 хватает.