В первой части нашей серии приложений Appserver мы обсудили очень высокие различия в архитектуре Appserver по сравнению со стандартными стеками веб-серверов и познакомили вас с экземпляром Appserver. Если вы пропустили эту часть, пожалуйста, найдите время, чтобы прочитать ее .
В этой части мы немного углубимся в архитектуре Appserver. Мы рассмотрим концепции различных контекстов и частей Appserver, которые вы получаете из коробки, которые охватывают некоторые из основ большинства популярных платформ PHP. Мы также настроим веб-сервер и рассмотрим структуру приложения. Когда мы закончим, у вас должно быть четкое понимание контекста Appserver в отношении потоков, веб-сервера и его настройки.
В последующих частях мы продолжим более подробно рассматривать механизм сервлета, контейнер персистентности, компоненты, систему обмена сообщениями и модуль таймера. ( Примечание: по мере развития этой серии направление также изменилось, чтобы включить больше практической информации для разрушения сухой теории. )
Контексты и потоки
Как мы уже говорили в первой части, в сегодняшнем стандартном сценарии веб-сервера у вас будет веб-сервер и либо модуль веб-сервера (mod_php), либо менеджер процессов php (PHP-FPM) для обслуживания сценариев / приложений PHP. Веб-сервер и диспетчер процессов PHP или модуль управляют своей работой и работой с потоками для обслуживания веб-страницы или приложения PHP.
В этом же отношении Appserver также обрабатывает потоки для разработчика клиента. Тем не менее, использование потоков несколько отличается. Содержимое, созданное в потоке, не постоянно создается и уничтожается во время работы сервера приложений. Другими словами, пока запущен сервер приложений, код, который вы дали ему для выполнения, будет продолжать работать (оставаться в памяти) для каждого запроса. Это фундаментальное различие повторяется, так как оно очень важно для понимания всего остального, в которое мы углубимся.
Мы перешли темы в последнем посте. Теперь вы можете спросить, что такое контекст? Определение контекста в Appserver — это «среда выполнения потока». Таким образом, каждый поток имеет свой собственный контекст. Преимущество потока и его контекста над общим процессом заключается в его способности делиться своим содержимым с другими потоками и при этом оставаться «потокобезопасным». Можно назвать это преимуществом, но если его не контролировать, это может стать кошмаром. Итак, чтобы избежать кошмара, Appserver контролирует совместное использование для вас, и это делается через контекст или наследование потоков.
Appserver предлагает ряд стандартных контекстов. После запуска и запуска Appserver создаст иерархию или дерево контекстов с корневым контекстом, являющимся верхним уровнем или родительским контекстом. Оттуда у вас будет контекст контейнера и ниже этого контекста сервера, где находится веб-сервер. Веб-сервер создает рабочие контексты (количество рабочих настраивается). Это рабочие контексты, которые позволяют параллельную обработку запросов, которые создаются и контролируются внутри каждого рабочего.
Дочерние контексты могут выборочно наследовать экземпляры, значения конфигурации, константы, функции, определения классов и даже комментарии от своих родителей. Формирование контекстов также позволяет четко разделить проблемы, где это необходимо. Однако, пожалуйста, не путайте это наследование с обычным наследованием ООП. Это не совсем то же самое.
Совместное использование данных между контекстами и тот факт, что контексты не уничтожаются при каждом запросе, — это возможность внутри Appserver, которая обещает повышение производительности приложения, специально созданного для Appserver. Такие вещи, как результаты инициализации приложения (начальной загрузки), которая часто считается одним из самых дорогостоящих процессов в приложении PHP, теперь могут находиться в памяти. Кроме того, работа может передаваться в другие контексты, поэтому процессу приложения не нужно ждать выполнения этой работы (асинхронное программирование). Вот некоторые из преимуществ, которые дает веб-разработчик, использующий Appserver.
Прежде чем мы углубимся в глубину модулей appserver и их программирование, нам необходимо рассмотреть некоторые концепции программирования, которые он использует.
Концепции и методы программирования в Appserver
Аннотации
Одним из важных и, вероятно, противоречивых методов, используемых в Appserver, являются аннотации. Основная идея использования аннотаций заключается в том, чтобы «сделать Appserver простым в настройке» или, скорее, «сохранить Appserver простым в программировании». Аннотации играют важную роль в программировании в среде Appserver от маршрутизации до объявления bean-компонентов и настройки сервлетов.
Хотя аннотации являются основной частью системы конфигурации appserver, клиент-разработчик все же может настраивать файлы XML. Фактически, практически все, что аннотируется, также может быть установлено и даже переопределено через web.xml находящийся в каталоге приложения ( /WEB-INF ). Таким образом, для тех, кто не хотел бы, чтобы аннотации были добавлены в код, вы можете использовать файл XML для настройки.
АОП — Аспектно-ориентированное программирование
Основной парадигмой программирования, используемой в Appserver, является AOP или Аспектно-ориентированное программирование . Вы не замкнулись в этом, но это современный способ программирования, за которым следует Laravel, вероятно, самая популярная среда PHP в настоящее время. Таким образом, эта парадигма ООП стоит посмотреть. Понимание значения сквозных проблем или аспектов, ткачества и точек соединения поможет вам понять некоторые основы, лежащие в основе дизайна и правильного использования Appserver.
Дизайн по контракту
Проект по контракту также отслеживается в Appserver. Это удобно, поскольку обеспечивает строгую типизацию между всеми модулями. Appserver использует комментированные аннотации типов для параметров и возвращаемых значений методов (что является стандартным в большинстве IDE) и использует их для обеспечения более строгой типизации. Если во время выполнения неправильно выполняется ввод текста, могут возникать исключения. Исключения, которые вы также можете создать сами. Также возможно регистрировать эти исключения. Мы покажем пример этого позже.
Теперь давайте рассмотрим каждый из доступных модулей.
Веб-сервер
Одна из основных целей Appserver — предложить разработчикам PHP относительно простой в использовании, но готовый к работе стек веб-серверов. Это достигается за счет того, что он предлагает множество функциональных возможностей, присутствующих в большинстве сред PHP, которые формируют основу для более быстрой среды разработки PHP. Фактически, «встроенный» веб-сервер на самом деле является важной частью, отсутствующей в этих платформах.
Веб-сервер в Appserver является частью серверной инфраструктуры . Это веб-сервер, написанный исключительно на PHP. Да! PHP! Он также представляет основной модуль серверного контекста Appserver. В настоящее время подключение к веб-серверу возможно через HTTP 1.1. Поддержка HTTP 2.0 планируется для будущей версии, в настоящее время 1.3.0 или, возможно, 2.0.
Основные функциональные возможности, которые большинство из вас, вероятно, распознают в большинстве популярных платформ, поступают с веб-сервера в форме объектов $request и $response . Поскольку Appserver следует AOP, объекты будут фактически вызываться через интерфейс, такой как HttpServletRequestInterface . Мы рассмотрим использование объектов запроса и ответа в нашем обзоре примера приложения, установленного вместе с Appserver, в следующей части.
С точки зрения пользователя или клиента Appserver конфигурация и использование веб-сервера аналогичны настройке веб-сервера Apache. В модуле веб-сервера возможны такие вещи, как перезапись, виртуальные хосты, установка переменных среды и HTTP-аутентификация.
Самые важные файлы конфигурации для контекста сервера находятся в /etc/appserver . Там вы найдете файл appserver.xml для настроек сервера, веб-сервера и контейнера, а также файлы /conf.d/virtual-hosts.xml , в которые будут добавлены определения вашего виртуального хоста. Уже установлен пример файла, который поможет вам настроить виртуальный хост.
Давайте теперь настроим виртуальный хост в веб-сервере appserver.
Создание виртуального хоста
Надеемся, что вы выполнили указания из первой части этой серии, и на вашей удобной локальной виртуальной машине работает Appserver. В прошлом сообщении в блоге мы использовали виртуальную машину Debian Wheezy. Установка должна была настроить вас с примером приложения, которое вы можете найти по адресу http://my-app.com:9080/example . Мы собираемся настроить Appserver для обслуживания примера приложения по URL- http://my-app.com ( my-app.com представляющий имя, которое вы настроили для сервера, если оно будет отличаться от того, что Bruno предложил в своей статье ). Этот короткий процесс поможет вам настроить виртуальный хост.
Шаг 1 — Изменить порт (однократное изменение)
Не совсем необходимо, но все же удобно. Мы избавимся от необходимости вводить номер порта :9080 с каждого URL. Во-первых, убедитесь, что никакой другой веб-сервер не блокирует порт 80, остановив службу, например:
service nginx stop
или
service apache2 stop
Затем перейдите в /opt/appserver/etc/appserver и откройте appserver.xml . Найдите следующие строки.
<server name="http" type="\AppserverIo\Server\Servers\MultiThreadedServer"
Под ними ищите параметр порта.
<param name="port" type="integer">9080</param>
И изменить 9080 на 80 .
Шаг 2 — Изменить / добавить виртуальный хост
Теперь перейдите в каталог /conf.d и откройте файл virtual-hosts.xml . Это должно выглядеть так.
<?xml version="1.0" encoding="UTF-8"?> <!-- ! The following is a basic showcase example for a virtual host configuration. ! Some more examples can be found at: ! ! http://appserver.io/get-started/documentation/webserver.html#virtualhost-examples --> <virtualHosts xmlns="http://www.appserver.io/appserver"> <virtualHost name="example.local www.example.local"> <params> <param name="admin" type="string">[email protected]</param> <param name="documentRoot" type="string">webapps/example</param> </params> <rewrites> <rewrite condition="-d{OR}-f{OR}-l" target="" flag="L" /> </rewrites> <accesses> <access type="allow"> <params> <param name="X_REQUEST_URI" type="string">^.* </param> </params> </access> </accesses> </virtualHost> <virtualHost name="dbadmin.awesome.dev"> <params> <param name="admin" type="string">[email protected]</param> <param name="documentRoot" type="string">webapps/phpmyadmin</param> </params> <rewrites> <rewrite condition="-d{OR}-f{OR}-l" target="" flag="L" /> </rewrites> <accesses> <access type="allow"> <params> <param name="X_REQUEST_URI" type="string">^.* </param> </params> </access> </accesses> </virtualHost> </virtualHosts>
Важно отметить различные области файла, такие как, virtualHost , accesses и rewrites . Это общие конфигурации, с которыми вы будете иметь дело для каждого виртуального хоста. Также обратите внимание на параметр documentRoot . Теперь это поможет нам избежать добавления каталога /example в URL.
Измените имя virtualHost чтобы оно выглядело следующим образом.
<virtualHost name="my-app.com www.my-app.com">
И снова my-app.com — это имя, которое вы создали с помощью поля Vagrant. Мы также добавляем здесь www.my-app.com , так как мы www.my-app.com правильный веб-сайт с доступом к www. суб-домен.
Чтобы эти изменения вступили в силу, вам необходимо перезапустить Appserver.
service appserver restart
Если вы хотите (и должны), вы можете добавить правило перезаписи, которое будет перехватывать любой вызов www. поддомен и перенаправить его в основной домен или наоборот. Мы пойдем с первым, www. поддомен к основному домену. Это следует очень важному и довольно стандартному правилу SEO. Один и тот же контент никогда не должен быть доступен под разными URL!
Чтобы создать это правило, в разделе <rewites> добавьте следующую строку под уже существующим условием перезаписи.
<rewrite condition="^www\.@$HTTP_HOST" target="$REQUEST_SCHEME://my-app.com$X_REQUEST_URI" flag="R,L" />
Это условие ищет любой URL с префиксом www. и перенаправляет его к целевой схеме, которая является нашей основной областью. Также обратите внимание, что мы можем просто добавить переменную $X_REQUEST_URI вместо $X_REQUEST_URI . Это экономит немного вычислений для регулярных выражений. Вы можете использовать любые значения массива $_SERVER обычно доступные из PHP в правилах перезаписи. Это удобно, не правда ли?
Проверьте, можете ли вы увидеть пример приложения под своим доменным именем. В нашем примере это будет под:
http://my-app.com
Если все прошло хорошо, вы должны увидеть пример приложения.
Последнее замечание, прежде чем копаться в сервлетах. Appserver также поставляется с собственным PHP-FPM, в настоящее время 5.5.x, работающим на порту 9010. Вы также можете запустить с вашим собственным FPM, изменив порт в файле appserver.xml . Кроме того, Appserver в настоящее время не запускает свою службу FPM автоматически, поэтому не забудьте также запустить ее, если вам нужно запускать приложения, не созданные непосредственно для Appserver (например, WordPress). Чтобы запустить службу, в консоли вашей оболочки введите
service appserver-php5-fpm start
Если вам нужно внести какие-либо изменения в настройки PHP Appserver, вы также найдете соответствующий файл .ini в /opt/appserver/etc
Servlet Engine
Если вы можете вообразить, что веб-сервер — это глаза, уши и рот Appserver, то механизм сервлетов — это временная доля мозга . Те из вас, кто любит Java, могут также распознать сходство между сервлетами Appserver и Java-сервлетами . В теории и на практике они в значительной степени одно и то же.
Мучительный процесс начальной загрузки больше не
Одним из самых дорогостоящих процессов, которые имеют все основные фреймворки или мощные веб-приложения с текущими стеками веб-серверов PHP, является процесс начальной загрузки. В этом процессе читается конфигурация и настраивается среда выполнения. Поскольку этот процесс должен выполняться с каждым запросом, он является источником потери производительности и часто компенсируется некоторой схемой кэширования, которая добавляет сложности приложению. При использовании appserver процесс начальной загрузки выполняется только один раз при запуске сервера, поэтому он автоматически кэшируется. Загрузочный код, как сервлеты в движке сервлетов, хранится в памяти, пока не будет остановлен appserver. Эта часть инициализации appserver довольно важна и является одним из ее основных преимуществ.
Файловая структура Appserver
Прежде чем идти дальше, нам необходимо понять структуру файлов и каталогов приложения Appserver. Он отличается от обычной файловой структуры, которую вы можете найти в большинстве проектов PHP. Фактические приложения находятся в каталоге /webapps . В нашей установке Appserver вы должны увидеть пример приложения в каталоге /example . В этом каталоге вы найдете следующую структуру каталогов.
Вот краткий обзор важных каталогов в приложении Appserver.
/WEB-INF — этот каталог содержит клиентские классы PHP. Вы заметите, что в примере приложения есть как примеры для сервлетов (которые непосредственно не используются в приложении), так и классы «действий», которые используются в приложении. Эти классы образуют контроллеры приложения.
/META-INF — этот каталог содержит код для внутренних служб. Здесь должны храниться аспекты и любой код входа для моделей предметной области.
/common — В этом каталоге содержатся общие классы, общие для классов META-INF и WEB-INF.
/vendor — этот каталог содержит любые библиотеки, которые вы, возможно, импортировали в свой проект с помощью Composer . Appserver поддерживает Composer и PSR-0 для автозагрузки классов. PSR-4 не поддерживается, так как требуется пользовательская структура каталогов.
/static — Этот каталог является домом для всех статических ресурсов (например, JS, CSS и файлов изображений), которые необходимы для правильной визуализации веб-приложения.
Вышеуказанные каталоги являются структурой каталогов по умолчанию. Структура также может быть настроена через дополнительный файл context.xml в META-INF или WEB-INF. Если вы намерены отойти от структуры по умолчанию, дополнительную информацию об этом можно найти в документации appserver .
Важно отметить — Связь между классами, используемыми в механизме сервлета (WEB-INF) и контейнере персистентности (META-INF), может осуществляться с прокси-объектами. Эти объекты могут быть переданы по сети, аналогично удаленному вызову метода в Java. Это означает, что можно экстраполировать эти два уровня на их собственные машины и запускать их в качестве служб в системе на основе SOA . Эта способность отправлять объекты по сети позволяет асимметрично масштабировать Appservers, что является еще одной из его встроенных функций.
Вывод
Мы рассмотрели контексты и многопоточность в Appserver и то, как Appserver позаботится о «грязной работе» для вас с многопоточностью, предварительно создав необходимые модули в контекстах потоков. Мы кратко рассмотрели различные инструменты программирования и предлагаемые парадигмы, такие как AOP или проектирование по контракту. Мы познакомили вас с веб-сервером Appserver и объяснили, как должна выглядеть структура файла приложения. Мы также погрузились в настройку веб-сервера.
Уф!
И мы даже не поцарапали поверхность Appserver, правда. Это отличная платформа, предлагающая новый шанс для создания более мощных и легко масштабируемых веб-приложений на PHP.
В следующих частях мы углубимся в другие модули, предлагаемые «из коробки», такие как механизм сервлетов и очередь сообщений.
Как всегда, ваши хорошие комментарии, критика и просьбы освещать любые пропущенные области приветствуются!
Примечание. Данный пост был сделан с помощью appserver версии 1.0.6. Самая новая версия 1.1.0 была выпущена незадолго до того, как этот пост был включен в процесс публикации. Мы постараемся охватить как можно больше новых функций в следующих частях этой серии.