Приложение iQIYI Overseas — этотяжелая операцияПриложения. Для верхней навигации, моей страницы, всплывающих окон и т. д. в приложении управление операциями должно осуществляться в соответствии с различными параметрами, такими как режим, версия, платформа, язык и канал. При быстром развитии бизнеса и быстрой итерации версий нам необходимо решить, как эффективно, стабильно и гибко настраивать операционные ресурсы, а также как эффективно и стабильно обеспечивать поддержку новых операционных потребностей.
В этом контексте зарубежная команда разработчиков телефонов iQIYI создалаСтабильный, гибкий и эффективныйПлатформа конфигурации операции для решения проблем, возникших ранее. В этой статье в основном рассказывается о некотором опыте, накопленном нами в процессе создания эффективной платформы конфигурации операций, и о проблемах, с которыми мы сталкиваемся.бросай вызов и думай.
1. Демонтаж ресурсов конфигурации
Конфигурация операции может быть разделена на две части: конфигурация операционных ресурсов и основные данные.
1.1 Операционные ресурсы
Проще говоря, под операционными ресурсами можно понимать некую рекламу, операционную деятельность и т. д., которые часто меняются в приложении. Например, всплывающее окно с рекламой на картинке выше — типичный рабочий ресурс. Для таких оперативных ресурсов они обычно имеют следующие характеристики:
** Сильная своевременность: ** Отображается только в фиксированном положении на терминале C в течение определенного диапазона времени.
**Режимы сильно связаны: **Каждое действие и реклама будут отображаться только в определенных фиксированных режимах.
**Частые изменения данных: **Особенно в данных об активности, копия отображаемого изображения и другие изменения происходят чаще.
**Поддержка многоязычного отображения: **Исходя из того, что зарубежный сайт iQIYI ориентирован на пользователей со всего мира, копирайтинг на разных языках должен отображаться в разных режимах.
1.2 Базовая конфигурация данных
По сравнению с операционными ресурсами частота изменений конфигурации базовых данных относительно низкая, а связь со временем и версией не так сильна. Например, следующая панель навигации в нижней части приложения iQIYI Overseas (стиль показан на рисунке выше). Эта конфигурация имеет следующие характеристики:
**Многомерность:** для разных режимов и языков требуются разные конфигурации.
**Долгосрочная действительность.** Конфигурация этого типа обычно существует в течение длительного времени, и сценариев с истекшим сроком действия немного.
2. Болевые точки на практике: низкая эффективность работы и много повторяющейся работы.
Столкнувшись с последовательными требованиями к операционной конфигурации, мы изначально реализовали различные интерфейсы конфигурации для удовлетворения различных операционных требований к продукту. Но это неизбежно натолкнется на большие проблемы, которые в основном отражаются в следующих аспектах:
низкая операционная эффективность
В соответствии с новыми требованиями к конфигурации операции студенты, занимающиеся исследованиями и разработками, должны разработать соответствующие страницы конфигурации, а затем передать их учащимся, занимающимся эксплуатацией, для управления конфигурацией. Наконец, операционный персонал настраивает ресурсы и подключается к сети. Блок-схема выглядит следующим образом:
Для каждого требования к рабочей конфигурации оно должно пройти процесс проверки требований, разработки страниц, управления конфигурацией и онлайн. В то же время для разработки страницы конфигурации требуется не менее 1-2 человеко-часов разработки, а стоимость исследований и разработок высока. Проблемы суммированы следующим образом: 1. Стоимость исследований и разработок высока, и для каждого требования необходимо разработать новую страницу управления конфигурацией.
2. Длительный цикл исследований и разработок, низкая эффективность работы, длительный цикл от предложения спроса до запуска в эксплуатацию.
3. Низкая гибкость, а различные рабочие параметры (режим, версия, время и т. д.) необходимо определять заранее и нельзя динамически регулировать.
Много повторяющихся разработокЧто касается серверной части общей конфигурации операций, некоторые уникальные функции особенно очевидны для интерфейсной и серверной частей, чтобы дублировать работу по разработке. Такие функции, как записи операций, механизмы аудита, фильтрация данных в соответствии с различными языками версии схемы и т. д., требуют повторной разработки для каждого требования к конфигурации.
3. Практическое мышление: проясните три принципа
В ответ на вышеуказанные проблемы мы надеемся решить различные проблемы управления операционными ресурсами, описанные выше, путем разработки общего решения. Мы называем этот проект IQ Operation Bit.
Благодаря исследованиям мы подтвердили наличие трех основных принципов проектирования проекта: возможность настройки всех данных, оперативные данные, высокая доступность, производительность интерфейса, высокая эффективность.
Благодаря постоянной практике и обобщению мы надеемся реализовать вышеуказанные принципы в следующих трех аспектах:
3.1 JSONизация данных
При непрерывной итерации бизнеса, независимо от состава полей данных, трудно удовлетворить требования полей бизнес-изменений (имеются в виду заголовки, субтитры, изображения, ссылки для перехода и т. д.). JSONize базовые данные, и соответствующие поля данных могут быть реализованыДинамически масштабируемый, чтобы удовлетворить потребности непрерывной бизнес-итерации. JSONизация также повлечет за собой проблему управления полями битов операции, которую мы решаем, предоставляя соответствующие функции управления полями в фоновом режиме операции.
3.2 Многоточечное хранение оперативных данных
Благодаря постоянному хранилищу, распределенному кешу и доступу к локальному кешу бизнес-стороны, а также многостороннему хранению операционных данных, он может обеспечить получение ухудшенных данных в экстремальных случаях и уменьшить потери системных исключений.
3.3 Интерфейс SDK
Для оперативных данных, будь то реализация решения для базы данных или решение с распределенным кэшем, проблемы централизации обслуживания и флуктуации обслуживания не могут быть полностью решены. Благодаря доступу к SDK можно реализовать механизм обновления данных в локальном кэше и уменьшить зависимость от централизованных служб.Повышение стабильности и производительности службы. В то же время весь битовый сервис операции IQ становится горизонтально масштабируемым, и стабильность центрального сервиса не пострадает в процессе расширения. Блок-схема запроса вызывающего абонента выглядит следующим образом:
4. Архитектура рабочего бита IQ
Общая диаграмма кадра системы конфигурации рабочего места IQ. С функциональной точки зрения он обычно делится на четыре уровня: уровень данных, уровень обслуживания, уровень доступа и уровень мониторинга. Схема архитектуры рабочего бита IQ выглядит следующим образом:
4.1 Уровень данных
Уровень данных в основном хранит все виды операционных данных, связанных с битом операции IQ. Слой данных в основном сталкивается со следующими трудностями. **Сложность 1, большой объем данных, сложность 2, большое количество запросов в секунду. **Исходя из двух вышеупомянутых трудностей, мы используем кластер Redis в качестве промежуточного кеша, используем SDK, чтобы предоставить каждой бизнес-стороне доступ к локальному кешу, и решаем нагрузку на трафик центральной службы, отслеживая асинхронное обновление сообщения. .
4.2 Сервисный уровень
Уровень обслуживания работает с базовыми данными снизу вверх, а уровень доступа вверх предоставляет возможности доступа для получения данных уровнем доступа. Он предоставляет четыре возможности обслуживания:Предыстория работы, открытая платформа, служба данных, IQKIT-SDK.
Среди них фон операции в основном предназначен для операторов и продуктов и обеспечивает фон конфигурации данных.
Открытая платформа возвращается разработчикам и техническому персоналу, обеспечивая основу для увеличения конфигурации рабочих битов.
Служба передачи данных в основном предназначена дляУнифицированный, высокодоступный, высокопроизводительный API-интерфейс.
SDK обслуживает службы данных. Основное направление — упростить стоимость доступа для разработчиков и обеспечить производительность и доступность службы данных.
4.3 Уровень доступа
**Как сделать доступ к С-терминалу более удобным? **Чтобы упростить стоимость доступа для разработчиков, логика вызова реализована в SDK.Пользователям нужно только импортировать пакет maven, внедрить OppkitClient, инкапсулировать OppkitRequest и напрямую вызвать через OppkitClient, чтобы вернуть отфильтрованные и переведенные данные.
**Как удобнее настроить сторону Б? **При разработке проекта принцип конфигурации фона один:все настраивается. Настройте бит операции IQ, открыв фон.Каждый бит операции IQ эквивалентен бизнес-форме, такой как панель навигации, а бит операции содержит несколько данных, таких как заголовок, ссылка и т. д., а заголовок содержит несколько языков , который необходимо настроить на несколько языков. Роль открытой платформы заключается в создании битов операции IQ и настройке полей для битов операции IQ. Фон операции используется для настройки битовых данных операции IQ, созданных открытой платформой.
4.4 Уровень мониторинга
В дополнение к мониторингу уровня хранения данных и мониторингу уровня данных и сервисного уровня с помощью Parllay, мы также отслеживали локальный кеш, реализованный в SDK.
Доступ на стороне C, то есть сбор данных, реализован внутри SDK.В SDK мы реализовали следующие функции: 1. Если запрос содержит какие-то определенные дискретные поля, такие как идентификатор устройства, потому что количество содержащихся данных очень большой, хранение его в локальном кеше будет предоставлять услуги для бизнеса.Если есть большая нагрузка на машинную память стороны, служба запрашивается напрямую, избегая кеша.
2. Чтобы удовлетворить бизнес-сторону с высокими требованиями к данным в режиме реального времени, добавлена логика отказа от доступа к локальному кешу.
3. Если включены только некоторые поля с высокой степенью агрегирования, такие как поле платформы, версия, режим, язык и т. д., запрошенные данные сохраняются в локальном кэше. Локальный кеш обновляется асинхронно, отслеживая операционную платформу.Когда асинхронное обновление не может получить данные, предыдущие данные сохраняются и возвращаются, чтобы избежать крайних случаев, когда все рабочие данные пусты.Минимизируйте потери бизнеса.
4. Использование локального кеша сохраняется в синхронизированном потоке через асинхронный поток внутри SDK, а использование каждого кеша отображается через фоновый интерфейс, а использование различных кешей отслеживается в режиме реального времени.
5. Гарантия стабильности и производительности
Как упоминалось выше, при проектировании фона операции мы придерживаемся следующих принципов:
- Все данные настраиваются
- Высокая доступность оперативных данных
- Эффективная работа интерфейса
Ниже мы представляем решения для обеспечения стабильности и производительности фоновой работы.
Общая схема запроса выглядит следующим образом:
5.1 Гарантия стабильности
В качестве фона операции различной конфигурации данных операции,стабильностьОсобенно важно.
В дополнение к механизму работы, то есть механизму конфигурации данных рабочего процесса, использованию распределенного кэша и распределенной базы данных для многоуровневого хранения данных, мы также предоставляем SDK-решение для деградации сервисных сбоев. Ниже мы подробно опишем процесс реализации схемы.
Решение для локального кэша SDK
Мы считаем, что внедрение локального кэширования дает несколько преимуществ:
1. Сбросьте нагрузку на трафик центральной службы, больше трафика будет запрошено в память локальной службы.
2. Основываясь на характеристиках бизнеса зарубежных станций iQIYI, внешняя сетевая среда непредсказуема, а среда плохая, чтобы максимально сократить количество сетевых запросов.
3. Хорошо известно, что в случае сбоя центральной службы деловые стороны не должны повторно развертывать и использовать локальный кэш для снижения качества данных.
Однако недостаток решения с локальным кэшем также очень очевиден, то есть после обновления фоновых данных операции бизнес-стороны не могут получать самые последние данные в режиме реального времени. Исходя из этого, мы итеративно работали над следующими версиями SDK. Подробности смотрите на рисунке ниже:
Процесс эволюции внутренней технологии SDK
Техническая архитектура эволюционировала до третьей версии, которая может лучше решить проблему трафика центральной службы, так что трафик фона операции определяется объемом запросов пользователя.Частота обновления фоновых данныхрешение проблемы перегрузки трафика. Однако реализация этой версии также требует решения следующих трудностей:
1. Использование локального кэша каждой бизнес-партией различно, как обеспечить мониторинг системы?
2. Как должна быть разработана схема MQ?
Для проблемы 1 мы реализуем такой механизм внутри SDK, черезscheduledexecutorserviceЗапланированные задачи периодически загружают данные об использовании кеша в библиотеку, чтобы использование локального кеша можно было отображать в зависимости от времени через фоновый интерфейс. Таким образом, можно систематически отслеживать использование кэшей различных бизнес-участников, чтобы обеспечить поддержку данных для приложения и распределения памяти бизнес-участника.
Для проблемы 2 возникают две основные трудности: (1) Машина бизнес-службы, как правило, представляет собой службу с несколькими машинами, поэтому обновление сообщения должно потребляться несколькими серверами, развертывающими один и тот же код в одно и то же время, так чтоУбедитесь, что каждая машина получает последние данные.
(2) Существует несколько операционных битов, но для бизнес-стороны нет необходимости асинхронно запрашивать службу фонового центра операций для обновления данных, когда нет подключенного бита операции для обновления данных (поскольку бизнес-сторона не имеет доступа к эти данные вообще).
Для (1) ясно, что производителем сообщения является действующая фоновая служба, и сообщение должно контролироваться всеми деловыми сторонами, в частности каждой машиной всех деловых сторон. Следовательно, каждая машина должна принадлежать к разным потребительским группам. Поэтому нам нужно найти тот, который отличается для каждой машины.идентифицировать узели используйте этот узел в качестве группы потребителей. Очевидно, что самое лучшее в этом узле — это адрес машины, который может гарантировать, что каждая машина находится в другой группе.
Для (2) мы предоставляем файл конфигурации.Каждая бизнес-сторона должна записать битовое имя операции IQ, используемое каждой деловой стороной в файле конфигурации.Когда приходит сообщение, сначала необходимо определить, является ли битовое имя операции в сообщение включено в файл конфигурации, если нет, то это сообщение игнорируется (пустое потребление), если оно есть, бит операции запроса-ответа обновляется до локальных данных.
5.2 Гарантия производительности
Локальный кеш, предоставляемый вышеупомянутым SDK, может повысить производительность серверных служб, кроме того, мы проделали и другую работу.
В практической конфигурации бита операции мы обнаружили, что изменение данных операции или ситуация, когда оператор изменяет данные операции, очень редки по сравнению с сетевым запросом, таким как базовые данные операции, проанализированные ранее. Таким образом, кэширование данных на стороне клиента позволяет избежать потребления сети клиентом и серверной службой и значительно повысить производительность.
Наш подход заключается в предоставлении версии концепции для каждого рабочего бита данных. Сохраняя время последней операции каждого бита операции, запрос инициируется, когда клиент открывает экран, и время последнего обновления данных всех битов операции возвращается клиенту, и клиент локально кэширует метку времени. , также будет получена метка времени последнего обновления бита операции, возвращенная сервером, и локальная метка будет сопоставлена со служебной, чтобы подтвердить, следует ли обновлять данные каждого бита операции. клиент согласуется с тем, что возвращается операцией background , данные, кэшированные на стороне клиента, отображаются напрямую.
Еще одним преимуществом этой схемы является то, что в экстремальных случаях, таких как сбой внешнего API,Запрет обновления данных в фоновом режиме операции может привести к нормальному отображению бизнес-данных и избежать серьезных сбоев, при которых данные операции исчезают..
Конкретная блок-схема запроса выглядит следующим образом:
6. Резюме и перспективы
Эта статья в основном знакомит с дизайном и разработкой бита операции IQ.Во-первых, в соответствии с обнаруженными болевыми точками предлагаются принципы проектирования фона операции: все данные могут быть настроены, рабочие данные высокодоступны, а производительность интерфейса эффективен. Рассмотреть и реализовать конкретные технические решения согласно предложенным принципам.
Реализация бизнес-полей через Jsonization данных конфигурацииМасштабируемость. Благодаря разработанной модели данных вводятся различные методы работы с данными конфигурации, которые удовлетворяют многоязычной ситуации. За счет предоставления механизма локального кэширования, мониторинга MQ и асинхронного обновления в рамках SDK решается проблема большого трафика при централизации сервисов и проблема несогласованности данных, вызванная кэшированием. В соответствии с конкретной зарубежной ситуацией предлагается соответствующая схема кэширования на стороне клиента.
Операционная позиция IQ была запланирована с мая этого года, которая длилась почти полгода.Из-за вкраплений множества требований к продукту проблема была собрана через два канала самостоятельного использования и обратной связи с пользователями, и в общей сложности две версии были повторены до и после. В настоящее время интерфейс и простота использования фона операции постоянно оптимизируются.
Бит операции IQ широко используется на зарубежных станциях iQIYI с тех пор, как он был запущен более 2 месяцев, и инженерная эффективность была качественно улучшена.В качестве примера возьмем недавнюю конфигурацию кода ошибки.Код ошибки должен возвращать различные коды ошибок. к клиенту.И соответствующий копирайтинг, копирайтинг является многоязычным, и это реализуется через настройку битов операции IQ.в течение 5 минутМожет быть указан соответствующий операционный фон.
Конечно, с итерацией бизнеса и обновлением сценариев в рабочем положении IQ все еще есть некоторые недостатки.В будущем мы продолжим работу в непрерывном итеративном процессе в инженерной практике для решения различных проблем и лучшего обслуживания клиенты операционной позиции IQ и большинство зарубежных пользователей iQIYI.
знакомство с командой:
Группа iQIYI, занимающаяся телефонной связью за рубежом: Отдел зарубежного бизнеса iQIYI отвечает за разработку и обслуживание внутренних телефонных услуг iQIYI за рубежом, предоставляя пользователям стабильные, эффективные и бесперебойные услуги видеоконтента.
Чжэнфэй: Руководитель проекта бита операции IQ, дизайнер и разработчик бита операции IQ.