Архив

Архив раздела ‘PHP’

pushBridge.IO — Единый API на РНР для всех облачных push-сервисов

Приветствую всех читателей. Сейчас в веб-разработках столько трендов, что не уследишь. Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта. Простейший способ - поставить один из широко доступных открытых comet-серверов, например, Dklab_Realplexor, Socket.IO или Faye - что кому по душе или в зависимости от стека технологий. Правда это путь достаточно сложных проектов, где команда может себе позволить такое решение.

Для многих проектов попроще (хотя это всегда вопрос конкретики приложения) логично будет использовать сторонние решения. А проще - арендовать как услугу функционал comet-сервера. Сегодня недостатка в таких сервисах нет, так что нам есть что обозревать.

И так, сначала давайте кратко ознакомимся с существующими push-сервисами, которые позволят нам без создания и поддержки своей серверной инфраструктуры поддерживать реал-тайм общение между клиентами проекта.

Таких сервисов всего 6: Pusher, Pubnub, Partcl, BeaconPush, X-Stream.ly и ioBridge (с некоторыми особенностями). Под катом - кратки обзор всех сервисов, особенностей РНР-библиотек для них и описание библиотеки pushBridge.IO для унификации работы со всеми облачными пуш-сервисами.

Читать далее...

7 трендов веб-разработки 2011: Инструменты прогрессивных девелоперов. Статья для журнала Хакер.

27 ноября 2011 Comments off

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Тренд 1. noSQL

К современным сервисам и в том числе стартапам, которые только набирают аудиторию, предъявляются колоссальные требования по части отказоустойчивости. Они должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных SQL баз данных и переход там, где это возможно, к технологии noSQL. Это было сложно представить еще несколько лет назад, когда был только один memcache, теперь же настолько очевидно, что многие не перестают удивляться: "Как это мы не дошли до этого ранее?" Ведь для большинства веб-приложений вовсе не нужны все эти множества типов данных и средств их выборки. Иногда ты просто хочешь сохранить данные и иметь к ним доступ с минимальной задержкой и высокой надежностью. SQL-запросы, как ни крути, даже при оптимизации, выполняются относительно медленно (если взять профайлинг работы MySQL, то даже самый простой запрос на выборку почти 45% времени занимается парсингом SQL-а). При этом зачастую для хранения данных вполне достаточно самой простой структуры - пара "ключ-значение". Это фундамент любой noSQL технологии: memcached, Membase, Riak или CouchDB – все работают именно так. Интерфейс доступа к такой базе также максимально прост – обычно это простейшие команды типа get (получить данные по ключу), set (записать данные с ключом), delete (удаляет ключ и его данные), update (обновляет уже существующие данные). Решения noSQL оказались не только очень быстрыми, но еще и легко масштабируемы. На низком уровне такие базы строятся на базе хеш-таблиц и их разновидности – распределенной хеш-таблицы (DHT). Свойства DHT такие, что можно присоединять новые сервера постоянно, и такая база будет расти и расти. Столько - сколько надо. При этом в самих приложениях ничего менять не надо, все делается автоматически! Если очень нужна сохранность данных, можно пожертвовать несколькими серверами, тогда они будут хранить дубликаты данных. Например, Riak-у можно указать, сколько минимум серверов должно сразу сохранить данные, прежде, чем сервер ответит тебе, что все ок. Это очень важно, потому что если приложение не может одинаково хорошо работать и на одном, и на тысяче серверов, то оно не масштабируемо. А значит при неожиданно высокой нагрузке, оно ляжет и уже не сможет восстановить работу, даже при покупке новых серверов. В то время как обычные СУБД просто рвутся на части и подпираются костылями, чтобы работать хоть на паре десятков серверов сразу, то практически любое noSQL-решение может спокойно масштабироваться хоть на тысячу серверов. Значение – это стоки, числа или обычное сериализированные данные, например, в формате JSON или более продвинутой структуре вроде messagePak, Google ProtoBuf или Apache Thrift. MongoDB пошла еще дальше – придумав подмену для удобного JSON в виде двоичного формата. Другая разработка - Redis - перевернула понятие key-value хранилищ, добавив к ним простые, но оказавшиеся эффективными и востребованными списки, хэши, сортированные массивы и даже такую чертовски удобную штуку как publish/subscribe. И все это на скоростях более 100 тысяч операций в секунду, над гигабайтами данных и миллионами ключей на обычном железе. Правда, SQL тоже не сдается. Последние версии MySQL достаточно быстрые, а умные головы, поняв, что noSQL не потеснить, решили возглавить движение отказников, включив в версии 5.6.2 memcache-плагин для доступа к данным через простой протокол, а для особых случаев есть HandlerSocket Plugin, который может работать с таблицами гораздо эффективнее, используя легковесный сетевой слой и простой протокол без всякого SQL-а.

Тренд 2. Serverside JavaScript

Веб-разработчики давно поняли всю мощь JavaScript. Во многом благодаря этому языку стало возможным реализовать в веб-окружении самые разные приложения, которые ранее существовали только в виде десктопных программ. В то время как для реализации бэкэнда используется самый разный набор технологий, в создании фронтенда (т.е. внешнего вида приложения) все равно так или иначе всегда используется JavaScript. Пытливые умы почесали голову и подумали: а не будет ли легче использовать JS более универсально: и на клиенте, и на сервере? Он гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. Но, что важнее всего — это асинхронность и неблокируемость. Сравни это с обычным PHP-скриптом, которые непременно блокируется: например, в ожидании выборки из базы данных или ответа от другого сервера. Код выполняется последовательно: пока не будет получен ответ, сценарий будет тупо простаивать. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Чтобы работать с событиями и обработчиками событий было проще, были разработаны специальные платформы. Одним из самых продвинутых фреймворком для серверного JS стал Node.JS (подробнее о нем ты можешь прочитать в #139 номере ][). В основе его лежит V8, движок JavaScript, который используется в браузере Google Chrome и благодаря которому он работает невероятно быстро. Конкуренцию ему составляет другое решение, RingoJS. Этот движок работает поверх Java-машины, а многие из стандартных библиотек вполне совместимы с Node.JS. Java многим кажется более интересным решением, так как для нее написано великое множество библиотек и даже серверов, а работа с памятью, множеством процессоров и потоков гораздо более оптимизированная, чем у новичка Node. А вот кто лучше, пока не известно.

Тренд 3. Развертываемость и расширяемость

Облака — главный тренд не только в разработке, но и вообще всей отрасли ИТ в принципе. Cloud-технологии во многом сильно упростили жизнь при создании новых сервисов. Взять хотя бы всем известный Dropbox, разработки которого не стали изобретать велосипед с изобретением технологии для хранения данных, а использовали облачный сервис Amazon S3. Да и понятие «облако» сильно преобразовалось. Раньше можно было купить кучу серверов, объединить их в сеть, поставить поверх Xen и говорить: «вот это и есть cloud». Так и сейчас делает Amazon с их сервисом EC2. Но для многих вообще не нужны никакие серверы, им важна готовая инфраструктура для развертывания разработки из «коробки». Хостинг платформы — вот что модно сегодня. Что это такое? Добрые дяди за тебя уже поставили и настроили все, что может пригодиться для твоего супер-пупер приложения. Взяли несколько языков, типа PHP, Ruby вместе с Rails, обязательный Python и выскочку Node.JS, прицепили традиционную базу данных MySQL, а чтобы эстеты замолчали, добавили немного перчинки в виде NoSQL – MongoDB, Redis или Riak. Поверх поставили memcached, а вместо анахронизма в виде FTP теперь предлагают юзать Git. Управлять этим надо через красивый веб-интерфейс, где просто говоришь им – хочу 5 серверов memcached, два РНР и еще базу данных заверните. Тебе тут же выдают ключи доступа и пароли – и все, git clone && git push и твое приложение уже вольготно себя чувствует на серверах, а ты даже не подозреваешь на чем и где оно крутиться. Это называется Platform as a Service (PaaS) и сегодня самый модный тренд в сфере хостинга и разработки – посмотри на PHPFog, Jelastic (между прочим, продукт наших отечественных разработчиков!), CloudControl, Aptana Cloud, Heroku или Cloudbees. И конечно, все предлагают API, чтобы твоя программа могла сама себе выделять ресурсы, например, добавляя еще одну базу данных или новый инстанс приложения, если у тебя пользователей прибавилось. Просто вызываешь специальный URL или даже работаешь через библиотеку для любимого языка – а хостинг повинуется сам, выделяя все, что запросишь. А создание таких библиотек, которые бы прозрачно работали с разными интерфейсами разных провайдеров, само по себе тренд в разработке.

Тренд 4. Социализация разработчиков

Обрати внимание, что такие раньше традиционные друзья разработчика как FTP и SVN стремительно теряют популярность. Теперь многие делают это через систему контроля версий Git. Поправил файлик, добавил немного гениального кода и хочешь его выкатить на сервер? Сначала закоммить его в git-репозиторий, напиши комментарий, что там хорошего ты накодил, а потом только разверни на сервере, снова-таки при помощи git-а. И ведь реально удобно – и разработка, и деплой идет при помощи одной системы. Все в командной строке. Посмотрев на популярность сервиса Github (github.com), многие провайдеры, чтобы привлечь разработчиков и облегчить им жизнь стали разворачивать у себя git-репозитории как единственную возможность что-то залить на сервер. Ну, теперь хоть не будет криков, что снова Вася не то залил на сервер и все перестало работать. Да и чего таить, сам подход к разработке кода немного поменялся. Если раньше все твои друзья сидели уютно и кодили что-то там втихаря, теперь большинство перебралось на сервисы вроде GitHub-а и занимаются «социальным кодингом». С приходом Git-а стало намного проще следить за прогрессом твоих любимых библиотек. Если что-то надо срочно поправить в чужом коде, так без проблем: кнопка «форк» теперь так же близко, как и кнопка создание тикета. А чтобы автор заморского чуда принял твои правки, не нужно долго на ломаном английском объяснять, что ты сделал конфетку из его непонятного кода. Просто отправь ему пулл-реквест и если все хорошо, твой код быстро попадает в основную ветку. Github стал настоящим прорывом, потому что собрав в очень удобном веб-интерфейсе все, что надо матерому гику-программисту. И что еще важно он добавил острое блюдо социальщины. Теперь не нужны все эти твиттеры и фейсбуки: для многих разработчиков (прежде всего OpenSource) Github стал местом жизни, общения и тут же, не отходя от кассы, кодинга. А все потому, что выстраивая все же среду для совместной разработки кода, Github не прячет людей за всеми этими коммитами и чекаутами, а активно их выталкивает на поверхность. Согласись, очень приятно видеть свою аватарку или фотку возле каждого принятого патча в важный проект.
Да и работать с кодом можно прямо в браузере – например, через систему Cloud9 (c9.io). Это такая среда для кодинга прямо в браузере, которая изящно дополняет GitHub и позволяет реально вести разработку с любого места, где есть интернет. Теперь не важно, какой у тебя комп, хоть даже нетбук с GoogleOS, на который ничего не поставить, а программировать все равно можно. Одним кликом подключаешь к ней свой GitHub-аккаунт - и продолжаешь работу.

Тренд 5. Даешь сокеты!

Любой веб-приложение теперь должно работать в браузере. Без задержек и тормозов, иначе все пользователи сразу разбегутся. Сейчас есть немало решений, позволяющих реализовать реалтайм для веба, но самой прогрессивной технологией являются веб-сокеты (WebSockets).  Ага, все уже устали, что в браузере у тебя есть только HTTP и ничего больше, да и тот урезанный и затиснутый в ограничения безопасности. Конечно, вражеский Flash заботливо подсуетился и предложил альтернативу, но кому он теперь нужен. В этом году все хотят полного реалтайма, чтобы ты только успел подумать, а на сервере уже все отправилось и обратно вернулось. Этого не может обеспечить привычный HTTP, так как ему нужно на каждый чих создавать новое соединение, а это снова и снова пару килобайт данных гонять туда-сюда и ждать в среднем полсекунды. Создатели обычных программ потирают руки - у них-то есть полный доступ к системе, ничем не ограниченый и они используют сеть сразу напрямую на низком уровне. Не долго они радовались, в HTML 5 появился раздел WebSockets, который почти те же сокеты только сразу у тебя в браузере, на любой веб-странице. Один раз соединившись с сервером, ты можешь держать открытым канал передачи (в обе стороны между прочим) как угодно долго и пересылать по нему любые данные. Без задержек, сразу, мгновенно, как позволяет твой интернет. Но вот в чем проблема – разработчики кинулись делать всякие штуки, вешать на них ярлык реалтайма (то есть – очень быстрые и без перезагрузки страницы), а сервера то для них нет. Любимый Nginx, хоть и добравшийся уже до версии 1.0.3, что в мире опенсорс и постоянной беты просто событие, увы, никак не умеет работать с сокетами. И дело не софте – все существующие веб-сервера просто не умеют рулить в ситуации, когда клиенты не просто пришли, сделали запрос и отвалились до следующего сеанса связи (пусть даже раз в секунду, по меркам сервера это очень много времени), а постоянно висят на связи. Даже когда данных нет, а все равно, сокет открой да держи, а вдруг в следующую секунду или полчаса что-то произойдет, о чем пользователь хочет узнать мгновенно! Вот тут то и пригодился новооткрытый JavaScript на стороне сервера – на Node.JS такие вещи делаются просто несколькими строками, а соединений пусть и постоянно открытых, он может держать столько, сколько позволит тебе ресурсы
сервера (размер памяти и настройки ядра ОС и сетевого стека).

Тренд 6. Использование функциональных языков

Кроме обычных для всех языков, пусть и сдобренных примочками для поддержи новомодных технологий, сейчас трендово пробовать новые языки и приемы программирования, использующие асинхронность. Для Python-а придумали хорошие ребята Twisted и Tornado, но это уже отстой, для Ruby есть EventMashine, но оно никому не нужно, для РНР сделали phpDeamon с честным fastcgi, Java разродилась своим поделием – Netty, на котором можно сделать все, что угодно. Теперь все это забудь, выбрось – сегодня и завтра будут рулить функциональные языки и платформы. При каждом удобном случае раздвигай пальцы веером и говори, что Erlang рулит и обставляет все, что есть в мире, держа сотни тысяч потоков, гибко и главное, сам расползается, занимая все доступные ядра и даже сервера, а уж видео и прочие реалтайм штуки, так раздает так шустро, как только может железка. Но вот в коде сам черт ногу сломает, а если твой программер уйдет в запой, проект станет, так как людей, кроме пиара, могущих че-то написать и поддерживать на Erlang-е очень мало. Любишь Java? У меня для тебя хорошая новость – Scala, вот что реально круто и нужно всем в мире! Мощный, смешанный объектно-ориентированный и функциональный язык со статической типизацией и встроенной параллельностью поверх JVM, а для особо нуждающихся – к нему добавлен фреймворк Akka. Слышал булшит вроде многопоточность, устойчивость к сбоям, распределенная архитектура, реал-тайм? Иногда это правда - Akka, основанная на параллелизации вычислений в виде акторов  (небольшие блоки кода, которые самостоятельно планируются для исполнения по разным ядрам, процессам и даже узлам кластера, ближайший аналог – grenlets из Python). Шутка ли, твиттер наконец слез с Ruby-иглы и переписал большую часть критичного софта на Scala!

Топ модностей
Думаешь, много всего написано? Согласен, давай если кратко, я тебе в двух словах расскажу, что модного и современного уже есть, и что будет пользоваться спросом еще думаю пару лет, пока не изобретут чего прикольнее.
И так, поехали!

  • JavaScript на стороне сервере (Node.JS, RingoJS)
  • Автоматизированные клауд-платформы (AppEngine, PHPFog, Azure, RackCloud)
  • Разработка и развертывание кода через Git и Github
  • Долой Eclipse, теперь IDE прямо в браузере (Cloud9)
  • Real-time везде, где можно (websockets)
  • Общий код для сервера и браузера (nowJS, Aptana Jaxer)
  • Функциональные языки (Erlang, Scala/Akka, Haskell)
  • Мобильные фреймворки для веб-разработки (jQuery Mobile, Dojo.mobile, Sencha Touch, Cappuccino) и приложений (PhoneGap, Appcelerator Titanium)

Тренд 7. Мобилизация - главный тренд года

 

Портативные устройства реально уже захватили мир, поделив его между яблочниками и роботами. А вот дизайнерам и разработчикам приходиться поддерживать оба лагеря. Хорошо, что им на помощь пришли программисты. Сегодня почти все топовые JS-фреймворки (jQuery, ExtJS, Dojo) имеют мобильные версии, часто совместимые по API с обычными, что позволяет просто заменой файла подогнать сайт под требования мобилок. Самым ожидаемым является jQuery Mobile (сейчас он в версии alpha 4.1), который заявлен по все платформы, включая экзотику для нас типа Blackberry и вряд ли существующий Windows Phone, webOS, bada и другие. Будучи расширением, а по большому счету, очень крутым плагином для jQuery, он стандартизирует API на различных устройства их и браузерах (а в мобильном мире браузеры это вообще кошмар, так что браузерные войны на десктопах это только цветочки), а также дает в руки нерадивым разработчикам строгий гайдлайн на интерфейс. Потому большинство веб-приложений будут выглядеть стандартно так, чтобы юзер не искал на своем маленьком экране минуту кнопку назад или отмена. Правда, есть еще проблемы с производительностью – если некоторые жалуются на тормознутость в обычных браузерах, то что говорить про маломощные мобилки. И конечно все эти библиотеки поддерживают модные нынче тач-экраны, так что смело везде тыкай – оно работает!

Облачные интерфейсы на заметку

Если ты хочешь использовать возможности облачных сервисов в своих проектах, советую тебе воспользоваться некоторыми полезными вспомогательными инструментами.
Apache Nuvem (incubator.apache.org/nuvem) – попытка создать кроссплатформенный открытый интерфейс для работы с разными cloud-платформами, включая Amazon EC2, Microsoft Azure и Google AppEngine. В идеале, твоя программа сможет использовать ресурсы сразу нескольких облаков.
Deltacloud (incubator.apache.org/deltacloud) – решение на Ruby, умеющее работать со всеми известными и не очень cloud-провайдерами. Предоставляет единый REST-интерфейс, который скрывает нюансы разных платформ.
libcloud (libcloud.apache.org) – библиотека для программ на Java или Python, которая работает чуть ли не со всеми в мире известными облачными платформами и унифицирует основные операции по созданию и управлению виртуальными машинами.
Simplecloud (simplecloudapi.org) – если ты все еще программируешь на РНР, то для тебя есть отличный компонент Zend_Cloud, который добавляет базовую поддержку хранилищ данных, очередей сообщений и другие фишки разных cloud-платформ просто в твое веб-приложение на Zend Framework или даже на чистом РНР.

Очереди сообщений — современный тренд в области веб-приложений.

24 августа 2010 7 комментариев

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

The Art of Message Queues - для тех, кто хочет вообще понять, о чем речь, когда говорят про сообщения, очереди и брокеры. Хорошее введение в тему.
[slideshare id=4182369&doc=art-of-message-queues-100520171613-phpapp02]

Читать далее...

Я убью тебя, Google Reader! Высоконагруженный сервис своими руками. Статья для журнала Хакер.

18 июля 2010 Comments off

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Шеф, что делать будем?

Получение новостей через фиды или RSS-ленты сегодня самый быстрый и простой способ следить за жизнью любимых сайтов или блогов. Твиттер, конечно, крут, но рсс-кам ещё рано умирать. Сегодня у тебя большой выбор - RSS можно читать кучей способов, начинаю  от почтового клиента (да, в Mozilla Thunderburd 3 встроен клиент) и браузера, заканчивая специальными программами и онлайн сервисами. Самым крутым из таких будет, конечно, Google Reader. Пользоваться им вроде бы легко - вводишь адрес сайта и отныне просто заходи и читай новости, никакой кнопки Refresh жать не надо, гугл сам позаботится о том, чтобы найти новые новости и показать их тебе. Но при этом у него есть много врождённых проблем, например, не очень интуитивный интерфейс, а также часто сильные задержки в получении новых сообщений. Особенно это касается лент из Твиттера. Ага, популярнейший сервис также вовсю использует RSS, транслируя туда твои сообщения. Но ведь ты уже в курсе, как быстро там все изменяется - написал о новом хаке винды, а через минуту уже весь интернет с криками "ура!" бросается ломать империю Билли. Но читатели через Google живут в параллельном мире и просто тормозят - там лента из твиттера обновляется часто с задержками в минуты и часы, непорядок!

Давай напишем для себя любимого (ну и друзей, куда ж без них) простую онлайновую читалку RSS-новостей. Фичами будет возможность автоматически находить фиды с любого адреса (если они там есть, конечно) и  полное игнорирование нюансов форматов ( мы сможем работать с любым фидом). Кроме этого, научимся высшему пилотажу РНР-программирования - созданию распределённых систем. Когда у тебя две-три ленты, с ними справиться даже твой нетбук, но когда друзья поймут, что гугл теперь отстой, и начнут добавлять свои ленты, станет плохо. А мы сделаем так, что читалка будет работать с любым количеством лент, просто успевай доставлять сервера! Помнишь, мы не раз рассказывали тебе про облачный компьютинг, Amazon EC2 и прочие заморские технологии? Вот с их помощью это сделать очень легко - нажав кнопочку и у тебя уже два сервера вместо одного. Используя РНР и немного магии, ты сможешь заставить работать на наше благо столько серверов, сколько достанешь. Читать далее...

Горячая замена кода (code hot swapping) в РНР

24 января 2010 Comments off

Приветствую читателей. Погода за окном просто требует чего-то горяченького, поэтому воспользовавшись возможностью что-то по исследовать в свободное время, я решил подумать - а можно ли не останавливая скрипт, подменить функцию, которая выполняется? С таким требованием я встретился чуть ранее, при разработке нашего стартапа. У нас был один из внутренних серверов, который заведовал всеми действиями между пользователями в реальном времени. Это обычный РНР-демон-роутер, который обрабатывал запросы от клиентских запросов (внутри сервера), но была одна сложность - в случае, когда я что-либо изменял в коде сервера или обработчиков отдельных команд, демон приходилось перезагружать, что означало отключение текущих клиентов и потеря информации о состоянии сервера (этот вопрос решаемый, конечно). То же самое было в случае ошибки в коде - все подключенные пользователи сразу это чувствовали на себе (хорошо, что все они такие же разработчики, а не реальные клиенты). Можно ли этого избежать?

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

NoSQL: А ты уже отказался от SQL? Статья в журнал Хакер

16 января 2010 Comments off

128

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Первым кинь камень в того, кто скажет, что делать новый суперпроект надо с SQL базой данных.

Скажи честно, тебе ведь интересно, как устроены внутри все эти суперсайты, на которых висишь сутками ты и еще сотни миллионов человек сразу? Ну, это я говорю о Facebook и нашем вКонтакте, Google, Amazon, ebay, Twitter и десятки других сайтов, которые самые посещаемые в мире. Если ты делал уже сайты, то знаешь, что большинство веб-сайтов просто странички на PHP вместе с базой данных мускула (MySQL). База данных нужна для всего – там и новости и товары из магазина, статьи и  комментарии, и даже самое вкусное – логины и пароли пользователей, которые взламываются за пару секунд. Ты же даже не мыслишь о том, что сделать сайт без применения базы данных вообще – я говорю о реальном сайте типа форума или социальной сети, ну, на худой конец, магазин хакерских программ?

База данных – вширь и ввысь

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

Читать далее...

Получить RSS-ленты из страницы? Так точно!

2 января 2010 Comments off

Billboard_Feed_256x256Приветствую своих читателей! С Новым Годом! Первой темой, который мы откроем этот год жизни блога, будет следующая задача. Дано - система, схожая с Google Readers, которая принимает от пользователя некоторый адрес и должна обеспечить просмотр (а позже, и подписку) доступных там RSS-фидов. Задача осложняется тем, что от пользователя нельзя требовать ввода именно полного адреса ленты, да и даже просто адреса сайта или произвольной страницы - он может быть введен в совершенно разных вариантах, полностью или частично и т.п. Самих лент на странице также может быть более одно, часто нескольких форматов сразу (а то и не быть вовсе). Поэтому нам надо выбрать из всех доступных лент последние сообщения и отобразить пользователю, чтобы именно он выбрал в конечном итоге одну ленту, которая его интересует. Открою секрет - да, это только начало и в последующих статьях мы вместе постоим несколько уменьшенную версию системы агрегации и чтениях новостей. Но сегодня попробуем решить первую задачу, без которой наша "читалка" просто не сможет работать, какие бы дальше технологии не применялись.

Основой будет мой любимый инструмент  - Zend Framework (используем последнюю, trunk версию). Если вы знакомы с его возможностями, что сходу предложите компонент Zend_Feed, который имеет встроенные возможности по извлечению из страницы лент. Однако не спешите, на практике задача не так и проста. Поэтому будем решать ее постепенно.

Читать далее...

SignalsyMQ — простая и быстрая очередь сообщений на PHP+Redis (и немножко Zend Framework)

12 декабря 2009 3 комментария

1250198491_signalПриветствую своих читателей. Знаю, что давно не писал, обычно активность проявлял только в твиттере - как оказалось, это очень удобно для постоянных постингов, когда на основной блог не хватает времени. Кстати, кроме официального твиттера блога (@abrdev) я открыл еще один  - @phpatcloud, в котором буду собирать ссылки на все материалы по теме РНР и Cloud Computing. Эта тема достаточно актуальная, в том числе и для меня, так как на основной работе мы сейчас делаем серьезную систему, которая как раз и базируется на облачном хостинге (от Amazon) и платформе РНР (мой внутренний продукт, Signalsy и Zend Framework). Кому интересно - подписывайтесь, комментируйте и ретвитьте, буду благодарен.

А теперь хотел бы рассказать, собственно, о причинах некоторых задержек в пополнении блога статьями. Причина простая - как уже анонсировал, я веду разработку собственного фреймворка, основанного в противовес главенствующей сейчас модели MVC, на базе сигнальной архитектуры (signal/slot). Сейчас этот фреймворк, уже третья версия, проходит боевую обкатку в нашем стартапе, и за это время я понял, что одного продукта в линейке мало - реальные задачи и виденье будущего показывает, что необходим разный функционал, но объединенный одной темой - обработка и доставка информации множеству клиентов в реальном времени. Поэтому я расширяю свою систему таким образом, чтобы в результате получит некоторую платформу для построения быстрых и масштабированных систем для веб-приложений. Сегодня я расскажу о первом компоненте, который является основной нашей платформы - SignalsyMQ - очередь сообщений на базе PHP/Redis/Zend Framework.

Читать далее...

Работаем с Google Protocol Buffer в РНР

pb4php_logoПриветствуем наших читателей. На этот раз обойдусь без длительного вступления, а сразу перейду к делу, то есть, к теме сегодняшней статьи. В проекте, который я сейчас разрабатываю, возникла необходимость, а точнее, я понял, что архитектуру надо расширять, и решил заменить используемый сейчас протокол для обмена данными между частями приложения. Сейчас, на уровне внутренних сервисов, обмен происходит через передачу сериализированных массивов РНР поверх TCP сокетов. Так как по обе стороны находятся приложения на РНР, проблем не возникает, формат пакета данных также стандартный, поэтому особых сложностей нет. Разве что часто меня не удовлетворяет скорость обработки, а также то, что мы сильно завязаны на язык и платформу. Если придется стыковать с другой системой или же переписать что-либо, будут сложности - ведь сериализированный формат поймет лишь родной язык, а писать парсер мне не очень хочется. Первоначальный выбор был более чем оправданным - скорость разработки и отладки были приоритетными, сейчас есть немного времени и желания посмотреть на архитектуру с высока и другим взглядом. Читать далее...

Анонс: Signalsy Platform Framework (open source)… coming soon!

14 августа 2009 6 комментариев

1250198491_signalПриветствую читателей моего блога. Позволю себе сделать небольшой анонс. В последнее время я работаю над достаточно большим проектом, игровой он-лайн платформой для разработчиков браузерных игр AGPsource Game Platform (кстати, проект открытый, присоединяйтесь, уже вышла версия 3.1). Разработка достаточно интересная и нетривиальная в архитектурном плане. Попробовав ее в реальных условиях, в том числе и под достаточной нагрузкой (например, мы сделали на нем одно приложение для сети вКонтакте, пока там 20 тыс. пользователей, но их количество увеличивается постоянно), мы поняли, что архитектура достаточно хорошая. Но движок, конечно, проект большой и сложный, попробовав применить его в других проектах, не очень игровых, стало ясно, что требуется все то же, но более легкое, простое и быстрое. Да и хотелось внести кое-какие изменения в основу проекта, переделать узкие места.

Так родился наш второй проект - Signalsy Platform Framework. Вкратце - это небольшая и гибкая платформа для разработки и поддержки веб-проектов, основанная на сигнальной (Signal/Slot, но, конечно, модифицированной, о реализации в библиотеке ezComponents мы уже писали) архитектуре. Похоже, мы первые в мире, кто сделал подобное для веб-а! Внутри, кроме нашего небольшого набора базовых компонент, лежит Zend Framework, так что разрабатывать можно с учетом всех его возможностей. По сути, это замена традиционной модели MVC (как ее понимают в ZF), но внутри, в компонентах и логике конкретного приложения, конечно, можно придерживаться любых паттернов и приемов построения архитектуры. Signalsy лишь заменяет слой обработки URL  и добавляет возможности Signal/Slot-архитектуры в ваше веб-приложение.

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

Developers.org.ua