Ниже приведен небольшой отрывок из нашей недавней книги « Среда PHP Start Start» , доступной бесплатно для членов SitePoint Premium . Печатные и электронные книги продаются в магазинах по всему миру, или вы можете заказать их здесь . Мы надеемся, что вам понравится этот экстракт и вы найдете его полезным.
Эта часть будет посвящена среде приложения. Мы также обсудим комплекты * AMP, такие как XAMPP, и почему они плохой выбор; соотношение производства / развития; и производительность и отладка.
Среда приложения — это термин, используемый для описания среды, в которой ваше приложение может оказаться на различных этапах жизненного цикла: производственная среда, среда разработки и промежуточная среда.
Слово среда относится к аппаратному и программному обеспечению вокруг вашего приложения; то есть все, что использовалось для его питания.
Мы начнем с самой простой среды: производственной среды .
При развертывании приложения ― другими словами, загрузите его на сервер и сделайте его общедоступным для целевой аудитории ― вы запускаете его в производство или в эксплуатацию . Производственная среда — это конечный пункт назначения вашего приложения, цель вашего кода.
В жизненном цикле приложения производственная среда — это живой сервер — серверный компьютер, настроенный так, чтобы другие люди могли подключиться к нему и увидеть ваш веб-сайт. Этот оперативный сервер будет настроен для максимально эффективного обслуживания вашего приложения. Все дополнительные файлы, которые вы использовали во время разработки, будут удалены из приложения с помощью процесса, известного как компиляция или сборка, что объясняется далее.
Находясь в работе, ваш сайт считается живым (или развернутым) и будет доступен через собственный домен; например, http://mysite.com . Когда вы запускаете свой сайт (переводите его в рабочий режим), у вас есть повод для празднования, потому что это последний шаг в процессе разработки вашего приложения.
Это равносильно тому, что повар готовит еду в ресторане и доставляет ее заказчикам.
В среде разработки ваше приложение активно разрабатывается. Среда разработки — это компьютер, который вы, как разработчик, используете для разработки приложения, включая компьютеры всех членов вашей команды, независимо от того, находятся ли они рядом с вами или удаленно. Важно отметить, что, несмотря на охват обоих аспектов, среда разработки больше относится к состоянию вашего приложения , а не к его физическому расположению — приложение находится в состоянии разработки .
В среде разработки в вашем распоряжении имеются различные инструменты — от IDE (см. Главу 2) до библиотек модульного тестирования и фиксаторов стандартов, компиляторов и сборщиков, средств просмотра файлов и многого другого — всего, что вам нужно для выполнения поставленной задачи.
Если мы сравним наше приложение со смартфоном, сборочный завод, на котором оно производится, является средой разработки. Эта среда содержит все необходимые компоненты — экран, корпус, аккумулятор, различные светодиоды — и каждая часть проходит индивидуальное тестирование перед использованием в конструкции блока смартфона. Это называется модульным тестированием, обеспечивающим работу каждого модуля.
Пример модульного тестирования при разработке приложений см. В разделе «Для тех, кто хочет большего» в конце этой главы.
Чтобы продолжить аналогию со сборкой смартфона, для тестируемой батареи может потребоваться отдельное зарядное устройство или может потребоваться тестирование экрана с помощью роботизированной руки с синтетическими пальцами, чтобы убедиться, что сенсорная чувствительность экрана работает.
Все эти дополнения есть только в процессе разработки. При преобразовании из среды разработки в производственную среду (также известную как развертывание ) эти надстройки удаляются. Для нашего приложения это означает вышеупомянутый этап компиляции / сборки: различные файлы CSS и JavaScript объединяются и сокращаются, чтобы уменьшить размер веб-сайта, делая его быстрее, когда люди посещают его; модульные тесты игнорируются и остаются в среде разработки; и происходят различные другие оптимизации (описанные далее в этой главе) — все с целью сделать конечный продукт максимально привлекательным и потенциальным, когда он будет объявлен готовым.
Когда вы разрабатываете на своем компьютере, невозможно зайти по URL http://mysite.com и ожидать увидеть ваш сайт; В конце концов, ваш сайт еще не запущен, его нет в Интернете. Чтобы обойти это и увидеть наш сайт как живой, мы подделываем Интернет, определяя виртуальные хосты.
Проще говоря, виртуальный хост дает инструкцию серверной программе, установленной на вашем компьютере, такую как: ЕСЛИ пользователь запрашивает http://mysite.com в браузере, запускает файл mysite.php через PHP и показывает его вывод в браузер.
Как видите, это практически идентично обычному потоку запросов живых сайтов. Но что заставляет браузер запрашивать серверную программу нашего собственного компьютера для домена mysite.com , а не искать его на серверах имен в Интернете? Файл hosts .
Файл hosts — это специальный файл, присутствующий в каждой операционной системе. Мы кратко упомянули об этом в разделе «Для тех, кто хочет большего» в Главе 1. Он содержит список доменов и их соответствующие IP-адреса, так что любой браузер на вашем компьютере может прочитать его и перейти непосредственно к IP-адресу, не имея поговорить с DNS, чтобы проверить, куда идти. В Windows этот файл находится в C:\Windows\System32\drivers\etc\hosts , а на машинах Linux и Mac — в /etc/hosts . Если вы поместите пару IP-имен в этот файл, компьютер выполнит его. Мы даже можем попробовать это прямо сейчас. Не бойтесь, нет ничего, что может пойти не так. Готов?
В Windows введите поле поиска, введите «блокнот» и, как только он появится, щелкните его правой кнопкой мыши и выберите « Запуск от имени администратора» . Затем система запросит у вас подтверждение. В открывшемся окне выберите « Файл»> «Открыть» и перейдите: « Мой компьютер»> «C:»> «Windows»> «System32»> драйверы> и т . Д. В правом нижнем углу окна «Блокнот» может потребоваться выбрать « Все файлы», чтобы hosts файл hosts . Дважды щелкните, чтобы открыть его.
На компьютерах с Linux / Mac откройте терминал, выполнив его поиск. В Linux откройте текстовый редактор по умолчанию от имени администратора, введя sudo gedit в Terminal. Вам будет предложено ввести пароль администратора. В OS X введите sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit , который выполнит ту же задачу. В любом из этих редакторов перейдите в File -> Open и введите каталог /etc чтобы найти файл hosts . Дважды щелкните, чтобы открыть его.
Как только файл откроется, обратите внимание на первые несколько строк: все они начнутся с символа хеша (#). Это указывает на то, что они являются комментариями и не влияют на файл. Они служат для объяснения пользователю цели файла и существуют также в PHP.
Теперь под всеми этими строками комментариев добавьте следующую строку:
208.117.229.217 bing.com
Сохраните файл и откройте http://bing.com в вашем браузере. Вы только что успешно перенаправили все запросы в поисковую систему Microsoft Bing в Google! Конечно, мы не хотим сохранять эти изменения; не стесняйтесь удалить эту строку или поставить перед ней символ хеша, чтобы превратить ее в комментарий, и сохранить файл. Вы сможете снова зайти на http://bing.com в обычном режиме.
Используя этот метод, мы позже перенаправим все запросы браузера для http://mysite.com (который будет примером домена нашего приложения) на сервер нашего собственного компьютера. Это позволит нам легко протестировать версию разработки нашего сайта, не разворачивая его вживую.
Промежуточная среда — это отдельный сервер (или несколько серверов), содержащий копию (также известную как зеркало) производственной среды. Промежуточная среда часто пропускается в небольших компаниях или проектах. Он спроектирован так, чтобы максимально приближаться к производственной среде с соответствующими версиями установленного программного обеспечения, одинаковыми значениями конфигурации и т. Д. Постановка для проведения финальных испытаний; например, Facebook может перепроектировать свою главную страницу, и, прежде чем развернуть ее в производство для всеобщего обозрения, он развернет ее на своих промежуточных серверах, чтобы сотрудники (выделенные непрограммисты, также известные как группа обеспечения качества) могли сначала протестировать все как будто использую это регулярно. Если все идет хорошо, происходит окончательное развертывание от подготовки к производству.
Постановка выходит за рамки этой книги, но полезно знать об этом. В эпоху виртуальных машин и небольших одноразовых проектов подготовка может быть ненужной, только вступая в игру с более крупными долгосрочными веб-приложениями.
Существует также режим обслуживания , термин, который мы должны охватить в этом контексте. Это режим, а не среда, потому что среда вокруг приложения не меняется — меняется только состояние приложения. Обычно это просто переключение на производственном сервере, когда те, кто пытается получить доступ к веб-сайту, произносят слова «Вернись, настраивайся!»
Когда вы начинаете разработку PHP, заманчиво загрузить и установить такие пакеты, как XAMPP, WAMP, MAMP или EasyPHP . AMP в этих именах означает «Apache, MySQL и PHP». XAMPP добавляет еще один P в конце для языка Perl. Первая буква относится к операционной системе: Windows, Linux, Mac OS X или, в случае XAMPP, кроссплатформенной (то есть она работает на любой ОС).
Эти пакеты содержат все программное обеспечение, необходимое для быстрого и удобного запуска PHP-приложений на вашем компьютере. Одним щелчком мыши вы можете установить все, что вам может понадобиться, чтобы написать свой самый первый PHP-скрипт. Так где же в этом зло?
-
ваш компьютер будет загрязнен ненужным программным обеспечением
-
вы узнаете меньше, чем вы, установив вручную
-
тестирование сложно
-
если вы допустили ошибку, либо очень трудно, либо невозможно вернуться в предыдущее состояние
Давайте рассмотрим их по одному.
Всякий раз, когда вы устанавливаете программное обеспечение, такое как стек * AMP, на ваш компьютер, часть вашего компьютера умирает. Даже если вы впоследствии удалите программное обеспечение, неудобные следы обычно остаются — часто в форме записей реестра в Windows или файловой пыли в Linux. На самом деле это особенно заметно в Linux. В то время как приложения для Windows и OS X устанавливаются в папке приложений со всеми связанными файлами внутри нее, в Linux установка программного обеспечения подобна переносу дробовика в замок, построенный из Legos. Один клик и они везде .
Со временем вы установите другую библиотеку, другой пакет, другой инструмент. По мере дальнейшего развития вашего приложения вы будете добавлять дополнительное программное обеспечение, возможно, полностью добавляя различные элементы, потому что вы начали параллельно работать над новым проектом. Возможно, app1 требуется расширение PHP для редактирования изображений, а app2 — расширение PHP, которое позволяет упаковывать код в архивы с закрытым исходным кодом, чтобы ваш код был скрыт от конкурентов. Со временем вы будете иметь сотни мегабайт программного обеспечения для разработки на вашем компьютере, не зная, нужно ли вам это по-прежнему.
Ваша машина будет работать медленнее, приложения станут менее пригодными для использования, а ваша машина разработки — компьютер, на котором вы работаете — станет настолько отличаться от рабочего сервера, на котором вы в конечном итоге намереваетесь развернуть свое приложение, что вы не сможете справиться с разница изящно В конечном итоге вы будете регулярно бороться с ошибками на живом веб-сайте и бесконечно раздражать ваших посетителей.
В зависимости от этих готовых пакетов вы также лишаете себя опыта обучения системному администрированию ( ops , вкратце). В крупных компаниях Ops — это команда или лицо, отвечающее за проблемы с сервером — будь то исправление ошибок, установка нового программного обеспечения, обновление существующего программного обеспечения и т. Д. В небольших командах или при работе с клиентами в одиночку базовое системное администрирование является необходимым навыком.
В то время как возможность установить все, что вам нужно, на ваш компьютер одним щелчком мыши, очень удобна, на сервере нет пользовательского интерфейса и, следовательно, нечего щелкать; вам нужно освоить команды, необходимые для настройки программного обеспечения сервера, чтобы он мог запускать ваше PHP-приложение. В противном случае вам либо придется нанять администратора сервера, чтобы помочь вам, либо, что еще хуже, использовать виртуальный хостинг (страшная история, которая описана в главе 6).
Отказываясь полагаться на эти комплекты * AMP, вы будете вынуждены пройти курс обучения по установке сервера и другого программного обеспечения вручную — знания, которые будут полезны во многих отношениях, чем один, если вы серьезно относитесь к этому пути карьеры , Кроме того, закрепить основы на самом деле не так сложно, как вы увидите позже в книге.
Скажем, app1 и app2 построены на PHP 5.3, работают под управлением MySQL 4.0 и предназначены для запуска на сервере с Apache (серверное программное обеспечение). Затем есть новое требование: убедитесь, что app1 работает на PHP 5.6 и MySQL 5.1 и может работать на Nginx (еще одна серверная программа, конкурирующая с Apache, произносится как «engine x»). О-о, что теперь?
Мы могли бы обновить PHP до более новой версии и проверить, все ли работает app1 , но как мы можем затем продолжать разработку app2 без случайного использования кода, который недоступен в PHP 5.3, если весь наш компьютер теперь работает под управлением 5.6? Аналогично, мы могли бы обновить MySQL до 5.1 и проверить, что он все еще работает, но как мы узнаем, что MySQL не выпустил некоторые старые функции в версии 5+, которые могли бы сломать app2, даже если мы исправили app1 для работы на 5.1? В конце концов, app2 все еще должен работать на 4.0, потому что он, вероятно, все еще развернут на таком производственном сервере. Черт возьми, как нам справиться с проблемой Apache против Nginx? Мы устанавливаем оба веб-сервера на наш компьютер и тестируем для каждого? Как мы их выключаем? Как мы можем гарантировать, что не забудем тестировать наш сайт на одном, пока другой работает?
И это только для двух приложений. Теперь представьте, что вам приходилось иметь дело с дюжиной приложений от десяти разных клиентов, у каждого из которых разные требования. Все перестает быть веселым очень, очень быстро.
Такое разделение различных версий программного обеспечения легко решить с помощью виртуальных машин, о которых мы поговорим в главе 4.
Наконец, что если мы попытаемся установить новую версию PHP, но что-то пойдет не так? Этот сценарий особенно распространен в OS X и Linux — теперь ни одна из версий PHP, которые мы установили на машине, не работает, и невозможно запустить ни один сайт. Какой беспорядок! Вместо того, чтобы легко возвращаться к предыдущему состоянию работы, мы вынуждены провести целый день, отлаживая нашу собственную систему и пытаясь заставить ее работать — не обязательно нужную версию, а просто запустить .
Разве не было бы замечательно, если бы мы могли просто ввести команду и заставить вещи вернуться к тому, что было 10 минут назад? Ну, мы можем! Это также будет продемонстрировано в главе 4.
Эта сложно звучащая фраза на самом деле очень проста — мы уже коснулись ее раньше. Соотношение между производством и разработкой означает не что иное, как создание среды производства и разработки, максимально похожей друг на друга, предпочтительно идентичной, чтобы все, что вы разрабатываете, автоматически запускалось в производстве без какой-либо чрезмерной конфигурации, дополнительной отладки или настройки.
Достижение паритета очень важно для рабочего процесса из-за огромного количества времени, которое он экономит. Избегать необходимости выполнять какую-либо дополнительную работу для запуска приложения в производственной среде означает, что у вас есть свобода и время сосредоточиться на важных бизнес-логических проблемах, которые действительно полезны для контекста вашего приложения, а не зацикливаться на постоянном разгоне. Внесение изменений в разработку, а затем необходимость внесения двух изменений в производство, чтобы это изменение стало очевидным, в лучшем случае утомительно, а в худшем — вредно для здоровья проекта. Вы никогда не знаете, кто в команде ускользнет и заставит приложение приветствовать людей с экраном ошибки.
Лучший способ достижения паритета — это использование в среде разработки того же программного обеспечения, что и в производственной среде. Например, если вы хотите развернуть свое приложение в рабочей среде на сервере с операционной системой Ubuntu Linux версии 14.04, лучше всего разрабатывать и эту операционную систему. Тем не менее, что если мы работали под управлением Windows, потому что нам нравится использовать расширенный мультимедийный контент, например игры, или нам нужно мощное программное обеспечение для работы с изображениями и видео, которое просто не может существовать в ОС Linux? Должны ли мы оставить все наши другие интересы, установить Linux поверх Windows и стремиться к паритету в отношении всего остального? Или мы должны просто оставить паритет и рисковать им, сохраняя при этом наш компьютер мощным, красивым и стабильным, придерживаясь выбранной нами операционной системы?
К счастью, существует третий способ, позволяющий вам достичь лучших результатов в обоих мирах: виртуальные машины (см. Главу 4).
Последними аспектами среды приложения, которые мы должны затронуть, является обеспечение того, чтобы приложение было быстрым (производительность) и без ошибок (отладка). Этот раздел полностью теоретический; это просто, чтобы вы знали, чего ожидать позже, когда мы сталкиваемся с некоторыми из этих терминов.
Производительность достигается за счет различных методов оптимизации . Вопреки смыслу слова, оптимизация разработки приложений часто имеет несколько уровней и редко является изменением, которое немедленно приводит к идеальному решению. Производительность включает, но не ограничивается, несколькими областями:
- Оптимизация базы данных
-
Часто самая медленная часть любого веб-сайта, база данных может извлечь выгоду из дополнительных оптимизаций после того, как она работает некоторое время, и становятся очевидными узкие места (части, которые являются самыми медленными, потому что они не могут обработать количество входящих запросов достаточно быстро). Методы оптимизации базы данных включают настройку индексов, разделение операций чтения и записи, изменение механизмов базы данных, кэширование извлеченных данных и другие фразы, звучащие мистически.
- Оптимизация внешних активов
-
Мы упоминали о компиляции и сборке ранее — так мы оптимизируем интерфейс сайта. Когда веб-сайт показывается пользователям, они видят выходные данные, состоящие из изображений, HTML, CSS и JavaScript, все из которых необходимо загрузить и выполнить в браузере, как описано в главе 1. Чем меньше эти файлы, тем меньше there чем быстрее загружается сайт. Часто веб-сайт имеет несколько файлов CSS и несколько файлов JavaScript. Объединение каждого типа в один больший файл CSS или JavaScript приводит к значительному увеличению скорости загрузки веб-сайта. Еще один часто используемый трюк по оптимизации ресурсов интерфейса — это обслуживание изображений через сеть доставки контента или CDN, стороннюю службу, которая размещает ваши изображения для вас и гарантирует, что посетитель вашего сайта загрузит их с ближайшего к ним сервера, тем самым дальнейшее увеличение скорости. Можно также уменьшить размер изображения, создать спрайт изображения , поместив все изображения в один файл, и многое другое.
- Оптимизация серверной части
-
Это также этап компиляции / сборки. Тестовые файлы игнорируются, и файлы объединяются в более крупные, чтобы использовать их вместо миллиона меньших. Некоторые приложения PHP даже скомпилированы в другой язык программирования, такой как C ++, который намного, намного быстрее.
- Кэширование
-
Кэширование — это сохранение ранее необходимых файлов и ответов на более поздний срок с ожиданием их повторного запроса. Если вы спросите базу данных об общем количестве пользователей в вашей базе данных, она подсчитает их и даст вам номер. Если вы заставите его сохранить этот номер на потом (то есть кэшировать его), в следующий раз, когда его спросят, он может просто получить уже подготовленную информацию. Когда вы спрашиваете сервер «Что я получу, если я зайду на mysite.com/user/5?», Он ответит вам. Если вы скажете ему вспомнить ответ в следующий раз, когда задается вопрос, серверу не нужно выглядеть так, как он уже знает. Кэширование так важно в веб-разработке — часто говорят, что «кеш — это король». Это может означать разницу между жизнью и смертью для вашего приложения, когда внезапно происходит огромный всплеск трафика.
Отладка тесно связана с производительностью. Помимо неприятного экрана ошибок для ваших пользователей, ошибка в коде может привести к блокировкам выполнения, задержкам в вашем коде, где их не должно быть, повторным и ненужным запросам в вашу базу данных и многим другим.
Итак, как можно измерить производительность или найти ошибки? Существует множество инструментов для профилирования PHP-приложений (так называется поиск ошибок и измерение производительности различных аспектов вашего приложения). Двумя лучшими из них являются Z-Ray и Blackfire (мы не будем рассказывать о них в этой книге, поскольку они выходят за рамки ее возможностей).
Предупреждение: остерегайтесь микрооптимизации
Важно отметить, что распространенная ошибка новичка — микрооптимизация. Например, когда-то считалось, что использование одинарных кавычек со строками ( $var = 'Some String' ) быстрее, чем двойные кавычки ( $var = "Some String" ). Повышение производительности, которое может принести такая оптимизация, является небрежным и почти всегда незначительным; вместо этого улучшение сложного SQL-запроса или кэширование удаленного HTTP-вызова всегда будет на порядок больше. В случае сомнений используйте эталонные тесты и реальные данные (например, данные Z-Ray или Blackfire), а не свои интуиции.
В этой главе мы рассмотрели среду приложения, охватывающую различные экосистемы, присутствующие вокруг вашего приложения на данном этапе его жизненного цикла. Мы поговорили о виртуальных хостах и настройке вашего компьютера для перенаправления URL-адресов веб-сайтов на вашу собственную установку PHP, а не на поиск результатов в Интернете, и мы обсудили важнейшее соотношение между разработкой и производством.
Если все это кажется слишком сложным, не отчаивайтесь. Это только потому, что мы до сих пор занимались почти исключительно теорией — теорией, которая необходима для смелого перехода в практическую сферу. В следующей главе мы запачкаем руки виртуальными машинами.
В юниверсе приложений тестирование отдельных компонентов называется модульным тестированием — тестированием каждого отдельного набора кода, чтобы вы знали, что он работает.
Например, часть вашего приложения может иметь возможность удалять локальные символы из каждого имени и превращать их в удобные для США буквы. Моя фамилия «Škvorc» будет, таким образом, превращена в «Skvorc». Превращение Škvorc в Skvorc — это небольшой набор кода или единица . Этот блок тестируемый ; то есть для любого заданного ввода «Škvorc» я ожидаю вывод «Skvorc». Затем я могу написать модульный тест , который представляет собой файл, который определяет ввод и желаемый вывод, и когда я его запускаю, он проверяет, не этот функционал все еще работает. Если спустя два месяца я что-то изменю в своем приложении, я могу легко запустить этот тест (который все еще там) и проверить, что это преобразование все еще работает. Этот вид рабочего процесса гарантирует, что вы сможете обновить свое приложение позже, не боясь сломать что-то, что вы создали ранее и о чем забыли. В нашей аналогии со смартфоном в начале главы одним тестируемым устройством может быть сенсорный экран или батарея.