1. С этим проблемы имеются ввиду обширности архитектуры авито. У нас миллионы запросов в минуту и соответственно ОЧЕНЬ много серверов, которые орекстрируются при помощи kubernetes, поверх которого наш PaaS. Но тем не мене, оверхед в необходимости закодировать/декодировать данные перед отправкой в Redis остается, хоть и минимизируются сетевые издержки.
2. Не подойдет, но тем не менее, его мы используем в других задачах. Не подойдет потому, что нас придется тогда обучать всех разработчиков работе с tarantool, когда у нас все разработчики уже знают Go. Это первый момент. Второй момент — опять же загрузка сети.
Ну в случае любой встраиваемой БД (ровно как и sqlite) как правило будет все равно оверхед. В моем же случае, мы просто храним в оперативной памяти данные, которые не надо никуда преобразовывать и RT сервиса в этом случае будет равняться RT получению нужных данных из оперативной памяти и декодированию/кодированию запроса, что в общем то и надо на высоких нагрузках.
Благодарю за замечание! Действительно, в go чаще используется термин slice для массивов, которые не имеют заданной длины и в терминологии go array и slice действительно отличаются. Но я в статье имел ввиду массив как более общий для программирования термин, просто не очень хотелось использовать слово «срез» или англицизм «слайс» и именно поэтому я использовал слово «массив». В статью внес правку, чтобы не вводить никого в заблуждение.
Неееет! Первое что должно приходить в голову — какого этот сервис не может за 300мс выполнить свою работу? И только после ответа на этот вопрос — кеши и ещё ещё что-то.
Это было известно с самого начала, но специально не упомянуто тут, т.к. выходит за рамки статьи. Сервис медленный, т.к. сделан на php и работает с внешними сервисами, которые выделяют номера. За тот сервис отвечала другая команда, но в процессе оптимизации phones-gateway, о котором и рассказано в статье, наша команда также оптимизировала тот сервис, но переписывать его на Go было не в рамках нашего пула задач, и сильно оптимизировать мы не смогли, сейчас ситуация с ним значительно лучше, т.к. его переписали и оптимизировали.
Вообще непонятно зачем все эти сложности? Есть юзер, у него есть верифицированный номер телефона. Есть объявление, у него тоже есть номер телефона, который либо anonymous, либо call tracking, либо берётся из данных юзера. Система решает этот вопрос в момент создания объявления. Есть отдельный сервис — пул телефонов, который связан с АТС и выдаёт номер нужного типа, в момент создания объявления.
Тут у нас уже появляются требования Роскомнадзора и других органов. Номер телефона пользователя является персональными данными пользователя и хранится в отдельной таблице от объявления в виде зашифрованных данных и получение этих данных происходит через специальный сервис-хранитель перс. данных. Более того, в вашей модели не учтен момент, что пользователь может захотеть поменять номер телефона и поменять его так, чтобы он поменялся сразу на всех объявлениях.
Больше к нему никто не обращается, нагрузки особой на него нет. Кажется все. И тут не видно всех тех сложностей, о которых пишут в статье, типа сервисы работы с телефонами тормозят, а их ещё и несколько штук…
Тут еще дело в том, что этими сервисами заведуют разные команды, которые решают разные бизнес задачи, поэтому есть дифференциация на разные типы номеров для переадресации, и они преследуют разные цели. Также, реальный номер телефона может потребоваться получить в админке или еще в каких-то сервисах, по рассылке СМС к примеру. Поэтому архитектура на деле оправдана и обусловлена требованиями бизнеса.
Ожидал подобного вопроса. В данном случае я специально применил in-memory cache, т.к. если использовать Redis и Memcached у нас появляется сразу большое количество ошибок с сетью, которые регулярно происходят при использовании Redis и подобных решений. Помимо этого, у нас появляется оверхед в виде кодирования данных для отправки в Redis, отправки данных через сеть, получения ответа от Redis, раскодирования и так далее. Это сильно аффектит response time сервиса и нагружает и без того нагруженную сеть у нас. При этом, оперативной памяти у нас довольно много свободной, поэтому мы можем пожертвовать дублированием в данном случае ради большей стабильности и производительности.
2. Не подойдет, но тем не менее, его мы используем в других задачах. Не подойдет потому, что нас придется тогда обучать всех разработчиков работе с tarantool, когда у нас все разработчики уже знают Go. Это первый момент. Второй момент — опять же загрузка сети.
Это было известно с самого начала, но специально не упомянуто тут, т.к. выходит за рамки статьи. Сервис медленный, т.к. сделан на php и работает с внешними сервисами, которые выделяют номера. За тот сервис отвечала другая команда, но в процессе оптимизации phones-gateway, о котором и рассказано в статье, наша команда также оптимизировала тот сервис, но переписывать его на Go было не в рамках нашего пула задач, и сильно оптимизировать мы не смогли, сейчас ситуация с ним значительно лучше, т.к. его переписали и оптимизировали.
Тут у нас уже появляются требования Роскомнадзора и других органов. Номер телефона пользователя является персональными данными пользователя и хранится в отдельной таблице от объявления в виде зашифрованных данных и получение этих данных происходит через специальный сервис-хранитель перс. данных. Более того, в вашей модели не учтен момент, что пользователь может захотеть поменять номер телефона и поменять его так, чтобы он поменялся сразу на всех объявлениях.
Тут еще дело в том, что этими сервисами заведуют разные команды, которые решают разные бизнес задачи, поэтому есть дифференциация на разные типы номеров для переадресации, и они преследуют разные цели. Также, реальный номер телефона может потребоваться получить в админке или еще в каких-то сервисах, по рассылке СМС к примеру. Поэтому архитектура на деле оправдана и обусловлена требованиями бизнеса.