Содержание
Перевод © Чепиков Александр <achepikau • gmail • com>
Редактирование © Попов Руслан <radz • yandex • ru>
На протяжении всей книги мы перечислили множество задач, на решение которых нацелена разработка Django — это простота использования, дружелюбность к новичкам, освобождение от рутинной работы.
Однако с самого начала работы над Django существовала еще одна важная задача: Django должнен быть по возможности простым в развертывании и обрабатывать большой трафик при ограниченных требованиях к ресурсам.
Причина очевидна, если взглянуть на исходные данные этой задачи: небольшая «семейная» газета из Канзаса вряд ли была в состоянии приобрести высококлассное серверное оборудование, поэтому авторы Django сконцентрировались на выжимании наилучшей производительности из доступных им ресурсов. Более того, разработчики Django долгое время работали и как системные администраторы — просто потому что имеющегося в наличии оборудования не хватало для принятия на работу системного администратора на полную ставку — несмотря на то, что их сайты обрабатывали к тому времени десятки миллионов обращений в сутки.
Когда же Django превратился в проект с открытым исходным кодом, нацеленность на производительность и простоту развертывания стала важной и по другой причине: у свободных разработчиков аналогичные требования. Те из них, кто хотел использовать Django, были рады тому, что смогут платить всего 10 долларов за хостинг не очень большого (среднего) сайта.
Но возможность масштабирования «вниз» — это только половина успеха. Django должен масштабироваться и «вверх», чтобы удовлетворить запросы крупных компаний и корпораций. Поэтому Django придерживается общего подхода для LAMP-подобных веб приложений, который часто называют «ничего общего».
Как расшифровывается LAMP?
Аббревиатура LAMP изначально была придумана для описания популярного набора программного обеспечения с открытым кодом, который используется в работе многих вебсайтов:
Linux (Операционная система);
Apache (Веб сервер);
MySQL (Сервер базы данных);
PHP (Язык программирования).
Впоследствии, однако, эта аббревиатура стала скорее обозначением каких-то совокупностей общих типов программ с открытым кодом, нежели конкретного набора приложений. Поэтому, хотя Django использует Python и не привязана к конкретной базе данных, философия LAMP сильно влияет на умонастроения разработчиков Django.
Было даже несколько (в основном юмористических) попыток придумать похожую аббревиатуру для описания технологий, используемых в Django. Авторам данной книги пришлись по душе сокращения LAPD (Linux, Apache, PostgreSQL и Django), PAID (PostgreSQL, Apache, Internet и Django), а так же девиз «Use Django and get PAID!», что буквально означает «Применяй Django и получай зарплату!».
По своей сути данный подход означает, что приложение использует множество программных компонентов, слабо связанных между собой. Такая архитектура появилась, как альтернатива на превалирующий когда-то подход: монолитный сервер приложений, объединяющий язык программирования, базу данных, веб сервер и даже часть операционной системы в один процесс (например, Java).
И когда приходит время увеличить размеры приложения, это может стать основной проблемой: практически невозможно распределить монолитный процесс на физически разные компьютеры, поэтому монолитным приложениям требуются очень мощные сервера. Такие сервера, естественно, стоят десятки и даже сотни тысяч долларов, что препятствует их использованию небольшими компаниями и физическими лицами, всегда испытывающими нехватку денег.
Сообщество LAMP, однако, обращает внимание на то, что если разбить каждую часть веб приложения на отдельные компоненты, то вполне можно стартовать с недорогого сервера и просто добавлять такие же сервера по мере роста проекта. Если сервер базы данных за 3 тысячи долларов не справляется с нагрузкой, достаточно просто купить ещё один (второй, третий или четвертый) столько раз, сколько потребуется. Если потребовалось дополнительное дисковое пространство, несложно добавить еще один NFS сервер.
Для того, чтобы такой подход всё-таки работал, веб приложения не должны быть привязаны к одному серверу при обработке запроса, или даже части запроса. В сильно распределенных LAMP (и Django) системах по крайней мере полдюжины серверов могут использоваться для выдачи одной веб страницы! Вариантов построения таких систем множество, но все они сводятся к следующим принципам:
Текущее состояние не сохраняется локально. Другими словами, любые общие данные для различных запросов должны храниться в базе данных либо в централизованной кэш-системе.
Программа не должна быть замкнута на использование локальных ресурсов. Например, веб сервер не должен полагаться на то, что сервер базы данных работает на одном с ним физическом сервере. Он должен поддерживать работу с удаленной базой данных.
Каждый компонент в приложении должен быть легко заменяем и поддерживать репликацию. Например, если веб сервер Apache по каким-то причинам не подходит для текущего приложения, должна быть возможность без проблем заменить его другим веб сервером. Или в случае выхода из строя компьютера с веб сервером можно заменить его на другой с минимальным временем простоя. Помните, весь этот подход базируется на использовании недорогих, широко распространенных компьютеров. Выход из строя отдельных серверов должен быть предусмотрен заранее.
Как и следовало ожидать, Django соответствует этим принципам более или менее точно — ни один из компонентов Django не нарушает данного подхода — но знание его основ поможет, когда наступит время для увеличения размеров приложения.
Как это работает?
Такие рассуждения могут выглядеть неплохо на бумаге (или на вашем экране), но как всё это работает на самом деле?
Хорошо, вместо того, чтобы отвечать непосредственно на вопрос, давайте посмотрим на крайне неполный список компаний, которые основали свой бизнес на этой основе. Вы могли уже встречать их названия: Amazon, Blogger, Craigslist, Facebook, Google, LiveJournal, Slashdot, Wikipedia, Yahoo, YouTube.
Перефразируя известную сцену из «Когда Гарри встретил Салли»: «У нас будет всё то же, что и у них!»
0 комментариев | Оставьте комментарий