Всем привет! Для меня большая честь иметь возможность поделиться опытом и дизайнерскими идеями, накопленными в процессе фоновой разработки за эти годы, написав сообщение в блоге.
Модульная конструкция
В соответствии с бизнес-сценарием бизнес разделен на независимые модули, а внешние сервисы предоставляются через интерфейс, что снижает сложность и связанность системы, а также реализует возможность повторного использования, простоту обслуживания и легкое расширение.
Практические примеры в проекте:
До:
В приложении для обратной покупки есть функция [Мой красный конверт].Данные пользователя в красном конверте поступают от нескольких предприятий, таких как: приглашение новых пользователей зарегистрироваться для получения красных конвертов по 100 юаней, двойных красных конвертов для крупных рекламных мероприятий и другие красные конверты для различных действий, несколько В бизнесе мероприятий реализован набор механизмов для сбора красных конвертов и распределения вознаграждений в красных конвертах с различными правилами, в результате чего красные конверты неуправляемы, не могут использоваться повторно и их трудно поддерживать и расширять.
После:
- Реконструкция бизнеса в красных конвертах
- Красными конвертами можно управлять в фоновом режиме
- Управление информацией о красных конвертах, можно добавлять, редактировать, настраивать правила для красных конвертов и управлять красными конвертами пользователей.
- Унифицированная обработка распределения наград в красных конвертах
- Доступ к службам приложений должен быть сосредоточен только на выдаче пользователям красных конвертов.
Краткое описание дизайна
Before VS After
Иногда бизнес-требования, предлагаемые продуктом, не учитываются в этом отношении.В сочетании со сценарием и будущими потребностями расширения во время обсуждения спроса предлагается модульный план проектирования, который может помочь в разработке продукта.
Общая абстракция службы
Подобные функции часто встречаются при разработке проектов, но разные разработчики реализуют их по отдельности, либо из-за невозможности их повторного использования и повторной разработки, что приводит к повторной разработке аналогичных функций, поэтому нам необходимо иметь возможность извлекать независимые сервисы.Функции разделены на достичь эффекта повторного использования и может постоянно расширяться и улучшаться, что экономит последующие затраты на разработку, повышает эффективность разработки и прост в обслуживании и расширении.
Практические примеры в проекте:
Before
В бизнесе часто необходимо уведомлять пользователей о такой информации, как: SMS-уведомление о времени, push-сообщение APP, уведомление WeChat и т. д.
Когда разработчик получил функцию уведомления в запросе, он не рассматривал последующее расширение, он подключился к сторонней платформе уведомления информации, а затем просто инкапсулировал метод уведомления информации.Когда было подобное требование уведомления информации в В будущем другой разработчик обнаружил, что метод уведомления не может удовлетворить их собственные потребности, а затем они понимают, что сторонняя платформа переупаковала метод уведомления или в последующих требованиях была добавлена функция уведомления о времени. разработчик реализует функцию уведомления о времени для бизнеса, но использовать ее можно только в своем бизнесе.Использование, другие сервисы не доступны, никто не будет делать разделение этой функции, и она со временем перерастет в повторную разработку функций , и его непросто поддерживать и расширять
After
При столкновении с таким общим требованием к услуге, которое может быть извлечено, он подтвердит с продуктом, будут ли подобные потребности в будущем, а затем предложит, чтобы это блочное требование было абстрагировано в общую услугу, чтобы облегчить последующее обслуживание и расширение.
Краткое описание дизайна
Before VS After
Архитектурные независимые услуги
Некоторые требования в процессе разработки проекта не связаны с бизнесом проекта, такие как: сбор привычек поведения пользователей, сбор кликов по экспозиции продукта, сбор данных и предоставление их в BI для вывода статистического отчета, публичное продвижение нового бизнеса (youzi улица и возвращение в общественное пользование), аналогично Для этого требования мы объединяем сценарии приложений, учитываем независимость сервисов и потребности в будущем расширении, структурируем независимые проекты для обслуживания, а независимое распределенное развертывание на сервере не влияет на существующий основной бизнес. ресурсы сервера.
Практические примеры в проекте:
Архитектура независимой службы отслеживания поведения пользователей, объем запросов этой службы оценивается до разработки, и будет относительно большое количество одновременных запросов.
Схема архитектуры:
- Конструкция проекта выбирает использование nodejs в качестве сервера.
- Единый процесс, основанный на управляемом событиями и неблокирующем вводе-выводе, поэтому он очень подходит для обработки параллельных запросов.
- Балансировка нагрузки: модуль кластера/PM2
- Независимый сервис архитектуры nodejs
- Предоставление сервисного интерфейса клиенту
- Интерфейс не работает напрямую с БД, что обеспечивает стабильность в условиях параллелизма.
- Асинхронное хранение данных
- Перенести данные из: очереди сообщений => mysql через программу
- nodejs+express+redis(list)/mq+mysql
Схема архитектуры службы службы отслеживания поведения пользователей
Высокая параллельная оптимизация
В дополнение к необходимости вертикального и горизонтального расширения сервера для высокой степени параллелизма, в качестве серверной разработки, высокая степень параллелизма может быть оптимизирована, чтобы обеспечить стабильную работу бизнеса при высокой степени параллелизма, избежать потерь, вызванных стагнацией бизнеса, и принести неудобство для пользователей. хороший опыт
Кэш:
- кеш сервера
- База данных памяти
- redis
- memcache
- Способ
- Приоритетный кеш
- Проблема проникновения в БД
- кэш только для чтения
- обновить/удалить
- Приоритетный кеш
- Уведомление
- Выделенный объем памяти для базы данных в памяти ограничен. Разумное планирование и использование в конечном итоге приведут к нехватке памяти.
- Для кэшированных данных необходимо установить время истечения срока действия, недействительные/неиспользуемые данные автоматически истечет.
- Данные кэша сжатых данных, неиспользуемые поля не добавляются в кэш
- Демонтаж и развертывание кэш-серверов в соответствии с бизнесом
- База данных памяти
- Кэш клиента
- Способ
- Клиент запрашивает интерфейс данных, кэширует данные и номер версии данных и предоставляет номер версии кэшированных данных с каждым запросом.
- Сервер сравнивает сообщаемый номер версии данных с текущим номером версии данных.
- Если номер версии тот же, список данных не будет возвращен. Если номер версии отличается, будут возвращены последние данные и номер последней версии.
- Сцены:
- Редко обновляемые данные
- Способ
Схема архитектуры кэша на стороне сервера
асинхронный
Асинхронное программирование
- Способ:
- многопоточное программирование
- асинхронное программирование nodejs
- Сцены:
- SMS-уведомление об успешном участии
- Операции, не требуемые основным процессом бизнес-логики, допускающие асинхронную обработку других вспомогательных сервисов и т. д.
Бизнес-асинхронная обработка
- Способ
- Бизнес-интерфейс помещает данные, сообщенные клиентом, в очередь сообщений (промежуточное ПО MQ), а затем отвечает на результат пользователю.
- Напишите независимую программу для подписки на очередь сообщений и асинхронного выполнения операций.
- Сцены:
- Большие рекламные акции в час, чтобы получить ограниченное количество красных конвертов
- Эвфемистическое напоминание после успешного участия: ожидается, что красные конверты будут розданы через X дней.
- Для бизнеса с относительно большим объемом параллелизма, когда нет другого лучшего решения для оптимизации, бизнес допускает асинхронную обработку.
- Большие рекламные акции в час, чтобы получить ограниченное количество красных конвертов
- Уведомление:
- Контролируйте ход использования очереди
- Гарантированная идемпотентность и возможная согласованность данных
- дефект:
- жертвуя пользовательским опытом
[Бизнес-асинхронная обработка] Схема архитектуры
[Бизнес-асинхронная обработка] Помимо использования в бизнесе с высокой степенью параллелизма, эта архитектура также используется при разработке вышеуказанных общих служб.
Ограничение
Ограничивая количество запросов в пиковой активности, можно избежать таких проблем, как перепроданность и перепродажа.
Активный бизнес с высокой степенью параллелизма, через интерфейсный поток управления, разрозненные запросы, сокращение количества параллелизма
- Текущий лимит на стороне сервера
- счетчик Redis
- Такие как: действия в области безопасности
- Поток управления клиентом
- Участвуя в игре
- Дождь в красном конверте/мини-игра и т. д.
понижение уровня обслуживания
Когда потребление ресурсов сервера достигло определенного уровня, чтобы обеспечить нормальную работу основного бизнеса, необходимо защитить автомобиль и отказаться от автомобиля, чтобы защитить красавца.Плохой опыт
- понижение рейтинга бизнеса
- От сложного сервиса к простому сервису
- От динамического взаимодействия к статической странице
- Выгрузка в CDN
- Извлечь подготовленные данные JSON из CDN
- Загрузите статическую страницу CDN
- Не работает
- Остановить непрофильный бизнес и мягко напомнить
Обзор оптимизации с высокой степенью параллелизма
Вечеринка Anti-Brush / Anti-Wool
Большинство дизайнеров продуктов и программистов компании не знают об антикистовой осведомленности о бизнесе по продвижению.В процессе проектирования и разработки событийного бизнеса функция антикисти не была добавлена в бизнес, создавая много для те, кто любит заниматься щеткой. лазейка Когда вы узнаете, что вас зачистили, вы уже понесли много убытков, начиная от сотен тысяч и заканчивая десятками тысяч.
С искушением интересов появилось новое занятие, «свайп клиентов». Профессиональное свайпирование в Интернете для заработка, поднятие N мобильных телефонов + N номеров мобильных телефонов + N учетных записей WeChat и снятие вознаграждений, полученных путем чистки, чистки на активные товары для недорогой перепродажи открыли новую цепочку серой промышленности
Нужно браться за оружие (коды) для самозащиты, контроля рисков, повышать порог, снижать возможность рисков через контрольные суммы и лимиты, а также уменьшать потери, вызванные возникновением рисков
Вот общие процедуры (конкретные приложения в сочетании с бизнес-сценариями):
Проверить обоснованность запроса
- Оценка достоверности параметра запроса
- Запросить проверку заголовка
- user-agent
- referer
- ... ...
- Проверка подписи
- Подписать параметры запроса
- Ограничения устройства
- Ограничение IP
- Суждение о легитимности профсоюза WeChat unionid/openid
- Проверочный код/SMS код подтверждения
- жертвуя опытом
- Самостоятельно построенная система фильтрации черных списков
Контроль бизнес-рисков
- Ограничьте время участия устройства/WeChat
- Ограничьте максимальное количество наград
- Лимиты призового фонда
- Разработано в соответствии с конкретными бизнес-сценариями...
копирующая роль
- обычный пользователь
- технический пользователь
- Профессиональная кисть
- Нет хорошего способа ограничить
Обзор рутинной вечеринки Anti-brush / Anti-Wool
дополнительный
- Правила подписи в APP/H5 должны разрабатываться клиентом, а затем расширять API для вызова интерфейса JS. Когда H5 инициирует запрос интерфейса, следует вызывать расширенную подпись на стороне клиента, чтобы избежать подписи правила, созданные во внешнем JS и найденные взломанными.
Проблемы параллелизма
несколько операций
- Сцены:
Когда == один и тот же пользователь == запускает несколько кликов или имитирует одновременные запросы, возникнут проблемы с несколькими операциями, такие как: функция регистрации, вы можете отмечаться только один раз в день, вы можете получить 1 балл, но в случае одновременных пользователей появятся вопросы, которые могут заработать несколько баллов
- Анатомия:
Упрощенная логика регистрации обычно выглядит следующим образом:
Проверить наличие записи о регистрации --> Нет --> Добавить сегодняшнюю запись о регистрации --> Накопить баллы пользователя --> Регистрация прошла успешно
Проверьте, есть ли запись о регистрации --> да --> зарегистрировались сегодня
Предполагая, что пользователь A отправляет два запроса на регистрацию в это время, он вводит [Запрос, есть ли запись о регистрации] одновременно, а затем одновременно возвращает ответ Нет, будут две записи о регистрации. добавлено, и будет накоплено больше очков.
- решение:
Самое идеальное и простое решение — добавить уникальный индекс комбинации [дата регистрации] + [идентификатор пользователя] в таблицу записей регистрации. не удается из-за уникальных ограничений.
отрицательный запас
- Сцены:
Когда ==несколько пользователей==одновременно кликают для участия в таких действиях, как: лотереи, в это время существует только один набор призов, и теоретически только один пользователь может его получить, но когда это происходит одновременно, часто бывает так, что все они успешно получают призы, что приводит к увеличению расходов на призы, увеличивая стоимость мероприятий.
- Анатомия:
Рассматриваемый логический поток обычно выглядит следующим образом:
Выигрыш --> Запросить инвентарь призов --> Да --> Обновить инвентарь призов --> Добавить запись о выигрыше --> Уведомить победителя
Выигрыш --> Проверить инвентарь призов --> Нет --> Сообщить, что выигрыша нет
Предположим, что в лотерейном событии текущий приз A имеет только последний инвентарь, а затем пользователи A, B, C, одновременно участвующие в событии и выигравшие призы, — все A. В это время, если есть один предмет в инвентарь, инвентарь будет обновлен и победная запись будет добавлена.
- решение:
В идеале нет необходимости выполнять еще одну операцию ИЗБРАННОГО инвентаря приза, просто ОБНОВИТЬ инвентарь приза -1 ГДЕ инвентарь приза>=1, после успешного ОБНОВЛЕНИЯ это означает, что инвентарь есть, а затем выполнить последующие операции, при одновременном выполнении только один пользователь UPDATE будет успешным
Суммировать:
При разработке бизнес-интерфейсов необходимо учитывать сценарии == одного пользователя == и == многопользовательского == параллелизма, чтобы избежать исключений данных во время параллелизма, приводящих к высоким затратам.
Тестирование фиктивного параллелизма можно выполнить с помощью следующих инструментов:
- Apache JMeter
- Charles Advanced Repeat
- Нагрузка на производительность Visual Studio
Навыки сбора данных (дополнительно)
Универсальная программа
- Получить интерфейс данных платформы
- запрос фиктивного интерфейса
- Парсинг и фильтрация данных
- хранение структуры данных
Используйте фреймворк автоматизированного тестирования selenium+Headless.
- развивать
- Рекомендуется разрабатывать на python
- python+selenium+headless
- Контролируйте частоту запросов, чтобы избежать ограничений со стороны платформы
- Используйте IP-адрес прокси, чтобы обойти ограничения IP-адреса запроса
- Рекомендуется разрабатывать на python
- преимущество
- Не нужно имитировать запросы интерфейса
- Не удалось преодолеть запрос моделирования интерфейса данных (зашифрованная подпись и т. д.)
- Версия интерфейса часто меняется (необходимо повторное исследование)
- Интерфейс платформы/версия страницы меняется, можно быстро настроить
- Нужно только настроить положение элемента HTML, в котором находятся собранные данные (класс/идентификатор).
- Пользователь может управлять/выбирать/нажимать/имитировать вход в систему и т. д.
- После сбоя входа в систему вы можете имитировать вход в систему
- Вы можете отправить QR-код для входа в Dingding, чтобы отсканировать код для входа в систему.
- Не нужно имитировать запросы интерфейса
- Сценарии применения:
- Сбор данных о конкурентах
- Цены на товары Taobao и самостоятельный мониторинг цен на товарный склад
- Сумма купона Taobao и мониторинг суммы фонового купона собственного товарного склада
- ... ...
Анти-Анти-Рептильный
В процессе сбора данных некоторые платформы настраивают политики защиты от сканирования для важных запросов данных, чтобы избежать интеллектуального анализа и использования данных конкурирующими продуктами, а также потребляют много ресурсов, чтобы перегрузить сервер. Анти-рептилия и анти-анти-рептилия - это состязание технологий, и эта война без пороха никогда не закончится. (Почему программисты должны смущать программистов)
-
Антикраулеры можно разделить на следующие два типа
- лимит сервера
- Ограничение запросов строк на стороне сервера, чтобы сканеры не могли запрашивать данные
- Ограничения внешнего интерфейса
- Внешний интерфейс использует теги CSS и HTML, чтобы вмешиваться и скрывать ключевые данные, чтобы сканеры не могли легко получить данные.
- лимит сервера
-
Ограничения взломанного сервера:
- Имитировать настройку заголовков запроса
- Referer
- User-Agent
- Authorization
- .....
- взломать подпись
- Правила подписи
- Найдите правила подписи в JS
- Правила подписи
- Фиксированная ставка запроса управления
- Отрегулируйте время запроса, задержите запрос
- IP-адрес прокси
- Переключить запрошенный IP-адрес прокси, собственный/сторонний
- Ограничения входа
- Принесите Cookie/авторизацию после успешного входа в систему
- лимит капчи
- Распознавание изображений, основанное на библиотеке или третьей стороне
- Отравление и растрескивание
- Чтобы предотвратить отравление, данные должны быть отобраны и проверены.
- Имитировать настройку заголовков запроса
-
Взломайте внешние ограничения:
- шрифт, интерференция пользовательского шрифта
- Найдите адрес файла шрифта ttf, затем загрузите его, используйте пакет модуля синтаксического анализа шрифта для анализа файла ttf и сопоставьте его с кодировкой текста на китайском языке.
- Псевдоэлемент скрыт
- Найдите китайский язык, соответствующий xxxx::before {content: "Chinese";} в CSS.
- смещение фонового изображения
- Карта по смещению позиции фонового изображения и содержимого на изображении
- вмешательство в HTML-тег
- Отфильтруйте теги HTML, которые мешают запутыванию, или читайте только содержимое тегов HTML, которые являются допустимыми данными.
- шрифт, интерференция пользовательского шрифта
Суммировать
Как back-end разработчик, вы должны не только завершить разработку необходимых функций, но и сделать разумный дизайн на основе бизнес-сценария, построить будущее и оптимизировать основной бизнес, чтобы обеспечить нормальную работу бизнеса в условиях параллелизма. , В то же время вы должны учитывать вопросы безопасности и анти-щетки. , Сторона против шерсти, избегать неприятного запаха кода при кодировании, сталкиваться с абстрактной разработкой, надлежащим образом использовать шаблоны проектирования, избегать технического долга.
Разработайте цитаты, которые следует иметь в виду:
- Ценность существования технологии заключается в том, чтобы позволить технологии способствовать росту бизнеса и достигать роста прибыли компании.
- Нет лучшей архитектуры, есть только самая подходящая архитектура
- Язык разработки — это всего лишь инструмент, используйте правильный инструмент в правильном сценарии
- Абстрактное мышление позволяет проникнуть в суть проблемы из различных существующих проблем, понять модель требований к продукту на глубоком уровне и устранить первопричину, а не симптомы.
- Знания очень важны. Хотя она не может дать вам богатство напрямую, она может дать вам много возможностей жить и учиться.