company_banner

Сервисы на Go в Badoo: как мы их пишем и поддерживаем


    Написать сетевой сервис на Go очень просто: в стандартной библиотеке есть куча инструментов, а если чего-то и не хватает, то на Github есть много модных библиотек для удовлетворения большинства нужд.


    Но что, если необходимо написать с десяток разных сервисов, работающих в одной инфраструктуре?


    Если каждый демон будет использовать все свежие разнообразные «смузи»-технологии, получится «зоопарк», который сложно и дорого поддерживать, не говоря уже о добавлении в них новой функциональности.


    У нас в Badoo крутятся >30 самописных демонов, написанных на разных языках, и ~10 из них – на Go. Все эти демоны работают на порядка 300 серверах. Как мы к этому пришли, не получив в итоге «зоопарк», как админы с мониторингом умудряются спать спокойно, не ограничивая при этом никого в смузи, а девелоперы, QA и релизеры живут дружно и до сих пор не переругались – читайте под катом.


    В Badoo Go впервые появился примерно в 2014 году, когда перед нами встала задача быстро написать демон, который ищет пересечения между координатами пользователей. Тогда последняя версия Go была 1.3, и поэтому мы долго боролись с GC-паузами, о чём даже сделали доклад на Go-митапе у нас в офисе.


    С тех пор у нас появляется всё больше и больше демонов, написанных на Go. В основном это то, что раньше было бы написано на C, но порой и то, что не так хорошо ложится на PHP (например, наш асинхронный прокси или планировщик ресурсов нашего «облака»).


    Все запросы от клиентских приложений у нас обслуживает PHP, который ходит в наши разнообразные самописные и несамописные сервисы. Упрощённо это выглядит так:



    Хотя из этого правила и есть некоторые исключения, в целом для всех наших демонов на Go справедливо следующее:


    1. Они не «торчат наружу» в интернет
    2. Основной «пользователь» демона – код на PHP.

    Все наши демоны вне зависимости от языка их написания выглядят одинаково «извне» с точки зрения протокола, логов, статистики, деплоя и прочего. Это упрощает жизнь админам, релиз-инженерам, QA и PHP-разработчикам.


    Поэтому с одной стороны, многие подходы, которые мы используем для демонов на Go, были продиктованы уже существующими подходами к написанию демонов на C/ C++, а с другой стороны, многое из этой статьи справедливо не только для Go, но и для любого нашего демона.


    Ниже я расскажу, как устроены наши основные инфраструктурные части и как они отражаются в Go-коде.


    Протокол


    Когда речь заходит о клиент-серверном взаимодействии, встаёт вопрос о протоколе. Мы взяли за основу Google Protobuf. Наш протокол похож на упрощённую версию gRPC, поэтому нам неоднократно задавали вопросы из разряда «зачем нужно было изобретать велосипед?». Скорее всего, сегодня мы бы действительно воспользовались gRPC, но в те времена (2008 год) его ещё не существовало, а менять одно на другое сейчас нет никакого смысла.


    Protobuf заворачивает в бинарное представление только тело сообщения и при этом не сохраняет его тип. Поэтому каждый раз, когда клиент обращается к серверу с запросом, сервер должен понять, какое это именно protobuf-сообщение и какой метод необходимо выполнить. Для этого перед protobuf-сообщением мы добавляем идентификатор типа сообщения и длину сообщения. Идентификатор однозначно даёт понять, какой именно GPB-message пришёл, а длина позволяет сразу же аллоцировать буфер нужного размера.


    В итоге один вызов в терминах протокола выглядит так:


    • 4 байта – длина сообщения N (число в network byte order);
    • 4 байта – идентификатор типа сообщения (тоже);
    • N байтов – тело сообщения.

    Для того чтобы и клиент, и сервер имели одинаковую информацию об идентификаторах сообщений, мы их так же храним в proto-файле в виде enum’ов со специальными именами request_msgid и response_msgid. Например:


    enum request_msgid {
        REQUEST_RUN = 1;
        REQUEST_STATS = 2;
    }
    
    // в общем случае на один request могут быть разные response, и наоборот
    enum response_msgid {
        RESPONSE_GENERIC = 1; // например, таким response у нас может ответить любой метод, обычно мы это используем для передачи ошибок
        RESPONSE_RUN = 2;
        RESPONSE_STATS = 3;
    }
    
    message request_run {
      // ...
    }
    
    message response_run {
      // ...
    }
    
    message request_stats {
      // ...
    }
    
    // ...

    За всю эту протокольную часть отвечает наша библиотека, которую мы называем gpbrpc. Её можно грубо разделить на две части:


    • одна часть – это кодогенератор, который на основе request_msgid и response_msgid генерирует карты соответствий id => message, шаблоны методов-обработчиков, карты их вызовов с приведением типов и ещё некоторый необходимый нам код;
    • вторая часть занимается разбором всех этих данных, пришедших по сети, и вызовом соответствующих им методов-обработчиков.

    Кодогенератор из первой части реализован в виде плагина к Google Protobuf.


    Примерно так выглядит автоматически сгенерированный обработчик для приведённого выше proto-файла:


    // интерфейс, содержащий совокупность методов, сгенерированных из proto-файла 
    type GpbrpcInterface interface {
        RequestRun(rctx gpbrpc.RequestT, request *RequestRun) gpbrpc.ResultT
        RequestStats(rctx gpbrpc.RequestT, request *RequestStats) gpbrpc.ResultT
    }
    
    func (GpbrpcType) Dispatch(rctx gpbrpc.RequestT, s interface{}) gpbrpc.ResultT {
    
        service := s.(GpbrpcInterface)
    
        switch RequestMsgid(rctx.MessageId) {
        case RequestMsgid_REQUEST_RUN:
            r := rctx.Message.(*RequestRun)
            return service.RequestRun(rctx, r)
        case RequestMsgid_REQUEST_STATS:
            r := rctx.Message.(*RequestStats)
            return service.RequestStats(rctx, r)
        }
    }
    
    // в закомментированном виде генерируются шаблоны будущих методов-обработчиков
    /*
        func ($receiver$) RequestRun(rctx gpbrpc.RequestT, request *$proto$.RequestRun) gpbrpc.ResultT {
            // ... 
        }
    
        func ($receiver$) RequestStats(rctx gpbrpc.RequestT, request *$proto$.RequestStats) gpbrpc.ResultT {
            // ...
        }
    */

    gogo/protobuf


    В документации к Protobuf Google рекомендует использовать эту библиотеку для Go. Но, к сожалению, она генерирует плохо ложащийся на GC-код. Пример из документации:


    message Test {
      required string label = 1;
      optional int32 type = 2 [default=77];
    }

    превращается в


     type Test struct {
        Label         *string             `protobuf:"bytes,1,req,name=label" json:"label,omitempty"`
        Type          *int32              `protobuf:"varint,2,opt,name=type,def=77" json:"type,omitempty"`
    }

    Каждое поле структуры стало указателем. Это необходимо для optional-полей: для них нужно различать случай отсутствия поля от случая, когда в поле содержится нулевое значение.


    Даже если вам это не нужно, библиотека не позволяет управлять наличием указателей в сгенерированном коде. Но не всё так плохо: у неё есть форк gogoprotobuf, в котором это поддерживается. Для этого необходимо указать соответствующие опции в proto-файле:


    message Test {
      required string label = 1 [(gogoproto.nullable) = false];
      optional int32 type = 2 [(gogoproto.nullable) = false];
    }

    Избавление от указателей было особенно актуально для Go до версии 1.5, когда GC-паузы были гораздо длиннее. Но и сейчас это может дать весомый прирост (иногда в разы) к производительности нагруженных сервисов.


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


    Подходящий набор опций зависит от конкретной ситуации. Мы почти всегда используем как минимум nullable, sizer_all, unsafe_marshaler_all, unsafe_unmarshaler_all. Кстати, опции, имеющие вариант с суффиксом _all, можно применить сразу ко всему файлу, не дублируя их на каждое поле:


    option (gogoproto.sizer_all) = true;
    
    message Test {
      required string label = 1;
      optional int32 type = 2;
    }

    JSON


    В Google Protobuf прекрасно практически всё, но поскольку это бинарный протокол, его сложно отлаживать.


    Если нужно найти проблемы на уровне взаимодействия готового клиента и сервера, то можно, например, воспользоваться gpbs-dissector для Wireshark. Но это не подходит в случае разработки новой функциональности, для которой ещё нет ни клиента, ни сервера.


    По сути, чтобы написать какой-то тестовый запрос в сервис, нужен клиент, который сможет завернуть его в бинарное сообщение. Писать такой тестовый клиент для каждого демона хоть и не очень сложно, но неудобно и рутинно. Поэтому наш gpbrpc умеет обрабатывать и JSON-подобное представление протокола на другом, отличном от gpb-интерфейса, порту. Вся обвязка для этого генерируется автоматически (подобным образом, как описано выше для protobuf).


    В результате в консоли можно написать запрос в текстовом виде и тут же получить ответ. Это удобно для отладки.


    pmurzakov@shell1.mlan:~> echo 'run {"url":"https://graph.facebook.com/?id=http%3A%2F%2Fhabrahabr.ru","task_hash":"a"}' | netcat xtc1.mlan 9531
    run {
        "task_hash": "a",
        "task_status": 2,
        "response": {
            "http_status": 200,
            "body": "{\"og_object\":{\"id\":\"627594553918401\",\"description\":\"Хабрахабр – самое крупное в Рунете сообщество людей, занятых в индустрии высоких технологий. Уникальная аудитория, свежая информация, конструктивное общение и коллективное творчество – всё это делает Хабрахабр самым оригинальным IT-проектом в России.\",\"title\":\"Лучшие публикации за сутки / Хабрахабр\",\"share\":{\"comment_count\":0,\"share_count\":2456},\"id\":\"http:\\/\\/habrahabr.ru\"}", 
            "response_time_ms": 179
        }
    }

    Если ответ объёмный, и из него нужно выбрать какую-то часть или просто необходимо его как-то преобразовать, можно воспользоваться консольной утилитой jq.


    Конфиги


    Вообще к конфигам обычно предъявляют два основных требования:


    • удобочитаемость;
    • возможность описать структуру.

    Чтобы не вводить для этого ещё новых сущностей, мы воспользовались тем, что уже есть: protobuf – структура, читаемость – его JSON-представление.


    У нас уже есть вся обвязка для protobuf и генераторы парсеров его JSON-представления для дебага (см. предыдущий раздел). Остаётся только добавить proto-файл для конфига и «скормить» его этому разборщику.


    На самом деле, всё чуточку сложнее: так как нам важно максимально стандартизировать разные демоны, в конфиге существует часть, которая одинакова для всех демонов. Она описывается общим protobuf-сообщением. Итоговый конфиг – это совокупность стандартизированной части и того, что специфично для конкретного демона.


    Этот подход хорошо ложится на embedding:


    type FullConfig struct {
        badoo.ServiceConfig
        yourdaemon.Config
    }

    Пример для наглядности. Общая часть:


    message service_config {
      message daemon_config_t {
    
         message listen_t {
            required string proto                 = 1;
            required string address               = 2;
            optional bool   pinba_enabled         = 4;
         }
      repeated listen_t   listen                   = 1;
      required string     service_name             = 2;
      required string     service_instance_name    = 3;
      optional bool       daemonize                = 4;
      optional string     pid_file                 = 5;
      optional string     log_file                 = 6;
      optional string     http_pprof_addr          = 7;                 // net/http/pprof + expvar address
      optional string     pinba_address            = 8;
      // ...
      }
    }

    Часть для конкретного демона:


    message config {
      optional uint32 workers_count = 1 [default = 4000];
      optional uint32 max_queue_length = 2 [default = 50000];
      optional uint32 max_idle_conns_per_host = 4 [default = 1000];
      optional uint32 connect_timeout_ms = 5 [default = 2000];
      optional uint32 request_timeout_ms = 7 [default = 10000];
      optional uint32 keep_alive_ms = 8 [default = 30000];
    }

    В итоге JSON-конфиг выглядит примерно так:


    {
        "daemon_config": {
            "listen": [
                { "proto": "xtc-gpb",             "address": "0.0.0.0:9530" },
                { "proto": "xtc-gpb/json",        "address": "0.0.0.0:9531" },
                { "proto": "service-stats-gpb",        "address": "0.0.0.0:9532" },
                { "proto": "service-stats-gpb/json",   "address": "0.0.0.0:9533" },
            ],
            "service_name": "xtc",
            "service_instance_name": "1.mlan",
            "daemonize": false,
            "pinba_address": "pinbaxtc1.mlan:30002",
            "http_pprof_addr": "0.0.0.0:9534",
            "pid_file": "/local/xtc/run/xtc.pid",
            "log_file": "/local/xtc/logs/xtc.log",
        },
    
    // специфичная для конкретного демона часть
        "workers_count": 4000,
        "max_queue_length": 50000,
        "max_idle_conns_per_host": 1000,
        "connect_timeout_ms": 2000,
        "handshake_timeout_ms": 2000,
        "request_timeout_ms": 10000,
        "keep_alive_ms": 30000,
    }

    В listen перечисляются все порты, которые будет слушать демон. Первые два элемента с типами xtc-gpb и xtc-gpb/json – для портов того самого gpbrpc и его JSON-представления, о которых я писал выше. А с service-stats-gpb и service-stats-gpb/json мы собираем статистику, о которой пойдёт речь далее.


    Статистика


    При сборе статистики (как и в случае со стандартизированной частью конфига) нам важно, чтобы каждый демон писал как минимум основные метрики: количество обслуженных запросов, потребление CPU и памяти, сетевой трафик и т. д. Эта типовая статистика собирается с порта service-stats-gpb, она одинакова для всех демонов.


    Запрос статистики, по сути, ничем не отличается от обычного запроса к демону, поэтому мы применяем всё те же подходы: статистика описана в терминах gpbrpc, как и обычные запросы. Обработчики этой “стандартизированной” статистики уже есть в нашем фреймворке, поэтому их не нужно писать каждый раз для очередного демона.


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


    Раз в минуту PHP-клиент-сборщик статистики подключается к демону, запрашивает значения и сохраняет их в time-series-хранилище. На основе этих данных мы строим такие графики:



    Значения для пяти первых графиков собираются автоматически со всех демонов, на остальных представлены значения, специфичные для конкретного демона.


    У нас принято считать, что статистики много не бывает, и мы стараемся получать максимальное количество данных, чтобы потом было проще разбираться с проблемами и изменениями в них. Поэтому в конфиге можно увидеть параметр pinba_address, это адрес сервера Pinba, в который демон также отправляет статистику.


    Из Pinba мы строим графики по распределению времени ответа:



    Дебаг и профилирование


    Ещё в конфиге можно заметить параметр http_pprof_addr. Это порт net/http/pprof – встроенного в Go инструмента, который позволяет легко профилировать код. О нём написано много статей (например, эта и эта), поэтому я не буду останавливаться на подробностях его работы.


    Мы оставляем pprof даже в продакшн-сборках демонов. Он не даёт практически никакого оверхеда, пока им не пользуются, но добавляет гибкость: в любой момент можно подключиться и понять, что происходит и на что конкретно тратятся ресурсы.


    Кроме того, мы используем expvar, он позволяет одной строкой кода сделать доступными значения любых переменных демона по HTTP в JSON-виде:


    expvar.Publish("varname", expvar.Func(func() interface{} { return somevariable }))

    По умолчанию HTTP-обработчик expvar добавляется в DefaultServeMux и доступен по адресу http://yourhost/debug/vars. Пакет при подключении обладает сайд-эффектом. Он автоматически публикует со всеми параметрами командную строку, при помощи которой был запущен бинарник, а также результат runtime.ReadMemStats().


    Осторожно! ReadMemStats() сейчас может приводить к stop-the-world на длительное время, если выделено много памяти. Мой коллега Марко Кевац создал тикет на эту тему, и в версии 1.9 это должно быть исправлено.


    Кроме стандартных значений, все наши демоны публикуют ещё множество отладочной информации, наиболее важная – это:


    • конфиг, с которым запущен демон;
    • значения всех счётчиков статистики, о которой я писал выше;
    • данные о том, как был собран бинарник.

    С первыми двумя пунктами, я думаю, всё понятно. Последний же даёт информацию о версии Go, под которую был собран демон, хеше git-коммита, времени сборки и другие полезные данные о сборке.


    Пример:



    Мы делаем это с помощью генерации при сборке файла version.go, в который записывается вся эта информация. Но аналогичного эффекта можно добиться и при помощи ldflags -X.


    Логи


    В качестве логгера мы используем logrus со своим кастомным форматтером. Файлы логов при помощи Rsyslog и Logstash собираются в Elasticsearch и впоследствии выводятся в дашборде Kibana (ELK).


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


    Воркфлоу, тесты и прочее


    Вся работа ведётся в JIRA. Каждый тикет – отдельная ветка. Для каждой ветки из тикетов TeamCity собирает бинарник. Для сборки мы используем GNU Make, так как, кроме непосредственно компиляции, нам нужно сгенерировать version.go и код для gpbrpc из proto-файлов, а также выполнить ещё ряд задач.


    Мы используем Go 1.5 Vendor Experiment, чтобы иметь возможность положить код зависимостей в директорию vendor. Но, к сожалению, пока мы делаем это простым добавлением всех файлов зависимостей в наш репозиторий. В планах есть использование какой-нибудь утилиты для вендоринга. Перспективной выглядит dep, остаётся только дождаться её стабилизации.


    После того как тикет проходит ревью, за него берутся ребята из QA-команды. Они пишут функциональные тесты на новые фичи демона и проверяют регрессию. Тесты пишутся на PHP, поскольку в большинстве случаев именно он является клиентом демона в продакшне. Тем самым мы гарантируем, что, если что-то работает в тестах, это будет работать и на продакшне.


    Что касается тестов на Go, то они являются опциональными и пишутся по необходимости. Но мы работаем над этим и планируем писать больше тестов на Go (см. постскриптум).


    Из тикетов, проверенных QA и готовых к релизу, TeamCity собирает билдовую ветку. Когда она готова к выкладке, разработчик заходит в специальный интерфейс и финиширует её. При этом билдовая ветка мёржится в мастер, и в JIRA-проекте админов создаётся тикет на выкладку.



    Шаблон демона


    Написать новый демон в наших условиях просто, но тем не менее это требует некоторых шаблонных действий: нужно создать структуру директорий, сделать proto-файл для клиент-серверного протокола, конфиг и proto-файл к нему, написать код старта сервера на основе gpbrpc и прочее. Чтобы не заморачиваться с этим каждый раз, мы сделали репозиторий с шаблонным демоном, в котором есть небольшой bash-скрипт, который на его основе делает новый полноценный демон по этому шаблону.


    Заключение


    В результате мы получили то, что, даже когда в новом демоне ещё не написано ни строчки кода, он уже готов к нашей инфраструктуре:


    • одинаковым образом конфигурируется;
    • пишет статистику и логи;
    • общается по такому же производительному (protobuf) и легко читаемому (JSON) протоколу, как и остальные демоны (в том числе написанные на других языках);
    • одинаковым образом обслуживается и мониторится.

    Это позволяет нам не тратить ресурсы разработчиков и при этом получать предсказуемые и легкоподдерживаемые сервисы.


    На этом всё. А как вы пишете демоны на Go? Добро пожаловать в комментарии!


    P. S. Пользуясь случаем, хочу сказать, что мы ищем таланты.


    Многое уже написано на Go, но ещё больше предстоит написать, поскольку мы хотим развивать это направление. И мы ищем толкового человека, который может нам в этом помочь.


    Если вы – Go-разработчик и немного знаете C/C++, пишите mkevac в личку или на почту: m.kevac@corp.badoo.com (в его команду мы присматриваем коллегу).

    Метки:
    Badoo 360,06
    Big Dating
    Поделиться публикацией
    Похожие публикации

    Вакансии компании Badoo

    Комментарии 23
    • +3
      Спасибо за статью, было интересно. Подскажите, а принудительный вызов runtime.GC() перед вызовом runtime.ReadMemStat() не снижает время StopTheWorld?
      И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
      • +2
        > Спасибо за статью, было интересно. Подскажите, а принудительный вызов runtime.GC() перед вызовом runtime.ReadMemStat() не снижает время StopTheWorld?
        Скажу сразу — не экспериментировал. Но, по логике, он сможет снизить время, только если в хипе значительное количество мусора. А если бОльшая часть памяти используется и мусора мало, то особой разницы быть не должно.

        > И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
        Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
        • 0
          При большом потреблении памяти мусор всё равно будет, так что, в теории, должно тогда дать прирость, но вызов GC, насколько я помню, тоже вызывает stopTheWorld. Именно в этом моменте было интересно, будет ли в сумме две таких остановки мира быстрее, чем одна из-за runtime.ReadMemStat, по логике — да
          >Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
          Ага, спасибо, просто у себя, обычно, предпочитаю генерировать код валидный и с паниками, но против исторически сложившихся фактов ничего не имею ;)

          И, ещё бы хотелось полюбопытствовать в чём у вас пишут код =)
          • 0

            В принципе нам ничто не мешает стандартизировать и подстановки, но так как новые сервисы появляются не чаще раза в месяц в этом пока не было необходимости.

            • 0
              Я писал всегда и все в Vim. Некоторое время пробовал VS Code. Он мне нравится, но там нет просмотра тегов. В остальном он классный. Ну и последний месяц я активно пробую Gogland. Gogland мощный и вкусный, но я пока не привык к таким монструозным IDE и учусь новым вещам очень медленно. Скорее всего я так и продолжу использовать Vim и Gogland.
              • 0
                Я пользуюсь плагином для IDE от jetBrains.
                Его можно поставить, например, на phpStorm и будет удобно править одновременно Go- и PHP-код. Тоже самое можно сделать с другими IDE от jetBrainds — по ссылке написано, что он поддерживает.
              • 0
                Вызов runtime.GC() вызывает сборку мусора, которая целиком STW :-(
                If the line ends with "(forced)", this GC was forced by a
                runtime.GC() call and all phases are STW.

                https://golang.org/pkg/runtime/
            • +2
              Спасибо за статью.
              Раз в минуту PHP-клиент-сборщик статистики подключается к демону, запрашивает значения и сохраняет их в time-series-хранилище. На основе этих данных мы строим такие графики:

              Какая причина(ы) использовать PHP для сбора статистики, а не писать в TS хранилище прямо из демона, или же другим Go демоном собирать ее вместо PHP? Просто любопытно.
              • +1
                Как я писал выше в статье, многие подходы мы изначально позаимствовали из того, что у нас уже было до Go. Это — как раз хороший пример.
                Вероятно в будущем мы придём к схеме, когда не будет сборщика и демоны будут этим заниматься сами. Как это, например, уже сделано для отправки PINBA-статистики.
              • +2
                Не планируете открыть код Вашего протокола? Было бы интересно взглянуть
                • +3
                  Он есть в open-source, например, как часть ранее нами открытого для сообщества LSD, исходный код которого есть на GitHub.
                  LSD можно использовать в качестве примера демона, реализованного под нашу инфраструктуру. В нём используется большая часть того, что я описываю в статье.
                • 0
                  Стандартная реализация протобуферов 3 версии сохраняет поля без указателей.
                  • +1
                    Это очень интересно. Надо посмотреть как они понимают задано поле или нет. Там теоретически вариантов несколько. Например, использовать has_ поля булевые, как в protobuf-c или битовые поля.
                    • +1
                      Я попробовал собрать один из наших proto стандартным компилятором. Если собрать не указывая proto3, то ничего не поменялось. Указатели.

                      Если сделать синтакс прото3, то надо в proto много чего поправить (убрать все optional, required, все enum начинаются с 0, нет дефолтных значений) и получается без указателей, действительно.

                      Но я в апи не вижу как понять задано поле или нет. Только сравнивать с нулевым значением?
                      • 0
                        > Только сравнивать с нулевым значением?
                        Да, другого выхода нет. Приходится избегать ситуаций, когда int может быть задан 0, или не задан вообще.
                  • +4
                    Классная диаграмма. Мне одному показалось, что суслик и слоник не ровно дышат по отношению друг к другу? :)
                    • 0

                      Если PHP обслуживает все клиентские endpoint, значит общение клиентов с ним только по HTTP? Или для других протоколов, например websocket, демоны на PHP? Или же есть демоны для клиентов без PHP?

                      • 0
                        Вы всё верно подметили, именно о таких исключениях я и имел в виду в статье: у нас есть 2 демона, которые обслуживают длинные соединения от браузеров и нативных клиентов, позволяя отправлять им пуши.
                        Эти демоны написаны очень давно на C. Go'шных, работающих напрямую с клиентами, — нет. По крайней мере пока :)
                        • 0

                          А мне вот как раз интересен вопрос на чём писать таких демонов в SOA-системе в целом написанной на PHP. Основных варианта три: PHP, Node.js и Go. В пользу PHP прежде всего консистентность стэка, но есть опасения по надежности. Для Go — компилируемость и статичность как причины низкого потребления ресурсов, деплой одним бинарником — бесплатный бонус, для Node — более простой переход с PHP (субъективно все пхпешнки джс худо-бедно знают). При том, что поддержка после первоначального написания таких демонов будет лишь дополнительной задачей для пхп-разработчиков, в обозримой перспективе даже одного разработчика только на демонов искать нет экономического смысла.


                          Вы рассматривали Node как альтернативу Go для демонов в системе, где упор на PHP? Если да, то только ли более низкое ресурсопотребление (по крайней мере в теории) сыграло решающее роль? Вопрос о том, демоны на каком из языков проще начать писать "стандартному" пехепешнику был важным при выборе?

                          • +2

                            99% кода на Go в Баду пишется в отделе C-разработки и задачи выбрать язык который был бы проще в изучении PHPшникам не стояло. Была цель выбрать язык который был бы достаточно эффективен (ближе к C чем к PHP), но при этом бы на нём было быстрее писать (основное, насколько я понимаю, чтобы был GC). Так что Node.js не подошёл нам по многим параметрам.


                            P.S. Моё личное мнение насчет Node.js — на нём даже проще написать плохо работающий код, чем на PHP.

                            • 0

                              Привет, я вот начал активно использовать Crystal, где возможно :)

                      • 0
                        На схеме php выглядит как узкое горлышко в бутылке. Так ли оно на самом деле не берусь судить конечно.
                        • 0

                          Если рисовать пропорционально все площадки и подкластера инфраструктуры Баду — на экран не влезет :-)

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

                        Самое читаемое