Линь Фань, старший инженер отдела эффективности исследований и разработок Alibaba
Надлежащая практика отправки кода и надлежащая проверка перед изменением могут помочь уменьшить количество сбоев, но не могут полностью устранить риск. Хотя добавление нескольких копий тестовой среды может эффективно контролировать масштаб воздействия сбоев, большинство предприятий имеют ограниченные ресурсы, что приводит к конфликту между снижением затрат на тестовую среду и повышением стабильности тестовой среды.
Чтобы решить эту проблему, инновационная группа по исследованиям и разработкам Alibaba разработала потрясающую технологию виртуализации многократного использования на уровне обслуживания, называемую средой функций. В этой статье мы сосредоточимся на управлении тестовой средой и рассмотрим этот уникальный метод, используемый в Alibaba.
Предисловие
Многие практики в Alibaba кажутся простыми, но на самом деле они основаны на многих хорошо продуманных концепциях, таких как управление тестовой средой.
Сервисы интернет-продуктов обычно состоят из веб-приложений, промежуточного программного обеспечения, баз данных и множества бизнес-программ вспомогательного офиса. Среда выполнения - это небольшая автономная экосистема. Самая простая среда выполнения - это онлайн-среда, в которой развертывается официально выпущенная версия продукта для предоставления пользователям непрерывных и надежных услуг.
Кроме того, многие среды выполнения, которые не открыты для внешних пользователей, также доступны и используются для рутинной разработки и проверки продуктовых групп. Эти среды вместе называются тестовыми средами. Стабильность формальной среды, помимо качества самого программного обеспечения, в основном связана с работающими инфраструктурами, такими как хост и сеть, в то время как стабильность тестовой среды в большей степени зависит от человеческого фактора. Сбои в тестовой среде часто возникают из-за частой смены версий и развертывания непроверенного кода.
Хорошая привычка к отправке кода и соответствующая проверка перед изменением могут помочь уменьшить возникновение ошибок, но не могут полностью их устранить. Увеличение числа реплик тестовой среды может эффективно контролировать масштаб воздействия сбоев. Однако ресурсы предприятия ограничены, поэтому снижение стоимости и повышение стабильности тестовой среды стали двумя задачами, которые необходимо сбалансировать.
В этой области гениальная группа исследований и разработок Alibaba разработала технологию виртуализации многократного использования на уровне обслуживания, названную «Среды функций», идея которой остроумна и впечатляет. Эта статья посвящена теме управления тестовой средой, чтобы обсудить этот способ работы с характеристиками Alibaba.
Трудности в управлении тестовой средой
Широко используются тестовые среды. Общие тестовые среды, такие как среда тестирования системной интеграции, среда тестирования пользовательской приемки, среда предварительного тестирования и среда поэтапного тестирования, отражают жизненный цикл поставки продукта и, косвенно, организационную структуру всей команды.
Средой тестирования для небольшой продуктовой группы в стиле мастерской очень легко управлять. Каждый инженер может локально запустить полный набор программных компонентов для отладки. Если вы все еще думаете, что это небезопасно, достаточно добавить общедоступную интегрированную тестовую среду.
По мере масштабирования продукта запускать все сервисные компоненты на месте становится трудоемким и громоздким. Инженеры могут запускать только некоторые компоненты для локальной отладки, а затем использовать остальные компоненты в общедоступной тестовой среде для формирования полной системы.
Более того, с увеличением размера команды, обязанности каждого члена команды еще больше подразделяются, и формируются новые подгруппы, что означает, что затраты на коммуникацию проекта возрастают, а стабильность общедоступной тестовой среды становится трудно контролировать. В этом процессе влияние сложности управления тестовой средой не только отражается в громоздкой совместной отладке сервисов, но также напрямую отражается в изменениях в процессе доставки и стоимости ресурсов.
Существенным изменением в процессе доставки является увеличение разнообразия тестовых сред. Инженеры разработали различные специализированные тестовые среды для разных целей. Комбинация этих тестовых сред формирует уникальный процесс доставки для каждого предприятия. На следующем рисунке показан сложный процесс доставки для крупных проектов.
С точки зрения отдельных сервисов, среды связаны конвейерами в сочетании с уровнями автоматизированного тестирования или операций ручного утверждения для реализации передачи между средами. Как правило, чем выше уровень среды, тем ниже частота развертывания и, следовательно, выше относительная стабильность. Напротив, в среде низкого уровня новые развертывания могут произойти в любое время, прерывая работу других, использующих среду. Иногда, чтобы воспроизвести некоторые особые сценарии проблем, некоторые разработчики должны входить на сервер напрямую для выполнения операций, что еще больше влияет на стабильность и доступность среды.
Столкнувшись с тестовой средой, которая может рухнуть в любой момент, малые предприятия пытаются применить метод «блокировки», то есть ограничить время смены услуги и установить строгие спецификации изменений, в то время как крупные предприятия хорошо умеют «расцеплять», что то есть, чтобы увеличить количество реплик тестовой среды, чтобы изолировать диапазон воздействия ошибок. Очевидно, что если будет принят метод «блокировки», ситуация в перегруженной тестовой среде обязательно будет становиться все хуже и хуже, что является истиной, которая давно раскрыта в «Легенде о царе Ю, приручившем Потоп тысячу лет назад». Итак, преднамеренный контроль не может спасти хрупкую тестовую среду.
В последние годы рост культуры DevOps полностью освободил руки разработчиков, но это палка о двух концах для управления тестовой средой. С одной стороны, DevOps побуждает разработчиков участвовать в O&M, чтобы понять полный жизненный цикл продукта, что помогает сократить ненужные инциденты O&M. С другой стороны, DevOps позволяет большему количеству людей получить доступ к тестовой среде, поэтому появляется больше изменений и исправлений. С глобальной точки зрения, у этих методов больше преимуществ, чем недостатков, но они не могут улучшить стабильность тестовой среды. Простой процесс «разблокировки» также не может спасти хрупкую тестовую среду.
Затем то, что нужно вложить, нужно вложить. Среды низкоуровневого тестирования, используемые разными командами, делаются независимыми, так что каждая команда видит линейный конвейер, а форма конвергенции реки проявляется при рассмотрении в целом.
Поэтому в идеале каждый разработчик должен получить эксклюзивную и стабильную тестовую среду и выполнять свою работу без помех. Однако из-за затрат на самом деле в группе могут использоваться только ограниченные ресурсы тестирования, и вмешательство между различными участниками в тестовой среде становится скрытой опасностью, влияющей на качество разработки программного обеспечения. Увеличение количества реплик тестовой среды - это, по сути, способ увеличения стоимости в обмен на эффективность. Однако многие исследователи, пытающиеся найти оптимальный баланс между стоимостью и эффективностью, похоже, идут все дальше и дальше по тому же пути без возврата.
Из-за объективного масштаба и объема продуктовые группы Alibaba также подвержены упомянутым выше проблемам управления тестовой средой.
Задача первая: управление типами тестовой среды
В Alibaba также есть много типов тестовых сред. Именование различных тестовых сред тесно связано с их функциями. Хотя некоторые имена обычно используются в отрасли, авторитетного стандарта именования сформировано не было. По сути, название среды - это всего лишь форма. Ключ заключается в том, что различные тестовые среды должны быть соответственно адаптированы к конкретным сценариям приложений, и между сценариями должны существовать более или менее различия.
Некоторые различия заключаются в типах выполняемых служб. Например, в среде тестирования производительности может потребоваться запускать только наиболее посещаемые ключевые службы, связанные со стресс-тестированием, в то время как это только пустая трата ресурсов, если она запускает другие службы. Некоторые различия заключаются в источнике данных доступа. Например, источник данных в тестовой среде разработчика определенно отличается от источника данных в формальной среде, поэтому фальшивые данные, используемые в тесте, не загрязняют запросы онлайн-пользователей. Предварительная среда (или среда пользовательского приемочного тестирования) использует источник данных (или копии формальных источников данных), согласованный с формальной средой, чтобы отразить работу новых функций с реальными данными. Среда, связанная с автоматическим тестированием, имеет отдельный набор тестовых баз данных, чтобы избежать вмешательства в другие ручные операции во время тестирования.
Некоторые другие различия заключаются в пользователях. Например, как поэтапная среда, так и среда предварительного выпуска используют формальные источники данных, но пользователи в поэтапной среде представляют собой небольшое количество реальных внешних пользователей, в то время как все пользователи в среде предварительного выпуска являются внутренним персоналом. Короче говоря, нет необходимости создавать тестовую среду для тестового сценария без специфики бизнеса.
На уровне Группы у Alibaba относительно жесткие ограничения на форму конвейера. Объективно только передовые команды разработки знают, каким должен быть лучший процесс доставки для команды. Платформа разработки Alibaba стандартизирует только некоторые рекомендуемые шаблоны конвейера, на которых могут строить разработчики. Ниже приведены несколько типичных примеров шаблонов:
Здесь появляется несколько имен типов среды, которые менее распространены во внешнем мире и будут подробно описаны позже.
Вторая задача: управление затратами на тестовую среду
Проблемы управления затратами сложны, и их стоит изучить. Затраты, связанные с тестовой средой, в основном включают «затраты на рабочую силу», необходимые для управления средой, и «затраты на активы», необходимые для приобретения инфраструктуры. С помощью автоматизированных средств и инструментов самообслуживания можно эффективно снизить затраты на рабочую силу. Автоматизация - тоже большая тема. Желательно обсудить это в другой статье, поэтому мы пока не будем здесь углубляться.
Снижение затрат на приобретение активов зависит от совершенствования и прогресса технологии (без учета факторов изменения цен, вызванных крупномасштабными закупками), в то время как история развития инфраструктурных технологий включает две основные области: оборудование и программное обеспечение. Значительное снижение затрат, вызванное разработкой оборудования, обычно достигается за счет новых материалов, новых производственных процессов и новых идей проектирования оборудования. Однако в настоящее время существенное снижение затрат на инфраструктуру, связанное с разработкой программного обеспечения, в основном связано с прорывом в технологии виртуализации (то есть изоляции и мультиплексирования ресурсов).
Самая ранняя технология виртуализации - виртуальные машины. Еще в 1950-х годах IBM начала использовать этот метод виртуализации на аппаратном уровне для экспоненциального улучшения использования ресурсов. Различные изолированные среды на виртуальной машине работают под управлением полных операционных систем соответственно, поэтому изоляция высока, а универсальность высока. Однако это немного громоздко для сценария запуска бизнес-сервисов. После 2000 года проекты с открытым исходным кодом, такие как KVM и XEN, популяризировали виртуализацию на аппаратном уровне.
В то же время появилась еще одна облегченная технология виртуализации. Ранняя контейнерная технология, представленная OpenVZ и LXC, достигла виртуализации среды выполнения, построенной на ядре операционной системы, что снизило потребление ресурсов независимой операционной системы и обеспечило более высокое использование ресурсов за счет определенной изоляции.
Позже Docker с его концепцией инкапсуляции образов и однопроцессного контейнера продвинул эту технологию виртуализации на уровне ядра на высокий уровень, востребованный миллионами людей. Следуя темпам технического прогресса, Alibaba очень рано начала использовать виртуальные машины и контейнеры. Во время карнавала покупок в День холостяков в 2017 году доля контейнерных онлайн-сервисов достигла 100%. Однако следующая проблема заключается в том, можно ли использовать ресурсы инфраструктуры более эффективно.
Избавившись от накладных расходов, связанных с преобразованием аппаратных команд и операционными системами для виртуальных машин, между программами и обычными программами, работающими в контейнерах, существует только тонкий слой изоляции пространства имен ядра, что вообще не приводит к потере производительности во время выполнения. В результате виртуализация, похоже, достигла своего предела в этом направлении. Единственная возможность - отказаться от общих сценариев, сосредоточиться на конкретных сценариях управления тестовой средой и продолжить поиск достижений. Наконец, Alibaba нашла новое сокровище в этой области: виртуализацию уровня обслуживания.
Так называемая виртуализация уровня обслуживания по существу основана на управлении маршрутизацией сообщений для повторного использования некоторых служб в кластере. В случае виртуализации на уровне обслуживания многие кажущиеся большими автономными тестовыми средами фактически потребляют минимальные дополнительные ресурсы инфраструктуры. Следовательно, предоставление каждому разработчику выделенного кластера тестовой среды больше не является значительным преимуществом.
В частности, процесс доставки Alibaba включает два специальных типа тестовых сред: «общая базовая среда» и «функциональная среда», которые образуют метод использования тестовой среды с характеристиками Alibaba. Общая базовая среда - это полная среда выполнения службы, в которой обычно работает относительно стабильная версия службы. Некоторые группы используют низкоуровневую среду (называемую «повседневной средой»), в которой всегда развертывается последняя версия каждой службы в качестве общей базовой среды.
Среда функций - самая интересная часть этого метода. Это виртуальная среда. На первый взгляд, каждая функциональная среда представляет собой независимую и полную тестовую среду, состоящую из кластера сервисов. Фактически, помимо сервисов, которые некоторые текущие пользователи хотят протестировать, другие сервисы виртуализируются через систему маршрутизации и ориентированное на сообщения промежуточное программное обеспечение, указывая на соответствующие сервисы в общей базовой среде. В общем процессе разработки в Alibaba задачи разработки должны проходить через функциональные ветки, релизные ветки и множество связанных ссылок, чтобы быть наконец выпущенными и запущенными. Большинство сред развертывается из ветки выпуска, но такие виртуальные среды для самостоятельного использования для разработчиков развертываются из версии ветки функций кода. Поэтому ее можно назвать «средой функций» (в Alibaba она называется «средой проекта»).
Например, полное развертывание системы транзакций состоит из более чем дюжины небольших систем, включая службу аутентификации, службу транзакций, службу заказов и службу расчетов, а также соответствующие базы данных, кэш-пулы и ориентированные на сообщения промежуточное ПО. Тогда его общая базовая среда по сути представляет собой полную среду со всеми службами и периферийными компонентами. Предположим, что в это время работают две функциональные среды. Один только запускает службу транзакций, а другой запускает службу транзакций, службу заказов и службу расчетов. Для пользователей в первой функциональной среде, хотя все службы, кроме службы транзакций, фактически проксируются общей базовой средой, кажется, что служба транзакций владеет полным набором сред во время использования: вы можете свободно развернуть и обновить версию службы транзакций в среду и отлаживайте ее, не беспокоясь о влиянии на других пользователей. Для пользователей второй функциональной среды три службы, развернутые в среде, могут совместно отлаживаться и проверяться. Если в сценарии используется служба проверки подлинности, отвечает служба проверки подлинности в общей базовой среде.
Разве это не похоже на адрес маршрутизации, соответствующий динамически изменяемому доменному имени, или на адрес доставки, соответствующий теме сообщения? На самом деле, это не так просто, потому что маршрут общей базовой среды не может быть изменен для определенной среды функций. Следовательно, традиционный механизм маршрутизации может реализовать только одностороннее целевое управление, то есть служба в среде функций может активно инициировать вызов, чтобы гарантировать правильную маршрутизацию. Если инициатор запроса находится в общей базовой среде, невозможно узнать, в какую среду функций отправить запрос. Для HTTP-запросов даже трудно обрабатывать обратные вызовы. При обратном вызове службы в общей базовой среде разрешение доменного имени нацелено на службу с тем же именем в общей базовой среде.
Как можно правильно маршрутизировать и доставлять данные в обоих направлениях? Вернемся к сути проблемы: среда, в которую должен входить запрос, имеет отношение к инициатору запроса. Следовательно, ключ к реализации двусторонней привязки заключается в идентификации среды функций, в которой находится инициатор запроса, и проведении контроля сквозной маршрутизации. Этот процесс чем-то похож на «поэтапное освобождение» и может быть решен с использованием аналогичного подхода.
Благодаря техническому опыту Alibaba в области промежуточного программного обеспечения и широкому использованию инструментов отслеживания, таких как EagleEye, легко идентифицировать инициаторов запросов и отслеживать обратные ссылки. Таким образом, управление маршрутизацией упрощается. При использовании среды функций пользователю необходимо «присоединиться» к среде. Эта операция связывает идентификацию пользователя (например, IP-адрес или идентификатор пользователя) с указанной средой функций. Каждый пользователь может одновременно принадлежать только к одной функциональной среде. Когда запрос данных проходит через промежуточное программное обеспечение маршрутизации (такое как очередь сообщений, шлюз сообщений и HTTP-шлюз), после определения того, что инициатор запроса в настоящее время находится в среде функций, запрос направляется службе в среде. . Если в среде нет той же службы, что и у цели, то запрос маршрутизируется или доставляется в общую базовую среду.
Среда функций не существует независимо. Он может быть построен на базе контейнерной технологии для большей гибкости. Подобно тому, как удобство приобретения инфраструктуры может быть получено путем создания контейнера на виртуальной машине, в среде функций быстрое и динамическое развертывание служб через контейнер означает, что пользователи могут добавлять в функцию службу, которую необходимо изменить или отладить. environment в любое время или уничтожить службу в среде в любое время, чтобы общая базовая среда могла автоматически заменить ее.
Еще одна проблема - отладка сервисного кластера.
В сочетании с тем, как работает функциональная ветвь AoneFlow, если разные сервисные ветки нескольких сервисов развертываются в одной и той же среде функций, совместная отладка нескольких функций в реальном времени может выполняться для использования среды функций для тестирования интеграции. Однако, несмотря на низкую стоимость создания среды функций, службы развертываются в тестовом кластере. Это означает, что каждый раз, когда вы изменяете код, вам нужно ждать, пока конвейер будет построен и развернут, что сэкономит накладные расходы на пространство, но не сократит накладные расходы времени.
Чтобы еще больше снизить затраты и повысить эффективность, члены команды Alibaba выступили с другой идеей: добавить локальные машины для разработки в среду функций. Внутри группы как машина разработки, так и тестовая среда используют IP-адрес интрасети, поэтому нетрудно напрямую направить запросы из конкретной тестовой среды на машину разработки с некоторыми изменениями. Это означает, что даже если пользователь в среде функций обращается к сервису, который фактически исходит из общей базовой среды, некоторые из сервисов на последующем канале обработки также могут поступать из среды функций или даже из локальной среды. Таким образом, отладка сервисов в кластере становится простой, не дожидаясь долгого ожидания построения конвейера, как если бы вся тестовая среда работала локально.
Самостоятельное построение среды функций
Считаете ли вы, что виртуализация на уровне обслуживания слишком нишевая и недоступная для обычных разработчиков? Это не тот случай. Вы можете сразу же самостоятельно создать функциональную среду, чтобы попробовать.
Среда функций Alibaba реализует виртуализацию на уровне обслуживания двусторонней маршрутизации, которая включает в себя различные общие методы взаимодействия служб, такие как HTTP-вызов, RPC-вызов, очередь сообщений и уведомление о сообщениях. Создание такой полнофункциональной тестовой среды может оказаться сложной задачей. С точки зрения общего назначения, вы можете начать с наиболее популярного протокола HTTP и создать простую функциональную среду, поддерживающую одностороннюю маршрутизацию.
Чтобы упростить управление средой, лучше всего иметь кластер, который может запускать контейнеры. В сообществе разработчиков ПО с открытым исходным кодом полнофункциональный Kubernetes - хороший выбор. Некоторые концепции, связанные с управлением маршрутизацией в Kubernetes, отображаются для пользователей как объекты ресурсов.
Вкратце, объект «Пространство имен» может изолировать домен маршрутизации службы, который не совпадает с пространством имен ядра, используемым для изоляции контейнера. Не путайте эти два. Объект Service используется для указания цели маршрутизации и имени службы. Объект Deployment соответствует фактически развернутой службе. Объект Service типа ClusterIP (типы NodePort и LoadBalancer, которые на данный момент игнорируются) может маршрутизировать реальную службу в том же пространстве имен, в то время как объект Service типа ExternalName может использоваться в качестве прокси-сервера маршрутизации внешней службы в текущем Пространство имен. Управление этими объектами ресурсов можно описать с помощью файлов в формате YAML. Узнав об этом, вы можете приступить к созданию среды функций.
Пропускается процесс построения инфраструктуры и кластера Kubernetes. Давайте сразу к делу. Во-первых, подготовьте среду общедоступной инфраструктуры для маршрутизации резервных копий, которая представляет собой полномасштабную тестовую среду и включает все службы и другую инфраструктуру в тестируемой системе. Внешний доступ на данный момент не рассматривается. Соответствующие объекты Service всех служб в общей базовой среде могут использовать тип ClusterIP и предполагать, что эти объекты соответствуют пространству имен с именем pub-base-env. Таким образом, Kubernetes автоматически назначает доменное имя «service name.svc.cluster» и глобальное доменное имя кластера «service name.pub-base-env.svc.cluster», доступное в пространстве имен, каждой службе в этой среде. С гарантией резервного копирования вы можете приступить к созданию функциональной среды. Простейшая среда функций может содержать только одну реальную службу (например, trade-service), а все остальные службы проксируются в среду общедоступной инфраструктуры с помощью объектов Service типа ExternalName. Предполагая, что среда использует пространство имен с именем feature-env-1, YAML которого описывается следующим образом (информация о неключевых полях опускается):
kind: Namespace
metadata:
name: feature-env-1
________________________________________
kind: Service
metadata:
name: trade-service
namespace: feature-env-1
spec:
type: ClusterIP
...
________________________________________
kind: Deployment
metadata:
name: trade-service
namespace: feature-env-1
spec:
...
________________________________________
kind: Service
metadata:
name: order-service
namespace: feature-env-1
spec:
type: ExternalName
externalName: order-service.pub-base-env.svc.cluster
...
________________________________________
kind: Service
...Обратите внимание, что к службе order-service можно получить доступ, используя локальное доменное имя order-service.svc.cluster в пространстве имен текущей среды функций, и запрос будет перенаправлен на глобальное доменное имя order-service.pub-base -env.svc.cluster, настроенный Службой, то есть он будет перенаправлен на службу с тем же именем в среде общедоступной инфраструктуры для обработки. Другие службы в пространстве имен не воспринимают эту разницу. Вместо этого они могут предположить, что все связанные службы развернуты в этом пространстве имен.
Если разработчик изменяет заказ-сервис во время разработки среды функций, измененная версия должна быть добавлена в среду. Все, что вам нужно сделать, это изменить свойство объекта Service для order-service с помощью операции исправления Kubernetes, изменить его на тип ClusterIP и создать объект Deployment в текущем пространстве имен, чтобы связать его с.
Измененный объект Service действителен только для служб в соответствующем пространстве имен (то есть соответствующей среде функций) и не может влиять на запросы, отозванные из среды общедоступной инфраструктуры, поэтому маршрут является односторонним. В этом случае среда функций должна содержать службу портала ссылки вызова, которую нужно протестировать, и службу, содержащую операцию обратного вызова. Например, тестируемая функция инициируется операцией интерфейса, а служба, обеспечивающая пользовательский интерфейс, является службой портала. Даже если служба не была изменена, ее основная версия должна быть развернута в среде функций.
С помощью этого механизма несложно реализовать функцию, частично заменяющую службу кластера на локальную службу для отладки и разработки. Если кластер и локальный хост оба находятся в интрасети, просто укажите объект Service типа ExternalName на локальный IP-адрес и порт службы. В противном случае вам необходимо добавить общедоступную сетевую маршрутизацию для локальной службы и реализовать эту функцию посредством динамического разрешения доменных имен.
В то же время Yunxiao постепенно улучшает решение среды функций на основе Kubernetes, которое обеспечит более полную поддержку изоляции маршрутизации. Стоит отметить, что из-за специфики общедоступного облака необходимо решить проблему, чтобы присоединить локальный хост к кластеру в облаке во время совместной отладки. Поэтому Yunxiao реализовал метод присоединения локального хоста LAN (без общедоступного IP-адреса) к кластеру Kubernetes в другой интрасети для совместной отладки с помощью возможности маршрутизации туннельной сети + kube-proxy. Технические подробности также будут объявлены в ближайшем будущем в официальной учетной записи Yunxiao WeChat, так что следите за обновлениями.
Резюме
Хотя многие люди все еще ждут появления следующей волны технологий виртуализации после виртуальных машин и контейнеров, Alibaba уже дала ответ. Менталитет предпринимателей заставляет людей в Alibaba понять, что им нужно экономить каждую копейку. На самом деле, инновации ограничивают не технологии, а воображение. Концепция виртуализации на уровне обслуживания выходит за рамки традиционного понимания реплик среды и решает проблему баланса между стоимостью и стабильностью тестовых сред с уникальной точки зрения.
Ценность среды функций как специального технического носителя заключается не только в облегчении управления тестовой средой, но и в обеспечении бесперебойной работы для каждого разработчика, которая на самом деле «минимальна, но не проста».
Опыт лучший учитель. Alibaba Yunxiao очень помогла с методологией сотрудничества по крупным продуктам. Промышленные задачи и технические проблемы, такие как гибкие и быстрые итерации продукта, огромные объемы размещенных данных, высокоэффективные инструменты тестирования, распределенная структура второго уровня и выпуск развертывания кластера большого объема, - это вклады, предлагаемые внутренними командами группы Alibaba, партнерами по экосистеме, и облачные разработчики. Мы искренне приветствуем коллег из всей отрасли для обсуждения и общения с нами.
