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: Инструменты прогрессивных девелоперов. Статья для журнала Хакер.
Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант, без правок или ограничения на объем материала.
К современным сервисам и в том числе стартапам, которые только набирают аудиторию, предъявляются колоссальные требования по части отказоустойчивости. Они должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных 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-а.
Веб-разработчики давно поняли всю мощь JavaScript. Во многом благодаря этому языку стало возможным реализовать в веб-окружении самые разные приложения, которые ранее существовали только в виде десктопных программ. В то время как для реализации бэкэнда используется самый разный набор технологий, в создании фронтенда (т.е. внешнего вида приложения) все равно так или иначе всегда используется JavaScript. Пытливые умы почесали голову и подумали: а не будет ли легче использовать JS более универсально: и на клиенте, и на сервере? Он гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. Но, что важнее всего — это асинхронность и неблокируемость. Сравни это с обычным PHP-скриптом, которые непременно блокируется: например, в ожидании выборки из базы данных или ответа от другого сервера. Код выполняется последовательно: пока не будет получен ответ, сценарий будет тупо простаивать. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Чтобы работать с событиями и обработчиками событий было проще, были разработаны специальные платформы. Одним из самых продвинутых фреймворком для серверного JS стал Node.JS (подробнее о нем ты можешь прочитать в #139 номере ][). В основе его лежит V8, движок JavaScript, который используется в браузере Google Chrome и благодаря которому он работает невероятно быстро. Конкуренцию ему составляет другое решение, RingoJS. Этот движок работает поверх Java-машины, а многие из стандартных библиотек вполне совместимы с Node.JS. Java многим кажется более интересным решением, так как для нее написано великое множество библиотек и даже серверов, а работа с памятью, множеством процессоров и потоков гораздо более оптимизированная, чем у новичка Node. А вот кто лучше, пока не известно.
Облака — главный тренд не только в разработке, но и вообще всей отрасли ИТ в принципе. 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 или даже работаешь через библиотеку для любимого языка – а хостинг повинуется сам, выделяя все, что запросишь. А создание таких библиотек, которые бы прозрачно работали с разными интерфейсами разных провайдеров, само по себе тренд в разработке.
Обрати внимание, что такие раньше традиционные друзья разработчика как FTP и SVN стремительно теряют популярность. Теперь многие делают это через систему контроля версий Git. Поправил файлик, добавил немного гениального кода и хочешь его выкатить на сервер? Сначала закоммить его в git-репозиторий, напиши комментарий, что там хорошего ты накодил, а потом только разверни на сервере, снова-таки при помощи git-а. И ведь реально удобно – и разработка, и деплой идет при помощи одной системы. Все в командной строке. Посмотрев на популярность сервиса Github (github.com), многие провайдеры, чтобы привлечь разработчиков и облегчить им жизнь стали разворачивать у себя git-репозитории как единственную возможность что-то залить на сервер. Ну, теперь хоть не будет криков, что снова Вася не то залил на сервер и все перестало работать. Да и чего таить, сам подход к разработке кода немного поменялся. Если раньше все твои друзья сидели уютно и кодили что-то там втихаря, теперь большинство перебралось на сервисы вроде GitHub-а и занимаются «социальным кодингом». С приходом Git-а стало намного проще следить за прогрессом твоих любимых библиотек. Если что-то надо срочно поправить в чужом коде, так без проблем: кнопка «форк» теперь так же близко, как и кнопка создание тикета. А чтобы автор заморского чуда принял твои правки, не нужно долго на ломаном английском объяснять, что ты сделал конфетку из его непонятного кода. Просто отправь ему пулл-реквест и если все хорошо, твой код быстро попадает в основную ветку. Github стал настоящим прорывом, потому что собрав в очень удобном веб-интерфейсе все, что надо матерому гику-программисту. И что еще важно он добавил острое блюдо социальщины. Теперь не нужны все эти твиттеры и фейсбуки: для многих разработчиков (прежде всего OpenSource) Github стал местом жизни, общения и тут же, не отходя от кассы, кодинга. А все потому, что выстраивая все же среду для совместной разработки кода, Github не прячет людей за всеми этими коммитами и чекаутами, а активно их выталкивает на поверхность. Согласись, очень приятно видеть свою аватарку или фотку возле каждого принятого патча в важный проект.
Да и работать с кодом можно прямо в браузере – например, через систему Cloud9 (c9.io). Это такая среда для кодинга прямо в браузере, которая изящно дополняет GitHub и позволяет реально вести разработку с любого места, где есть интернет. Теперь не важно, какой у тебя комп, хоть даже нетбук с GoogleOS, на который ничего не поставить, а программировать все равно можно. Одним кликом подключаешь к ней свой GitHub-аккаунт - и продолжаешь работу.
Любой веб-приложение теперь должно работать в браузере. Без задержек и тормозов, иначе все пользователи сразу разбегутся. Сейчас есть немало решений, позволяющих реализовать реалтайм для веба, но самой прогрессивной технологией являются веб-сокеты (WebSockets). Ага, все уже устали, что в браузере у тебя есть только HTTP и ничего больше, да и тот урезанный и затиснутый в ограничения безопасности. Конечно, вражеский Flash заботливо подсуетился и предложил альтернативу, но кому он теперь нужен. В этом году все хотят полного реалтайма, чтобы ты только успел подумать, а на сервере уже все отправилось и обратно вернулось. Этого не может обеспечить привычный HTTP, так как ему нужно на каждый чих создавать новое соединение, а это снова и снова пару килобайт данных гонять туда-сюда и ждать в среднем полсекунды. Создатели обычных программ потирают руки - у них-то есть полный доступ к системе, ничем не ограниченый и они используют сеть сразу напрямую на низком уровне. Не долго они радовались, в HTML 5 появился раздел WebSockets, который почти те же сокеты только сразу у тебя в браузере, на любой веб-странице. Один раз соединившись с сервером, ты можешь держать открытым канал передачи (в обе стороны между прочим) как угодно долго и пересылать по нему любые данные. Без задержек, сразу, мгновенно, как позволяет твой интернет. Но вот в чем проблема – разработчики кинулись делать всякие штуки, вешать на них ярлык реалтайма (то есть – очень быстрые и без перезагрузки страницы), а сервера то для них нет. Любимый Nginx, хоть и добравшийся уже до версии 1.0.3, что в мире опенсорс и постоянной беты просто событие, увы, никак не умеет работать с сокетами. И дело не софте – все существующие веб-сервера просто не умеют рулить в ситуации, когда клиенты не просто пришли, сделали запрос и отвалились до следующего сеанса связи (пусть даже раз в секунду, по меркам сервера это очень много времени), а постоянно висят на связи. Даже когда данных нет, а все равно, сокет открой да держи, а вдруг в следующую секунду или полчаса что-то произойдет, о чем пользователь хочет узнать мгновенно! Вот тут то и пригодился новооткрытый JavaScript на стороне сервера – на Node.JS такие вещи делаются просто несколькими строками, а соединений пусть и постоянно открытых, он может держать столько, сколько позволит тебе ресурсы
сервера (размер памяти и настройки ядра ОС и сетевого стека).
Кроме обычных для всех языков, пусть и сдобренных примочками для поддержи новомодных технологий, сейчас трендово пробовать новые языки и приемы программирования, использующие асинхронность. Для 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. Мобилизация - главный тренд года
Облачные интерфейсы на заметку
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 или даже на чистом РНР.
Жизнь после MySQL: выбираем замену для популярной СУБД. Статья для журнала Хакер
Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант, без правок или ограничения на объем материала.
Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без призрака оракла за спиной?
Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись»