Комментарии 43
Слоган над космонавтом — норм)
Http вызовы + сообщения очередей — это основные каналы взаимодействия, да. И в обоих каналах приложения должны придерживаться объявленного контракта (request/response схемы или model события). У нас также есть система (пока она работает только для api вызовов), которая валидирует при выкладке, что не произошло breaking change в принимаемых api или вызываемых среди всех монолитов и микросервисов (мы умеем по коду автоматически найти схемы request / response приложения).
Можно поподробнее про это? 8k RPS => 700 млн. записей в день, откуда берется 3.8 млрд и что делаете с такими объемистыми логами?
Думаю подробнее расскажем в отдельной статье. Вкратце, логируем не только акцесслоги, но и события в микросервисов, цепочки вызовов, ошибки, ворнинги и т.д. Все это позволяет мониторить и отлаживать систему. Также на базе этих логов строим siem систему
Мы сейчас идём другим путём — хотим, чтобы у каждого микросервиса был, скажем, свой микрокластер postrgre или elastic (на контейнерах, чтобы не получать оверхед от виртуалок). Тогда мы сможем ограничить негативное влияние одного микросервиса на другие.
Мы всегда исходим из того, что накосячить могут все и очень разным способом и под каждый способ накосячить невозможно держать отдельного человека, поэтому более стратегически правильно научиться минимизировать взаимовлияние (изоляция + деградация) и время простоя компонент (алерты + автоматизация).
Отсюда квартиры в панельных домах при поиске кирпичных, отсюда квартиры с газовыми плитами в электрифицированных домах и так далее. Важно, чтобы вы увидели «замануху», а цифровизация это вторично.
8k rps и 300 серверов… Куда столько? Допустим с десяток фронтов, бэки, очереди, базы, реплики, статика, логи… но куда 300?
Тогда вполне можно понять.
Никто ж не писал, что на каждом из серверов топовое железо — может 2/3 на Атомах?
По структуре внутренних запросов отлично понимаю, работал с недвижкой в нгс.
Возможно C# накладывает свой отпечаток, ну и да, если много микросервисов, то много и накладных расходов.
Хорошо быть богатой компанией, а если бюджетов на железо нет, приходится заниматься оптимизацией))
Поэтому, да — занимаемся оптимизацией. Наверное, не так, как если бы у нас было 10 серверов, но всё же активно с этим работаем.
И, пожалуй, самое «тяжёлое» по железу это не C#, а machine learning (ибо big data и все дела) и, как ни странно, frontend (nodejs server side rendering) — там много CPU bound операций (парзинг json, рендеринг html), на которые приходится достаточно большой RPS. Но шарп мы тоже активно переводим на .NET Core (и вот скоро приступим к переводу на .NET Core 3).
Как я понимаю, используете некие математические модели. Но по любому нужно иметь доступ к информации о реальных продажах. У вас есть такой источник?
>>> Они всё знают ;)
Одно дело — просто знать, а другое дело — понимать, как это реально работает. Если бы я был далек от высшей математики, то тоже не доверял бы таким калькуляторам.
А куда же без неё. Мы очень активно боремся за чистоту контента, выявляем различные виды нарушений. Начиная от банальных непреднамеренных ошибок в параметрах объявления, заканчивая намеренным размещением «заманух» (несуществующих привлекательных объявлений с целью получить звонки) и даже «лохотронов» (несуществующих объявлений, размещаемых с целью кинуть пользователей на деньги). Для чего мы разрабатываем различные инструменты (статические алгоритмы, модели ML, интеграции с внешними сервисами), которыми пользуются наши сотрудники-модераторы.
Для более глубокого погружения в тему выявления видимых нарушений можно посмотреть наш доклад на PyData в прошлом году: www.youtube.com/watch?v=VAGV7aqani4
Настраивали систему антиботов и сами себя забанили.
lol! просто и со вкусом :)
Кстати, а сильно ли мешают боты, и стоило ли оно того?
1,2 миллиона уникальных клиентов в день? — для недвижимости это бред.
Как мы в ЦИАН цифровизируем рынок недвижимости