Tencent и China Reading Technology сотрудничают, микросервисный фреймворк Tars добавляет PHP

PHP открытый источник Тенсент

Лян Чен (Тед), работающий в Технологическом центре Китайской литературной группы, отвечает за разработку фона WEB китайского веб-сайта Qidian. Он отвечал за разработку маркетингового бэкэнда QQWeb и официального веб-аккаунта QQ отдела корпоративных продуктов Tencent Shanghai.У него есть собственный опыт и понимание технической архитектуры крупномасштабных веб-сайтов. Он является разработчиком платформы TSF2.0 проекта Tencent с открытым исходным кодом, разработчиком компонента Tencent с открытым исходным кодом Tars-PHP, а также разработчиком и сопровождающим нескольких компонентов расширения PHP Tencent.

введение

В качестве отличной среды RPC и решения для развертывания и обслуживания сервисов с открытым исходным кодом Tencent, TARS была внедрена на практике China Literature Group.В то же время China Literature Group дополнила возможности TARS на уровне языка PHP, сделав TARS еще более мощный. Решение TARS-PHP простое и эффективное, интерфейс прост в обслуживании и расширении, код генерируется автоматически, включены функции интегрированной адресации, обнаружения сервисов, мониторинга и отчетности. Он прошел испытание и крещение онлайн-бизнеса China Literature Group, что полностью доказывает преимущества этого решения.

адрес проекта:GitHub.com/Tencent/tar…

«PHP — лучший язык в мире»

Как мы все знаем, в начале рождения PHP это была разработка WEB-сайтов. Но долгое время не получалось избавиться от шляпы слабого типа, производительности скриптового языка. Поскольку интернет-индустрия продолжает развиваться, а потребности пользователей и инфраструктура продолжают меняться, сам язык PHP также развивался. Будь то появление SWOOLE или повышение производительности PHP7, оно обогатило и помогло применению самого PHP.

Я считаю, что каждый обнаружит в разработке, что PHP, который часто находится в среднем слое WEB, на самом деле имеет много болевых точек. Получение внешних HTTP-запросов и вызов различных серверных служб и служб хранения часто становится узким местом для сайта. Среди них чрезмерная избыточность протокола HTTP и потери, вызванные инкапсуляцией верхнего уровня, являются относительно серьезной проблемой.

Разработчикам приходится сталкиваться не только с падением пропускной способности, вызванным использованием библиотек синхронных вызовов HTTP, но и с неэффективностью самого протокола HTTP, а также протоколов JSON и XML при передаче информации. Для решения этой проблемы на уровне протокола TCP используется простой двоичный протокол. Только таким образом бизнес может использовать меньшую полосу пропускания и передавать больше контента, тем самым улучшая пропускную способность и возможности обслуживания веб-сервисов.

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

Кроме того, с точки зрения эффективности разработки исходная разработка всегда содержит много повторяющейся работы, которую необходимо выполнить. Потому что каждый раз, когда разрабатывается новый протокол, код сложно использовать повторно, а JSON и XML не позволяют делиться частью данных. В то же время вполне реальная проблема заключается в том, что поставщики различных HTTP-интерфейсов часто определяют интерфейсы в соответствии со своими настроениями и привычками.

Типичным примером является определение кодов возврата, некоторые люди называют его ret, некоторые называют его кодом, а некоторые называют его r, и это всеобъемлющее определение. Поэтому такая повторяющаяся и неинтересная развивающая работа ложится тяжелым физическим и психологическим бременем на развивающих учеников вызывающего абонента. В соответствии с этим требованием и сервер, и клиент могут автоматически генерировать вызывающий код в соответствии с протоколом и интерфейсом, и решение, обеспечивающее плавную совместную отладку, имеет важное значение.

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

Tars, превосходная RPC-инфраструктура Tencent, а также решение для развертывания и обслуживания сервисов, могут удовлетворить все вышеперечисленные требования. Внедрив полное решение Tars-PHP, разработчики могут использовать бинарный протокол Tars, который значительно сжимает трафик сервисных запросов. В то же время он также может использовать расширение PHP, анализируемое протоколом Tars, для повышения производительности упаковки и распаковки, тем самым улучшая возможности обработки задач одним процессом. В-третьих, инструменты, которые автоматически генерируют код, также могут повысить эффективность разработчиков.

Решение Tars-PHP

Решение с открытым исходным кодом Tars-PHP начинается с бинарного протокола:

бинарный протокол

Протокол HTTP, вероятно, является наиболее широко используемым протоколом на прикладном уровне. Существующие версии HTTP в основном 1.0 и 1.1. Он выполняет очень краткую инкапсуляцию протокола прикладного уровня на основе протокола TCP, содержимого обычного текста и различия между заголовком и телом. Все это делает использование и понимание этого протокола очень удобными. Но неизбежно простота использования и чтения означает избыточность информации, а для передачи небольшого количества контента зачастую требуется большой объем трафика.

Двумя другими широко известными протоколами являются JSON и XML. Эти два протокола используются при взаимодействии API. Они легко читаемы, просты для понимания, имеют многоязычную клиентскую поддержку и выдающиеся возможности выражения протокола. Преимущество оператора. Давайте сначала посмотрим на один и тот же фрагмент информации и объем данных, необходимых для обоих.

Предположим, есть школа, студент, если он идентифицирован в JSON, следующим образом:

{
    "school":
    {
        "student":{
            "name":"ted",
            "age":18,
            "degree":"master"
        }
    }
}

Очень простая структура, для описания требуется всего 65 символов. И если вы перейдете на XML:

<school>
        <student>
            <name>ted</name>
            <age>18</age>
            <degree>master</degree>
        </student>
</school>

Всего требуется 92 символа. С точки зрения информатики информационная энтропия явно слишком мала. Следовательно, для достижения более высокой производительности связи и использования меньшей полосы пропускания введение двоичного протокола является обязательным.

Как бинарный протокол, протокол Tars имеет очевидные преимущества по сравнению с двумя вышеупомянутыми протоколами. Найдите гибкость в JSON и XML выше, то есть не указывая тип поля. Но неизбежно такая гибкость приводит к большой потере производительности. Поэтому Tars определяет восемь основных типов данных, которые оптимизируются путем кодирования разных типов данных:

bool、byte、short、int、long、float、double 、string

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

В соответствии с приведенной выше структурой производительности можно выполнить несколько структур.
Во-первых, это студенческая структура:

struct student {
    0 required string name; // tag为0，type为string，实际数据为ted，共5个字节
    1 required byte age; // tag为1，type为short，实际数据为18, 共2个字节
    2 required string degree; // tag为2，type为string，实际数据为master，共7个字节
}

Как видно из комментариев, количество байтов, необходимых для трех полей, равно 14, плюс начало структуры и идентификатор конца структуры составляют 2 байта, а всего нужно всего 16 байт. Напротив, это только 1/4 JSON и 1/5 той же информации, идентифицированной протоколом XML, что является решением высокого уровня. представляет собой бинарный протокол с высокой информационной энтропией.

Чтобы PHP был полностью интегрирован с Tars, он должен иметь возможность действовать как клиент и как сервер.

Tars-PHP клиент

Как клиент, он должен быть в состоянии удовлетворить потребности быстрой разработки, а также должен быть в состоянии сочетаться с существующим общим использованием PHP и в то же время давать примеры удаленных вызовов. Исходя из этих требований, в клиентском решении реализованы следующие возможности:

  • Реализовано расширение PHP и соответствующие тест-кейсы для упаковки, распаковки, кодирования и декодирования по протоколу TUP;
  • Реализован инструмент tars2php для создания соответствующих файлов классов PHP из файлов протокола Tars;
  • Реализована вторичная инкапсуляция, включая сетевую библиотеку и пример кода удаленного вызова;

Как самый основной шаг реализации клиента, это поддержка протокола TUP. Протокол TUP — это верхний уровень протокола Tars, который инкапсулирует некоторую информацию, необходимую для отправки и получения пакетов через фиксированную структуру данных, такую ​​как возвращаемые значения, входные и выходные параметры, статус самого пакета и количество пакетов. и т. д., для клиентов, отличных от Tars, и для серверов Tars.Протокол для связи. Tars-PHP использует расширение PHP в качестве метода реализации в схеме, поддерживающей протокол TUP.

Сам язык PHP больше всего критикуют за его неэффективность в операциях, интенсивно использующих ЦП. Из-за не очень эффективной виртуальной машины ZEND, свободных структур данных и слабой типизации неэффективно упаковывать и распаковывать задачи, интенсивно использующие ЦП. Таким образом, появилось расширение PHP. Внедрив высокопроизводительные библиотеки классов C/C++ и некоторые собственные реализации C/C++, PHP догнал процесс обработки производительности. Это первоначальное намерение реализовать основную логику упаковки и распаковки расширенным образом.

Давайте сначала посмотрим на структуру языка PHP5x:

Серверный API самого низкого уровня используется PHP для связи с веб-сервером, который в основном используется в сочетании с APACHE. Слой PHPCORE в верхнем левом углу обеспечивает самые основные возможности работы с файлами и сетью. ZEND в правом верхнем углу — это инструмент, используемый для компиляции языка сценариев PHP в машинный код. Верхний уровень – это уровень расширений. Этот уровень будет в полной мере использовать API ZEND и возможности PHPCORE для непосредственного написания кода, который ZEND сможет эффективно выполнять и понимать, устраняя необходимость в процессе компиляции скриптов PHP в машинный код, что значительно улучшает выполнение. производительность эффективность

Если вы хотите спроектировать это расширение, вы должны выразить приведенную выше структуру данных Tars на языке C и спроектировать кодировщик и декодер на основе этой структуры данных. Еще один аспект, который необходимо учитывать, заключается в том, что он должен быть максимально простым и легким в использовании на уровне PHP, что представляет собой относительно сложную задачу для разработки расширений. С одной стороны, нужно учитывать производительность, с другой стороны, Struct в протоколе Tars должен быть выражен как класс в PHP:

Как видно из рисунка, структура SimpleStruct разбивается на три части:

  • Раздел тегов
  • раздел переменных-членов
  • поля, описываемые переменной

Часть TAG имеет решающее значение, эта часть используется для представления значения TAG каждого элемента в структуре. Это также окончательный контент, содержащийся в двоичном пакете, когда фактически выполняется кодирование и декодирование TUP. Зачем ТАГ? Это связано с тем, что сам TAG экономит место по сравнению с описанием текстовой природы поля в JSON.

Вторая часть — это переменные-члены класса, которые последовательно соответствуют переменным в протоколе Struct of the Tars. Это существует, чтобы нести фактическое значение соответствующей переменной. Таким образом, реальные данные могут быть упакованы и распакованы.

Чтобы построить мост между TAG и переменными, есть третья часть: часть Fields. Эта часть представляет собой карту TAG и соответствующего атрибута переменной. Содержит имя переменной, требуется ли переменная и тип переменной. Через эту информацию, с одной стороны, реализуется бинарное кодирование протокола Tars, а также реализуется отображение при декодировании. Можно сказать, убить двух зайцев одним выстрелом.

Затем, после разработки и реализации сложного расширения, необходимо сравнить производительность упаковки и распаковки реализации расширения с производительностью упаковки и распаковки собственной реализации PHP. Из таблицы ниже совершенно очевидно, что расширенная реализация имеет абсолютное преимущество в производительности:

путь/100 раз сложность смол Время упаковки (мс) Время упаковки несколько Время распаковки (мс) Множитель времени распаковки
расширять Простой 0.69 1 1.18 1
родной php Простой 11.25 16 16.28 13
расширять сложный 1.17 1 1.55 1
родной php сложный 14.5 12 15.1 10

Из этой таблицы ясно видно, что, будь то простой протокол Tars или сложный протокол Tars, использование расширений для упаковки и распаковки лучше, чем собственный PHP.В десять раз лучше производительностьвыше. Когда встречается сложная бизнес-логика и необходимо вызвать большое количество фоновых служб, использующих протокол Tars, это повышение эффективности увеличит пропускную способность службы на порядок.

После завершения расширенной компиляции разработчики могут легко использовать протокол TUP для упаковки, распаковки, кодирования и декодирования.

// 针对基本类型的打包和解包的方法,输出二进制buf
$buf = \TASAPI::put*($name, $value);
$value = \TUPAPI::get*($name, $buf);

// 针对Struct,传输对象,返回结果的时候,以数组的方式返回,其元素与类的成员变量一一对应
$buf = \TUPAPI::putStruct($name, $clazz);
$result = \TUPAPI::getStruct($name, $clazz, $buf);

// 针对Vector,传入完成pushBack的Vector
$buf = \TUPAPI::putVector($name, TARS_Vector $clazz);
$value = \TUPAPI::getVector($name, TARS_Vector $clazz, $buf);

// 针对Map,传入完成pushBack的Map
$buf = \TUPAPI::putMap($name, TARS_Map $clazz);
$value = \TUPAPI::getMap($name, TARS_Map $clazz, $buf);

// 需要将上述打好包的数据放在一起用来编码
$inbuf_arr[$name] = $buf;
// 进行tup协议的编码,返回结果可以用来传输、持久化
$reqBuffer = \TUPAPI::encode(
                         $iVersion=3,
                         $iRequestId,
                         $servantName,
                         $funcName,
                         $cPacketType=0,
                         $iMessageType=0,
                         $iTimeout,
                         $context=[],
                         $statuses=[],
                         $inbuf_arr);
// 进行tup协议的解码
$ret = \TUPAPI::decode($respBuffer);
$code = $ret['code'];
$msg = $ret['msg'];
$buf = $ret['sBuffer'];

Для того, чтобы облегчить разработчикам расширение проблем, часто встречающихся в невозможности найти определенные функции и параметры, также предоставляется tars-ide-helper:

Взяв PHPSTORM в качестве примера, вам нужно только импортировать его в соответствующий путь INCLUDE, чтобы добиться автоматического запроса:

Помимо возможности упаковки и распаковки, Tars-PHP также предоставляет возможность отправки и получения по сети.Сетевой трансивер в основном реализует следующие моменты:

  • Файл TarsAssistant.php: загружается через COMPOSER, а нижний уровень имеет встроенный собственный сетевой уровень SOCKET для отправки и получения пакетов;
  • Автоматически генерировать класс PHP в соответствии с интерфейсом и легко интегрироваться с TarsAssistant.
  • Обеспечить отказоустойчивую обработку, такую ​​как Exception;

После завершения автоматической генерации кода пользователь может легко вызвать удаленную службу Tars с помощью следующего кода:

    require_once "./vendor/autoload.php";

    $ip = "";// taf服务ip
    $port = 0;// taf服务端口
    $servant = new App\Server\Servant\servant($ip,$port);

    $in1 = "test";
    $ss1 = new SimpleStruct();
    $ss1->id = 1;
    $ss1->count = 2;
    $ss1->page = 3;

    try {
        $intVal = $servant->singleParam($in1,$ss1,$out1);
    }
    catch(phptars\TarsException $e) {
        // 错误处理
    }

Тарс-PHP сервер

В дополнение к возможностям Tars-PHP в качестве клиента важны также возможности сервера. Чтобы удовлетворить потребности различных бизнес-сценариев, Tars-PHP в основном фокусируется на двух типах сервисов на стороне сервера.

Первый тип — это HTTP-сервис, который будет использовать SWOOLE2.0 в качестве основы для сетевой передачи и приема для реализации высокопроизводительной, простой и удобной в использовании инфраструктуры, ориентированной на веб-сервисы. Эта структура будет поддерживать общие функции веб-инфраструктуры, такие как базовая маршрутизация, промежуточное программное обеспечение и архитектура MVC. В то же время он также будет интегрировать общие клиенты, такие как Redis, Mysql, Http, Multicall, Tars и т. д., чтобы облегчить веб-сервису вызов фонового сервиса. Что еще более важно, доступ к платформе Tars позволяет отслеживать и перезапускать сервисы, пользуясь универсальным удобством, предоставляемым платформой эксплуатации и обслуживания Tars. В настоящее время первая версия фреймворка реализована и используется в China Literature Group.После того, как тест будет завершен, он будет со временем открыт.

Вторая категория — это служба TCP, которая также опирается на SWOOLE2.0 на нижнем уровне, но протокол изменен с HTTP на поддержку TUP и Tars. С точки зрения реализации фреймворка он будет совместим с серверной частью JAVA и C++, а нижний уровень интегрирует сетевые возможности.Пользователям нужно заботиться только об имени службы, параметрах интерфейса и собственной логике бизнес-процессов. Конечно, этот сервис также должен сочетаться с платформой эксплуатации и обслуживания Tars. На данный момент завершена первая версия поддержки фреймворком протокола TUP, и она будет использоваться и проверяться в бизнесе после завершения базовой поддержки протокола Tars.

бизнес практика

China Literature Group использовала решение Tars-PHP в процессе управления и преобразования фоновых услуг. С одной стороны, все интерфейсы фоновых и фоновых веб-служб переключаются с исходного интерфейса HTTP на сетевую передачу TCP на основе протокола Tars. Благодаря автоматической генерации кода Tars-PHP значительно повышается эффективность разработки, что обеспечивает плавный и своевременный запуск проекта. В то же время это решение, основанное на расширении PHP, также обеспечивает эффективную эффективность выполнения кода, а время обработки одного запроса значительно сокращается по сравнению с исходным вызовом интерфейса HTTP.

С другой стороны, поскольку используемая фоновая веб-служба находится в памяти, она реализована на основе SWOOLE. Поэтому он отличается от Apache и PHP-FPM, присущих исходному PHP, в плане публикации, запуска, мониторинга и т.д. Поэтому, как упоминалось выше, подключение сервиса к платформе Tars и использование ряда функций, таких как мониторинг, поддержание активности и ведение журнала, значительно улучшит удобство эксплуатации, обслуживания и расширения самого сервиса. На сегодняшний день в его онлайн-сервисах врубились и стабильно работают HTTP-сервисы, подключенные к платформе Tars, более десяти сервисов. Выпуск, расширение, эксплуатация и обслуживание этих сервисов полностью зависят от платформы Tars, что очень удобно.

В дополнение к эксплуатации и обслуживанию платформы Tars, существует также набор решений для обнаружения сервисов на серверной стороне Reading WEB.

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

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

Более общее решение — это единый центр конфигурации, предоставляющий услуги: каждый раз, когда необходимо вызвать фоновую службу, последний адрес службы вытягивается из центра конфигурации по уникальному идентификатору. Таким образом, с одной стороны, он может не воспринимать бизнес при сокращении и расширении. как компьютерный зал или ближайший набор SET и т.д. Локальная служба должна обеспечивать только две возможности: первая — вызывать службу периодической адресации и сохранять ее в локальном хранилище для обеспечения скорости адресации. Во-вторых, иметь возможность получать команды из центра конфигурации для обновления адреса конкретной службы. Если эти два пункта могут быть достигнуты, то может быть достигнута эффективная адресация и надежная адресация.

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

Эпилог

С точки зрения эффективности разработки, использование Tars-PHP избавляет от чрезмерно избыточного бизнес-кода и улучшает автоматизацию разработки кода за счет автоматической генерации.

Что касается производительности, решение Tars-PHP значительно улучшило производительность за счет внедрения расширений, так что производительность больше не является «смертью» PHP.

С точки зрения простоты использования, предоставляя компонент сетевого приемопередатчика TarsAssistant, пакет приемопередатчика не нужно реализовывать отдельно. Позже будет представлен более производительный Swoole в качестве мощного инструмента для приемопередатчиков сокетов для дальнейшего повышения производительности сети.

В будущем решение Tars-PHP на стороне СЕРВЕРА также будет открыто как можно скорее, чтобы обеспечить полное решение, включая клиент и сервер. Этот полный набор фоновой веб-системы разработки Tars-PHP действительно может обеспечить высокую производительность, высокую эффективность и высокую доступность. А China Literature Group продолжит сотрудничество и практику с Tencent по техническим решениям Tars-PHP. Разработчики могут попробовать!

Категории