Серия бессерверных интерфейсов обучения — практика миграции веб-приложений

внешний интерфейс Serverless

Автор статьи: IMWeb Команда IMWeb Источник исходного текста:Сообщество IMWebВоспроизведение запрещено без согласия

Введение: Говоря о самой современной технологии, в дополнение к новейшей блочной цепочке, AI, есть еще одна концепция, о которой следует упомянуть, — это Serverless. Как новый тип интернет-архитектуры, бессерверная архитектура прямо или косвенно способствует развитию облачных вычислений.От AWS Lambda до запуска бессерверных сервисных платформ различными производителями бессерверная технология поет на протяжении всего пути. В этой фурме передок вроде что-то делает?

содержание:

1. Введение в бессерверные технологии

2. Облегченная практика миграции веб-приложений

1. Введение в бессерверные технологии

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

Развитие облачных вычислений идет от IaaS, PaaS, SaaS до новейших BaaS, FasS.В этой тенденции бессерверность (де-серверизация) становится все более очевидной.

Голый металл (IDC):

Хостинг на физической машине

МААС:

Инфраструктура IaaS (инфраструктура как услуга) как услуга, __ поставщики услуг предоставляют ресурсы инфраструктуры базового/физического уровня (серверы, центры обработки данных, элементы управления окружающей средой, блоки питания, серверные помещения), пользователям необходимо приобретать виртуальные ресурсы через сервисную платформу, предоставляемую IaaS, выберите операционную систему, установите программное обеспечение, разверните программы и отслеживайте приложения.

В настоящее время хорошо известные платформы IaaS включают AWS, Azure, Google Cloud Plantform, Tencent Cloud Services, Alibaba Cloud и OpenStack с открытым исходным кодом.

ПААС:

Платформа PaaS (платформа как услуга) как услуга, поставщики услуг предоставляют базовые услуги инфраструктуры, предоставляют операционные системы (Windows, Linux), серверы баз данных, веб-серверы, балансировщики нагрузки и другое промежуточное программное обеспечение, по сравнению с IaaS клиентам нужно только контролировать себя. развертывание приложений верхнего уровня и среда размещения приложений.

В настоящее время хорошо известные платформы PaaS включают Amazon Elastic Beanstalk, Azure, Google App Engine, Tencent Container Service, VMware Cloud Foundry и т. д.

БААС:

BaaS (Backend as a Service) бэкэнд как услуга, поставщики услуг предоставляют клиентам (разработчикам) интегрированные облачные серверные услуги, такие как хранение файлов, хранение данных, push-сервисы, сервисы аутентификации и другие функции, чтобы помочь разработчикам быстро разрабатывать приложения.

ФААС:

FaaS (функция как услуга) функционирует как услуга, поставщики услуг предоставляют платформу, которая позволяет клиентам разрабатывать, запускать и управлять функциями приложений без создания и обслуживания инфраструктуры. Создание приложений в соответствии с этой моделью — это способ реализации «бессерверной» архитектуры, обычно используемой при создании микросервисных приложений.

Виртуализация и изоляция

Начиная с самых ранних физических серверов, мы все абстрагируем или виртуализируем серверы.

разработка сервера

Мы используем технологии виртуализации, такие как XEN, KVM и т. д., чтобы изолировать аппаратное обеспечение и работающую на нем операционную систему. Мы используем облачные вычисления для дальнейшей автоматизации управления этими виртуализированными ресурсами. Мы используем контейнерные технологии, такие как Docker, чтобы изолировать операционную систему приложения от работы сервера. Теперь, когда у нас есть Serverless, мы можем изолировать операционную систему и даже технические детали более низкого уровня.

нет статуса

Но это также определяет природу Serverless без сохранения состояния, поскольку каждый раз при выполнении функции может использоваться другой контейнер, и совместное использование памяти или данных невозможно. Если вы хотите обмениваться данными, вы можете использовать только сторонние сервисы, такие как Redis, COS и т. д.

Без эксплуатации и обслуживания

С Serverless нам не нужно заботиться о серверах, и нам не нужно заботиться об эксплуатации и обслуживании. Это также является ядром идеи Serverless.

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

бюджетный

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

  • В бессерверных приложениях разработчикам нужно сосредоточиться только на бизнесе, а об остальной работе и обслуживании не нужно беспокоиться.
  • Serverless действительно работает по запросу и работает только тогда, когда приходит запрос.
  • Serverless оплачивается по времени безотказной работы и памяти
  • Бессерверные приложения в значительной степени зависят от конкретных облачных платформ, сторонних сервисов

Serverless — это «бессерверная архитектура», которая позволяет пользователям сосредоточиться на технологии бизнес-логики, не заботясь о рабочей среде, ресурсах и количестве программ.

FAAS (функция как услуга) + BAAS (фон как услуга) можно назвать полной бессерверной реализацией.

Архитектура бессерверных облачных функций (SCF)

Бессерверные языки, которые в настоящее время поддерживаются Tencent Cloud SCF

Python 2.7 и 3.6, Node.js 6.10 и Node.js 8.9, Java 8, Php 5 и Php 7, Go 1.8, C# и C++ (планирование)

Преимущества безсерверных

  • Сокращение затрат на запуск
    • Сокращение эксплуатационных расходов
    • Сокращение затрат на разработку
  • Реализуй быстро онлайн
    • Более быстрый конвейер развертывания
    • более высокая скорость разработки
  • Безопасность системы выше
  • Адаптация к микросервисной архитектуре
  • Возможность автоматического расширения

Недостатки бессерверных

  • Не подходит для служб с отслеживанием состояния
  • Не подходит для долго работающих приложений
  • Полная зависимость от сторонних сервисов
  • Долгий холодный пуск
  • Отсутствие инструментов отладки и разработки

Применимые сценарии для бессерверных решений

  • отправить уведомление
  • WebHook
  • Легкий API
  • Интернет вещей
  • Статистический анализ данных
  • Триггерные и временные задачи
  • Бережливый стартап
  • Чат-бот

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

2. Облегченная практика миграции веб-приложений

В этой главе описывается практика миграции веб-приложения на основе миграции функций Tencent Cloud из архитектуры, а также процесс разработки и развертывания.

1. Миграция схемы

Давайте сначала взглянем на архитектуру общего веб-приложения на SCF.

статические ресурсы

Статические ресурсы (JS/CSS/IMG/HTML) хранятся в COS (хранилище объектов).COS может настраивать доменные имена и включать ускорение CDN (подробности см. в документе Tencent Cloud «Настройка пользовательских доменных имен для поддержки HTTPS-доступа» ), и прямой доступ через URL, который ничем не отличается от исходного веб-приложения.

Если мы являемся одностраничным асинхронным приложением, то есть наша страница html также является статическим ресурсом, вы можете вернуть его в SCF, точно так же, как обычный веб-сервер возвращает статические ресурсы, но чистые статические ресурсы используют SCF для возврата итог я чувствую, что это перебор, который потребляет текущие ресурсы, а производительность недостаточно хороша. Его также можно хранить на COS, а COS также может поддерживать собственные доменные имена и включать ускорение CDN.

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

Поддержка междоменного доступа: вы можете установить CORS через настройки шлюза API или настроить CORS через серверные программы.

Оптимизация производительности: использование предварительного подключения в заголовке страницы для динамического предварительного подключения API может значительно сократить время DNS/TCP/SSL. Не стоит недооценивать это время, поскольку в настоящее время шлюз API, соответствующий облачным функциям Tencent Cloud, поддерживает только одно местоположение. Доступ, географически удаленный, на этот раз может достигать сотен мс.

Шлюз API + логика приложения

Архитектурные изменения от исходного nodeServer к облачным функциям в основном заключаются в следующем:

Формат API GATEWAY EVENT

Вы можете проанализировать событие API GATEWAY EVENT непосредственно в коде и инкапсулировать тело ответа HTTP. HTTP в основном использует полученные связанные поля данных, и все поля в API GATEWAY EVENT имеют их, но они появляются в разных структурах данных. Если мы привыкли к среде экспресс-разработки и полагаемся на какое-то полезное промежуточное программное обеспечение, если нам нужно перестроить эту часть промежуточного программного обеспечения, это будет много работы. -- Тогда есть ли у нас план, совместимый с первоначальным текстом?

Будь то миграция или недавно разработанный проект, эта архитектура действительно может быть принята:

Мы можем преобразовывать события API Gateway в http-запросы и связываться с функцией nodeserver через локальный сокет.

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

Уже есть несколько доступных фреймворков (serverlessplus, scf-framework) для промежуточного уровня прокси-сервера пересылки, вы можете попробовать их, использование относительно простое.

хранилище данных

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

1. БД

Нет большой разницы с исходным использованием БД.

Как правило, мы выбираем для подачи заявки на ресурсы в VPC, который подключен к внутренней сети компании, так что коэффициент безопасности относительно высок, и он полностью изолирован от внешней сети.Только выбрав ту же подсеть, мы можем подключиться.

Приложение ресурса будет обсуждаться в разделе разработки и развертывания ниже.

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

Интерфейс экземпляра базы данных:

2. Кэш памяти

Как упоминалось выше, экземпляр будет иметь отложенное время уничтожения.Если тот же экземпляр будет поражен за короткое время, переменные памяти в экземпляре могут быть кэшированы. Содержимое, которое необходимо кэшировать, может кэшироваться на двух уровнях: сначала считываться из памяти, а затем считываться из Redis, если его невозможно прочитать.

Использование Redis аналогично использованию БД, подача заявок на ресурсы, настройка подсетей и подключение через IP-ПОРТ.

Redis можно легко использовать с помощью пакета npm, инкапсулированного ниже.

npm i qcloud-serverless-redis

3. Хранилище файлов

Доступный для записи каталог без сервера — /tmp/, но он будет освобожден при выпуске экземпляра, поэтому его можно разместить только временно.

Общий размер составляет всего 512 М. Рекомендуется активно удалять временные файлы, когда они израсходованы.

Если вы хотите хранить долговременные файлы, вы можете использовать COS для хранения.

Конкретные операции COS см. в документации Tencent Cloud, например: Node.js SDK Quick Start.

Я также просто инкапсулировал пакет cos npm здесь, вы можете быстро попробовать функцию доступа cos, см. README внутри для конкретного использования

tnpm i @tencent/serverless-cos

Вход связан

Это решение похоже на хранилище данных, которое может сохранять состояние с помощью сторонних сервисов или с помощью шифрования и дешифрования токенов.

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

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

настройка производительности

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

Давайте сначала посмотрим на процесс запуска облачной функции и какие шаги включены.

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

Если его нет, то нужно создать контейнер и загрузить код развертывания. Эти процессы занимают от ста миллисекунд до нескольких секунд и называются холодным запуском.

Чтобы оптимизировать производительность функции, необходимо оптимизировать различные этапы жизненного цикла функции.

  • 1. Повторное использование экземпляра функции — самый прямой и эффективный метод. Но как долго уместно хранить? За 3 минуты можно решить 95% проблем за 3 часа, 99% проблем можно решить за 3 дня и 99,9% проблем можно решить. Это вопрос оценки стоимости и эффекта. (Время удерживания не обязательно является фиксированным значением, и необходимо проанализировать функциональные характеристики и период времени. )
  • 2. Предварительно создайте партию контейнеров с разными спецификациями (без кода), чтобы сократить время создания контейнера.
  • 3. Платформа функций имеет хранилище кода для хранения кода функции и управления им, и он будет загружаться в контейнер при использовании. Горячий код можно кэшировать: Уровень 1: Кэш вычислительного узла узла, Уровень 2: Кэш машинного зала
  • 4. Прогнозировать трафик с помощью машинного обучения и запускать некоторые экземпляры функций заранее, чтобы можно было максимально исключить холодные запуски и гарантировать, что экземпляры будут горячими запусками.

Это все оптимизации, сделанные платформой, так что же могут сделать разработчики?

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

Для получения дополнительной информации, пожалуйста, обратитесь к другой моей статье «Серия Front-end Learning Serverless — Настройка производительности».

2. Разработка, развертывание, эксплуатация и обслуживание

Разработка и отладка

1) Отладка в облаке

В настоящее время требуется опубликовать папку node_modules в облачную функцию, даже если она не нужна, ее необходимо сжать, а затем передать по сети. Если вы измените строку кода, вам нужно загрузить ее один раз, чтобы выполнить ее, не произойдет ли сбой? И онлайн IDE может редактировать только index.js, но код не прописывается в файле ввода. Онлайн-среда IDE в настоящее время поддерживает только редактирование функций ввода отдельных файлов, и обновление среды IDE также находится в стадии разработки.

2) Локальная отладка 1.0

Нужно заранее установить tcf, docker

Для конкретной установки обратитесь к инструменту командной строки TCF.

Выполните команду локально:

tcf local invoke --template template.yaml --event event/apigateway.json

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

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

Однако проблем по-прежнему много:

Например, подключенная база данных должна быть внешним сетевым адресом, потому что сетевая среда Docker не может быть подключена ни к локальной среде, ни к среде в облаке.

Например, пакет npm, который я установил локально, не может нормально выполняться, потому что моя локальная система — это система Mac, а образ — система Linux.

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

3) Локальная отладка 2.0

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

Для конкретного использования см. документацию:GitHub.com/Tencent Cloud/…

tcf native invoke --template template.yaml --event event/apigateway.json

4) Отладка сервера узла:

Если ваш проект основан на фреймворке, таком как koa или express, вы можете напрямую добавить запись сервера.При локальной отладке вы можете напрямую запускать сервер и отлаживать его, как обычный сервер узла.

выпускать

Вы можете использовать команду tcf для публикации, а публикация командной строки tcf поддерживает два

  • Загрузить код через хранилище объектов cos
  • Загрузите код через локальный zip-пакет (размер zip не может превышать 50M)

Для получения подробной информации вы можете проверить документацию: Как опубликовать код развертывания с помощью tcf

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

//ориентировочный код

tcf package & tcf deloy

Но достаточно ли просто опубликовать его?

Как изолировать тестовую разработку и онлайн-среду и как откатиться?

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

API Gateway также по умолчанию имеет три среды: тестовую, предварительную и выпускную, и вы можете указать версию облачной функции.

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

Конкретный рабочий путь: щелкните конкретную службу шлюза API, чтобы перейти на страницу сведений, и отредактируйте каждый API в разделе «Управление API».

Выберите версию, которой вы хотите соответствовать:

После редактирования API необходимо опубликовать в соответствующей среде, чтобы он вступил в силу.

Так же очень удобно откатывать операцию, достаточно сразу перейти в историю к версии. Но будьте осторожны, пишите заметки, не пишите "тест", как я ^_^

На данный момент кажется возможным отделить тест от реальной среды.

Но на самом деле ресурсы, подключенные к тесту и онлайн, разные, например БД, мы обычно судим, какие ресурсы подключать, читая переменные среды, а не изменяя код, а облачная функция имеет только одну конфигурацию.

Затем мы можем использовать пространства имен, чтобы изолировать тестовую и тестовую среду. Релиз может быть выполнен с помощью копирования функций. При желании конфигурация не копируется. Конфигурация отличается от настроек тестовой среды онлайн. Код соединяет онлайн и тестовую среду судя по переменным окружения.resource.

Создайте пространство имен:

Скопируйте функции в другие пространства имен:

Установите переменные среды:

В соответствии с переменной среды, прочитанной иначе, чем в конфигурации:

//根据环境变量读取不同的配置
const devConfig = require('./config.dev');
const testConfig = require('./config.test');
const prodConfig = require('./config.prod');

const env = process.env.NODE_ENV;
console.log('process.env.NODE_ENV', process.env.NODE_ENV);
switch (env) {
  case 'prod':
    module.exports = prodConfig;
    break;
  case 'test':
    module.exports = testConfig;
    break;
  default:
    module.exports = devConfig;
}

В заключение:

1) Test и line размещаются в двух разных пространствах имен, изолируя код test и line.

2) Выход в интернет осуществляется копированием функции.

3) Тестовая среда и онлайн-среды различаются установкой разных переменных среды в конфигурации функции.

4) Откат осуществляется установкой версии функции.

Сопоставление доменных имен

Шлюз API будет иметь доменное имя по умолчанию, что позволит нам использовать шлюз API, не запрашивая доменное имя самостоятельно. Однако, как правило, если это URL-адрес, который пользователь посещает в браузере, это должно быть доменное имя, для которого требуется собственное/более короткое имя, чтобы быть более надежным.

Шлюз API – Пользовательское доменное имя

Если он поддерживает https, вам необходимо загрузить сертификат https в Tencent Cloud.

Кроме того, вы также можете настроить сопоставление путей, например изменить опубликованный путь сhttp://yourdomain/releaseприбытьhttp://yourdomain/Посещения короче. Вы также можете изменить тестовый путь /test на более сложный, чтобы пользователи не могли получить к нему доступ.Конечно, безопаснее, если вы не публикуете тестовую среду.

журнал

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

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

Но мы видим единственное поле поиска, которое можно получить только по RequestID, а у каждого запроса есть RequestID. Тогда где взять requestID, похоже, что его можно получить только из этого лога.Если передать его другим сервисам или фронтенду, когда другие сервисы отследят проблему, можно отследить ее здесь.

Это явно слишком неудобно.

Служба журналов не работала, когда я ее использовал, и была онлайн, когда я писал эту статью.

Если текущая функция настроила службу журнала, вы можете [Перейти к службе журнала], чтобы получить журнал более удобным способом.

Под интерфейсом конфигурации функции вы можете настроить доставку журнала в службу журналов. Создать новую службу журнала

Создайте набор журналов:

В наборе журналов можно создать несколько разделов журнала.

Как журнал может быть использован, вы можете увидеть следующее на этой панели действий:

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

Конфигурация индекса: можно настроить прерыватели токенов.

Конфигурация доставки: журналы могут быть доставлены на COS

Потребление в реальном времени: можно потреблять с Ckafka

Пример поиска:

монитор

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

Обзор домашней страницы облачных функций:

Информационный интерфейс мониторинга облачных функций:

Мониторинг шлюза API:

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

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

Меры предосторожности

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

2. Локальная среда разработки многих людей — это Windows или Mac, а некоторые зависимости node_module связаны с операционной системой, поэтому локально установленные node_modules нельзя использовать в облачных функциях или образах.

3. Среда Docker для локальной отладки изолирована от сети, поэтому, если вы хотите подключиться к связанной службе baas, вам потребуется служба baas, поддерживающая доступ к внешней сети. Если это узел, он уже может поддерживать собственный tcf для отладки без отладки докера.

4. В настоящее время сервер может установить только один файл cookie. Это Tencent Cloud тоже планируется отремонтировать.

подожди~

наконец

Когда мы сейчас используем протокол HTTP, нам нужно передавать один слой через API GATEWAY. Можем ли мы удалить этот уровень передачи?

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

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

Эти проблемы будут решены в Tencent Cloud Serverless 2.0, который скоро будет выпущен, вы можете с нетерпением ждать его.

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

Категории