Демистификация ядра управления кодом Tencent — архитектура системы worker bee Git

Tencent рабочая пчела Git

code.tencent.com

введение:

Недавно в здании Tencent Building в Шэньчжэне прошел салон DevOps China 2018. Этот салон пригласил ряд гостей, чтобы поделиться своей практикой и опытом в области DevOps. На встрече Луо Ци, старший инженер Tencent и руководитель отдела системной архитектуры рабочей пчелы, поделился своим опытом «Демистификация ядра управления кодом Tencent: системная архитектура рабочей пчелы Git» и объяснил происхождение, развитие и будущее планирование рабочей пчелы Tencent.

1 рабочая пчела Tencent

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

2 Архитектура системы рабочих пчел

С 2012 года Git постепенно взрослел. Многие разработчики предпочитают Git из-за его функций, таких как децентрализация, быстрое получение веток и удобное использование, и использование Git постепенно становится популярным в Китае. В настоящее время Tencent также готовится к созданию системы размещения кода Git и планирует постепенно переключать исходный SVN на Git.

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

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

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

На блок-схеме архитектуры рабочей пчелы перечислены четыре метода сетевых запросов: SSH, HTTP, WEB и API. Auth используется для службы единой аутентификации, Router используется для службы маршрутизации адресации фрагментов данных, Manager используется для службы сборки фоновых данных, а последний является базовым кластером кода.

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

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

Базовый сервер кода справа на рисунке использует решение аварийного восстановления, состоящее из двух и трех центров.

3 Какие возможности предоставляет архитектура

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

4 Какие проблемы возникают в реальной эксплуатации?

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

5 Эволюция архитектуры системы рабочих пчел

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

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

Чтобы решить проблему медленной загрузки операций, вызванную большой емкостью проекта, мы представили решение Git-lfs с открытым исходным кодом. Из рисунка видно, что локальная библиотека пользователя имеет различные типы файлов, включая код, изображения, видео и др. При хранении этих файлов вне репозитория Git в репозитории Git сохраняются только текстовые указатели файлов. Этот метод может уменьшить размер самого репозитория Git, а также ускорить репозиторий клонов.

Ниже представлена блок-схема архитектуры развертывания LFS. Мы развертываем прокси LFS и выделенный сервер LFS. Когда пользователь выполняет операцию LFS, интеллектуальный протокол Git будет передавать текстовые указатели кода, изображений, видео и других файлов в репозиторий кода через HTTP-прокси, а затем передавать файловые ресурсы на прокси-сервер LFS. сначала найдите маршрут и выполните аутентификацию разрешения. , и, наконец, отправьте файловые ресурсы на сервер LFS. Кроме того, чтобы пользователи могли выполнять унифицированный контроль в фоновом режиме, мы также добавили фоновую настройку в прокси-сервер HTTP для перехвата одного файла и одной отправки, и после перехвата пользователь будет уведомлен о необходимости использования LFS для преобразования. .

Совместная разработка в разных местах Мы обнаружили, что медленный доступ к удаленным проектам происходит по такому сценарию: сотрудники одного отдела распределены по Шэньчжэню и Пекину, и всем им нужно использовать систему worker bee. У групп в Пекине есть независимые проекты, а у сотрудников в Шэньчжэне и Пекине есть общественные проекты. Когда в проекте появляются такие операции, как Clone и Push для больших библиотек, реакция системы будет очень медленной. Поскольку один и тот же отдел, в случае с публичными проектами, невозможно развернуть два совершенно разных окружения, как решить эту проблему?

Предположим, IDC1 — это Шэньчжэнь, а IDC2 — это Пекин. Нам нужно только добавить координатора IDC в полную систему в Шэньчжэне, а затем развернуть самый простой HTTP-прокси, маршрутизацию, селектор IDC и новый кластер серверов для чтения и записи в Пекине, чтобы решить вышеуказанные проблемы. Когда коллега в Пекине использует клиент для работы, запрос доступа будет назначен соответствующему месту с помощью селектора IDC, чтобы реализовать ближайший доступ. Что касается совместной разработки, поскольку системы Интернета и базы данных в Пекине и Шэньчжэне используют одну и ту же систему, данные взаимно видны, и коллеги могут проводить совместную разработку через публичный проект Fork.

Есть и другой сценарий удаленной совместной разработки. Например, коллегам в Пекине необходимо использовать систему сборки, используемую в Шэньчжэне, для сборки и выпуска версий. В этом сценарии один и тот же репозиторий необходимо использовать в разных сетях. Для реализации такого сценария построения вне площадки мы развертываем самый простой HTTP-прокси, маршрутизацию, селектор IDC и резервную машину в Пекине (резервная машина и основная машина размещены в одном кластере). Когда хост получает запрос на запись, координатор выдает задачи синхронизации резервным машинам с обеих сторон в соответствии с флагом IDC для достижения синхронизации данных, чтобы удовлетворить потребности удаленного построения.

6 улучшений способностей, вызванных эволюцией

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

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

Разделение вычислений и хранилища Поддержка сегментирования MySQL позволяет емкости данных и вызовам API также выполнять операции сегментирования, тем самым обеспечивая поддержку больших объемов данных.

Предоставляет функции Open API и OAuth для лучшей интеграции со сторонними приложениями.

7 Ожидания на будущее

В качестве системы размещения кода система worker bee является важным звеном в цепочке инструментов DevOps R&D. В настоящее время система worker bee реализовала стыковку с другими системами через веб-хуки, API и OAuth и совместно открыла весь процесс требований, размещения кода и построения. В будущем мы сосредоточимся больше на потребностях предприятий, позволим системе рабочих пчел открыть больше возможностей и более тесно интегрировать сервисы в DevOps и, наконец, сформируем замкнутый цикл цепочки инструментов НИОКР.

Отсканируйте QR-код, управление исследованиями и разработками теперь будет эффективным, легким и надежным.