Ван Хунци
Я собираюсь представить модель программирования Alibaba Cloud Function Compute. Первоначально я разместил его в своем твиттере и подумал, что было бы неплохо поместить тему в одну статью. Давайте посмотрим, чем он отличается от других поставщиков и что это дает пользователю.
Сначала вы увидите знакомый обработчик (события), например. Python, как вы видели в других моделях программирования FaaS.
import json
def handler(event, context):
evt = json.loads(event)
result = 'hello %s' % evt.get('name', 'world')
return resultНа самом деле это немного другое, событие не является диктом. Это bytearray/ByteBuffer, так что вам, возможно, придется разбирать его самостоятельно в зависимости от ваших потребностей.
- Минусы: вы не можете предположить, что это JSON.
- Плюсы: платформа не заставляет вас преобразовывать не-JSON в формат JSON.
например Вы можете передать в функцию событие формата protobuf или файл изображения, платформа просто передает событие обработчику без какой-либо проверки/преобразования. Идея протобуфа и проверки типов, упомянутая @timallenwagner, может быть частично удовлетворена.
Напротив, если событие имеет тип JSON, для передачи двоичного значения его необходимо преобразовать во что-то вроде кодировки base64 и сформировать в строку JSON, передать службе, которая преобразует его в dict, а затем передать обработчику, который преобразует его в двоичный файл.
По той же причине возвращаемое значение не ограничивается JSON.
Далее вы также увидите знакомый интерфейс HTTP (req/resp) в модели программирования. Почему? Потому что использование JSON для описания запроса утомительно/неэффективно и не является родным для веб-разработки.
Если вы посмотрите на инструменты вокруг Lambda, вы увидите множество фреймворков/платформ, пытающихся вернуть разработчику интерфейс HTTP, например. @vercel сейчас, @tjholowaychuk вверх. Это выполнимо, но не совсем приятно. Подход с оболочкой также должен иметь дело с преобразованием события и запроса/ответа, что является накладным.
Служба вычисления функций (FC) избегает этого, предоставляя интерфейс функции HTTP, например. Python WSGI, NodeJS Express, сервлет Java и т. д. Это не только позволяет избежать ненужных накладных расходов на преобразование, но и возвращает родной опыт. Для запуска приложения Django или Flask на FC требуется всего несколько строк кода.
Этого достаточно? Клиенты также просят о дополнительной поддержке во время выполнения. Подход к пользовательской среде выполнения кажется правильным. Но какой интерфейс должна предоставлять пользовательская среда выполнения? Нравится модель функции события?
Чистые функции могут выглядеть круто, но написание приложения для веб-сервера не является головной болью для многих языков. Напротив, преобразование приложения на основе веб-сервера в чистые функции требует много работы, не говоря уже о накладных расходах между событием и HTTP-запросом.
Так почему бы просто не позволить пользователям запускать сервер и приложение как функции? Чтобы разработать пользовательскую среду выполнения, вместо того, чтобы общаться с некоторыми API, такими как подход Lambda, вы просто пишете свое приложение, прослушивающее порт 9000.
Что это дает пользователям?
- Это еще больше упрощает миграцию веб-приложений (например, alibabacloud.com/help/doc-detai⋯).
- Любой может использовать этот простой подход для написания функций. Возможно, это не очень хорошее имя, потому что функция и среда выполнения связаны вместе.
Еще одна вещь, у вас может быть необязательный обработчик инициализатора. Это хорошее место, чтобы сделать некоторые подготовительные работы, например. инициализация клиента HTTP/DB. Об этом спрашивали @theburningmonk, @timallenwagner и другие. Это не только делает код немного чище, но и сокращает время холодного старта. Я видел, как поставщики усердно работают над сокращением числа случаев холодного запуска платформы, например. как быстро запустить экземпляр функции.
Но как насчет холодного старта бизнеса? например загрузка модели, которая занимает несколько секунд или дольше.
import time
time.sleep(5)
def handler(event, context):
time.sleep(2)
return ''Если я вызову эту функцию дважды одновременно, будет 2 холодных запуска.
Платформа ничего не может сделать, потому что думает, что экземпляр готов обслужить запрос, хотя на самом деле он не готов. В чем разница с инициализатором? Платформа выполняет его перед обслуживанием запроса.
import time
def initializer(context):
time.sleep(5)
def handler(event, context):
time.sleep(2)
return ''Если я вызову функцию дважды одновременно, будет 1 холодный запуск. Почему? потому что 1-й экземпляр функции становится доступным раньше и, следовательно, обслуживает 2-й запрос, в то время как 2-й экземпляр все еще инициализируется.
Это всего лишь один пример, показывающий, как можно использовать инициализатор для уменьшения задержки холодного запуска. Есть больше оптимизаций, которые можно выполнить в фоновом режиме, например. функции обновления также запускают обновление экземпляра. Немного больше информации можно найти здесь.
На этом завершается текущее состояние модели программирования Function Compute. Будут ли еще стили? Может быть, дайте нам знать, что вам нужно.
