Все таки перечисленные проблемы относятся к монолиту, а именно к тому, как он строился все это время) вы правы в своих пунктах! И именно поэтому оказалось дешевле монолит распилить, чем пересобирать или отрефачить, потому что построить архитектуру кодовой базы сервиса силами одной команды мне точно кажется легче, чем держать в согласованном состоянии код монолита силами всех наших команд
Да, возникают проблемы с взаимоотношениями между сервисами, это тоже правда, но таков путь)
А ребята из PAS меня уже позвали к себе посмотреть на сервис, так что непременно, спасибо за наводку!
Привет! На счет угара относительно согласен) Мне кажется, что по хорошему он прошел еще раньше. Компания сама вошла в него тоже не вчера, просто до этого никто с нашей стороны не афишировал подобные изменения, а так как моя команда находится на их острие, то родилось и это вступление, и этот текст)
Спасибо за комментарий! Что касается ужаса монолита - тут статья больше не о том, что он ужасен, а о нашем переходе к другому решению - к SOA, а не к микросервисам) Да, в нашем случае монолит оказался бутылочным горлышком, но что мы делаем с бутылочными горлышками? Стараемся от них избавиться
Плюсом: явно же, что ту же проблему с доездом товаров со склада на сайт можно было решить и в монолите (как и многое другое), но в момент оценки трудозатрат на рефакторинг и вынос логики в отдельный сервис с большим отрывом победило второе решение. Благодаря выбранному вектору разработки у нас и сайт начал быстрее работать - с открытия страницы товара за 3 секунды до >1 секунды.
Но, повторюсь, это все можно было сделать и в монолите, и с PHP) Все же я старался не хаять что-то, а рассказать о предпосылках и конкретных решениях
PS. Для меня самого оказалось удивительным, что для разработчиков тема распила монолита все еще актуальна... И на Highload, и на митапах ко мне подходили коллеги (не один-два) и консультировались на этот счет. Так что я тоже думал, что тема себя изжила, но она все еще подает признаки жизни :D
Как раз такая разбивка и существует - получается после профилирования. Только эта информация используется как раз лишь двумя оптимизациями. В этом плане pgo и go в целом есть куда расти
Спасибо за статью, интересный кейс, приятный текст! Но да, сколько ядер в итоге то нужно для 30k+ rps? И было бы интересно еще узнать, на сколько сервисов в конечном счете этот прием лег: только на ценообразование и оптовых клиентов, или коллеги из других команд переняли опыт и смогли его масштабировать по всей компании, улучшив профит? Или mongo - не всегда целевое решение в компании, а довольно редкое? Вот как будто недосказанность есть легкая по этому кейсу) был бы рад еще рассказам о нечто подобном в вашей практике
Все таки перечисленные проблемы относятся к монолиту, а именно к тому, как он строился все это время) вы правы в своих пунктах! И именно поэтому оказалось дешевле монолит распилить, чем пересобирать или отрефачить, потому что построить архитектуру кодовой базы сервиса силами одной команды мне точно кажется легче, чем держать в согласованном состоянии код монолита силами всех наших команд
Да, возникают проблемы с взаимоотношениями между сервисами, это тоже правда, но таков путь)
А ребята из PAS меня уже позвали к себе посмотреть на сервис, так что непременно, спасибо за наводку!
Привет! На счет угара относительно согласен) Мне кажется, что по хорошему он прошел еще раньше. Компания сама вошла в него тоже не вчера, просто до этого никто с нашей стороны не афишировал подобные изменения, а так как моя команда находится на их острие, то родилось и это вступление, и этот текст)
Спасибо за комментарий! Что касается ужаса монолита - тут статья больше не о том, что он ужасен, а о нашем переходе к другому решению - к SOA, а не к микросервисам) Да, в нашем случае монолит оказался бутылочным горлышком, но что мы делаем с бутылочными горлышками? Стараемся от них избавиться
Плюсом: явно же, что ту же проблему с доездом товаров со склада на сайт можно было решить и в монолите (как и многое другое), но в момент оценки трудозатрат на рефакторинг и вынос логики в отдельный сервис с большим отрывом победило второе решение. Благодаря выбранному вектору разработки у нас и сайт начал быстрее работать - с открытия страницы товара за 3 секунды до >1 секунды.
Но, повторюсь, это все можно было сделать и в монолите, и с PHP) Все же я старался не хаять что-то, а рассказать о предпосылках и конкретных решениях
PS. Для меня самого оказалось удивительным, что для разработчиков тема распила монолита все еще актуальна... И на Highload, и на митапах ко мне подходили коллеги (не один-два) и консультировались на этот счет. Так что я тоже думал, что тема себя изжила, но она все еще подает признаки жизни :D
Понял! Нет, пока что у разработчиков golang это в беклоге лежит
Как раз такая разбивка и существует - получается после профилирования. Только эта информация используется как раз лишь двумя оптимизациями. В этом плане pgo и go в целом есть куда расти
За статью спасибо! Но как теперь разработчикам работается без кибаны? Удобно ли им юзать кликхаус?
Спасибо за статью, интересный кейс, приятный текст!
Но да, сколько ядер в итоге то нужно для 30k+ rps? И было бы интересно еще узнать, на сколько сервисов в конечном счете этот прием лег: только на ценообразование и оптовых клиентов, или коллеги из других команд переняли опыт и смогли его масштабировать по всей компании, улучшив профит? Или mongo - не всегда целевое решение в компании, а довольно редкое? Вот как будто недосказанность есть легкая по этому кейсу) был бы рад еще рассказам о нечто подобном в вашей практике
Судя по всему, на данный момент pgo только инлайн функций затрагивает