Библиотека сайта rus-linux.net
Фреймворк Zotonic
Глава 9 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: Zotonic
Авторы: Arjan Scherpenisse и Marc Worrell
Перевод: Н.Ромоданов
Архитектура фреймворка Zotonic
Прежде чем мы рассмотрим оптимизацию производительности фреймворка Zotonic, давайте взглянем на его архитектуру. На рис.9.1 показаны самые важные компоненты Zotonic.
Рис.9.1: Архитектура фреймворка Zotonic
На схеме показаны слои фреймворка Zotonic, через которые проходит запрос HTTP. Для обсуждения проблем с производительностью нам нужно знать, что представляют эти слои и как они влияют на производительность.
Во-первых, фреймворк Zotonic поставляется со встроенным веб-сервером Mochiweb (еще один проект Erlang). Для него не требуется внешний веб-сервер. Это позволяет свести к минимуму зависимости времени развертывания фреймворка [1].
Как и во многих других веб-фреймворках, для сопоставления запросов к контроллерам используется система маршрутизации URL. Благодаря библиотеке Webmachine контроллеры обрабатывают каждый запрос в стиле RESTful.
Контроллеры являются «немыми» исполнителями без какой-либо специальной логики, относящейся к приложениям. В Zotonic предоставляется ряд стандартных контроллеров, которых часто оказывается вполне достаточно для разработки типовых веб-приложений. Например, есть контроллер controller_template, единственной целью которого являются ответы на запросы HTTP GET согласно заданному шаблону.
Языком шаблонов является Erlang-реализация хорошо известного языка шаблонов Django, которая называется ErlyDTL. Общий принцип фреймворка Zotonic заключается в том, что управление запросами данных осуществляется с помощью шаблонов. В шаблонах принимается решение, какие данные нужны шаблонам, и данные извлекаются из моделей.
В моделях предоставляются функции, используемые для извлечения данных из различных источников данных, например, баз данных. В моделях предоставляются интерфейсы API, используемые в шаблонах, в которых определяется, как могут использоваться эти API. Модели также ответственны за кэширование своих результатов в памяти; в моделях решается, когда и что кэшировать и как долго. Когда шаблонам требуются данные, они обращаются к моделям, как если бы модели были глобально доступными переменными.
Модель является модулем-оберткой языка Erlang, который отвечает за определенные данные. Она содержит необходимые функции для получения и запоминания данных так, как это нужно приложению. Например, центральная модель Zotonic называется m.rsc, с помощью которой обеспечивает доступ к модели данных общего ресурса (к «странице»).Если ресурсы используют базу данных, в m_rsc.erl используется подключение к базе данных для получения необходимых данных и передачи их в шаблон, причем эти данные кэширются всякий раз, когда это возможно.
Такой подход «шаблоны управляют данными» отличается от подходов, используемых в других фреймворках, например, в Django и Rails, в которых обычно следуют более классическому подходу MVC, при котором контроллер направляет данные в шаблон. Для того, чтобы с помощью простого написания шаблонов можно было создавать типичные веб-сайты, Zotonic следует менее «контроллер-ориентированному» подходу.
В Zotonic для долговременного хранения данных используется СУБД PostgreSQL. Обоснование этого выбора приводится в разделе «Модель данных: База данных документов на языке SQL».
Дополнительные концепции фреймворка Zotonic
Хотя основное внимание в этой главе сосредоточено на производительности стека веб-запросов, полезно знать некоторые другие концепции, которые являются сердцем фреймворка Zotonic.
Виртуальный хостинг
Обычно один экземпляр Zotonic обслуживает более одного сайта. В нем поддерживается виртуальный хостинг, допускающий алиасы доменов и поддержку SSL. А благодаря изоляции процессов в языке Erlang выход из строя одного из сайтов не влияет на работу любых других сайтов, работающих в той же виртуальной машине.
Модули
Модули являются способом объединения функциональных возможностей, который применяется в Zotonic. Каждый модуль размещается в своем собственном каталоге, в котором находятся файлы Erlang, шаблоны, другие ресурсы и т.д. Модули можно использовать в каждом сайте. Модули могут подключаться к системе администрирования: например, модуль mod_backup добавляет контроль версий в редактор страниц, а также работает в роли средства ежедневного полного резервного копирования базы данных. Еще один модуль, mod_github, доступен для операции webhook, с помощью которой сайт Zotonic можно выбрать из репозитария github, пересобрать, загрузить и развернуть для использования.
Уведомления
Чтобы обеспечить слабую связность кода и возможность его расширения, взаимодействие между модулями и компонентами ядра происходит с помощью механизма уведомлений, который действует как средство отображения или рассылки уведомлений тем наблюдателям, которые следят за уведомлениями с определенными именами. Благодаря прослушиванию уведомлений в модуле становится проще переопределять или реализовывать определенные функциональные возможности. В вызывающей функции определяется, будет ли использоваться отображение или одноразовое уведомление. Например, в модули, в которых разрешается добавлять или удалять пункты в административном меню, однократно рассылается уведомление admin_menu.
Модель данных
Основную модель данных, которая используется в Zotonic, можно сравнить с модулем Node в Drupal: «каждая сущность является отдельной сущностью». Модель данных состоит из иерархически сгрупированных ресурсов, которые с помощью помеченных дуг подключаются к другим ресурсам. Точно также, как и система управления контентом Anymeta, послужившая прототипом, эта модель данных полностью базируется на принципах семантического веба Semantic Web.
Zotonic является расширяемой системой, и когда вы рассматриваете вопросы производительность, то следует оценивать все части системы. Например, вы можете добавить модуль, который перехватывает веб запросы и что-то делает в ответ на каждый запрос. Такой модуль может влиять на производительность всей системы. В этой главе мы не будет рассматривать подобные ситуации, а вместо этого сосредоточимся на базовых вопросах производительности.
Продолжение статьи: Решение проблемы: борьба с эффектом Slashdot.