а смена стека не обесценивает полученный ранее опыт?
а чьи "лычки" мега архитектора в конмпании делающей лединги и мидла в топовой IT больше?
Ну и главный вопрос - а точно ли имеет смысл гнаться за лычками? Некоторым дейтсивтельно комфортно делать то что они делают. И им не нужен ни доп головняк, ни дополнительная отвественность, более высокий темп гонки. Или с такими ребятами тоже "поняяятно"?
Простите пожалуйста, если излишне эмоционально. Очень не нравится, когда обесценивают чей-то труд
Пытался найти хоть один график, вдруг сохранился....но большую часть метрик мы уже флашнули. а что не флашнули - timeSeries схлопнула, и стало не очень нагялдно
Наших объемах фон ошибок уменьшился от 10% до 200% (то есть физически ошибок стало до 2х раз меньше)
Я легко могу представить больше одного сценария когда это оправдано. К примеру это требование сертификации при работе с персональными данными. Или желание защитить свои данные когда используешь не свое железо( MIM атаку никто не отменял)
Это вполне себе реальные риски. И прежде чем решить - http\https их надо оценить.
Рассматривали. И даже в ряде сценариев используем.
Но этот способ не очень подходит для интерактивных типов запросов - пока положишь в очередь пока вычитают, поработают, положат обратно, пока прочитаешь ответ.. + нужно вычитать именно свой ответ а не ответ на другой запрос, и оверхед от самой очереди..
Теперь абстратная Я.Недвижимость сможет делать обзвон клиентов абстрактного Cian и легально предлагать им перенос на свою площадку.
Раньше это было на грани законности, теперь-же обретает вполне легальный статус
> Чтобы избежать этого, имеет смысл использовать HPA
все вместе будет требовать определенного тюнинга каждого сервиса.
и доп тюнинга по мере развития проекта. ну и всегда есть шанс словить маркетинговую акцию и тупить пока развернуться до ядра.
В общем — это полезная штука, но использовать надо очень даже с умом.
Конечно можно положит по контейнеру с редисом в каждую реплику-)
Но тогда мы получим независимые кеши на каждой реплике а это не будет принципиально отличаться от memory кеширования в самом GO. Только больше CPU потратим.
Есть ли статистика hit/miss
Вы правы, говоря что каждый из 3-х реплик будет иметь независимый кеш. И что hit\miss считать нужно, дабы понимать эффективность всей этой истории.
И у нас она есть, и мы ее мониторим.
Но в целом — статья про работу планировщика в GO и нюансы профилирования, а не про
1) Коммуникации внутри одного хоста тоже совсем не бесплатные. Хоть они и ничтожны по-сравнению с сетью, но все-же гораздо выше чем inmemory
Второй момент — сервис запущен в нескольких экземплярах на физически-разных машинах (повышаем отказоустойчивость). Отсюда только одна реплика сервиса работает без сетевого оверхеда.
Третий момент k8s — он базово не гарантирует что после раскатки новой версии сервис не окажется на другой машине (на самом деле почти наверняка окажется).
2) Вероятно вы предлагаете использовать tarantool как application вместо GO. Tarantool не сильно cloud native. Готовить его так, чтобы ты мог в любой момент изменить количество реплик сервиса, и не терять стейт при перевыкатке или disaster крайне не просто. Ну и в итоге — мы получим все то-же inmemory хранилище как и в Go. Просто несколько более оптимизированное.
Невероятно, но факт.
У нас вышла статься, ровно про то что спросили
https://habr.com/ru/company/avito/blog/655553/
Почитайте https://habr.com/ru/company/avito/blog/505916/
Тут краешком рассказываем о зоопарке наших мер борьбы с негодяями.
Вы зря думаете что этого нет.
Все есть и, насколько я могу судить, едва ли не лучшие на рынке.
И автомодерация, и ручная модерация, и реакция на кнопку пожаловаться. Все есть.
Это всегда борьба мечта со шитом.
Так вот-же, в тексте есть все!
https://www.avito.ru/legal/rules/privacy-policy
Если эта статься не "зашла" вам, то есть другая https://habr.com/ru/company/avito/blog/505916/
в легси кусках монолита логика дейтвительно обитает в контроллерах (как хорошо, что таких кусков осталось очень мало)
А в целом - читай вместо контроллеров то место где лежит логика services, providers, domains, repositories
а кем надо стать за 11 лет?
а точно ли все 11 лет имеют одинаковый вес?
а смена стека не обесценивает полученный ранее опыт?
а чьи "лычки" мега архитектора в конмпании делающей лединги и мидла в топовой IT больше?
Ну и главный вопрос - а точно ли имеет смысл гнаться за лычками? Некоторым дейтсивтельно комфортно делать то что они делают. И им не нужен ни доп головняк, ни дополнительная отвественность, более высокий темп гонки. Или с такими ребятами тоже "поняяятно"?
Простите пожалуйста, если излишне эмоционально. Очень не нравится, когда обесценивают чей-то труд
Авито делает микросервисы на PHP, Golang, Python
Может просто вы не умеете PHP готовить?
Ну и исторически - наше монолитное приложение написано на PHP, и портировать код не еняя язык в разы дешевле-)
Пытался найти хоть один график, вдруг сохранился....но большую часть метрик мы уже флашнули. а что не флашнули - timeSeries схлопнула, и стало не очень нагялдно
Наших объемах фон ошибок уменьшился от 10% до 200% (то есть физически ошибок стало до 2х раз меньше)
Все так. Но даже это позволит писать код, более адаптированный для неблокирующих операций. А там выйдет - найдем куда применить-)
Спасибо!
и в правду.
FIXED
Боюсь я сильно конкретных цифр дать не смогу.
Оно все достаточно специфично под объемы нагрузки. Но из того чем могу поделится - уменьшения рейта ошибок до 5-10%, ускорение примерно до 5%.
Все так, не выйдет.
И поэтому я подсветил что эта опция не для всех подойдет.
И у нас все еще остаются другие способы оптимизации.
Привет.
Я легко могу представить больше одного сценария когда это оправдано. К примеру это требование сертификации при работе с персональными данными. Или желание защитить свои данные когда используешь не свое железо( MIM атаку никто не отменял)
Это вполне себе реальные риски. И прежде чем решить - http\https их надо оценить.
Привет.
Рассматривали. И даже в ряде сценариев используем.
Но этот способ не очень подходит для интерактивных типов запросов - пока положишь в очередь пока вычитают, поработают, положат обратно, пока прочитаешь ответ.. + нужно вычитать именно свой ответ а не ответ на другой запрос, и оверхед от самой очереди..
Раньше это было на грани законности, теперь-же обретает вполне легальный статус
все вместе будет требовать определенного тюнинга каждого сервиса.
и доп тюнинга по мере развития проекта. ну и всегда есть шанс словить маркетинговую акцию и тупить пока развернуться до ядра.
В общем — это полезная штука, но использовать надо очень даже с умом.
Но тогда мы получим независимые кеши на каждой реплике а это не будет принципиально отличаться от memory кеширования в самом GO. Только больше CPU потратим.
Вы правы, говоря что каждый из 3-х реплик будет иметь независимый кеш. И что hit\miss считать нужно, дабы понимать эффективность всей этой истории.
И у нас она есть, и мы ее мониторим.
Но в целом — статья про работу планировщика в GO и нюансы профилирования, а не про
Второй момент — сервис запущен в нескольких экземплярах на физически-разных машинах (повышаем отказоустойчивость). Отсюда только одна реплика сервиса работает без сетевого оверхеда.
Третий момент k8s — он базово не гарантирует что после раскатки новой версии сервис не окажется на другой машине (на самом деле почти наверняка окажется).
2) Вероятно вы предлагаете использовать tarantool как application вместо GO. Tarantool не сильно cloud native. Готовить его так, чтобы ты мог в любой момент изменить количество реплик сервиса, и не терять стейт при перевыкатке или disaster крайне не просто. Ну и в итоге — мы получим все то-же inmemory хранилище как и в Go. Просто несколько более оптимизированное.