GitHub изнутри :: WDev.tk — Познавательное в web-разработке

24 окт

GitHub изнутри

Совсем недавно, co-founder проекта GitHub по имени Tom Preston-Werner (аka mojombo), на радостях от переезда с Engineyard на Rackspace написал очень подробную статью о внутренних составляющих их детища. Краткая выдержка как всегда под катом.

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

Основной список компонент:

ldirectord под Xen для балансировки нагрузки.
4 frontend с 8 ядрами, 16GB RAM. Здесь стоят Nginx, Unicorn, Rails.
MySQL база расположена на двух 8 core, 32GB RAM серверах с DRBD репликацией.
Для получения данных о git репозитории используется собственная разработка Grit.
Grit делает RPC запрос на балансировщик с HAProxy
Информация о роутинге к реальному расположению git хранилища на файловых серверах размещена в Redis.
Файл-сервера с пользовательскими хранилищами идут парами с DRBD репликацией. Помимо этого в каждом сервере имеется 6 SAS дисков c RAID 10. Забэкапились по самое нехочу :)
Собственная разработка Ernie RPC сервера спрятаны за HAProxy. Они служат для чтения информации о хранилище.
Кеширование в Rails выполнено на основе memcached Ruby библиотеки.
Патченный ssh демон, которых хранит сертификаты не в локальной файловой системе, а в MySQL базе данных.

Также в этой статье присутствует ссылка на отдельную статью об их собственной разработке -- протоколе сериализации BERT и протоколе BERT-RPC для межпроцессного и межсерверного взаимодействия.

Отдельно хотелось бы обратить внимание на причины написание своего протокола и на анализ современного положения дел в области RPC. В этой статье рассматриваются современные Thrift и Protocol Buffers, а также вполне устоявшиеся XML-RPC, SOAP, JSON-RPC. Ни один из них не прошел по выдвигаемым критериям:

Чрезвычайная простота
Динамичность (Никаких IDL или кодогенераций) //согласен, очень порочная практика
Богаты набор встроенных типов (nil, symbols, hashes, bignums, heterogenous arrays, и т.д.)
Поддержка составных и сложных типов (Time, Regex, и т.д.)
Отсутствие необходимости кодировать двоичные данные
Синхронные/асинхронные вызовы
Быстрая сериализация/десериализация
Поддержка потоковой передачи во все направления
Директивы для кеширования.

Еще раз, ссылки на статьи:

А еще меня можно найти в twitter-е под ником @apoint. Присоединяйтесь, будет интересно.

Стоит почитать

Добавь свой

Комментарии (0)

Последние комментарии

Sunday, October 25, 2009 point
Переезжаем на git
В процессе поиска иконки для заметки наткнулся именно на эту. Мне она показалась подходящей т.к.хорошо отображает суть: процессы ветвления и слияния. Но если вы настаиваете, то я конечно же сменю :)
Saturday, October 24, 2009 bialix
Переезжаем на git
Почему в качестве иллюстрации к вашей статье выбрана иконка проекта Bazaar VCS (http://bazaar-vcs.org)? Это для чего? Из вашей статьи следует, что bzr вы не пользовались и переезжаете с SVN на Git. Каким тут боком bzr? Пожалуйста, уберите. Иконки svn или git можно взять на соответствующих сайтах.
Thursday, October 15, 2009 point
Переезжаем на git
Я наверное неправильно выразился. Перенес именно с помощью git-svn. Других простых путей я не нашел. А комментарий был на тему того, что _постоянно_ пользоваться git-svn не хотелось, ибо лень :) В итоге, по факту, пока приходится вручную sync-ать в свн с помощью старого доброго meld. > Якби ще цей wordpress... Это не вордпресс, а собственная разработка. Этот блог отчасти для его обкатки. А комментарии на почту скоро появятся. Совсем недавно мой коллега написал плагинчик delayed job, который сейчас тестируется. Он как раз таки и будет рассылать почту подписчикам.
Thursday, October 15, 2009 Анатолій Сахнік
Переезжаем на git
А як же тоді перенести історію розробки з svn у git? Є ще якийсь шлях крім git-svn? Якби ще цей wordpress присилав повідомлення про нові коментарі, ціни б йому не було…
Tuesday, October 6, 2009 point
Переезжаем на git
Но это была бы полумера. Да и я несколько ленив, поэтому не особо хотелось разбираться с git-svn. А разбираться, уверен, пришлось бы, т.к. ну не может всё проходить гладко -- рано или поздно возникнет неведомая х%ня, которая заставит прочесть man-ы от корки до корки.
Tuesday, October 6, 2009 Анатолій Сахнік
Переезжаем на git
Щоб перехід був не дуже болісний, можна було б деякий час покористуватися git-svn. Ця цяцька дозволяє не тільки перенести історію svn у локальне сховище git, але й навпаки.
Sunday, September 20, 2009 powerslave
Впечатления от Coffee'n'Code Харьков
Слушал вопрос по экономической эффективности. Ответ очень прост на самом деле: если проект будет на малое количество времени и поддержки особой не планируется. То есть через полгода-год - забыли про его существование, то эффект минимален. А вот если проект будет долгим(несколько лет с непостоянными доработками), то тут уже очень полезно. Уволят человека, которые сделал какую-то важную фичу, если тестов нет, то 100% с первого раза не получится что-то добавить правильно и 95% что тестеры пропустят какую-то мелочь, которая использует эту фичу не совсем стандартно. Очень было весело, когда один большой проект(без юнит-тестов) релизился с увеличением major версии. Тестеры проходили по всем кнопочкам. Находилась в первый раз штука, которая не работает. Ее быстренько подпиливали. Тестеры опять нажимали все кнопки. Версию отсылали клиентам. У какого-то из крупных клиентов раз в два-три релиза возникала ошибка в расчетах или в сохранении. Потому неделю все ждали ответа от пользователей нет ли какой ошибки. После моего ухода оттуда ввели зачатки по автоматизированному тестированию (клик на все кнопки) - одного тестера уволили. Начальник отдела проверяет правильность некоторых часто используемых вычислений запуском отчетов. (Фактически те же юнит-тесты). Баг-фиксы к релизам для всех уже не высылают. Тногда только какая-нибудь мелочь для клиентов, которые жалуются. Скорость разработки увеличилась.
Friday, September 18, 2009 point
libevent теперь и в PHP
Ну, во многих аспектах он ошибается. Главный его посыл -- запуск программы каждый раз при новом запросе, "программист теперь не привязан к постоянному перезапуску "приложения"". Есть системы из мира JavaEE, где приложение постоянно висит в памяти, и не запускается при каждом запросе. Как раз таки вызывается только нужная часть функционала. ИМХО, AJAX придуман не столько для "процедурности", сколько для более быстрой доставки информации. Если нужно изменить только небольшой блок страницы, зачем перегружать ее снова. AJAX-иком аккуратно его изменяем. Про кодировки -- на дворе 21 век. Unicode-у уже лет 15. Если разработчик не использует его, ну тогда придется заморачиваться с однобайтными кодировками. Как говорится, сам себе злобный буратино. "Нет такого свойства, чтобы готовые binary данные вставить в элемент." Очень давно существует. img src="data:image/gif;base64, и погнали. Да и про JavaScript тоже местами гониво. JS приложения можно успешно запускать не только в браузере.
Thursday, September 17, 2009 0lympian
libevent теперь и в PHP
Кулер читает наши мысли ;)) http://cooler-online.com/cl130909.html#a2
Wednesday, September 16, 2009 point
libevent теперь и в PHP
Например, nginx -- даже не обвязка, а полностью построенный на event-ах веб-сервер. А если поразмыслить, любую систему можно свести к event-ориентированной, где те или иные части срабатывают по наступлении определенного события.
Saturday, September 12, 2009 0lympian
libevent теперь и в PHP
Хе-хе... посетила странная мысль. Веб-свервер - это ведь и есть event-ориентированная обвязка. ;)
Monday, August 24, 2009 point
2 новости про APC и php-fpm
>Если честно, не очень понятно, что же выделилось из проекта. Ничего не выделялось. Был преобразован код. Похоже, что всё движется к чему-то вроде pecl extension. > О динамическом количество воркеров видимо так и придется только мечтать Это стоит в планах. Как только Майкл найдет программистов и финансы, эта фича будет реализована.
Monday, August 24, 2009 point
SQL. Всё-таки Да или Нет ?
Rapid по сравнению с чем ? Порой, оптимизация базы данных для уменшения нагрузки на систему, в целом занимает большой промежуток времени и требует знаний по внутреннему устройству конкретной СУБД. А это уже совсем не "Rapid".
Sunday, August 23, 2009 aekciy
2 новости про APC и php-fpm
Если честно, не очень понятно, что же выделилось из проекта. Понятно, что Андрей по видимому пока этим заниматься не будет, Michael на launchpad замутил, что-то отдельное, только вот что-то не уловлю что... Написано, теперь патчить ни чего не нужно. Получается это некий отдельный FastCGI менеджер который запускает скрипты? Как я понимаю ни каких отличий от версии когда нужно патчить нет? О динамическом количество воркеров видимо так и придется только мечтать...
Saturday, August 22, 2009 Artem
SQL. Всё-таки Да или Нет ?
Дануна! У них базы песец перегруженные, вот и денормализуют за счет программеров. Нам-то это зачем? Мы как раз SQL любим именно за его простоту и возможность RAPID DEVELOPMENT.

WDev.tk - cognitive in web development