автор: Lu Dan (Ning Di), присоединился к Alipay в 2011 году и отвечал за такие проекты, как Alipay WAP, Alipass карты и купоны, синхронизация данных синхронизации и т. Д. Существует определенное количество проекта практического опыта и накопления в терминальных базовых услугах Отказ В настоящее время ответственна за оптимизацию и дизайн архитектуры системы MPAAS Server Component System из мобильной платформы мобильной разработки Financial Financial.
Рекомендуемые действия: Как Ant Financial создает интеллектуальные механизмы, такие как прогнозирование поведения пользователей и итоговый анализ, целевая доставка и ABTest? Как использовать автоматический сбор и анализ журналов, чтобы улучшить построение системы онлайн-эксплуатации и обслуживания, отслеживать аномалии приложений в режиме реального времени и формировать замкнутый цикл онлайн-гарантии качества посредством динамического горячего ремонта?
зарегистрироваться:specialty.ant fin.com/activities/…
6 мая в Пекине прошла глобальная конференция по разработке программного обеспечения QCon 2019, организованная InfoQ. Lv Dan (Ning Di), технический эксперт Ant Financial, поделился на конференции «Проектирование системы компонентов Ant Financial для 100 миллионов одновременных сценариев». В соответствии с речью мы организовали следующее:
Сегодня я в основном хочу поделиться с вами основной системой компонентов в мобильном поле. Контент может быть примерно разделен на четыре части. Первая часть является основной системой обслуживания, необходимой для стандартных мобильных исследований и разработок, а вторая часть является Основные компоненты, которые поддерживают параллелизм уровня миллиарда уровней ». Процесс эволюции архитектуры« мобильного доступа », третья часть - это способ справиться с большой продвиженной деятельностью, такой как двойной одиннадцать, двойной двенадцать и китайские новогодние красные конверты, И последняя часть - это основные продукты обслуживания, которые были экспортированы в внешний мир.
0. Мобильная система базовых услуг НИОКР
Во-первых, давайте представим процесс эволюции клиента Alipay. Раньше основными функциями клиента Alipay были перевод, оплата заказа, запрос транзакции и т. д. Это было больше похоже на приложение типа инструмента.Он вынимался только тогда, когда нужно было заплатить, и возвращался, когда он был использованный. В 2013 году, после того как Ant Financial полностью перешла на беспроводную связь, она добавила множество сервисов, таких как Yu'ebao, карты и купоны, исследования и открытия и т. д. По сути, функции на веб-сайте Alipay были перенесены на клиент в той же степени, что и возможно, и Alipay постепенно превратился в клиент уровня платформы. После этого, с быстрым развитием мобильного Интернета, в компании было создано больше приложений, а другие отрасли также запустили большое количество предприятий в сфере мобильного Интернета.Чтобы увеличить количество пользователей и их привязанность, приложения также начали проводить Большое количество бизнес-интеграций привело к рождению суперприложений, которые начали развиваться в направлении экологической модели.
На сегодняшний день количество ежегодных активных пользователей клиента Alipay превышает 800 млн. В сценарии большого продвижения одновременный онлайн-объем превышает 300 млн, одновременный запрос превышает 100 млн, а количество одновременных онлайн-пользователей превышает один миллион в секунду. .
За этими данными должна стоять огромная, сложная и полная система поддержки для поддержки работы Alipay, важной частью которой является базовая система обслуживания мобильных исследований и разработок.
В соответствии с процессом исследований и разработок мы делим систему базовых услуг мобильных исследований и разработок на четыре части: этап исследований и разработок приложений, который в основном включает в себя структуру приложений, основные компоненты, облачные службы и инструменты исследований и разработок; этап тестирования приложений, который в основном включает совместную работу по исследованиям и разработкам. Платформа для тестирования на реальных машинах Платформа для совместной работы в области исследований и разработок включает в себя возможности управления версиями, управления итерациями, компиляции пакетов установки, сборки и упаковки, в то время как тестирование на реальных машинах в основном заменяет ручные услуги, снижает трудозатраты и повышает эффективность тестирования. этап обслуживания в основном включает в себя интеллектуальный выпуск, отслеживание журнала, управление чрезвычайными ситуациями и динамическую настройку; этап эксплуатации приложения, в основном включающий отзывы общественного мнения, анализ в реальном времени, автономные вычисления и интеллектуальный маркетинг.
1. Эволюция архитектуры мобильного доступа Ant
Сегодняшняя тема состоит в том, чтобы поддержать базовые услуги в возрасте до 100 миллионов уровень параллелизма, а мобильный доступ в соответствии со 100 миллионным уровнем параллелизма является основным и наиболее важной ссылкой. Мобильный доступ не является единой системой, а общий термин для полного набора компонентов, в том числе: управление гаечным ключом + управление соединениями, шлюз API, синхронизация данных Push-уведомлений и синхронизации. Это трафик всех мобильных услуг и должен поддерживать Состояние клиентского и поддержки объединения также необходимо выполнить некоторые бизнес-обработки данных.
На самом деле, в начале и нет мобильного доступа к этому аргументу, и эволюция клиента Alipay, как и итерации серверной части мобильного доступа, постепенно развивается. Изначально различные бизнес-сервисы имеют собственный API или напрямую подвергаются возможностям клиента, нет единой архитектуры, нет единой модели, нет единого управления и контроля.
Чтобы решить эту проблему, на этапе all in мы расширили шлюз API, который используется для централизованного управления, и заодно добавили возможность PUSH push. Поскольку в компании много приложений, мы надеемся, что эти возможности можно будет использовать повторно, поэтому с точки зрения архитектуры мы поддерживаем изоморфизм нескольких приложений, и клиент предоставит несколько SDK, которые можно интегрировать в любое время.
【Архитектура шлюза】
На приведенном выше рисунке показана архитектура мобильного API-шлюза.Как видно из рисунка, мы определяем жизненный цикл API как следующие этапы: определение API, разработка API, выпуск API, настройка API, онлайн-доступ к API, работа с API и API в автономном режиме. Мобильный шлюз делит жизненный цикл API на три части: этап поддержки исследований и разработок, этап выполнения и этап управления услугами.
На этапе поддержки исследований и разработок есть четыре основных возможности, а именно Code-Gen, API-MAN, API-Test и API-Mock. В целях повышения эффективности передачи данных API в сети все модели API Ant в настоящее время используют protobuf для сериализации, поэтому для облегчения развития бизнеса API Gateway предоставляет унифицированный инструмент генерации кода на основе файлов proto, а в чтобы уменьшить количество клиентов. Чтобы ограничить размер файла и количество методов на стороне клиента, мы изменили официальный сгенерированный код, который эффективно уменьшает количество избыточных методов и значительно уменьшает размер файла клиента.
На этапе выполнения основные функции включают управление трафиком API, проверку подписи данных, аутентификацию пользователей и маршрутизацию системы интерфейса.
API для обеспечения ежедневной эксплуатации и обслуживания системой управления услугами, в первую очередь возможностью мониторинга API и модели оценки качества API на основе данных в реальном времени, обеспечивая при этом некоторые меры по управлению чрезвычайными ситуациями.
Основной архитектурный дизайн API Gateway — Pipeline.Как мы все знаем, шлюз выглядит как простой элемент управления и маршрутизации API, но включает в себя множество узлов, и функции каждого узла не зависят друг от друга и от бизнеса. По мере развития сети функциональные узлы будут постепенно увеличиваться, и в некоторых сценариях необходимо выполнять различные комбинации узлов. Если используется традиционный цепной вызов, строка выполнения кода будет очень длинной, и ее будет очень сложно расширять и поддерживать. Поэтому мы обращаемся к дизайну конвейера netty и завершаем нашу собственную ссылку на конвейер. Каждый обработчик в конвейере остается независимым друг от друга и может свободно комплектоваться в соответствии с потребностями и конфигурациями, что также обеспечивает хорошую архитектурную поддержку для последующих функциональных расширений;
【Смена кода】
С точки зрения кода мы можем четко чувствовать, что предыдущий вызывающий процесс — это удаленный вызов, которому необходимо знать пути, параметры и т. д., и после унификации взаимодействия всех данных для бизнес-системы этот вызывающий процесс больше похож на локальный вызов, прямой вызов функции, инкапсуляция модели. Таким образом, студенты, изучающие бизнес-исследования и разработки, могут уделять больше внимания написанию логики кода своих собственных бизнес-систем, не обращая внимания на реализацию базовой коммуникации, что значительно повышает эффективность исследований и разработок.
Существует большая разница между мобильной сетью и проводной сетью. Мобильная сеть сложная, и статус пользователя тоже сложный.Это может быть подвал, лифт или другая слабая сетевая среда, и у пользователей очень высокие требования к опыту работы в мобильных сценариях.Например, при совершении платежа пользователь нужно получить результат платежа немедленно. Раньше мы в основном делали улучшения на стороне сервера, но не улучшали на стороне клиента. Для решения пользовательских проблем, проблем с производительностью и улучшения пользовательского опыта мы провели апгрейд, сделали единый шлюз доступа и построили его на базовых компонентах, в то же время мы разработали синхронизацию данных о производительности и расширенный IP возможности планирования. .
【Единый шлюз доступа】
Унифицированный шлюз доступа (ACCGW), который можно понимать как внешний Nginx, представляет собой набор компонентов, разработанных Ant на основе Nginx.Внутренне мы называем его Spanner, который в основном отвечает за обработку небизнес-логики в Архитектура доступа, в основном включая разгрузку SSL, анализ протокола MMTP, сжатие и распаковку данных, обслуживание длинных клиентских TCP-соединений, главный контроль над трафиком доступа, маршрутизацию пакетов данных и доступ к журналу клиента. Такие компоненты, как шлюз API, PUSH push и синхронизация данных, находятся в его тени.
【Оптимизация сетевого протокола】
Полное название протокола MMTP — Ant Mobile Transmission Protocol, который основан на структуре данных TLV.Преимущество этой структуры данных заключается в том, что эффективность подупаковки и распаковки очень высока, она основана на двоичном коде, а стоимость хранения относительно низко. В то же время он также удовлетворяет мультиплексированию каналов нескольких компонентов клиента.Конечно, MMTP также имеет некоторые собственные функции с клиентом.В то же время мы также добавили много новых функций, таких как интеллектуальное соединение стратегия. Поскольку статус сети пользователя в мобильной среде не очень надежен, если это традиционный метод подключения, он может не удовлетворить все запросы RPC, поэтому мы внесли улучшения в политику. Используйте длинное соединение как можно чаще, когда можно использовать длинное соединение.Если длинное соединение не может быть подключено или мигает, мы попытаемся использовать короткое соединение.Короткое соединение может соответствовать срочным данным RPC в то время. В то же время мы также будем использовать некоторые стратегии для одновременного установления соединения.Сеть оператора обычно использует то соединение, которое подключается первым.После соединения мы будем использовать стратегию интеллектуального пульса для захвата сердцебиения разных операторов и разных регионов для поддержания связь разница во времени.
В процессе установления параллельного соединения часто бывает такое явление, что клиент имеет несколько длинных соединений одновременно.Пакеты данных могут передаваться посередине.Если их сразу разъединить, то пакеты данных будут потеряны, что может иметь влияние на бизнес, поэтому мы добавили гибкое отключение, чтобы гарантировать безопасную доставку пакетов, которые могут находиться в пути. Кроме того, после установления нескольких соединений у клиента может возникнуть ситуация, а сервер вовремя этого не заметит и не сможет узнать, хорошее это соединение или плохое. Поэтому мы добавили мониторинг поддельного соединения.Когда пакет данных распространяется, он несет серийный номер.После того, как клиент отчитывается, если серийный номер возвращается, это доказывает, что соединение доступно.В противном случае мы рассматриваем соединение с находиться в состоянии ожидания. Разорвите соединение в подходящее время.
MTLS — это транспортный протокол Ant Mobile Security, основанный на TLS1.3. Пока мы это делали, TLS 1.3 официально не выпускался, но мы узнали о некоторых его функциях и включили некоторые функции в дизайн. Например, используется метод рукопожатия 1RTT ECDHE. 1RTT ECDHE основан на наборе шифрования ECC.Самая большая особенность ECC заключается в том, что строка ключа относительно мала.Меньшие данные имеют большие преимущества с точки зрения перемещения, такие как повышение эффективности передачи и снижение затрат на хранение. Размер пакета является особой проблемой в мобильном мире во время хранения или передачи. Из-за этого мы выбрали алгоритм сжатия ZSTD, ZSTD имеет очень большую степень сжатия, и при этой степени сжатия эффективность сжатия и распаковки хорошая. Кроме того, в некоторых бизнес-сценариях, которые могут поддерживать воспроизведение, мы также добавили стратегию 0RTT для максимально быстрой отправки данных от клиента на сервер. Благодаря приведенной выше оптимизации средняя эффективность отклика RPC повышается в 5–6 раз.
【Синхронизация данных SYNC】
Синхронизация данных SYNC звучит немного непривычно, но ее можно понять как усовершенствованную версию PUSH. Он основан на TCP, двунаправленной передаче. Хотя традиционный RPC может решить подавляющее большинство проблем, в некоторых сценариях он имеет недостатки. Например, после запуска клиента ему необходимо определить, есть ли у сервера данные через RPC-запрос. На самом деле в 90% случаев интерфейс запроса не изменился или клиент возвращаемых данных уже существует, так что этот процесс очень избыточен. Помимо избыточности данных, избыточны и запросы, так как никаких изменений не произошло, а вызовы в принципе можно сохранить.
В конце концов, в конце концов, мы сделали некоторые оптимизации опыта, такие как возможность предварительной нагрузки. Когда клиент запускается, предварительная загрузка данных срабатывает. Хотя он не входит в модуль, чтобы улучшить пользовательский опыт, клиент отправляет много RPC запросы., Что также вызвало большое количество избыточных одновременных запросов.
Другим недостатком является то, что клиент не может активно воспринимать изменения данных сервера.Например, в сценарии чата пользователь ждет взаимодействия.Если RCP используется для регулярного извлечения, стоимость клиента и сервера будет очень высокий, и общий отклик будет очень высоким.Время также медленнее. Благодаря режиму push SYNC, когда сервер генерирует данные, данные могут быть переданы клиенту на основе TCP, и клиент может получить данные для бизнес-рендеринга в первый раз, например, платеж кодом сканирования Alipay и лицом к лицу. -лицевая оплата.Синхронизируются ли данные результата через сервис SYNC.
Базовым ядром SYNC является oplog, который похож на binlog в mysql и представляет собой моментальный снимок всех инкрементных данных. SYNC будет генерировать уникальный и добавочный номер версии для каждого оплога, а затем вычислять разницу между двумя концами, записывая текущий номер версии данных клиента, и синхронизировать только данные разницы. Поскольку SYNC основан на TCP, он может активно передавать в обоих направлениях, чтобы обеспечить упорядоченную, надежную и пошаговую передачу данных в реальном времени. В то же время в сценарии срабатывания на стороне клиента SYNC основывается не на бизнес-сценариях, а на событиях, таких как установление соединений, вход в систему и переход из фона в активный режим. клиенту не нужно делать какие-либо другие RPC-запросы, что значительно снижает количество клиентских запросов и избыточную передачу данных, что не только повышает эффективность и производительность в реальном времени, но и косвенно снижает нагрузку на систему.
【Мобильный диспетчерский центр】
Самое главное для клиентских запросов — найти правильный IP в первый раз и отправить запрос. В прошлом эти задачи, как правило, выполнялись с помощью традиционной DNS, но традиционная DNS будет иметь некоторые проблемы, такие как перехват DNS, сбой разрешения DNS, различная эффективность разрешения DNS у разных операторов и т. д., разрешение DNS должно потреблять дополнительный RTT.
В ответ на эти ситуации мы настраиваем мобильный диспетчерский центр, который основан на HTTPDNS, и на этой основе добавляем информацию о пользовательском разделе. Что такое пользовательский раздел? В условиях 100-миллионного параллелизма сервер точно будет не в одном машинном зале, а может быть в нескольких машинных залах, а внутри машинного зала есть логические разделы. Только сервер знает, к какой логической области принадлежит пользователь, а сам клиент не может этого воспринять. Когда входит пользователь из определенного раздела, если он находится не в правильном разделе и его необходимо перенести в другие разделы для обработки бизнеса, невозможно использовать традиционный DNS, поскольку невозможно определить, к какому списку IP-адресов принадлежит пользователь. к. . Модель данных раздела HTTPDNS+ позволяет клиенту быстро получить наиболее точный IP-адрес.В то же время клиент может также выполнить проверку качества и проверки достоверности этого IP-адреса, а также определить оптимальный IP-адрес перед запросом. Кроме того, HTTPDNS также может поддерживать развертывание зарубежных узлов. HTTPDNS не должен быть менее эффективным, чем DNS, потому что у него все еще есть DNS для покрытия прибыли.Как только возникает проблема с HTTPDNS, он переключается на DNS для решения.
Вышеупомянутый процесс эволюции отвечает подавляющему большинству повседневных потребностей, но у Alipay есть много сценариев больших рекламных акций, и игровой процесс каждой большой акции отличается, а пик сосредоточен в один момент. Для этого сценария мы вывели новые модели, одна — децентрализация API-шлюза, другая — механизм SYNC-PULL, а третья — вычислительная модель SYNC-Bucket.
【Децентрализация шлюза】
Основная проблема, решаемая децентрализацией шлюза, — это стоимость. В сценарии большого продвижения объем бизнеса продолжает расти, и пиковое значение может быть очень высоким. Но пик только на мгновение, а в остальное время машина простаивает, что является огромной тратой ресурсов. Чтобы гарантировать, что большое продвижение не рухнет, машина не может быть уменьшена, поэтому нагрузка на приложение очень велика.
Если это одна точка, то будут проблемы со стабильностью. Если на шлюзе возникают какие-то ошибки при публикации, это может повлиять на обработку всех бизнес-процессов. Кроме того, если есть проблема с одним интерфейсом, у клиента бесконечный цикл и другие проблемы, это также повлияет на бизнес-процесс других систем. Перед лицом вышеуказанной ситуации мы можем компенсировать эти риски, децентрализовав шлюз.Если есть проблема только с одной системой, другие бизнес-проблемы не будут вызваны сетевыми проблемами.
[Распространение чтения SYNC-PULL]
Зачем нужна диффузия чтения SYNC-PULL? Поскольку у Alipay много крупных продавцов V, и у каждого продавца много внимания пользователей, ему необходимо регулярно или нерегулярно публиковать новости о работе. Если, согласно сценарию SYNC, одна часть данных будет предоставлена каждой проблеме посредством распространения записи, это не только приведет к нерациональному использованию хранилища, но и будет неэффективным. Если предположить, что у продавца 500 миллионов подписчиков, для сохранения всех 500 миллионов данных потребуются десятки минут. Кроме того, из-за большого количества наших мерчантов все конкурируют за этот ресурс, и могут быть очереди. Для продавцов невозможно сразу достичь пользовательской стороны действия, а для серверной стороны сообщение может быть точно таким же, что приводит к пустой трате памяти. Даже если используется кеш, для каждого пользователя необходимо хранить весь индекс, что по-прежнему требует очень высокой TPS данных.
Чтобы решить вышеупомянутые проблемы, мы перешли на режим распространения чтения, абстрагировали его в отношения озабоченности, абстрагировали каждого продавца в тему, а затем поместили все данные в тему. Поскольку пользователи уделяют меньше внимания большому V, а частота производственных данных большого V невелика, эффективный набор данных не особенно велик, поэтому данные сверхбольшого V можно сначала поместить в кеш, а затем быстро поиск по двоичному индексу.Взаимоотношения внимания под адресом пользователя, а добавочные данные передаются клиенту через исходный механизм SYNC. Таким образом, исходное хранилище на 100 миллионов уровней стало единым хранилищем, а исходное время отклика в десятки минут стало вторым уровнем, а эффективность и удобство значительно улучшились.
Ранее, когда мы сделали синхронизацию, мы хотели, чтобы каждый бизнес был относительно независимым и относительно изолированным, а расчеты проводились независимо. В то время было не так много бизнес-сценариев, но все больше и больше услуг доступны позже, было почти 80 бизнес-сценариев, и каждый бизнес был рассчитан независимо. Клиент на основе событий. После установления соединения он должен выполнить 80 независимых бизнес-расчетов. В случае большого продвижения 1 миллиона в секунду он может легко достичь уровня 100 миллионов. Это очень важно для баз данных , Приложения, кэширует и т. Д. Давление очень большое, и этот метод не может соответствовать устойчивому развитию в будущем.
Для решения этих проблем мы абстрактны несколько категорий для исходных вычислительных свойств. Например, несколько категорий данных, основанных на пользовательском измерении, измерении устройства, одноразовой, многосекретной синхронизации и глобальной конфигурации пользователя, абстрагируются на несколько абстрактных моделей. Мы предварительно считаем, что есть 5 ведер, и все расчеты выполняются на основе метода ведра. Если добавляется новый бизнес, он будет классифицирован в определенном ведре в соответствии с его характеристиками.
Кроме того, в сценарии большого продвижения будут высокоприоритетные услуги, поэтому необходимо реализовать некоторые конкретные текущие стратегии ограничения. В ответ на эту ситуацию сегменты могут динамически увеличиваться или уменьшаться, а бизнес может переключаться между сегментами в любое время. После запуска корзины объем наших вычислений упал более чем на 80%, в следующие 2-3 года количество предприятий увеличилось с 80 до 300, а количество серверов не увеличилось. В целом, улучшение производительности по-прежнему очень очевидно.
2. Как справиться с большой рекламной сценой
Предыдущий контент в основном посвящен тому, как компонентный дизайн мобильного доступа поддерживает сотни миллионов сценариев. Давайте поговорим о том, как эффективно справляться с масштабной рекламной деятельностью.
[Способ справиться с большой рекламной сценой: работа ногами]
Благодаря многолетнему опыту в продвижении мы технически усовершенствовали несколько шагов, чтобы справиться с продвижением: сначала студенты-бизнесмены устанавливают бизнес-цели и определяют бизнес-геймплей; индикаторы и определить соответствующее техническое решение в соответствии с возможностями, процессами и характеристиками соответствующих систем, а шаги для определения технического решения в основном следующие: анализ каналов, оценка пропускной способности, оптимизация производительности, решение по управлению потоком, стратегия предварительного планирования и определение эластичных правил дорожного движения. После определения и завершения технического решения самое главное — провести стресс-тест всей ссылки, через теневых пользователей и теневые таблицы, чтобы провести стресс-тест полной ссылки в производственной среде. Проблемы и узкие места обнаруживаются в ходе непрерывного стресс-тестирования, и стресс-тестирование проводится снова после оптимизации до тех пор, пока технические цели не будут достигнуты; после того, как все звено завершает показатели стресс-тестирования, проводятся несколько раундов учений для моделирования реальных бизнес-сценариев и проверки технологий. точность плана, после чего, в соответствии с реальными потребностями, выбрать время для выхода на большую стадию продвижения. На этом этапе основная работа студентов НИОКР заключается в сотрудничестве с эксплуатацией и техническим обслуживанием для реализации плана, наблюдения за изменениями различных показателей в период продвижения и подтверждения необходимости чрезвычайной ситуации в соответствии с мониторингом. Конечно, план на случай непредвиденных обстоятельств также необходимо проверить в предыдущем упражнении. После окончания большой акции необходимо откатиться и проверить план и стратегию действий в чрезвычайных ситуациях, чтобы большая акция действительно закончилась. В то же время, что более важно, нам необходимо пересмотреть и пересмотреть ежегодное продвижение, чтобы найти недостатки и исправить их в последующих мероприятиях.
[Способ справиться с большой рекламной сценой — управление потоком]
Во время проведения большой рекламной акции наиболее важным является контроль потока. Для студентов-технологов система должна выжить в случае большой силы, чтобы способствовать наибольшей поддержке, система управления потоком является самым мощным барьером. Поскольку роль системы в крупных рекламных мероприятиях зависит от срочности бизнеса, размер кластера варьируется, поэтому при большом продвижении обычно жертвуют некоторыми характеристиками производительности, чтобы освободить место для основного звена, например, заболачивание, порог сжатия, последовательное сообщение, например .
Управление трафиком также будет разделено на несколько уровней: на верхнем уровне LVS будет осуществлять контроль на миллиардном уровне над VIP, на уровне шлюза доступа он будет выполнять управление потоком на миллиардном уровне в зависимости от количества подключений и пакетов и Уровень шлюза API будет осуществлять контроль. Десятки миллионов уровней контроля. На этих слоях обычно достаточно простого подсчета. На бизнес-уровне, особенно на бизнес-уровне с низким и средним трафиком, обычно используются сегменты токенов и методы ограничения распределенного тока. Затем на API-шлюзе вы также можете выполнять некоторые пользовательские сценарии, и макет возвращает результат, чтобы противостоять некоторым запросам бизнес-системы.
【Автоматизированный тест на реальной машине】
В дополнение к основному звену нам также нужны некоторые логистические услуги. Например, в процессе тестирования необходима автоматизация, особенно тестирование с моделированием реальных машин, чтобы компенсировать часть ручного труда. В нашем компьютерном зале развернуты тысячи мобильных телефонов, и обычно проводятся некоторые автоматизированные тесты эксплуатации и обслуживания, включая установку и удаление установочных пакетов, снижение производительности и функциональное тестирование. Помимо автоматизированного тестирования, он также играет роль автоматического утверждения и сервисной инспекции, которые используются для обнаружения небольших программ и своевременного обнаружения проблем. Автоматическая тестовая платформа позволяет сократить более 60% повторяющихся затрат ручного труда.
【Интеллектуальная публикация клиентов - обеспечение безопасности клиентов】
Если вы хотите убедиться, что клиент защищен от дурака, тогда ядром является процесс в градациях серого.После того, как процесс в градациях серого завершится, мы можем выпустить его в производственную среду.
Умный выпуск в основном поддерживает различные пакеты выпуска клиента, включая установочные пакеты, автономные пакеты и небольшие программные пакеты. За годы выпуска мы также накопили некоторые шаблоны, такие как пользователи в градациях серого, покрытие в градациях серого и так далее. В градациях серого мы можем выбрать определенный шаблон и использовать автоматизированный процесс вместо ручной обработки по установленной логике.
【Анализ общественного мнения - своевременное получение отзывов пользователей】
После того, как клиент выпущен, студенты-бизнесмены должны быть очень обеспокоены мнением пользователей и реакцией рынка, в то время как студенты-технари надеются получить реальную обратную связь от пользователей как можно скорее. Для удовлетворения этих потребностей используется система анализа общественного мнения.Систему общественного мнения можно разделить на четыре основные части: сбор данных.Основными каналами сбора являются данные из крупных медиа-центров, обзоры рынка приложений, функции обратной связи для встреч и центров удовлетворенности клиентов. ; содержимое данных может включать в себя различные горячие темы, горячие события и основные производственные проблемы; хранение данных в настоящее время поддерживается четырьмя основными блоками: метаданные обычно могут быть реляционной базой данных, данные документа — MongoDB, а элементы, собранные сканером, передаются через MQ, Все данные в конечном итоге попадают в ES для поиска и базового анализа; расчет данных больше касается анализа данных в ES с помощью файловых алгоритмов и, наконец, создает различные тенденции и различные события, рейтинги тем и в то же время для каждого пользователя обратная связь, соответствующее ответственное лицо может быть уведомлено в режиме реального времени.
Мобильный анализ, о котором мы здесь говорим, в основном основан на возможностях анализа данных скрытой точки журнала клиента. Клиент должен иметь стандартный SDK для встраивания для сбора различных фреймворков и встраивания контейнеров Native, H5 и небольших программ, а также должен поддерживать встраивание сервисов, адаптированных для бизнеса. В то же время, чтобы эффективно повысить производительность сервера в сценарии большого продвижения, необходимо принять некоторые меры для динамического управления записью и отчетом о скрытых точках.После завершения скрытых точек на стороне клиента они будет сообщено службе в нужное время Шлюз мобильного журнала на терминале (шлюз мобильного журнала также был постепенно включен в мобильный доступ). После того, как журнал клиента передается на сервер, он может быть выведен шлюзом журнала в файл журнала сервера или доставлен компоненту сообщений для использования и обработки другими платформами, включая вычислительные платформы в реальном времени, такие как Jstorm, kepler и др. Flink, а также могут быть доставлены на офлайн-платформы для обработки больших данных, такие как Spark и odps, для дальнейшего анализа. В качестве базового компонента, в дополнение к сбору и синхронизации журналов, Mobile Analytics также выполняет некоторый базовый анализ данных журналов вывода фреймворка, анализ поведения (например, ежедневные действия, новые добавления и наличие потоковой передачи), анализ страниц (время пребывания, участие). , flash Он также предоставляет возможности обратного отслеживания журналов и извлечения журналов для студентов, занимающихся исследованиями и разработками, для устранения и анализа проблем. Конечно, эти данные можно использовать для различного бизнес-анализа, и форма анализа полностью зависит от того, как бизнес-сторона хочет их использовать.
3. Основные сервисные продукты, экспортируемые во внешний мир.
[Выход технического компонента продукта: зрелый, открытый]
После многих лет напряженной работы наши основные возможности также накопили много технической продукции, которую можно экспортировать. Эти технические продукты охватывают все этапы от разработки APP и тестирования до эксплуатации и обслуживания до эксплуатации, включая инфраструктуру на стороне клиента, базовые компоненты на стороне клиента, базовые облачные службы (такие как шлюз API, синхронизация данных SYNC, PUSH-уведомление) и открытые инструменты, есть подключаемые модули, есть платформа для совместной работы в области исследований и разработок, сопровождающая тестирование исследований и разработок для итеративного управления, компиляции, построения, упаковки, платформа для тестирования реальных машин, а также интеллектуальная публикация, управление журналами, управление в чрезвычайных ситуациях, необходимые для работы приложения. и фаза обслуживания, а также используются для работы приложения., различные продукты для анализа данных и маркетинговой доставки. Эти возможности были экспортированы в несколько партнерских приложений Ant International (India paytm, Малайзия, Индонезия, Филиппины и т. д.), сотни приложений корпоративного уровня в общедоступном облаке и десятки финансовых приложений в частном облаке.
Наша цель - зрелая, открытая для продвижения экология Интернета, чтобы строить с партнерами.
【Универсальная платформа для исследований и разработок — mPaaS】
Чтобы помочь партнерам быстро и эффективно создавать собственные приложения, мы также запустили универсальную мобильную платформу для исследований и разработок — mPaaS. mPaaS включает в себя упомянутые выше базовые возможности.В то же время он поддерживает общедоступные и частные облака.mPaaS — это не только результат технологии, но и результат производственного опыта и операционных концепций.
| Рекомендуемые действия
Как Ant Financial создает интеллектуальные механизмы, такие как прогнозирование поведения пользователей и итоговый анализ, целевая доставка и ABTest? Как использовать автоматический сбор и анализ журналов, чтобы улучшить построение системы онлайн-эксплуатации и обслуживания, отслеживать аномалии приложений в режиме реального времени и формировать замкнутый цикл онлайн-гарантии качества посредством динамического горячего ремонта?
Отсканируйте QR-код, чтобы зарегистрироваться сейчас 18 мая Салон mPaaS CodeDay # 2 Пекинская станция:
Прошедшее чтение
«Начало | Обзор системы основных компонентов сервера mPaaS компании Ant Financial»
«Обзор системы основных компонентов сервера mPaaS компании Ant Financial: мобильный шлюз API MGS»
«Основные компоненты сервера mPaaS: архитектура MPS для отправки сообщений и разработка процессов»
«Основные компоненты сервера mPaaS: анализ архитектуры службы мобильного анализа MAS»
Обратите внимание на наш общедоступный номер, получите первую практику технологии MPAAS для галантереи.
Групповые гвозди: гвозди Поиск по номеру группы "23124039"
С нетерпением жду вашего присоединения~