Ну, отправку можно делать через 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 автор, похоже, вообще не слышал, про проблемы мутаций составных объектов даже не догадывается, в каждом абзаце - фактическая ошибка. Для технического писателя это нормально, но зачем технический писатель вообще пишет подобные статьи самостоятельно? Интересно, а в МТС догадываются, как именно подобные статьи влияют на бренд компании? Я бы побоялся даже как пользователь связываться с компанией с таким уровнем публичных статей, про работать я даже не говорю....
Вообще во всех странах с богатой собственной культурой и не являющихся британскими колониями - не очень хорошо с английским языком. Китай, Япония, Франция (хотя казалось бы), Испания и так далее. Английским хорошо владеют в небольших странах, но это скорее про "у локальной культуры есть только один шанс к существованию - знание языка метрополии", поэтому в странах бывшего СССР все знали русский, в небольших странах Европы - сейчас английский.
Угу, потому я и говорю, что нормального протокола до сих пор нет. У протобафа и grpc плохо с реализациями, у json-over-http с производительностью. Какой-нибудь упрощенный bson с эффективной десериализацией поверх сокетов был бы нормальным решением, если бы был популярным и поддерживался всякими проксями и мешами, но увы.
Почти всем ) REST как идеология для service-service взаимодействия не так удобна, как RPC Работа с json медленнее, чем с protobuf
У подходов json-over-http основные плюсы в человекочитаемости сообщений, большой гибкости при версионировании, отсутствием кодогенерации и большим удобством библиотек. Но если требуется и производительность и удобство - то приходится искать какие-то сложные решения, так как и grpc и json не очень подходят (
Ну, отправку можно делать через 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 хватает.
Вообще во всех странах с богатой собственной культурой и не являющихся британскими колониями - не очень хорошо с английским языком. Китай, Япония, Франция (хотя казалось бы), Испания и так далее.
Английским хорошо владеют в небольших странах, но это скорее про "у локальной культуры есть только один шанс к существованию - знание языка метрополии", поэтому в странах бывшего СССР все знали русский, в небольших странах Европы - сейчас английский.
Угу, потому я и говорю, что нормального протокола до сих пор нет. У протобафа и grpc плохо с реализациями, у json-over-http с производительностью. Какой-нибудь упрощенный bson с эффективной десериализацией поверх сокетов был бы нормальным решением, если бы был популярным и поддерживался всякими проксями и мешами, но увы.
Почти всем )
REST как идеология для service-service взаимодействия не так удобна, как RPC
Работа с json медленнее, чем с protobuf
У подходов json-over-http основные плюсы в человекочитаемости сообщений, большой гибкости при версионировании, отсутствием кодогенерации и большим удобством библиотек. Но если требуется и производительность и удобство - то приходится искать какие-то сложные решения, так как и grpc и json не очень подходят (