azure 函数计算初体验

in 折腾一下 with 0 comment

概述

前天试着注册了下 azure student,没想到通过了。不得不说,国外对于教育都是很尊重的,在教育方面都给了不少福利。以 azure student 为例,学生可以体验虚拟机、数据库、人工智能、函数计算等资源,并且有一百刀的体验金。

由于最近在折腾 OnePoint 项目,我就寻思着,能不能部署到 azure 上,用上这每月一百万次的额度。真的用起来才发现,azure functions 用着还行,但在一些细节上不太友好。

demo: https://ukuq.azurewebsites.net/api/azure/

azure 部分福利截图

image-20200125192919505.png

创建部署

创建项目

首先需要通过下面的链接,打开函数应用控制面板,点击添加,将会进入到下图所示面板。

https://portal.azure.com/#create/Microsoft.FunctionApp

image-20200125193426053.png

基本配置可以参考我这里这个,剩下的默认就行,最后一直点 next,确认创建。

azure functions 支持 .NET Core, Node.js, Python, Java, PowerShell Core 几种语言,我只体验了 nodejs,其他版本你可以自行查看官方文档。

另外要注意,nodejs 仅支持 windows 系统,所以在创建时不要选择 linux 。

创建函数

创建完成后,进入到你创建的项目中,新建函数。

image-20200125194340196.png

image-20200125195147788.png

我们这里使用 http 触发器,并设置身份验证为 Anonymous ,便于无认证访问。

示例代码

创建完成后,点击触发器可以查看代码。下面是官方给出的代码。

module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');

    if (req.query.name || (req.body && req.body.name)) {
        context.res = {
            // status: 200, /* Defaults to 200 */
            body: "Hello " + (req.query.name || req.body.name)
        };
    }
    else {
        context.res = {
            status: 400,
            body: "Please pass a name on the query string or in the request body"
        };
    }
};

还是我们熟悉的 req 和 res 模式,req 是 express.req 的超集,其中有用的参数有 query, body, method, headers, cookies 等。body 默认会自动解析其类型,这一点非常方便,不需要我们再额外解析了,可以直接使用。返回数据则以 res 对象返回,也很容易看懂。

缺点

在线部署

首先就是文件的上传,在线文件编辑只支持新建文件,不支持新建文件夹,不支持浏览器上传压缩包(这一点应该学学腾讯云函数),用户体验极差。

命令行部署

毕竟是自家云服务,vscode 是必须要支持的。

我们可以使用 vscode 插件部署,先下载 Azure Functions(ms-azuretools.vscode-azurefunctions)插件,然后按照引导登录就行,配置时一键上传部署。你还可以设置部署时的参数,例如 function.json, host.json 文件,具体看官方文档。

但,部署体验极差。azure 的服务器在墙外,所以你懂的。建议学一学腾讯云,搞几个香港服务器,提升下用户体验。

文档问题

文档太繁琐,不好找,有问题只能谷歌。

路由问题

这个问题已经不只是缺点的问题了,我觉得这应该是产品经理的问题。

官方大概是这样想的,想要你创建 restful api , 假设你创建了一个名为 products 函数,你可能会创建下面类型的 rest api ,所以他们的设想就是,只将符合这个格式的请求转接至products 函数。

products/{category:alpha}/{id:int?}

但这样就带来了一个问题,长度差异比较大的 url 无法使用同一个函数。市场上大部分函数服务都是 aws 的 lambda 风格,他们都不会这样去干涉用户。azure 这样做,真的是管的太宽了,应该把选择权留给用户。

我查了文档(没啥用),问了百度(它也没啥用),用了多吉(当时上不了谷歌),上了谷歌。最后还是受到了官方文档的启发,想出了这种不够优雅但能解决问题的方法。

文档里面有提到上面例子中 ? 代表可选,于是我便决定这样用:

azure/{p1?}/{p2?}/{p3?}/{p4?}/{p5?}/{p6?}/{p7?}/{p8?}/{p9?}/{p10?}/{p11?}/{p12?}/

其中azure为函数名。这样,访问 url 深度在 12 以内的都能转发到 azure 函数,算是曲线救国了。

image-20200125202528706.png

总结

azure functions基本能用,但还存在一些小问题,如果上面提到的小问题以后有所改善的话还是一个不错的选择。

关于性能问题,我并没有进行深入测试,不过 azure 机器性能也不会差到哪里去。

但目前来看,没有折腾能力的小白还是选择腾讯云函数吧,这个就不要折腾了。

Responses