Comments 21
Скажите пожалуйста, а какой чудак у вас пишет ваши "секретные алгоритмы проверки достоверности объявлений"? Хотелось бы ему в харю плюнуть. Выложил объяву о продаже квартиры, объявление уже два раза блочили. Причину не говорят, чтобы "не раскрывать секретные алгоритмы". После второго раза уже требуют снять видео с квартирой и выложить его в отрытый доступ на ютуб (с персональными данными и всей моей личной жизнью - жалобы в прокуратуру и роскомнадзор уже написаны). В техподдержке у вас также работают полнейшие дегенераты, которые кроме как талдычить один и тот же бред и ложь ничего не могут.
Вместо заумных и неинтересных постов, от вашей конторы хотелось бы видеть статьи о том, какие действия предпринимаются, направленные на поворот лицом к пользователю, на реальные действия против мошенников, а не как здесь, действия по комплектованию техподдержки вменяемыми людьми.
Очень странный комментарий. На техническом ресурсе, в статье про переход с монолита на микросервисы. Думаете уместен?
Здравствуйте. Чтобы мы могли вам помочь, напишите нам в личку почту из вашего профиля и номер объявления.
Если эта статься не "зашла" вам, то есть другая https://habr.com/ru/company/avito/blog/505916/
Ну вот непонятно, зачем это все?
Так вот-же, в тексте есть все!
У такой архитектуры был ряд проблем:
1. Монолитное приложение недостаточно гибкое.
2. Возникла потребность где-то держать общую функциональность: у нас появлялись второстепенные продукты, и нужно было переиспользовать общую логику.
3. Всё концентрировалось в одном приложении, которое обращалось со множеством баз данных.
4. Страдала отказоустойчивость
Лучше раскажите про политику обработки ПД
Что авито, что киви, это не те места работы которым можно хвастаться.
Много информации поэтому ясно что стиль лапидарный, но все-таки такое
Если лейбл
app=supervisor, он подтягивает этот pod к себе,
это уж совсем, будто бы робот писал или переводил - какой лейбл, где, у кого и почему? До этого места про лейблы ни слова не было.
ну чё сказать, молодцы, классно двигаетесь, надо перенимать эстафету
Вы зря думаете что этого нет.
Все есть и, насколько я могу судить, едва ли не лучшие на рынке.
И автомодерация, и ручная модерация, и реакция на кнопку пожаловаться. Все есть.
Это всегда борьба мечта со шитом.
Почитайте https://habr.com/ru/company/avito/blog/505916/
Тут краешком рассказываем о зоопарке наших мер борьбы с негодяями.
Как у вас реализовано общение цепочки сервисов api-gateway -> api-composition -> microservice, чтобы клиент получил запрашиваемый результат? Кто-то говорит, что REST-запросов достаточно, а другие - "если у вас хай-лоад, то REST загибается и нужно использовать только брокеры сообщений (rabbit, kafka и тд)".
Интересно узнать какие практики используются именно на популярном проекте)
@Hell_Knight, спасибо за отличную техническую статью.
В итоге у service-user появится feature toggle монолита. Service-user будет пытаться что-то туда записать, но у него ничего не выйдет, потому что данные моментально будут перезаписываться.
(если redis-local выпилили, это менее актуально, но все же)
^ Такое могло происходить, если redis не прикрыт паролем. Авторизация это дополнительный запрос в redis, и при ваших нагрузках это разумеется не бесплатно. Это осознанный трейд-офф отказ от аутентификации или техдолг?
Так же в схеме видно, что redis-sentinel ходит напрямую извне pod-a, это означает, что redis-ы торчат внаружу для всех. Соответственно условный злоумышленник мог поменять поведение avito-site переписав содержимое redis-local. Сотрудничаете ли вы с security инженерами при проектировании сервисов?
слишком большая сетевая активность в одном контейнере
Мы разделили один xproxy на четыре разных контейнера
Можете пожалуйста раскрыть подробности? Во что именно упирались, и про какую именно сетевую активность идет речь?
По факту все осталось внутри той же k8s node, а значит те же ядра k8s node обратывают сетевые прерывания, и тот же сетевой интерфейс пропускает через себя весь трафик.
Про контейнер databases - процесс pgbouncer.
- Какую роль выполняет pgbouncer внутри этого контейнера?
- И второй вопрос в ту же тему - с точки зрения приложения нет разницы в ответственностях между контейнером caches и databases. Что препятствовало тому, чтобы Xproxy рендерил конфиги и для баз данных? Здесь ведь тоже можно сэкономить на ресурсах, и проще в поддержке -разработчику проще контролировать конфликты по локальным портам.
и нам нужен blue-green релиз
Судя по тексту LXC-контейнеры ничем не оркестрировались, соответственно вряд ли там был B-G деплой, и вы жили без него до 2019-го года. Так же не раз упоминалось про нехватку ресурсов. После переезда в k8s, вы стали пользоваться B-G релизами и что делаете с нехваткой ресурсов теперь?
По redis’у - он действительно был без авторизации, это наш тех долг. То что в редис можно сходить по IP - это возможно сделать только из внутренней сети, из внешки не пробиться, всё будет пресечено сетевыми политиками доступа. Да и на сколько мне известно в slaveof redis запись невозможна.
XProxy - там генерировался конфигурации с haproxy + twemproxy на не одну сотню нижестоящие железные сервера, которые они должны были health-check-ать, а помимо всего этого еще и обрабатывать запросы всё это возлагалось на один единственный контейнер. Он не успевал этого делать и часть запросов отваливались с дефолтным тайм-аутом в 300мс или имели задержку на выполнение запроса.
PgBouncer - для управления соединениями и контроля чтобы бекенд не злоупотреблял ресурсами. PgBouncer в составе XProxy у нас не полетел в силу следующих пунктов: 1) конструкция получилась тяжеловесная для задачи database service discovery и менее надежная, чем альтернативный вариант; 2) альтернативный вариант - захардкоженный виртуальный хост (DNS или k8s service) в конфигурации и отдельностоящая система по актуализации этого хоста. XProxy же для redis в первую очередь решает задачу прозрачного для приложения шардирования, а у же потом database service discovery. Для PostgreSQL задача с шардированием не стояла (и не могла быть в рамках текущих инструментов), а database service discovery решается гораздо лучшими способами (см. выше).
Blue-Green на LXC - у нас была система с подменом symlink-ов и релоадом процессов. Это происходило достаточно быстро, что можно было считать такой процесс как blue-green. После разъезда по 3дц емкость кластера высвободилась и ресурсов стало хватать без проблем.
Эволюция архитектуры Авито, или Как мы монолит в Kubernetes затолкали