Архив метки: архитектура

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

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 млрд. просмотров контента.

Про DDD

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

 

https://t.me/symfony_php

Про фичи, контексты и boundary context

Фичи формируют контексты (boundary context). Контексты пересекаются но в целом весьма изолированы. Их нутро не зависит друг от друга.

Возьмем к примеру каталог товаров и прикинем какие у нас тут есть контексты:

  • пользователи — авторизация, восстановление доступа, управление профилем
  • ордеры — весь цикл жизни ордера в системе
  • каталог товаров — управление каталогом, просмотр деталей о продукте
  • поиск — весь поиск.

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

Синхронизация этих модулей — ивенты. Кто-то обновил продукт — кидаем ивент — синхронизируем данные в других контекстах.

Профит тут в том что мы можем отдельно посадить чувака заниматься поиском, и отдельно чувака заниматься ордерами. Можем перевести поиск на свою СУБД которая хорошо умеет полнотекстовый поиск (например эластика). И при этом если у нас добавляются фичи в каталог — это не сильно влияет на поиск.

 

https://habrahabr.ru/company/englishdom/blog/328550/

Про гибкость

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

 

https://habrahabr.ru/post/327746/