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

1. Технология крупномасштабной распределенной архитектуры веб-сайта

1. Характеристики крупных сайтов

Многие пользователи, широко распространенные
Высокий трафик, высокий параллелизм
Массивные данные, высокая доступность услуг
Суровая среда безопасности, уязвимая для сетевых атак
Больше функций, быстрее, частые выпуски
От малого к большому, постепенное развитие
Ориентированный на пользователя
Бесплатный сервис, платный опыт

2. Цели крупномасштабной архитектуры веб-сайта

Высокая производительность: обеспечивает быстрый доступ.
Высокая доступность: услуги веб-сайта всегда доступны в обычном режиме.
Масштабируемость: увеличение/уменьшение вычислительной мощности за счет аппаратного увеличения/уменьшения.
Безопасность: Предоставляет политики для безопасного доступа к веб-сайтам, шифрования данных и безопасного хранения.
Расширяемость: легко добавляйте/удаляйте новые функции/модули путем добавления/удаления.
Гибкость: по запросу, быстрое реагирование;

3. Режим крупномасштабной архитектуры веб-сайта

Многоуровневость: обычно ее можно разделить на прикладной уровень, сервисный уровень, уровень данных, уровень управления и уровень анализа;
Сегментация: Как правило, он делится в соответствии с бизнес-/модульными/функциональными характеристиками.Например, прикладной уровень делится на домашнюю страницу и пользовательский центр.
Распределенный: развертывайте приложения отдельно (например, на нескольких физических машинах) и работайте вместе с помощью удаленных вызовов.
Кластер: развертывание нескольких копий приложения/модуля/функции (например, нескольких физических машин) и предоставление внешнего доступа посредством балансировки нагрузки.
Кэш: размещайте данные ближе всего к приложению или пользователю для более быстрого доступа.
Асинхронный: асинхронизируйте синхронные операции. Когда клиент отправляет запрос, он не ждет ответа от сервера, а после того, как сервер завершает обработку, информирует запрашивающую сторону посредством уведомления или опроса. Обычно относится к режиму запрос-ответ-уведомление.
Избыточность: добавьте реплики для повышения доступности, безопасности и производительности.
Безопасность: Существуют эффективные решения известных проблем и создание механизмов обнаружения и защиты от неизвестных/потенциальных проблем.
Автоматизация: повторяющиеся задачи, не требующие участия человека, выполняются с помощью инструментов и машин.
Гибкость: активно принимайте изменения в требованиях и быстро реагируйте на потребности развития бизнеса.

4. Высокопроизводительная архитектура

Ориентированный на пользователя, обеспечивающий быстрый доступ в Интернет. Основные параметрыКороткое время отклика, большая одновременная вычислительная мощность, высокая пропускная способность и стабильные параметры производительности.

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

Оптимизация внешнего интерфейса: часть перед бизнес-логикой сайта;
Оптимизация браузера: Уменьшите количество HTTP-запросов, используйте кеширование браузера, включите сжатие, местоположение CSS JS, асинхронный JS, уменьшите передачу файлов cookie, ускорение CDN, обратный прокси;
Оптимизация прикладного уровня: Сервер, отвечающий за работу веб-сайта. Использование кеша, асинхронность, кластеризация
Оптимизация кода: разумная архитектура, многопоточность, повторное использование ресурсов (пул объектов, пул потоков и т. д.), хорошая структура данных, настройка JVM, синглтон, кэш и т. д.;
оптимизация хранилища: Кэш, SSD, оптоволоконный транспорт, оптимизированное чтение и запись, резервирование диска, распределенное хранилище (HDFS), NoSQL и т. д.

5. Архитектура высокой доступности

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

Как улучшить юзабилити — проблема, которую нужно срочно решать. Во-первых, это нужно учитывать на архитектурном уровне, а при планировании учитывать доступность. В отрасли для представления индикаторов доступности обычно используется несколько девяток, например, четыре девятки (99,99), а допустимое время недоступности в течение года составляет 53 минуты.

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

прикладной уровень: как правило, не имеет состояния, для каждого запроса не имеет значения, какой сервер используется для его обработки. Обычно используйте технологию балансировки нагрузки (необходимо решить проблему синхронизации сеансов) для достижения высокой доступности.
сервисный уровень: Балансировка нагрузки, иерархическое управление, быстрый сбой (установка времени ожидания), асинхронные вызовы, снижение качества обслуживания, идемпотентный дизайн и т. д.
слой данных: резервное резервное копирование (холодный, горячий резерв [синхронизация, асинхронный], теплый резерв), отработка отказа (подтверждение, передача, восстановление). Общеизвестной теоретической основой высокой доступности данных является теория CAP (долговечность, доступность, согласованность данных [сильная согласованность, согласованность пользователей, конечная согласованность]).

6. Масштабируемая архитектура

Масштабируемость означает увеличение/уменьшение вычислительной мощности системы за счет добавления/уменьшения оборудования (серверов) без изменения исходной архитектуры.

Прикладной уровень:Разделите приложения по вертикали или горизонтали. Затем балансировка нагрузки для одной функции (DNS, HTTP [обратный прокси-сервер], IP, канальный уровень).
сервисный уровень: Аналогично прикладному уровню;
слой данных: подбаза данных, подтаблица, NoSQL и т. д., часто используемый алгоритм хэширования, согласованный хэш.

7. Масштабируемая архитектура

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

модульный, компонентный: Высокая связность, низкая связанность, улучшенная возможность повторного использования и масштабируемость.
стабильный интерфейс: определить стабильный интерфейс, а внутреннюю структуру можно изменить «по желанию», когда интерфейс остается неизменным.
Шаблоны проектирования: применять объектно-ориентированные идеи, принципы, использовать шаблоны проектирования и проектировать на уровне кода.
очередь сообщений: модульная система, которая взаимодействует через очереди сообщений, чтобы отделить зависимости между модулями.
Распределенный сервис: Публичные модули обслуживаются, предоставляя другие системы для использования, повышая возможность повторного использования и масштабируемость.

8. Архитектура безопасности

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

безопасность инфраструктуры: Безопасность при закупке оборудования, операционной системы и сетевой среды. Как правило, используйте официальные каналы для покупки высококачественных продуктов, выбирайте безопасную операционную систему, своевременно исправляйте уязвимости и устанавливайте антивирусное программное обеспечение и брандмауэры. Предотвратить вирусы, бэкдоры. Установите политики брандмауэра, установите системы защиты от DDOS, используйте системы обнаружения атак и выполните изоляцию подсети.
Безопасность системы приложений: Во время разработки программы используйте правильный метод для известных распространенных проблем и решайте их на уровне кода. Защищает от межсайтового скриптинга (XSS), инъекций, подделки межсайтовых запросов (CSRF), сообщений об ошибках, комментариев HTML, загрузки файлов, обхода путей и многого другого. Вы также можете использовать брандмауэр веб-приложений (например, ModSecurity) для сканирования уязвимостей системы безопасности и других мер по усилению безопасности на уровне приложений.
Конфиденциальность и безопасность данных: безопасность хранения (хранение на надежном оборудовании, в режиме реального времени, регулярное резервное копирование), безопасность хранения (важная информация шифруется и хранится, выбор соответствующего персонала для сложного хранения и обнаружения и т. д.), безопасность передачи (предотвращение кражи данных и подделки данных) ;

Широко используемые алгоритмы шифрования и дешифрования (шифрование с одним хэшем [MD5, SHA], симметричное шифрование [DES, 3DES, RC]), асимметричное шифрование [RSA] и т. д.

9. Ловкость

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

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

10. Примеры крупномасштабных архитектур

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

уровень клиента: Поддержка браузера ПК и мобильного приложения. Разница в том, что к мобильному приложению можно получить доступ напрямую через IP, обратный прокси-сервер.
Интерфейсный слой: Используйте балансировку нагрузки DNS, локальное ускорение CDN и сервисы обратного прокси;
прикладной уровень: Кластер приложений веб-сайта, вертикальное разделение в соответствии с бизнесом, например, товарное приложение, членский центр и т. д.;
сервисный уровень: Предоставление государственных услуг, таких как обслуживание пользователей, услуги заказа, платежные услуги и т. д.;
слой данных: поддержка кластера реляционной базы данных (поддержка разделения чтения-записи), кластера NOSQL, кластера распределенной файловой системы и распределенного кэша;
Уровень хранения больших данных: Поддержка сбора данных журнала прикладного уровня и сервисного уровня, сбор структурированных и полуструктурированных данных реляционной базы данных и базы данных NOSQL;
Слой обработки больших данных: Выполняйте автономный анализ данных или анализ данных Storm в реальном времени с помощью Mapreduce и сохраняйте обработанные данные в реляционной базе данных. (При фактическом использовании автономные данные и данные в реальном времени будут классифицироваться и обрабатываться в соответствии с бизнес-требованиями и храниться в разных базах данных для использования прикладным уровнем или сервисным уровнем).

2. Процесс эволюции системной архитектуры крупных сайтов электронной коммерции.

Системная архитектура зрелого крупномасштабного веб-сайта (такого как Taobao, Tmall, Tencent и т. д.) не рассчитана на полную высокую производительность, высокую доступность и высокую масштабируемость.Расширение функций постепенно развивалось и совершенствовалось.В ходе этого процесса , способ разработки, техническая архитектура и дизайн-мышление также претерпели большие изменения.Даже технический персонал превратился из нескольких человек в отдел или даже в линейку продуктов.

Таким образом, зрелая системная архитектура постепенно улучшается с расширением бизнеса, а не в одночасье; системы с различными бизнес-характеристиками будут иметь свою собственную направленность, например, Taobao, которая должна решать вопросы поиска, заказа и оплаты массивной информации о товарах; Например, Tencent нужно решить проблему передачи сообщений в режиме реального времени от сотен миллионов пользователей, а Baidu — обрабатывать массивные поисковые запросы.

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

1. Начальная архитектура сайта

В исходной архитектуре приложения, базы данных и файлы развернуты на одном сервере, как показано на рисунке:

2. Разделение приложений, данных и файлов

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

3. Используйте кеширование для повышения производительности сайта

Оптимизируя производительность оборудования, он также оптимизирует производительность с помощью программного обеспечения. В большинстве систем веб-сайтов технология кэширования используется для повышения производительности системы. Использование кэширования в основном связано с наличием горячих данных, и большинство посещений веб-сайтов следуют принципу 28. (То есть 80 % запросов на доступ заканчиваются на 20 % данных), поэтому мы можем кэшировать горячие данные, чтобы сократить пути доступа к этим данным и улучшить взаимодействие с пользователем.

Распространенным способом реализации кеша является локальный кеш и распределенный кеш. Конечно, есть еще CDN, обратные прокси и т. д., о которых речь пойдет позже. Локальный кеш, как следует из названия, кэширует данные локально на сервере приложений, которые могут находиться в памяти или в файлах.OSCache — широко используемый компонент локального кеша. Локальный кеш характеризуется высокой скоростью, но объем кэшируемых данных также ограничен из-за ограниченного локального пространства. Отличительной чертой распределенного кэша является то, что он может
Чтобы кэшировать большие данные, и их очень легко расширять, они часто используются на веб-сайтах порталов, а скорость не такая высокая, как у локального кеша.Обычно используемые распределенные кеши — это Memcached и Redis.

4. Используйте кластеры для повышения производительности сервера приложений

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

Обычно используемые технологии балансировки нагрузки включают F5 для относительно дорогого аппаратного обеспечения и программного обеспечения, такого как LVS, Nginx и HAProxy. LVS — это четырехуровневая балансировка нагрузки, а внутренние серверы выбираются по целевому адресу и порту, Nginx и HAProxy — семиуровневая балансировка нагрузки, а внутренние серверы можно выбирать по содержимому пакетов, поэтому LVS путь раздачи лучше, чем у Nginx и HAProxy, и его производительность выше, при этом Nginx и HAProxy более настраиваемые, например, их можно использовать для динамического и статического разделения (выбрать статический сервер ресурсов или сервер приложений по характеристикам пакетов запросов ).

5. Разделение чтения и записи базы данных и подтаблица подбазы данных

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

6. Используйте CDN и обратный прокси для повышения производительности сайта

Если наши серверы развернуты в компьютерном зале в Чэнду, доступ для пользователей в Сычуани будет быстрее, но доступ для пользователей в Пекине будет медленнее, потому что Сычуань и Пекин принадлежат к разным развитым регионам China Telecom и China Unicom соответственно. Пользователям из Пекина необходимо пройти длинный путь для доступа к серверу в Чэнду через интернет-маршрутизатор, и обратный путь такой же, поэтому время передачи данных относительно велико. В этом случае для решения проблемы часто используется CDN, который кэширует содержимое данных в машинном зале оператора, а пользователи при доступе получают данные от ближайшего оператора, что значительно сокращает путь доступа к сети. Более профессиональные операторы CDN включают Lanxun и Wangsu.

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

7. Используйте распределенную файловую систему

Количество пользователей растет день ото дня, объем бизнеса становится все больше и больше, и создается все больше и больше файлов.Один файловый сервер больше не может удовлетворить спрос.В настоящее время поддержка распределенной файловой системы нужный. Обычно используемые распределенные файловые системы включают GFS, HDFS и TFS.

8. Используйте NoSQL и поисковые системы

Для запросов и анализа массивных данных мы используем базу данных NoSQL и поисковую систему для повышения производительности. Не все данные должны быть в реляционных данных. Обычно используемые NoSQL включают MongoDB, HBase, Redis, а поисковые системы включают Lucene, Solr и Elasticsearch.

9. Разделите сервер приложений для бизнеса

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

10. Создание распределенных сервисов

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

3. Схема, иллюстрирующая структуру электронной коммерции

Четыре случая архитектуры крупномасштабного веб-сайта электронной коммерции

1. Причины случаев электронной коммерции

Существует несколько типов распределенных крупных веб-сайтов:

большой портал,Такие как NetEase, Sina и т. д.;
соц сайт,Например, школа, Kaixin и т. д.;
сайт электронной коммерции,Например, Alibaba, Jingdong Mall, Gome Online, Autohome и т. д.

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

2. Требования к веб-сайту электронной коммерции

потребности клиента:

Создайте веб-сайт электронной коммерции с полной категорией (B2C), где пользователи могут покупать товары в Интернете, платить онлайн или платить при доставке;
Пользователи могут общаться со службой поддержки онлайн при покупке;
После получения товара пользователь может поставить оценку и оценить товар;
В настоящее время существует отработанная система выставления счетов, ее необходимо связать с сайтом;
Надеемся поддержать развитие бизнеса в течение 3-5 лет;
Ожидается, что количество пользователей достигнет 10 миллионов через 3-5 лет;
Регулярно проводить Double 11, Double 12, Мужской день 8 марта и другие мероприятия;
Информацию о других функциях см. на таких веб-сайтах, как JD.com или Gome Online.

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

Матрица функций требований

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

Матрица спроса для этого веб-сайта электронной коммерции выглядит следующим образом:

3. Основная структура сайта

Общий веб-сайт в начале состоит из трех серверов, один из которых развертывает приложение, один развертывает базу данных и один развертывает файловую систему NFS.
Это более традиционная практика в последние несколько лет.Раньше я видел веб-сайт с более чем 100 000 участников, вертикальный портал дизайна одежды и N много фотографий. Сервер используется для развертывания приложения, базы данных и хранилища изображений. Есть много проблем с производительностью.

Как показано ниже:

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

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

4. Оценка пропускной способности системы

Предполагаемые шаги:

Количество зарегистрированных пользователей - среднесуточный объем UV - ежедневный объем PV - ежедневный одновременный объем;
Пиковая оценка: в 2-3 раза больше обычной суммы;
Рассчитайте емкость системы на основе количества параллелизма (параллельности, количества транзакций) и емкости хранилища.

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

Суточная УФ 2 млн (принцип 28);
Нажмите и просмотрите 30 раз в день;
Объем PV: 200*30=60 миллионов;
Концентрированные посещения: 24*0,2=4,8 часа, будет 60 млн*0,8=48 млн (принцип 28);
Параллелизм в минуту: 4,8 * 60 = 288 минут, 4800/288 = 167 000 посещений в минуту (приблизительно равно);
Параллелизм в секунду: 167 000/60 = 2780 (приблизительно равно);
Если предположить, что пиковый период в три раза превышает обычное значение, количество параллелизма в секунду может достигать 8340.
1 мс = 1,3 посещения;

Вы жалеете, что плохо изучали математику? ! (Я не знаю, неверен ли приведенный выше расчет, хе-хе~~)

Оценка сервера: (в качестве примера возьмем сервер tomcat)

По данным веб-сервера, он поддерживает 300 одновременных вычислений в секунду. Обычно требуется 10 серверов (примерно равно); [конфигурация tomcat по умолчанию — 150], в пиковые периоды требуется 30 серверов;

Оценка емкости: принцип 70/90

Системный ЦП обычно поддерживается на уровне около 70% и достигает уровня 90% в пиковый период, что не тратит ресурсы впустую и является относительно стабильным. Память, ввод-вывод аналогичны.

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

5. Анализ архитектуры сайта

Исходя из приведенных выше оценок, можно выделить несколько проблем:

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

Крупномасштабные веб-сайты, как правило, должны выполнять следующие архитектурные оптимизации (оптимизация должна учитываться при разработке архитектуры, и обычно она решается на уровне архитектуры/кода. Настройка — это в основном настройка простых параметров, таких как настройка JVM ; если тюнинг включает много преобразований кода, это не тюнинг, это рефакторинг):

разделение бизнеса
Развертывание кластера приложений (распределенное развертывание, развертывание кластера и балансировка нагрузки)
многоуровневый кэш
Единый вход (распределенный сеанс)
Кластер базы данных (разделение чтения-записи, подтаблица подбазы данных)
Обслуживание
очередь сообщений
другие технологии

6. Оптимизация архитектуры сайта

6.1 Разделение бизнеса
В соответствии с бизнес-атрибутами он делится на подсистему продукта, подсистему покупок, подсистему оплаты, подсистему комментариев, подсистему обслуживания клиентов и подсистему интерфейса (взаимодействие с внешними системами, такими как выставление счетов, SMS и т. д.).

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

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

Схема разделенной архитектуры:

Эталонный сценарий развертывания 2

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

6.2 Развертывание кластера приложений (распределенное, кластерное, балансировка нагрузки)

Распределенное развертывание: приложения после разделения бизнеса развертываются отдельно, и приложения напрямую взаимодействуют удаленно через RPC;
Развертывание кластера: требования к высокой доступности для веб-сайтов электронной коммерции, развертывание не менее двух серверов для каждого приложения для развертывания кластера;
Балансировка нагрузки: необходима для систем с высокой доступностью.Обычные приложения достигают высокой доступности за счет балансировки нагрузки, распределенные службы достигают высокой доступности за счет встроенной балансировки нагрузки, а реляционные базы данных достигают высокой доступности за счет режима «активный-резервный».

Схема архитектуры после развертывания кластера:

6.3 Многоуровневый кэш
Кэши обычно можно разделить на два типа: локальные кеши и распределенные кеши в зависимости от места их хранения. В этом случае для проектирования кэша используется кэш второго уровня. Кэш первого уровня — это локальный кеш, а кеш второго уровня — распределенный кеш. (И кеш страниц, кеш фрагментов и т. д., это более мелкое деление)

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

Соотношение кеша, как правило, 1:4, можно рассматривать как использование кеша. (теоретически это 1:2).

В зависимости от бизнес-характеристик можно использовать следующие политики истечения срока действия кэша:

Срок действия кеша истекает автоматически;
Срок действия триггера кеша;

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

Кроме того, в соответствии с распределенным сеансом может быть установлена полная система единого входа или управления учетными записями.

Описание потока

Когда пользователь входит в систему в первый раз, информация о сеансе (идентификатор пользователя и информация о пользователе), такая как идентификатор пользователя в качестве ключа, записывается в распределенный сеанс;
Когда пользователь снова входит в систему, получить распределенный сеанс, есть ли информация о сеансе, если нет, перейти на страницу входа;
Обычно реализуется промежуточным программным обеспечением Cache, рекомендуется Redis, поэтому он имеет функцию сохранения, которая удобна для загрузки информации о сеансе из постоянного хранилища после того, как распределенный сеанс не работает;
При сохранении сеанса вы можете установить продолжительность сеанса, например 15 минут, после чего он автоматически истечет;

В сочетании с промежуточным программным обеспечением Cache реализованный распределенный сеанс может хорошо имитировать сеанс сеанса.

6.5 Кластер базы данных (разделение чтения и записи, подбаза данных и подтаблица)
Большие веб-сайты должны хранить огромные объемы данных.Для достижения большого объема хранения данных, высокой доступности и высокой производительности система обычно проектируется с избыточностью. Обычно существует два способа чтения и записи разделения и подтаблицы подбазы данных.

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

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

После разделения бизнеса: каждой подсистеме нужна отдельная библиотека;
Если отдельная библиотека слишком велика, ее можно снова разделить в соответствии с бизнес-характеристиками, такими как библиотека классификации товаров, библиотека продуктов;
После разделения базы данных, если в таблице имеется большой объем данных, таблица будет разделена.Как правило, таблица может быть разделена в соответствии с идентификатором, временем и т. д. (Расширенное использование - это согласованный хэш).
На основе подбиблиотеки и подтаблицы осуществляется разделение чтения и записи;

Для связанного промежуточного программного обеспечения обратитесь к Cobar (Ali, в настоящее время не обслуживается), TDDL (Ali), Atlas (Qihoo 360), MyCat.

Проблема последовательности, СОЕДИНЕНИЯ и транзакции после подбазы данных и подтаблицы будет представлена в теме совместного использования подбазы данных и подтаблицы.

6.6 Обслуживание
Извлеките функции/модули, общие для нескольких подсистем, и используйте их как общедоступные службы. Например, подсистема членства в этом случае может быть извлечена как общедоступная служба.

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

После того, как пользователь размещает заказ, он записывается в очередь сообщений, а затем возвращается клиенту напрямую;
Подсистема инвентаризации: чтение информации об очереди сообщений и полное сокращение инвентаризации;
Подсистема доставки: чтение информации об очереди сообщений и доставка;

В настоящее время наиболее часто используемыми MQ являются Active MQ, Rabbit MQ, Zero MQ, MS MQ и т. д., которые необходимо выбирать в соответствии с конкретными бизнес-сценариями. Рекомендуется изучить Rabbit MQ.

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

Я не буду подробно представлять это здесь, вы можете спросить Du Niang/Google, и если у вас есть возможность, вы можете поделиться им со всеми.

7. Резюме архитектуры

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

об авторе

гнилая свиная кожа,Имея более чем десятилетний опыт работы, он несколько лет работал в иностранных компаниях, таких как Google.Он владеет Java, распределенной архитектурой, микросервисной архитектурой и базой данных.В последнее время он изучает большие данные и блокчейн, надеясь прорваться на более высокий уровень.