Самая подробная история процесса оптимизации технической архитектуры рекламной системы Sina

Возможно, некоторые друзья мало знают о технической структуре интернет-рекламы, вот общая структура. В основном у всех компаний в технических решениях есть биржа, модуль, отвечающий за доступ к рекламному трафику и оптимизацию трафика (средний модуль на рисунке).

Рекламный трафик с верхнего конца будет оптимизирован для трафика, а после завершения оптимизации будет отправлен на нижний DSP для запросов.

Весь процесс аналогичен аукциону.После поступления трафика, если он оценивается как высококачественный, он инициирует запрос ставок к некоторым DSP.Последний запрос рекламы отдается победителю. Здесь adexchange в основном делает две вещи: во-первых, определить победителя торгов, а во-вторых, настроить экологический уровень. постановочная рекламная экология.

В первые дни наш adexchange был основан на сервере Nginx, и внутри сервера была написана бизнес-логика на Lua, то есть упомянутые выше правила торгов и планирование оптимизации трафика.

Поскольку adexchange не относится к механизму доставки одинаково, весь трафик представляет собой воронкообразную модель.

В процессе разработки adexchange, чтобы лучше реализовать воронкообразную модель и улучшить бизнес, мы провели вторичную разработку внутри компании и обнаружили много проблем в процессе разработки.

Использовать Lua для разработки функций не удобно, так как частые изменения требований приводят к необходимости мгновенного ответа, а использовать Lua для встраивания некоторых функций в процесс мгновенного ответа очень хлопотно. Сопровождаемость кода Lua оставляет желать лучшего, и после смены персонала новичкам становится очень дорого читать предыдущий код.

В-третьих, это сложно контролировать внутри бизнеса.Если используется метод Nginx плюс Lua, строго говоря, единственным решением является использование какого-либо метода для вывода журнала.Внутри Nginx сложно извлечь количество состояний и отправьте его в ключевую точку обнаружения бизнеса. Наконец, есть проблема с тестами.Очень хлопотно проводить полномасштабное тестирование или полномасштабное тестирование в градациях серого на основе среды Nginx плюс Lua.Как правило, это можно решить только путем непосредственного встраивания кода и некоторых технических решений для передачи не может быть принят.

Причина, по которой я выбрал Nginx плюс Lua в то время, заключалась в том, что я чувствовал, что Nginx имеет хорошую производительность, а Lua также может очень хорошо решать проблемы с производительностью. Так что для нас производительность не является узким местом, настоящая проблема заключается во вторичной разработке.

На схеме технической архитектуры, упомянутой выше, существует множество механизмов доставки.На приведенном выше рисунке показана конкретная реализация механизма. В 2014 году все эти механизмы были реализованы на базе сервера tomcat, включая запрос портрета пользователя, поиск заказа на доставку, алгоритм грубой сортировки и другие функции на сервере tomcat.

Самая большая проблема, связанная с такой архитектурой, — это модель многопоточности. Tomcat — это модель многопоточности с блокировкой. После того, как поток выделен, запрос должен быть выполнен, прежде чем его можно будет выпустить. Однако в то время наш ежедневный трафик был очень большим, и стоимость и эффективность использования tomcat были очень высокими.

(на основе проблем, с которыми столкнулась система tomcat)

Самая большая проблема бизнеса, связанная с архитектурой Tomcat, заключается в том, что она не может справиться с внезапными скачками трафика. Если трафик внезапно увеличивается в несколько раз в определенное время, если только предыдущая нагрузка не была очень низкой, единственный способ снизить нагрузку на tomcat — это понизить рейтинг и слить, но такой подход фактически потеряет доход компании.

Технические проблемы, с которыми мы столкнулись в течение 2014 года, можно свести к четырем основным пунктам.

• Серьезные монолитные функции.Вся логика доставки рекламы и бизнес доставки реализованы в едином Nginx плюс Lua, а также tomcat, любые изменения сопряжены с большими рисками.

• Функциональное взаимодействие между модулями подключаемое.Модуль здесь относится к алгоритму.Для рекламы будет онлайн каждый день, а это значит, что вилку нужно часто менять, что увеличивает риск системы.

• Модель программирования не адаптируется к эволюции бизнеса.Модель программирования означает, что один поток tomcat должен выполнить задачу, прежде чем ее можно будет выпустить.Этот метод может легко заблокировать бизнес.Единственным решением является развертывание большого количества серверов tomcat независимо от стоимости.

• Рабочее состояние системы непрозрачно.

В ответ на вышеуказанные болевые точки мы провели технический анализ и отбор.

Функциональный сервис.Каждая услуга независима друг от друга, что снижает деловую связь и сокращает время отклика на развитие спроса на продукт.

РПЦ.Для связи между сервисами используется RPC.После сравнения экосистем различных фреймворков RPC, таких как thrift, gRPC, dubbo и Finagle, мы, наконец, приняли фреймворк finagle RPC с открытым исходным кодом от Twitter.

монитор.Для рекламной системы есть два аспекта, вызывающие наибольшую озабоченность при мониторинге: один — это мониторинг и отслеживание состояния системы в реальном времени, а другой — анализ и статистика бизнес-данных в реальном времени. Статус системы в реальном времени не ограничивается физическими машинами, но также фокусируется на скорости запросов в секунду и времени ожидания, а также на среднем времени, затраченном на запросы. Коммерческие данные в основном связаны с рекламным бизнесом, например, рейтинг кликов в реальном времени и изменения рекламы. Анализ этих предприятий в реальном времени требует своевременной обратной связи с рекламодателем или агентством, поскольку они будут напрямую оптимизировать неэффективная реклама.

1. Проблема дифференциации услуг

Раньше, на начальном этапе сервисизации, мы думали, что сумма, которую нужно отфильтровать в каждом слое модели воронки, может быть использована как услуга, что не только естественно в бизнес-логике, но и удобно для развития бизнеса. и добавление новых функций.Функциям продукта нужно только изменить соответствующие услуги.

Однако в последующем тестировании прототипа было обнаружено, что восходящие и нисходящие вызовы некоторых сервисов были слишком частыми. Это связано с тем, что это кажется абстрактной моделью уязвимости. На самом деле утечка трафика в модели может быть неравномерной, и может протечь на определенном слое чуть меньше. Наиболее прямое влияние частых восходящих и нисходящих вызовов заключается в том, что полоса пропускания слишком велика, а соотношение времени обработки ввода-вывода велико.

Позже мы внесли изменения в первоначальный дизайн-прототип, и теперь есть возможность автоматически объединять сервисы на основе характеристик трафика.

(Схема архитектуры после рефакторинга)

В новой архитектуре после того, как трафик спустится, он сначала будет проходить через RB и PB, то есть самая высокая цена находится на верхнем слое, а затем экранируется слой за слоем. Видно, что некоторая часть трафика направляется непосредственно к движку, который минует промежуточные звенья и улучшает ввод-вывод и эффективность.

Наш самый большой опыт в процессе обслуживания AdX заключается в том, что мы не должны полностью разделять сервис на основе бизнес-логики. Мы должны протестировать реальный трафик через прототип, чтобы определить фактическое разделение сервиса, которое необходимо сделать.

2. Поиск рекламы

(Сервисно-ориентированная архитектура рекламного движка)

В рекламной системе есть несколько процессов, после того, как весь трафик сойдет, он будет сливаться в конкретную систему доставки через adx. В процессе доставки механизма доставки служба создания проекта пользователя будет запрашивать портрет пользователя. В соответствии с портретом пользователя будет получена группа заказов на доставку и сохранена в наборе кандидатов для доставки. После этого он будет взаимодействовать с алгоритмом определения наиболее подходящего заказа на доставку.Есть биллинговые сервисы для выставления счетов. Все сервисы будут подключены к сервису логов для обработки логов.

Из-за компромиссов всей технологии в то время мы потратили много сил на службу индексов. Первоначальный план состоял в том, чтобы напрямую сделать службу Index службой, но увеличение объема данных qps повлияло на масштабируемость службы Index. Позже мы решили периодически пушить набор данных в службу доставки с помощью rsync, что решило проблему большого объема передаваемых данных и влияющих на масштабируемость системы.

1. Отказоустойчивость системы

В процессе рассмотрения высокой надежности и масштабируемости мы думаем, что есть один момент, который необходимо решить больше всего, то есть отказоустойчивость системы, что также является проблемой, которую необходимо учитывать в распределенных системах. В визуализации отказоустойчивости системы есть три основных момента: во-первых, проектирование системы с учетом ошибок.Эти ошибки включают не только ошибки связи, но и простои физических машин и некоторые непредсказуемые ошибки, во-вторых, проектирование сервисов без сохранения состояния; третий отказ Автоматическая замена услуг.

2. Надежность системы

Что касается надежности системы, то есть три момента, с которыми мы больше всего столкнулись в процессе архитектуры.

• Отслеживайте статус работы программы мониторинга и горячие точки.Мониторинг рабочего состояния прост для понимания, и причина отслеживания горячих точек заключается в том, что некоторые горячие точки в сервисной программе, которые не были обнаружены в прошлом, могут срабатывать с течением времени.Если эти горячие точки не отслеживаются вовремя, они немедленно это обернулось катастрофой.

• Мониторинг обработки системных исключений в режиме реального времени и прямая изоляция аномальных служб.

• Сервис рассчитан на выполнение нескольких резервных копий.Как правило, учитывая отказоустойчивость и высокую надежность, мы можем развертывать несколько резервных копий для одного и того же сервиса, что также означает увеличение затрат. В рекламной системе будем классифицировать сервисы, и делать N бэкапов для первого уровня, и только 1-2 бэкапа для низкоуровневых с учетом стоимости.

3. Масштабируемость вычислительной мощности системы

При разработке системной архитектуры разработчики обычно думают, что добавление серверов определенно улучшит вычислительную мощность системы. На самом деле это не обязательно. Мы не можем ожидать улучшения общей вычислительной мощности системы, просто добавляя физические машины и вычислительные ресурсы, даже при некоторые пики qps. Это также снижает вычислительную мощность.

Только когда вычислительная мощность службы с одним компьютером достигает мощности линеаризации, можно гарантировать масштабируемость последующей вычислительной мощности системы.

Ключом к расширению возможностей обработки услуг системы является распределение ресурсов.Ключевым моментом распределенной системы является управление планированием.В прошлом управление планированием могло осуществляться только некоторыми запросами, но теперь больше внимания уделяется рациональному распределению ресурсов. Для рекламы пиковое изменение трафика очень серьезно.Как правило, ранним утром трафика не так много, а пики достигаются соответственно утром и в полдень.В этом случае динамическое распределение ресурсов может значительно облегчить трата ресурсов.

Раньше мы думали, что рекламные запросы больше всего заслуживают внимания, но в случае с первыми двумя масштабируемость ввода не является проблемой, наиболее критична точка доступа к данным в системе. Поскольку это часто является узким местом системы, например, когда согласованность данных не может быть гарантирована, мы можем улучшить уровень согласованности только для некоторых предприятий, и в это время легко сформировать горячие точки данных.

В процессе проектирования системы ее необходимо объединить с бизнесом, чтобы увидеть, всегда ли присутствовала точка доступа к данным, и, если она существует, понизить ее. Только когда мы обеспечим, чтобы горячие точки данных не оценивались как горячие точки в течение определенного периода времени при мониторинге или системном анализе, мы будем считать эту систему масштабируемой.

4. Масштабируемость архитектуры системы

Для масштабируемости системной архитектуры мы ссылаемся на шаблон лямбда-архитектуры, который делит систему на пакетный уровень, сервисный уровень и уровень скорости, так что автономные данные и данные в реальном времени могут быть объединены для предоставления услуг системе.

На самом деле рекламная система делает упор на обратную связь с данными в реальном времени, такими как расчет модели, эффект доставки, портрет пользователя и т. д. Если используются только офлайн-данные, эффект будет не очень хорошим. Второй момент — согласованность данных, так как объем данных в рекламной системе не очень велик, проще всего использовать иерархический метод для его обеспечения.

Третий пункт связан с согласованным хешированием.Хотя согласованное хеширование может восстановить узлы, которые были приостановлены, оно также приведет к потере трафика. Поэтому впоследствии мы убрали согласованное распределение хэшей всех запросов, которые использовались в прошлом, и распределили трафик напрямую по грузоподъемности следующих сервисов.

(эффект оптимизации системы)

Для грубого и мелкозернистого понимания сервисного подразделения, во-первых, необходимо уяснить, что нельзя просто разделить сервисную логику в соответствии с бизнес-логикой; во-вторых, суть сервисного подразделения состоит в том, чтобы найти реальный бизнес-центр и бизнес-поддержку; в-третьих, нет единого стандарта во всем процессе, ключ лежит в компромиссе.

Что касается системных проблем, разработчики обычно думают, что их можно решить с помощью сервисизации, но реальность такова, что горячие точки системы не исчезнут естественным образом с сервисизацией.

Поэтому в процессе оптимизации сервитизации мы должны сосредоточиться на оптимизации бизнес-логики, ведь вся сервитизация заключается в реализации бизнес-логики.Только когда у нас есть глубокое понимание бизнес-логики, оптимизация сервисов может быть целенаправленной, а не чисто с технической точки зрения. Мы считаем, что принцип, которого необходимо придерживаться в процессе сервисизации, заключается в том, что реализация технологии является лишь средством.

Для обслуживания существующей системы это означает, что есть две системы, которые необходимо плавно подключить к сети в течение определенного периода времени. В процессе разработки коллега из нашего отдела разработки как-то сказал, что сервисизация системы — это как замена двигателя во время полета.

В таком рискованном процессе есть два ключевых момента: во-первых, на онлайн-этапе оттенков серого необходимо учитывать параллельную совместимость старой и новой систем. Во-вторых, рассмотреть влияние запуска службы отдельной функции на систему в целом.

Для управления услугами мы считаем, что не обязательно полностью следовать его принципам, а скорее с точки зрения распределенных систем, рассматривая управление услугами с точки зрения согласованности данных и отказоустойчивости. Мы делаем некоторые подразделения по этому поводу.

Во-первых, это автоматическая деградация и восстановление возможностей обработки услуг, во-вторых, защита услуг, включая балансировку нагрузки и автоматические выключатели, и, наконец, прозрачная работа услуг.В практике управления на основе услуг будет много услуг, и так много сервисов нужно контролировать.И отслеживание, если использовать ручные или скриптовые методы, будет очень неэффективно и неинтуитивно.В это время очень важна прозрачность сервисов.

Выше все делится, спасибо!