14 сентября Baidu официально открыла исходный код своей RPC-инфраструктуры brpc на GitHub, основанной на протоколе Apache 2.0. brpc — это инфраструктура RPC, основанная на интерфейсе protobuf, который в Baidu называется «baidu-rpc». Он включает в себя все протоколы RPC внутри Baidu и поддерживает множество сторонних протоколов. лидирует в других аналогичных продуктах RPC.
brpc был разработан в 2014 г. Основные используемые языки — C++ и Java.Это наиболее широко используемый фреймворк RPC в Baidu.Он был проверен в производственной среде с высоким параллелизмом и высокой нагрузкой и поддерживает около 750 000 одновременных онлайн-экземпляров. внутри Байду. По данным InfoQ, у Baidu есть ряд RPC-фреймворков, и в 2014 году он даже открыл исходный код еще одного RPC-фреймворка диван-pbrpc. В какой среде родился brpc? Какие у него есть преимущества? Почему с открытым исходным кодом? По этим вопросам корреспонденты InfoQ взяли интервью у главы brpc Гэ Джуна.
Адрес GitHub: https://github.com/brpc/brpc
InfoQ: Расскажите об основах brpc? Когда он начал развиваться? Какие итерации и обновления вы прошли? Как он в настоящее время используется внутренне?
Гэ Джун: brpc был создан в 2014 году и известен в Baidu как «baidu-rpc». Всего на данный момент в brpc внесено около 3000 изменений, и он все еще оптимизируется, описание каждого изменения можно найти на вики в Baidu. Основными языками brpc являются C ++ и Java, а поддержка других языков осуществляется в основном за счет обертывания версии C ++ Например, версия brpc для Python содержит большинство функций версии C ++.
В настоящее время brpc поддерживает около 750 000 одновременных онлайн-инстансов (без учета клиентов) внутри Baidu и более 500 видов сервисов (в статистике прошлого года такие данные уже не учитываются). Hadoop, Table, Mola (другое широко используемое хранилище), высокопроизводительные вычисления, обучение моделей, многочисленные поисковые онлайн-сервисы — все используют brpc. brpc впервые объединяет коммуникационную структуру распределенных систем и бизнес-направлений внутри Baidu.
InfoQ: Почему Baidu разработала brpc в то время?
Гэ Джун: На практике мы поняли, что RPC, как самый базовый коммуникационный компонент, на тот момент уже не опережал Baidu. Мой тогдашний руководитель, Лю Ян, был инженером в Google, придавал большое значение строительству инфраструктуры и был готов вкладывать ресурсы в это направление.
Мы более подробно обсуждаем эти вопросы внутри компании. "Простота в использовании" иногда кажется очень субъективной, но на самом деле она основана на доказательствах. Его ключевой момент заключается в том, может ли он действительно повысить эффективность пользователей: необходимо учитывать разработку, отладку и обслуживание. Если эффективность пользователей действительно повышается Теперь, пользователи будут думать о вас, и вы не сможете завоевать сердца людей, хвастаясь или рекламируя что-то. Наше первоначальное намерение создать brpc состоит в том, чтобы решить практические проблемы, с которыми сталкивается бизнес Baidu, и в то же время мы также надеемся стать любимым инструментом студентов Baidu.Даже если мы покинем Baidu, нам будет не хватать brpc. Мы надеемся, что, предоставляя простую в использовании структуру, мы также покажем рабочий метод: как писать комментарии, как печатать журналы, как писать журнал изменений, как выпускать версии, как организовывать документы, и даже для студентов, которые в будущем их нет в Baidu. Помогите, поэтому brpc с самого начала использует открытый исходный код. На самом деле, у нас неплохо получается сарафанное радио, и вики brpc, вероятно, является одним из самых популярных материалов на Baidu.
InfoQ: Каковы преимущества brpc по сравнению с некоторыми другими средами RPC с открытым исходным кодом?
Гэ Джун: brpc фокусируется на глубине и простоте использования. С одной стороны, у нас нет сил размазывать пирог, как gRPC, и делать все подряд. С другой стороны, мы также заметили, что gRPC (включая более ранний Thrift) недостаточно глубок и прост в использовании. Технические аспекты таковы.Глядя на образец программы, документация очень классная, но это может быть другое дело в реальном бою.Одна скрытая причина, почему каждая компания должна создавать свои собственные колеса, заключается в том, что поверхностные вещи заключаются в некоторых деталях. , сделать вас невыносимым.
Каковы настоящие болевые точки RPC? Это надежность, простота использования и легкость обнаружения проблем. В сервисе не должно быть необъяснимого длинного хвоста, переменных элементов программы должно быть как можно меньше, а различные странные проблемы должны поддерживаться инструментами для быстрого устранения неполадок. И они не очень хорошо реализованы в текущей среде RPC с открытым исходным кодом.Большинство из них выглядят великолепно, но их нельзя продвигать в своих организациях. Возвращаясь к предыдущим трем пунктам, как это делает brpc?
надежность. Этот аспект связан с качеством кода, и, установив высокий порог найма для команды brpc, а также обстоятельные технические обсуждения внутри команды, мы обеспечили прочную кодовую базу. Другой проблемой является проблема длинного хвоста, которая является проблемой дизайна.На самом деле brpc содержит много модулей, среди которых bthread — библиотека потоков M:N, которая должна улучшить параллелизм и избежать блокировки. И чтение, и запись в brpc не требуют ожидания, что является высшей степенью параллелизма. Пожалуйста, нажмите на ссылку ниже для получения технических деталей. https://github.com/brpc/brpc/blob/master/docs/cn/bthread.md
https://github.com/brpc/brpc/blob/master/docs/cn/io.md
Простота использования. Существует дизайн, в котором все варианты выбора делаются как варианты и передаются пользователю, утверждая, что у него есть все функции, но как только возникает проблема, пользователь «настраивает ее неправильно». Более того, пользователи по-прежнему очень зависимы от команды разработчиков, и без поддержки команды разработчиков они в принципе бесполезны, а у команды разработчиков достаточно причин для расширения команды. На самом деле это очень безответственно, и пользователям сложно столкнуться с большим количеством вариантов. brpc очень осторожно относится к добавлению опций. Фреймворк может принимать собственные решения и никогда не отдавать их пользователю. Все пользовательские опции имеют наиболее разумные значения по умолчанию, и их можно использовать, даже если они не установлены. Мы считаем, что это очень важно для пользовательского опыта.
Легкость локализации проблем. В настоящее время другие фреймворки с открытым исходным кодом не очень хороши на этом этапе.Его можно использовать в обычном режиме, но это будет проблематично, если возникнут проблемы. Эта проблема на самом деле очень серьезна внутри Baidu. Перед brpc пользователи должны просить студентов RPC вместе исследовать проблемы. Фреймворк RPC — это черный ящик для пользователей, и пользователи понятия не имеют, что происходит внутри. По нашему опыту, практически каждый день несколько пользователей в группе задают такие вопросы, как зависание сервера и тайм-ауты клиента.Устранение неполадок является нормальным явлением, и должно быть недостаточно рабочей силы. Через долгое время пользователи почувствуют, что с вашим фреймворком есть различные проблемы, и люди не смогут их тащить и редко отвечают на их сообщения. Решение brpc заключается в добавлении к серверу встроенных сервисов различных HTTP-интерфейсов, с помощью которых пользователи могут быстро видеть задержку сервера, ошибки, соединения, отслеживать определенный RPC, точку доступа CPU, выделение памяти, конкуренцию блокировок и т. д. Пользователи также могут использовать bvar для настройки различной статистической информации и ее обобщения на платформе эксплуатации и обслуживания Baidu NOAH. Таким образом, пользователи могут решить большинство проблем самостоятельно. На самом деле мы тоже смотрим на эти, но это будет более профессионально. Подробное описание встроенной службы можно найти здесь: https://github.com/brpc/brpc/blob/master/docs/cn/builtin_service.md.
InfoQ: Что вы думаете об управлении службами, как о структуре RPC в компании?
Гэ Джун: широко используется внутренний RPC Baidu, в основном вызовы RPC, а некоторые линейки продуктов также изолируют инженерные структуры и коды политик через локальный RPC. С годами системы, окружающие сервис, стали более комплексными: BCLOUD используется для компиляции, Agile — для публикации, BNS — для регистрации и обнаружения сервисов, Giano — для сертификации, NOAH — для мониторинга и O&M. Внутри Baidu brpc тесно связан с этими системами, и пользовательский интерфейс является универсальным. Хотя в версии с открытым исходным кодом большинство этих комбинаций удалены, но пользователи могут настроить его в соответствии с инфраструктурой своей организации: протоколы взаимодействия, службы имен и алгоритмы балансировки нагрузки — все это можно настроить. Для некоторых из них, которые являются особенно общими, мы хотим, чтобы отзывы пользователей были включены в версию с открытым исходным кодом для общего удобства.
InfoQ: У Baidu уже был open-source диван-pbrpc, в чем разница между brpc и it?
Гэ Джун: диван-pbrpc также является ранним RPC-фреймворком, разработанным Baidu, который является частью каркаса программирования дивана и имеет приложения в поиске. По сравнению с диван-пбрпк, брпк имеет следующие преимущества:
Абстракция протокола является более общей и унифицирует коммуникационную архитектуру всей Baidu. bprc может поддерживать множество протоколов, основанных на Protobuf, основанных на HTTP, nshead/mcpack в Baidu, Redis/Memcached с открытым исходным кодом и даже протоколах прямой трансляции RTMP/FLV/HLS. brpc можно постепенно встраивать в существующие системы без необходимости. Полностью рефакторинг, но у дивана-pbrpc нет возможности расширять протокол. Точно так же диван-pbrpc не может настраивать алгоритм балансировки нагрузки. brpc по умолчанию предоставляет четыре алгоритма: циклический, случайный, согласованное хеширование и Locality-aware (осведомленность о местоположении), которые могут быть настроены пользователями.
Многопоточность более качественная. Многопоточное программирование очень сложно, кажется, что простые RPC полны многопоточных ловушек, например, код для обработки таймаутов может быть запущен до отправки RPC, обратный вызов для обработки ответа выполняется до функции отправки завершено; один ответ все еще обрабатывается, возвращается другой ответ и так далее. Кроме того, что происходит, когда синхронный RPC инициируется в обратном вызове асинхронного RPC, и что происходит, когда синхронный RPC выполняется с блокировкой. Мы не можем найти удовлетворительных ответов на эти вопросы в диване-pbrpc.
Полная отладка и поддержка эксплуатации и обслуживания. Суть решения этой проблемы заключается в масштабируемости.Как вы позволяете пользователям участвовать в настройке интересующих их индикаторов?По этой причине мы разработали bvar, чтобы пользователи могли свободно настраивать различные индикаторы таким образом, чтобы это было дешевле, чем атомарные переменные. Пользователи могут увидеть кривую изменения показателей в браузере или увидеть агрегированные данные мониторинга на платформе эксплуатации и обслуживания NOAH. brpc также добавляет большое количество встроенных сервисов, облегчающих пользователям отладку программ, просмотр подключений, изменение gflags в режиме онлайн, отслеживание RPC, анализ горячих точек ЦП, выделение памяти, блокировку конкуренции и т. д.
Излишне говорить, что у brpc и диван-pbrpc были конкурентные отношения с диваном-pbrpc в Baidu в начале, но, как и в других местах, эта конкуренция придала жизненную силу. Точно так же brpc и другие среды RPC с открытым исходным кодом также находятся в здоровой конкуренции, добиваясь прогресса в процессе конкуренции за то, кто действительно может повысить эффективность работы пользователей. Каждый пользователь может сравнить код, качество документа, дизайн интерфейса, простоту использования, масштабируемость и т. д. и отдать свой голос.
InfoQ: Расскажите об общей архитектуре brpc?
Гэ Джун: Стек технологий — это не что иное, как от уровня передачи к уровню приложений, поэтому я не буду о нем говорить, за подробностями вы можете обратиться к документам с открытым исходным кодом. Архитектура brpc делает упор на «повышение масштабируемости без ущерба для простоты использования». Например, brpc поддерживает множество протоколов. В Baidu сервер и порт brpc могут поддерживать более 20 протоколов, что очень важно для бесперебойной работы сервисов. Миграция очень полезна.
На стороне клиента также много протоколов.Пользователи очень хорошо используют brpc и bthread, поэтому я надеюсь, что мы сможем унифицировать всех клиентов.Например, клиентская поддержка Redis и Memcached также сделана в этом контексте.Эти два клиента Терминал гораздо проще в использовании, чем официальный клиент, и заинтересованные читатели могут его опробовать. Но настройка очень многих протоколов очень проста, просто введите строку.Например, HTTP означает установку ChannelOptions.protocol на «http», а Redis означает «redis». Серверную часть даже не нужно ставить, она автоматически определит протокол каждого клиента, а как это сделать тоже есть в открытом доступе, подробнее по этой ссылке:
https://github.com/brpc/brpc/blob/master/docs/cn/new_protocol.md
Также можно настроить службы имен и балансировку нагрузки. Однако, чтобы быть ответственными перед пользователями, мы не поощряем «слишком свободную» настройку, например, если небольшое изменение спроса требует нового, тем более необходимо выяснить, в чем заключается существенное отличие. Мы делаем это каждый день в нашей группе поддержки внутри Baidu.Мы являемся открытой «партией Б», но мы также являемся строгой «партией Б».
InfoQ: Какова производительность brpc? Как достигается такая высокая производительность?
Гэ Джун: Производительность — это то, что нам очень нравится, и это также тесно связано с пользовательским опытом. Простой в использовании, но не с хорошей производительностью, или плохой в использовании, но с хорошей производительностью, пользователи будут чувствовать себя очень неудобно, мы не хотим, чтобы пользователи были запутаны. С другой точки зрения, на что следует полагаться на ранней стадии продвижения, чтобы убедить линейку продуктов использовать brpc? Наиболее интуитивно понятным является улучшение производительности. И производительность здесь не может оставаться на картинке бенчмарка, а может отражаться в реальном приложении. Документы открытого дела более или менее содержат улучшения производительности, а именно:
Запись API карты Baidu:
https://github.com/brpc/brpc/blob/master/docs/cn/case_apicontrol.md
DSP Альянса:
https://github.com/brpc/brpc/blob/master/docs/cn/case_baidu_dsp.md
Система обучения ELF:
https://github.com/brpc/brpc/blob/master/docs/cn/case_elf.md
Прокси-сервис облачной платформы:
https://github.com/brpc/brpc/blob/master/docs/cn/case_ubrpc.md
Сравнение производительности с другими фреймворками RPC (включая thrift, gRPC) можно увидеть:
https://github.com/brpc/brpc/blob/master/docs/cn/benchmark.md
Схема производительности описана в документации с открытым исходным кодом, а в документации в разделе «RPC в деталях» рассказывается более подробно. Я не буду вдаваться в подробности здесь, пожалуйста, прочитайте документацию напрямую:
https://github.com/brpc/brpc#better-latency-and-throughput
InfoQ: Почему brpc с открытым исходным кодом? Есть ли планы на следующую итерацию проекта с открытым исходным кодом?
Введение гостяГэ Джун: потому что все еще есть много систем Baidu, исходный код которых зависит от RPC. Как самый основной компонент RPC, открытый исходный код предназначен не только для себя, но и для того, чтобы проложить путь для других проектов с открытым исходным кодом.Например, мы скоро откроем исходный код библиотеки RAFT на основе BRPC, что очень удобно для создания высокодоступная распределенная система; потоковые вычисления стали проще. С годами понимание Baidu об открытом исходном коде также углубилось.Похоже, что открытый исходный код раскрывает основную технологию Baidu, но экологическое влияние, которое оно оказывает, важнее. Начиная с Apollo и PaddlePaddle, Baidu действительно использует открытый исходный код. Версия brpc с открытым исходным кодом очень близка к внутренней версии, за исключением того, что поддержка некоторой уникальной инфраструктуры внутри Baidu была удалена.Углубленный анализ технических деталей RPC документов, которые мы написали во внутренней сети, также находятся в открытом доступе. , и будет перенесено в будущем. Изменения, пожалуйста, будьте уверены. Это живой проект, и не имеет значения, если вы не потянете ветку с открытым исходным кодом.
Гэ Джун, главный архитектор Baidu, главный автор brpc, имеет большой опыт в системном программировании, структурах данных, проектировании и реализации крупномасштабных распределенных систем.
Крайне важные рекомендации по совещаниюКак сказал Гэ Цзюнь, в 2017 году Baidu серьезно примет открытый исходный код, и многие ключевые технологии начнут распространяться извне. управление рисками, которое объясняет основное применение анализа ассоциаций графов в интеллектуальном анализе данных и управлении рисками.
Конференция также организовала в общей сложности более 100 сеансов обмена техническими данными по таким темам, как производительность программного обеспечения и инфраструктурные технологии. Для получения более подробной информации, пожалуйста, нажмите "читать оригинал«К пониманию!
Сегодняшняя рекомендация
Нажмите на изображение ниже, чтобы прочитать
Как программисты должны справляться с неудачами на рабочем месте?