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

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

Примечание 2. Дизайн пользовательского центра, описанный в этой статье, не имеет ничего общего с собственным бизнесом vivo.

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

1. Сервисная архитектура

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

Следовательно, исходя из бизнес-характеристик, мы можем разделить пользовательский центр на 3 независимых микросервиса: сервис шлюза, базовый сервис и асинхронный сервис потребителя. Служба шлюза, предоставляющая службу http, агрегирующая различную бизнес-логику и сервисные вызовы, такие как контроль рисков или SMS, которые необходимо проверять при входе в систему; основная служба, обрабатывающая простую бизнес-логику и хранилище данных, основная служба находится в конце call link, которые почти не зависят от вызова других сервисов, таких как проверка токенов или получение информации о пользователе, они полагаются только на Redis или базы данных, тогда как асинхронные сервисы-потребители обрабатывают и потребляют асинхронные сообщения. Подробности будут приведены ниже.

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

2. Дизайн интерфейса

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

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

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

Как это сделать? С одной стороны, мы делаем таблицу с основной информацией о пользователе простой. Информация о пользователе будет включать такие поля, как userId, номер мобильного телефона, пароль, аватар, псевдоним и т. д. Если вся информация о пользователе хранится в таблице, таблица будет очень большой, и изменить поля будет крайне сложно. . Поэтому необходимо разделить таблицу пользователей и сохранить основную информацию в таблице пользователей, такую ​​как идентификатор пользователя, имя пользователя, номер мобильного телефона, пароль, значение соли (сгенерированное случайным образом) и т. д., а также некоторую информацию, такую ​​как пол, аватар. , никнейм и т.п. хранятся в таблице пользователей в даташите.

С другой стороны, нам нужно сократить основную ссылку входа в систему, чтобы она зависела только от библиотеки чтения. В обычных обстоятельствах после входа пользователя в систему необходимо записать информацию о входе пользователя и вызвать службы, такие как контроль рисков или SMS. Что касается ссылки для входа, проблемы с любой ссылкой могут привести к тому, что пользователь не сможет войти в систему. Итак, как мы можем получить самую короткую ссылку? Метод заключается в том, что зависимые службы могут быть автоматически деградированы. Например, если есть проблема с проверкой защиты от мошенничества, она автоматически понизится и будет использовать свою политику по умолчанию.В крайних случаях выполняется только проверка пароля.После приостановки основной библиотеки информация о пользователе может быть считана из рабская библиотека.

Наконец, есть проверка безопасности интерфейса. Для интерфейса приложения нам нужно сделать антиповтор и проверку подписи. Вы можете быть знакомы с проверкой подписи, но вы можете быть относительно незнакомы с концепцией защиты от повторного воспроизведения. Антиповтор, как следует из названия, предотвращает повторную отправку запросов. Запросы пользователей могут быть запрошены только один раз в течение определенного периода времени. Даже если пользовательский запрос перехвачен злоумышленником, запрос не может быть повторен в течение определенного периода времени. Если злоумышленник захочет подделать запрос пользователя и отправить его снова, извините, запрос не пройдет. Благодаря поддержке больших данных в сочетании с терминалом мы также можем хранить каждый портрет поведения пользователя в системе (или вызывать сторонние сервисы). После того, как пользователь инициирует запрос, наш интерфейс выполнит проверку, такую ​​как проверка номера мобильного телефона, аутентификация по реальному имени, проверка лица или живого пользователя на основе портрета пользователя.

3. Подтаблица подбиблиотеки

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

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

Во-вторых, мы можем использовать характеристики внешнего и внутреннего бизнеса, чтобы относиться к ним по-разному. Для внешнего доступа на стороне пользователя: пользователь входит в систему через имя пользователя/мобильный телефон или запрашивает информацию о пользователе через uid. Доступ к информации на стороне пользователя обычно представляет собой запрос одного фрагмента данных.Мы можем решить проблему согласованности и высокой доступности, запрашивая несколько раз с помощью индексации. Для фонового доступа на стороне операции: запрос на основе возраста, пола, периода времени входа в систему, периода времени регистрации и т. д., в основном, пакетные запросы на пейджинг. Однако, поскольку это внутренняя система, объем запросов невелик, а требования к согласованности невысоки. Если запрос на стороне пользователя и на стороне операции использует одну и ту же базу данных, запрос сортировки на стороне операции увеличит нагрузку на ЦП всей базы данных, снизит эффективность запроса и повлияет на сторону пользователя. Следовательно, база данных, используемая на стороне операции, может быть той же автономной библиотекой MySQL, что и на стороне пользователя.Если вы хотите повысить эффективность запросов на стороне операции, вы можете использовать нереляционную базу данных ES. ES поддерживает фрагментацию и репликацию, что удобно для горизонтального разбиения и расширения.Репликация обеспечивает высокую доступность и высокую пропускную способность ES, а также может удовлетворить требования к запросам со стороны эксплуатации.

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

1. Когда пользователь регистрируется, в соответствии с номером мобильного телефона пользователя используйте функцию для генерации N-битного гена mobile_gen, так что mobile_gen=f(mobile);
2. Генерировать M-битный глобально уникальный идентификатор в качестве идентификатора пользователя;
3. Объединение M и N и присвоение их пользователю в качестве UID;
4. Возьмите остаток в соответствии с N бит, чтобы вставить в конкретную базу данных;
5. При поиске пользовательских данных взять остаток последних N бит пользовательского UID в конечную библиотеку.

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

4. Гибкий переход на более раннюю версию токена

После входа пользователя в систему еще одним важным моментом является создание и проверка токена. Токен пользователя делится на две категории. Одна из них — это токен, сгенерированный при входе в систему через веб-интерфейс. Этот токен можно комбинировать с файлом cookie для достижения эффекта единого входа. Здесь я не буду вдаваться в подробности. Другой тип — это токен, сгенерированный при входе в приложение. После того, как пользователь введет имя пользователя и пароль в нашем приложении, сервер проверит имя пользователя и пароль пользователя.После успеха версия и секретный ключ алгоритма шифрования будут получены из центра конфигурации системы, а также идентификатор пользователя и номер мобильного телефона будет организован в определенном формате., случайный код и время истечения срока действия, после серии шифрования токен генерируется и сохраняется в кэше Redis. Проверка токена заключается в объединении идентификатора пользователя и токена и проверке его существования в Redis. Что делать, если Redis недоступен? Здесь есть высокая доступность и автоматический даунгрейд. Когда Redis недоступен, сервер сгенерирует токен специального формата. При проверке токена будет принято решение о формате токена.

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

5. Безопасность данных

Безопасность данных очень важна для пользовательского центра. Конфиденциальные данные должны быть десенсибилизированы, а пароли должны быть зашифрованы несколько раз. Хотя у приложения есть собственная политика безопасности, если хакер будет ограничен перед входом в систему, безопасность приложения будет значительно повышена. Случаи утечки открытых текстовых данных пользователей в Интернет происходили часто, поэтому осведомленность крупных предприятий о безопасности данных также была поднята на беспрецедентный уровень. Даже если используются методы шифрования MD5 и соли, метод радужной таблицы все равно можно использовать для взлома. Так как же пользовательский центр сохраняет информацию о пользователе?

Прежде всего, как упоминалось выше, данные для входа, такие как пароль пользователя и номер мобильного телефона, отделены от другой информации и находятся в разных базах данных. Во-вторых, пароль, установленный пользователем, занесен в черный список.Пока слабый пароль соответствует условиям, отправка будет отклонена, потому что независимо от того, какой метод шифрования используется, слабый пароль чрезвычайно легко взломать. Зачем? Поскольку у людей очень плохая память, большинство людей всегда наиболее склонны выбирать в качестве паролей дни рождения, слова и т. д. Чистое 6-значное число может сгенерировать 1 миллион различных паролей, а комбинация 8 строчных букв и цифр может сгенерировать примерно 2,8 триллиона различных паролей. Базы паролей с масштабом 7,8 триллиона достаточно, чтобы покрыть пароли большинства пользователей.Возможно иметь такую ​​базу паролей для разных алгоритмов шифрования, поэтому большинство веб-сайтов рекомендуют пользователям использовать более 8 цифр и букв для паролей. . . . Конечно, если, с одной стороны, добавляется значение соли, а с другой стороны, ключ хранится отдельно, сложность взлома возрастет в геометрической прогрессии.

Наконец, его можно зашифровать с помощью bcrypt/scrypt. Алгоритм bcrypt реализован на основе алгоритма блочного ключа Blowfish.bcrypt внутренне реализует случайное соление.После использования bcrypt зашифрованный шифртекст каждый раз разный, а процесс хеширования инициализируется с использованием памяти. Из-за использования памяти, хотя она быстро работает на ЦП, параллельные операции на графическом процессоре не выполняются быстро. Поскольку в новую FPGA встроена большая оперативная память, проблема ввода-вывода с интенсивным использованием памяти решена, но сложность взлома по-прежнему невелика. Алгоритм scrypt компенсирует недостаток алгоритма bcrypt, который экспоненциально увеличивает нагрузку на ЦП и использование памяти. Алгоритмы bcrypt и scrypt могут эффективно противостоять радужным таблицам, но повышение безопасности приводит к снижению производительности входа пользователей. Вход и регистрация пользователей не являются параллельным интерфейсом, поэтому влияние не будет особенно большим. Таким образом, безопасность и производительность должны быть сбалансированы в соответствии с типом и размером бизнеса.Не все приложения должны использовать этот метод шифрования для защиты паролей пользователей.

6. Дизайн асинхронного потребления

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

Семь, гибкий и разнообразный мониторинг

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

8. Резюме

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

Автор: техническая команда vivo game