книги хакеры / журнал хакер / 167_Optimized

Фреймворквдействии

честве URL http://oursite.com/shop/buy, то мы должны обратиться к контроллеру с именем shop и вызвать его метод buy. Если такой контроллер отсутствует, то нужно сгенерировать ошибку 404.

Для экономии места я не стал приводить код ее отображения, его ты сможешь увидеть в исходниках, прилагаемых к статье.

Представим, что с контроллером мы определились. Теперь самое время задуматься о модели. Ты же помнишь, контроллеру для осуществления своей работы может потребоваться модель,

араз так, то нужно ее подключить. Чтобы знать, какую модель требуется инклудить (их может быть несколько), условимся заранее, что имя файла с моделью должно соответствовать шаблону: Model_ ИмяКонтроллера. Таким образом, каждый контроллер нашего фреймворка может иметь одну модель, что более чем достаточно для реального приложения. Файл с моделью подключается точно таким же образом, как и файл с контроллером.

После успешного подключения необходимых файлов нам требуется сделать еще одну проверку. Файл с контроллером мы нашли,

агде гарантии, что у него есть соответствующий метод? Если его нет, то нужно прерывать дальнейшие действия и генерировать страницу с кодом ошибки 404. Для определения наличия метода в PHP есть функция method_exists. Первым параметром передается класс, а вторым — имя метода, наличие которого требуется проверить. Если функция выполняется успешно, то можно вызывать нужный метод контроллера. Для этого применяем функцию call_user_func().

Все, на этом с разбором роутинга покончено, и можно переходить к рассмотрению базовых классов, описывающих заготовки для моделей, контроллеров и представлений. Их код приведен в листингах 2, 3 и 4.

Листинг 2. Код класса Controller

<?php

class Controller { public $model;

public $view;

function __contruct()

{

$this -> view = new View();

}

function action_index()

{ ... }

}

Листинг 3. Код класса Model

<?php

ТрюгвеРеенскауг(слева)

class Model

{

public function get() { ... }

}

<?php

class View

{

function generate($content, $template, $data = null)

{

include 'application/views/'.template;

}

}

Как видишь, код листингов практически пуст и содержит только базовое определение классов и методов. Исключение составляет разве что класс View. В нем определен метод generate(), в котором происходит подключение файла с шаблоном представления. Весь остальной код будет описан в пользовательских реализациях контроллеров, моделей и представлений.

ТЕСТИРУЕМ ФРЕЙМВОРК

Все! Наш простейший фреймворк можно считать готовым. Да, получилось максимально просто, но он работает, и в этом

ты убедишься через несколько минут. Для тестирования новоиспеченного продукта я подготовил небольшой пример: взял одну из бесплатных тем оформления и преобразовал ее к виду представления. Далее я определил один контроллер и в методе index описал вызов представления:

$this -> view -> generate('myview', 'template.php');

Результат работы приложения ты можешь увидеть на соответствующих рисунках, а полный код демонстрационного проекта ждет тебя на диске к статье.

ВМЕСТО ЗАКЛЮЧЕНИЯ

Создать свой фреймворк — не такая уж и сложная задача. Приведенный в этой статье пример — лишнее тому подтверждение. Да, описанный вариант фреймворка достаточно прост и малофункционален. Однако тебе ничто не мешает самостоятельно доработать функционал и сделать из него полноценный продукт, который не стыдно будет представить на паблик. Все в твоих руках! Мне же остается только пожелать удачи и попрощаться. Как обычно, свои вопросы можешь присылать мне на почту. z

УРОК# 1 2 3 4 5 6

Каждыйпрограммистхочетстатьлучшим, получатьвс болееинтересныеисложные задачи решатьихвсеболееэффективными способами.Вмиреинтернет-разработок ктаким задачамможноотнестите, скоторымисталкиваютсяразработчики систем.

УЧЕБНИК ПОВЫСОКИМ НАГРУЗКАМ

Большаячастьинформации, опубликованнаяпотемевысоких нагрузоквинтернете,представляет соб всеголишьописания техническиххарактеристиккрупных систем.Мыжепопробуемизложить принципы,покоторымстроятся архитектурысамыхпередовых исамыхпосещаемыхинтернет- проектовнашеговремени.

Впоследнийурокмырешилидобавитьвсе,чтонеуспелирассмотретьвпредыдущих.Такжездесьмысистематизируем основныеизученныепаттерныпроектирования.Крометого, осталсяпоследнийпунктнашейобязательнойпрограммы— этоэксплуатация.Малоразработатьсистему,нужноещеиподдерживать,аэтоцелоеискусство.

Какуженеоднократноговорилось,первоеиглавноеотличие высоконагруженногопроектазаключаетсявсложностииналичиибольшогочиславзаимосвязанныхкомпонентов.Ключевое слово,накотороенужносделатьударение,—большого.

ПредставьсебепоисковыйкластерЯндексаилихранение фотографий«ВКонтакте»—тамиспользуютсятысячимашин. Серверныйдиск,приегоактивномиспользовании,всреднем выходитизстрояразвдвагода.Этоозначает,чтоизтрехтысяч серверовпрямосегодняполетятдискиучетырехмашин.Вывод— вбольшойкрупнойсистемевсегдачто-тонеработает,какой-то изсервероввышелизстроя,какой-тоиздисковсбоит.Иэто— нормальноесостояниесистемы.Тыдолженбытькнемуготов, имывэтойстатьерасскажемкак.

НАДЕЖНОСТЬ

Надежностьвеб-системы(какилюбойдругойсистемы)за- ключаетсявспособностисохранятьвпределахустановленной нормызначениявсехпараметров,характеризующихспособность выполнятьтребуемыефункции.Внашемслучае—обрабатывать запросыпользователей.

Взависимостиотситуациипараметрыустановленнойнормы можноопределятьпо-разному.Конечно,хорошо,еслисайтотве- титназапросзаоднудесятуюсекунды,но,еслионответитназапросзадвесекунды,ничегокритичногонепроизойдет.Сэтим связанодинизспособовборьбысрезковозросшейнагрузкой, которыйназываетсядеградацияфункциональности.Влюбом проектеестьфункции,почтинезаметныепользователю,нотребующиедлясвоейреализациисерьезныхсерверныхресурсов. Например,скоростьпоявлениянасайтеопубликованнойредакторомновости.Еслиэтоненовостноеиздание,топострадает липользовательоттого,чтоновостьстанетдоступнатолькочерездесятьминутпослепубликации?Нет,непострадает,ондаже этогонезаметит.Норазработчикамэтопозволитвнедритькеши-

рованиеилипрегенерацию.

Возьмемвкачествепримераонлайн-конструкторсайтов Setup.ru,разработанныйвнашейкомпании.Созданныйпользователемсайтненачнетработать,покатотненажметкнопку «Опубликовать».Этозвучитпросто,нотакоеискусственное препятствиепозволилозначительноснизитьнагрузкунасистему,поддерживающую356тысячпользовательскихсайтоввсего нанесколькихсерверах.

Подробноодеградациифункциональностимырассказываливчетвертомуроке,асейчасвернемсякнадежности.Одно дело—допустимоеснижениескоростиработынашейсистемы, нокакизбегатьпроблемсоскоростьювовсехдругихслучаях? Какизбегатьзамедленийвнезависимостиоттого,какиедиски полетелиикуда?

ИЗБЫТОЧНОСТЬИДУБЛИРОВАНИЕ

Способровноодин:еслитыхочешьбытьготовымквыходу изстроянекоторыхэлементов—вводиизбыточностьэтихсамых элементов.Это,ксожалению,неизбежно.Еслихочешь,чтобы

фронтендвсегдабылнасвязи—ставьдва,еслихочешьнадеж- ностивработебазыданных—настраивайрепликацию.

автоматизированы.Еслитысталкиваешьсяскакой-топроблемой болеечемодинраз—автоматизируйее.Нобольшуючастьавто- матизируйаприори.

Синхронизациясерверадляхранениякартинокдолжнапро- изводитьсяскриптом.Изменениенастроек—скриптом,настрой- кановогосервера—темболее.Подробнееобэтомстоитпочитать популярнуюнынетемуDevOps,амыприведемнесколькоключевыхмыслейиздокладаАлександраТитоваиИгоряКурочкинапро организациюсистемногоадминистрированиявкомпанииSkype.

Естьоднапритча,котораяописываетэволюцию.Когдацарь пришелкмудрецуиспросилего:«КакустроенаЗемля?Почему онанепадает?»,мудрецответил:«Землястоитнальве».Тогда царьспросил:«Хорошо.Почемулевнепадает?»—«Левстоит наслоне».—«Почемуслоннепадает?»—«Слонстоитначерепа-

хе.Большенеспрашивайтеменя,потомучтодальшеидутодниче- репахи».Одинсервер—это,посутидела,оноиесть,основавсего.

Соднимсерверомвсепонятно.Онпростоадминистрируется однимспециалистом,которыйвладеетполнойинформациейосо- стоянииэтогосервера—всеумещаетсяунеговголове.Дальше идетследующийуровень—пятьсерверов.Побольшомусчету, подходытежесамые,ноуженачинаетсяобобщениеиавтоматизация.Появляютсяскрипты,решающиетуилиинуюзадачу системногоадминистрирования.Большедвадцатимашин— этовпервуюочередьбольшаясистема.Уженаэтомуровневоз- никаютпроблемыиз-заразницыконфигураций.Разныеверсии LIPCнаодномсервереработают,надругомсерверенеработают. РазныеверсииPHP,Ruby.Всеэтодостаточнознакомомногим.

Начинает требоваться большое количество документации. Каждое изменение ты должен прописать — ведь когда различного рода неочевидных изменений станет много, ты начнешь их забывать. На количестве машин больше двадцати стоимость поддержки сильно превышает стоимость внесения изменений. Ты перестаешь вносить изменения, ты постоянно исправляешь ошибки.

В этот момент начинает приходить понимание, что надо управлять не одной машиной, а какой-то абстрагированной штукой — кластером. Потребуется ввести автоматическую