Бэкенд ВКонтакте — от разработки до продакшена

PHP — очень простой язык, тупой как пробка, идеальный язык для бизнес-логики и прототипов!

ВКонтакте — по сути классическое приложение на PHP. Есть frontend, есть backend, есть база данных и т.п. Но во всех этих частях свои нюансы. В качестве базы данных использются свои внутренние «движки», в качестве основного языка для backend — KPHP. Логи собираются в ClickHouse. В ряде мест вместо HTTP используется QUIC. Весь php-backend — один огромный монолит, возможно, самый большой в мире ) Примерно 25К php-файлов, 9 млн. строк php-кода, около 800К коммитов в git-репозитории! Для ускорения работы KPHP переводит весь пхп-код в 200К C++ файлов, а далее компилирует в бинарник размером 1,5 ГБ. В итоге получаем прирост производительности в 10 раз! Весь backend компилируется за 3-5 минут, статика собирается до полу часа +) Полученный бинарь раскатывается сначала на стейджинг (1 % пользователей ~ около миллиона человек!), далее на 10К production-серверов. Сборка и деплой осуществляется через TeamCity. Раскатка происходит по протоколу Gossip.

Разработчик имеет свою полную копию vk.com, развернутую в контейнере. Правим обычный php-код и после обновления странички видим результат. При необходимости на этом же контейнере можно собрать полноценную kphp-версию. Однако в большом проекте разработчик не только пишет код, точнее даже не столько.

  • 5 % времени — пишешь код
  • 50 % — читаешь свой и чужой код
  • % — думаешь как безпроблемно выкатить правки, как мониторить и следить

Любой проект через два года превращается в легаси или умирает.

Цифры: 1,5 млн rps, 160 ms latency, 99.96 % availability, > 70 % resource utilization, 87 млн MAU, 9 млрд. просмотров контента.

amylabs =(

Продолжаю находить артефакты прошлого.
Помню в то время я работал в «Мегалабс», вечерами мы делали OpenSource   продукт http://github.com/yupe/yupe и в один прекрасный день решили открыть свою студию-агенство. Ну а что еще открывать тем, кто делает свою CMS. Помню как я в припрыжку бежал к станции метро Добрынинская, куда должен был приехать курьер и привезти первую партию напечатанных визиток. Голова кружилась от счастья! Я делаю свою компанию! Сам! Вот даже визитки уже есть! 😬
Много воды утекло с тех пор, домена уже нет, номера телефона тоже )

Немного жив только Open Source 😭 Но обо всем этом более подробно будет попозже.

Yii. TAGLINE. 2016

Яндекс.Диск иногда рекомендует посмотреть старые фотографии — классная функция.

Сегодня выпала вот такая.


Мы с Сашей Макаровым (sam_dark) на TAGLINE 2016.
В тот год Yiiframework получил премию как лучший backend-фреймворк в России.

А вот и моя заметка того времени https://yupe.ru/post/yii-luchshiy-po-vresii-tagline.html
Душевные были времена +) 

Крах ДотКомов 2.0

DHH — создатель Ruby On Rails, BaseCamp, Hey и еще некоторых классных продуктов, запустил новую инициативу — https://once.com/. Запустил уже некоторое время назад, я как-то пропустил. Суть в том, чтобы поставлять веб-сервисы не по подписке (saas) а как раньше — на дисках, для разворачивания где угодно +) К слову, в BaseCamp отказались от облаков и переехали на свое железо, сэкономив много денег. Shopify в одной из статей упоминал возобновившейся рост количества магазинов на их платформе и исход селлеров с маркетплейсов.
А тут еще склады огромные горят 🙃

Спираль истории интернета начинает новый виток.
Ждать «краха саасов» !? 

Acceptance, functional, unit. В таком порядке.

Вы решили написать тесты? Отлично! С чего начнем?

Блин!

Ваш проект полон «костылей» и кода, которые делают тестирование сложным или даже почти невозможным, а если вы еще и новичок в тестировании. Что делать?

Очень просто! Начните с Acceptance-тестов, далее functional-тесты и только в самом конце unit-тесты!

Приемочные (acceptance) тесты очень похожи на Behat-тесты, где вы тестируете конкретные пользовательские истории и поведение. Приемочные тесты проверяют весь цикл от веб-сервера до базы данных и обратно, они способны выявить множество ошибок приложения.

Как только вы напишите приемочные тесты — можно приступать к рефакторингу кода приложения и написанию функциональных (functional) тестов, которые проверяют взаимодействие отдельных компонентов. Дальнейший рефакторинг делает возможным написание модульных (unit) тестов — тестов, которые проверяют компоненты приложения отдельно друг от друга.

Тестирование это не «все или ничего»! Начните с простейших тестов, которые охватывают все части приложения и тестируют верхнеуровневую логику.

Начните писать тесты уже сегодня!

Приходите, научу писать тесты….