Динамические приложения, в отличие от статического содержимого веб-сайтов, относятся к веб-прикладному программному обеспечению, разработанному с использованием серверных языков, таких как C/C++, PHP, Java, Perl, .NET, — например, форумы, онлайн-фотоальбомы, социальные сети, BLOG и другие распространённые приложения. Динамические прикладные системы обычно неотделимы от систем баз данных, систем кэширования, систем распределённого хранения и так далее.
Платформа крупномасштабной динамической прикладной системы — это прежде всего низкоуровневая системная архитектура, созданная для веб-сайтов с высоким трафиком и высокой конкурентностью. Работа крупных веб-сайтов требует надёжной, безопасной, масштабируемой и легко поддерживаемой платформы прикладных систем в качестве поддержки, чтобы обеспечивать бесперебойную работу веб-приложений.
Крупномасштабные динамические прикладные системы можно далее разделить на несколько подсистем:
- 1) Система веб-фронтенда
- 2) Система балансировки нагрузки
- 3) Система кластера баз данных
- 4) Система кэширования
- 5) Распределённая система хранения
- 6) Распределённая система управления серверами
- 7) Система распространения кода
Система веб-фронтенда
Структурная схема:
Чтобы достичь целей совместного использования серверов между разными приложениями, избежать единых точек отказа, централизованного управления, унифицированной конфигурации и т. д., серверы не разделяются по приложениям. Вместо этого все серверы используются единообразно, и каждый сервер может предоставлять услуги нескольким приложениям. Когда трафик к определённым приложениям возрастает, добавление серверных узлов повышает производительность всего серверного кластера, и другие приложения также получат выгоду. Эта веб-фронтенд-система основана на платформах виртуального хостинга, таких как Apache/Lighttpd/Eginx, и предоставляет среду выполнения PHP-программ. Серверы прозрачны для разработчиков, и разработчикам не нужно участвовать в управлении серверами.
Система балансировки нагрузки
Системы балансировки нагрузки делятся на два типа: аппаратные и программные. Аппаратная балансировка нагрузки эффективна, но дорога, например F5. Программные системы балансировки нагрузки недороги или бесплатны, и хотя они менее эффективны, чем аппаратные системы балансировки нагрузки, их достаточно для сайтов со средним или чуть выше среднего трафиком, например LVS и Nginx. Большинство сайтов используют комбинацию аппаратных и программных систем балансировки нагрузки.
Система кластера баз данных
Структурная схема:
Поскольку веб-фронтенд использует кластерную структуру с балансировкой нагрузки для повышения доступности и масштабируемости сервиса, база данных также должна быть высоконадёжной, чтобы обеспечить высокую надёжность всей сервисной системы. Как построить высоконадёжную систему баз данных, способную справляться с крупномасштабной параллельной обработкой?
Мы можем применить решение, показанное на схеме выше:
1) Использовать базу данных MySQL. Учитывая характерную для веб-приложений особенность, когда чтение из базы данных происходит чаще, чем запись, мы в основном оптимизировали базу данных для чтения, предусмотрев выделенные базы данных для чтения и базы данных для записи, и реализовали в приложении операции чтения и записи так, чтобы они обращались соответственно к разным базам данных.
2) Использовать механизм MySQL Replication для быстрого реплицирования данных из главной базы данных (базы данных для записи) в подчинённые базы данных (базы данных для чтения). Одна главная база данных соответствует нескольким подчинённым базам данных, и данные из главной базы данных синхронизируются в подчинённые базы данных в реальном времени.
3) Имеется несколько баз данных для записи, каждая из которых может совместно использоваться несколькими приложениями. Это позволяет решить проблему узкого места производительности и проблему единой точки отказа баз данных для записи.
4) Имеется несколько баз данных для чтения, и балансировка нагрузки достигается с помощью устройств балансировки нагрузки, что обеспечивает высокую производительность, высокую надёжность и высокую масштабируемость баз данных для чтения.
5) Серверы баз данных отделены от серверов приложений.
6) Использовать BigIP для балансировки нагрузки подчинённых баз данных.
Система кэширования
Кэширование делится на файловое кэширование, кэширование в памяти и кэширование баз данных. В крупномасштабных веб-приложениях кэширование в памяти используется наиболее широко и является наиболее эффективным. Наиболее часто используемый инструмент кэширования в памяти — Memcached. Использование подходящей системы кэширования позволяет достичь следующих целей:
1. Использование системы кэширования может повысить эффективность доступа, увеличить пропускную способность сервера и улучшить пользовательский опыт.
2. Снизить нагрузку от обращений к базам данных и серверам хранения.
3. Имеется несколько серверов Memcached, чтобы избежать единых точек отказа, обеспечить высокую надёжность и масштабируемость и повысить производительность.
Распределённая система хранения
Структурная схема:
Требования к хранению в платформе Web-системы имеют следующие две характеристики:
1) Объём хранения очень велик и часто достигает масштаба, который не может обеспечить один сервер, как, например, в приложениях фотогалерей и видео. Поэтому необходима профессиональная крупномасштабная система хранения.
2) Каждый узел в кластере с балансировкой нагрузки может обращаться к любому объекту данных, и обработка данных каждого узла также может совместно использоваться другими узлами. Поэтому данные, с которыми этим узлам нужно работать, логически могут быть только единым целым, а не независимыми ресурсами данных.
Поэтому высокопроизводительная распределённая система хранения является очень важной частью крупномасштабных веб-приложений. (Здесь нужно добавить краткое введение в распределённую систему хранения.)
Распределённая система управления серверами
Структурная схема:
С постоянным ростом трафика веб-сайтов большинство сетевых сервисов предоставляют внешние сервисы в виде кластеров с балансировкой нагрузки. По мере расширения масштаба кластера исходная модель управления серверами на базе одной машины больше не может удовлетворять наши потребности. Новые требования должны позволять управлять серверами централизованно, по группам, пакетно и автоматизированно, а также пакетно выполнять запланированные задачи.
Среди программного обеспечения распределённых систем управления серверами есть несколько превосходных программ, и одна из наиболее удачных — Cfengine. Он позволяет группировать серверы, и разные группы могут отдельно настраивать системные конфигурационные файлы, запланированные задачи и другие параметры. Он основан на структуре C/S. Все конфигурации серверов и программы управляющих скриптов хранятся на Cfengine Server, а управляемые серверы запускают программу Cfengine Client. Cfengine Client периодически отправляет запросы на сторону сервера через SSL-шифрованные соединения для получения последних конфигурационных файлов, команд управления, программ скриптов, установки патчей и других задач.
С помощью централизованного инструмента управления серверами, такого как Cfengine, мы можем эффективно реализовать управление крупномасштабными серверными кластерами. Управляемые серверы и сервер Cfengine могут быть распределены где угодно, и при наличии сетевого подключения можно обеспечить быстрое автоматизированное управление.
Система выпуска кода
Структурная схема:
С непрерывным ростом трафика веб-сайтов большинство сетевых сервисов предоставляют внешние сервисы в виде кластеров с балансировкой нагрузки. По мере расширения масштаба кластера, чтобы обеспечить пакетное распространение и обновление программного кода в кластерной среде, нам также нужна система выпуска программного кода.
Эта система выпуска может помочь нам достичь следующих целей:
1) Серверы в производственной среде предоставляют услуги в виде виртуальных хостов, не требуя участия разработчиков в обслуживании и прямых операциях. Система выпуска позволяет распространять программы на целевые серверы без входа на серверы.
2) Нам нужно реализовать управление четырьмя этапами разработки: внутренняя разработка, внутреннее тестирование, тестирование в производственной среде и выпуск в производственную среду. Система выпуска может участвовать в выпуске кода на каждом этапе.
3) Нам нужно реализовать управление исходным кодом и контроль версий. SVN может удовлетворить это требование.
Здесь можно использовать такие распространённые инструменты, как Rsync, а путём разработки соответствующих скриптов можно добиться синхронизированного распространения кода между серверными кластерами.
Источник: http://blog.csdn.net/dinglang_2009/article/details/6863697