Проблемы крупных веб-сайтов в основном связаны с огромным количеством пользователей, большим одновременным доступом и огромными данными.Как только любой простой бизнес должен иметь дело с десятками петабайт данных и сталкиваться с сотнями миллионов пользователей, проблема станет сложной. Крупномасштабная архитектура веб-сайта в основном предназначена для решения такого рода проблем. Читать далееКраткое изложение эволюции архитектуры крупных интернет-компаний,Краткий обзор технологии крупномасштабной архитектуры веб-сайтадве статьи.
Большая часть содержания этой статьи взята из«Техническая архитектура больших сайтов», Эту книгу стоит прочитать и настоятельно рекомендуется.
Характеристики крупной системы веб-сайтов
Высокий параллелизм, большой трафик
Он должен сталкиваться с большим количеством одновременных пользователей и большим доступом к трафику. Средний ежедневный PV Google составляет 3,5 миллиарда, а количество ежедневных IP-посещений — 300 миллионов, максимальное количество онлайн-пользователей Tencent QQ — 140 миллионов (данные 2011 года).
Высокая доступность
Система 7 x 24 часа бесперебойного обслуживания.
Массивные данные
Нужно хранить, управлять большими данными, нужно использовать много серверов. Facebook загружает почти 1 миллиард фотографий каждую неделю, у Baidu есть десятки миллиардов веб-страниц, а у Google почти миллион серверов, обслуживающих пользователей по всему миру.
Широкое распределение пользователей и сложные сетевые условия
Многие крупные Интернет-сайты предоставляют услуги глобальным пользователям, пользователи широко рассредоточены, а сетевые условия сильно различаются. В Китае по-прежнему существует проблема сложности взаимодействия сетей различных операторов.
Плохая среда безопасности
Из-за открытости Интернета интернет-сайты более уязвимы, а крупные сайты взламываются чуть ли не каждый день.
Быстрые изменения требований и частые релизы
В отличие от частоты выпуска версий традиционного программного обеспечения, чтобы быстро адаптироваться к рынку и удовлетворить потребности пользователей, интернет-продукты имеют очень высокую частоту выпуска. Как правило, новые версии продуктов на крупных сайтах выходят каждую неделю, а на малых и средних сайтах — чаще, иногда по несколько десятков раз в день.
постепенное развитие
Почти все крупные Интернет-сайты начинаются с небольшого сайта и постепенно растут. Facebook был разработан одноклассниками Цукерберга в общежитии Гарварда, первый сервер Google был развернут в лаборатории Стэнфордского университета, Alibaba родилась в гостиной Джека Ма. Хорошие интернет-продукты разрабатываются медленно, не разрабатываются вначале, что также соответствует развитию и эволюции архитектуры веб-сайта.
Эволюция и процесс разработки крупномасштабной архитектуры веб-сайта
Технические проблемы крупных веб-сайтов в основном связаны с огромным количеством пользователей, большим одновременным доступом и огромными данными.Как только любому простому бизнесу потребуется обрабатывать десятки миллионов данных и сталкиваться с сотнями миллионов пользователей, проблема станет очень серьезной. . Масштабная архитектура веб-сайта в основном решает эту проблему.
Архитектура сайта на начальном этапе
Большие веб-сайты разрабатываются из небольших веб-сайтов, и то же самое относится к архитектуре веб-сайтов, которая постепенно эволюционировала из архитектуры небольших веб-сайтов. Вначале небольшой сайт посещает не так много людей, и одного сервера более чем достаточно.Структура сайта в это время показана на следующем рисунке:
Все ресурсы, такие как приложения, базы данных, файлы и т. д., находятся на одном сервере.
Разделение сервисов приложений и сервисов данных
С развитием веб-бизнеса один сервер постепенно не может удовлетворить спрос: все больше и больше пользователей приводят к снижению производительности, а все больше и больше данных приводит к нехватке места для хранения. Вот где приложения и данные должны быть разделены. После разделения приложения и данных весь веб-сайт использует 3 сервера: сервер приложений, файловый сервер и сервер базы данных. 3 сервера имеют разные требования к аппаратным ресурсам:
Сервер приложений должен обрабатывать много бизнес-логики, поэтому ему нужен более быстрый и мощный ЦП;
Серверы баз данных требуют быстрого поиска на диске и кэширования данных, поэтому более быстрые диски и больший объем памяти;
Файловые серверы должны хранить большое количество загружаемых пользователями файлов, поэтому требуются жесткие диски большего размера.
На этом этапе архитектура системы веб-сайта показана на следующем рисунке:
После того, как приложение и данные разделены, серверы с разными характеристиками берут на себя разные сервисные роли, а возможности одновременной обработки и пространство для хранения данных веб-сайта были значительно улучшены, что поддерживает дальнейшее развитие бизнеса веб-сайта. Однако по мере того, как количество пользователей постепенно увеличивалось, веб-сайт снова сталкивался с проблемами: слишком большая нагрузка на базу данных приводила к задержкам доступа, что, в свою очередь, сказывалось на производительности всего веб-сайта и влияло на удобство работы пользователей. В настоящее время структура веб-сайта нуждается в дальнейшей оптимизации.
Использование кэширования для повышения производительности сайта
Характеристики посещений веб-сайтов такие же, как и распределение богатства в реальном мире, которое следует закону 28: 80% деловых посещений сконцентрированы на 20% данных. Поскольку большая часть бизнес-доступа сосредоточена на небольшой части данных, если эта небольшая часть данных кэшируется в памяти, давление доступа к базе данных может быть уменьшено, скорость доступа к данным всего веб-сайта может быть улучшена, а производительность записи базы данных можно улучшить. Есть два типа кешей, используемых веб-сайтами: локальные кеши, кэшированные на серверах приложений, и удаленные кеши, кэшированные на специализированных серверах распределенного кэша.
Скорость доступа к локальному кэшу быстрее, но он ограничен памятью сервера приложений, а объем кэшируемых данных ограничен, и он будет конкурировать с приложением за память.
Удаленный распределенный кеш может использовать кластерный метод для развертывания сервера с большим объемом памяти в качестве выделенного сервера кеша, что теоретически может обеспечить службу кеша, не ограниченную объемом памяти.
После использования кеша давление доступа к данным эффективно снижается, но количество запросов, которые может обработать один сервер приложений, ограничено.В пиковый период доступа к веб-сайту сервер приложений становится узким местом всего веб-сайта.
Улучшите параллельную вычислительную мощность вашего веб-сайта с помощью кластера серверов приложений.
Использование кластеров — это распространенный метод для веб-сайтов для решения проблем с высоким параллелизмом и большими объемами данных. Когда вычислительной мощности и места для хранения на сервере недостаточно, не пытайтесь заменить более мощный сервер.Для крупных веб-сайтов, независимо от того, насколько мощным является сервер, он не может удовлетворить потребности бизнеса в постоянном росте веб-сайта. В этом случае более целесообразно добавить сервер, чтобы разделить доступ и нагрузку на хранилище исходного сервера.Что касается архитектуры веб-сайта, поскольку давление нагрузки может быть улучшено путем добавления одного сервера, сервер можно постоянно увеличивать таким же образом, чтобы постоянно улучшать производительность системы, тем самым реализуя масштабируемость системы.. Кластер реализации сервера приложений представляет собой относительно простой и зрелый тип масштабируемой архитектуры веб-сайта, как показано на следующем рисунке:
Через сервер планирования балансировки нагрузки запросы доступа из браузера пользователя могут быть распределены на любой сервер в кластере серверов приложений.Если пользователей больше, в кластер будет добавлено больше серверов приложений, что окажет давление на приложение. сервера.Больше не быть узким местом всего веб-сайта.
Разделение чтения и записи базы данных
После того, как веб-сайт использует кеш, доступ к большинству операций чтения данных можно получить без прохождения через базу данных, но все же есть некоторые операции чтения (отсутствие доступа к кешу, истечение срока действия кеша) и все операции записи, которым требуется доступ к базе данных. пользователей достигает определенного масштаба, база данных становится узким местом сайта из-за чрезмерной нагрузки. В настоящее время большинство основных баз данных обеспечивают функцию горячего резервного копирования «главный-подчиненный».Настроив отношения «главный-подчиненный» двух баз данных, можно синхронизировать обновление данных одного сервера базы данных с другим сервером. Веб-сайт использует эту функцию базы данных для разделения чтения и записи базы данных, тем самым снижая нагрузку на базу данных. Как показано ниже:
Когда сервер приложений записывает данные, он обращается к базе данных master, а база данных master синхронизирует обновления данных с подчиненной базой данных посредством механизма репликации master-slave, так что когда сервер приложений считывает данные, он может получать данные из подчиненной базы данных. Чтобы облегчить прикладной программе доступ к базе данных после разделения чтения-записи, на стороне сервера приложений обычно используется специальный модуль доступа к данным, так что разделение чтения-записи базы данных прозрачно для приложения.
Ускорьте отклик сайта с помощью обратного прокси и CDN
С непрерывным развитием бизнеса веб-сайтов количество пользователей становится все больше и больше.Из-за сложной сетевой среды в Китае пользователи в разных регионах имеют большие различия в скорости доступа к веб-сайту. Исследования показали, что задержка посещения веб-сайта положительно связана с оттоком пользователей: чем медленнее посещение веб-сайта, тем легче пользователям потерять терпение и уйти. Чтобы обеспечить лучший пользовательский опыт и удержать пользователей, веб-сайты должны ускорить доступ к веб-сайтам. Основным средством является использование CDN и прокси направления. Как показано ниже:
Основным принципом CDN и обратных прокси является кэширование.
CDN развертывается в компьютерном зале сетевого провайдера, чтобы пользователи могли получать данные из ближайшего к ним компьютерного зала сетевого провайдера при запросе услуг веб-сайта.
Обратный прокси-сервер развертывается в центральном компьютерном зале веб-сайта. Когда пользователь запрашивает центральный компьютерный зал, первым сервером для доступа является обратный прокси-сервер. Если ресурс, запрошенный пользователем, кэшируется на обратном прокси-сервере, он будет возвращен непосредственно пользователю.
Цель использования CDN и обратного прокси — как можно быстрее вернуть данные пользователям, с одной стороны, для ускорения доступа пользователей, а с другой — для снижения нагрузки на внутренние серверы.
Работа с распределенными файловыми системами и системами распределенных баз данных
Ни один мощный сервер не может удовлетворить растущие бизнес-потребности крупного веб-сайта. После того, как база данных отделена от чтения и записи, она разделена с одного сервера на два сервера.Однако с развитием бизнеса веб-сайтов она все еще не может удовлетворить спрос.В настоящее время необходимо использовать распределенную базу данных. То же самое касается файловой системы, которая требует использования распределенной файловой системы. Как показано ниже:
Распределенные базы данных являются последним средством разделения базы данных веб-сайта и используются только тогда, когда масштаб данных одной таблицы очень велик. В крайнем случае, наиболее часто используемый метод разделения базы данных для веб-сайтов — это бизнес-подбаза данных, которая развертывает данные разных предприятий на разных физических серверах.
Использование NoSQL и поисковых систем
Поскольку бизнес веб-сайтов становится все более и более сложным, а требования к хранению и извлечению данных становятся все более и более сложными, веб-сайту необходимо использовать некоторые технологии нереляционных баз данных, такие как NoSQL, и технологии запросов к базам данных, такие как поисковые системы. Как показано ниже:
И NoSQL, и поисковые системы являются техническими средствами, полученными из Интернета, и лучше поддерживают масштабируемые распределенные функции. Сервер приложений получает доступ к различным данным через унифицированный модуль доступа к данным, что избавляет прикладную программу от необходимости управлять многими источниками данных.
разделение бизнеса
Чтобы справиться со все более сложными бизнес-сценариями, крупные веб-сайты делят весь бизнес веб-сайта на различные линейки продуктов, используя метод «разделяй и властвуй». Например, веб-сайты с крупными торговыми операциями будут разделять домашнюю страницу, магазины, заказы, покупателей, продавцов и т. д. на разные линейки продуктов, которые назначаются разным бизнес-командам.
С точки зрения технологии, он также разделит веб-сайт на множество различных приложений в соответствии с линейками продуктов, и каждое приложение будет развернуто независимо. Отношения между приложениями могут быть установлены через гиперссылку (каждая навигационная ссылка на домашней странице указывает на другой адрес приложения), а также данные могут быть распределены через очереди сообщений, Конечно, большинство из них формируются путем доступа к одним и тем же данным. Соответствующая полная система показана на следующем рисунке:
Распределенный сервис
По мере того, как разделение бизнеса становится все меньше и меньше, система хранения становится все больше и больше, общая сложность системы приложений возрастает в геометрической прогрессии, а развертывание и обслуживание становятся все более и более сложными. Поскольку всем приложениям необходимо подключаться ко всем системам баз данных, на веб-сайте с десятками тысяч серверов число этих подключений равно квадрату размера сервера, что приводит к нехватке ресурсов для подключения к базе данных и отказу в обслуживании.
Поскольку каждая прикладная система должна выполнять множество одних и тех же бизнес-операций, таких как управление пользователями, управление товарами и т. д., эти общие службы могут быть извлечены и развернуты независимо друг от друга. Эти сервисы многократного использования подключены к базе данных для предоставления общих бизнес-сервисов, в то время как системе приложений нужно только управлять пользовательским интерфейсом и вызывать общие бизнес-сервисы через распределенные сервисы для выполнения определенных бизнес-операций. Как показано ниже:
Архитектура крупномасштабных веб-сайтов развивалась здесь, и в основном было решено большинство технических проблем, таких как синхронизация данных в реальном времени между центрами обработки данных, а проблемы, связанные с конкретными службами веб-сайта, также могут быть решены путем объединения и улучшения существующих технических архитектура. Для распространяемого контента вы можете продолжить чтениеРаспространяемый цикл статей.