前言Serverless架构是一个新的概念，也可以说是一种新的架构或者技术，但是再新也不能一下子完成现有的开发习惯向serverless架构过渡显然是不可能的，现有的工程师也显然不可能抛弃现有的Express、Koa、Flask、Django等框架，直接在serverless上开发项目建筑学。即使可能，也需要时间。适应和过渡。那么在这个过渡时期，是否可以考虑将已有的框架部署到Serverless架构上呢？接下来我们用Flask框架进行简单的测试：测试四个接口：Get请求（可能涉及到通过path传递参数）Post请求（通过Formdata传递参数）Get请求（通过url参数传递参数）Get请求（带计算功能）如jieba）测试两种情况：本地性能通过Flask-Component部署性能测试两种性能：传统云服务器上的性能云函数性能首先是测试代码：fromflaskimportFlask,redirect,url_for,requestimportjiebaimportjieba.analyseapp=Flask(__name__)@app.route('/hello/')defsuccess(name):return'hello%s'%name@app.route('/welcome/post',methods=['POST'])defwelcome_post():user=request.form['name']return'POST%s'%user@app.route('/welcome/get',methods=['GET'])defwelcome_get():user=request.args.get('name')return'GET%s'%user@app.route('/jieba/',methods=['GET'])defjieba_test():str="ServerlessFrameworkisav业界非常流行的无服务器应用程序框架。开发者无需关心底层资源，即可部署完整可用的Serverless应用架构。ServerlessFramework具备资源编排、自动伸缩、事件驱动等能力，涵盖编码调试、测试、部署等全生命周期，帮助开发者通过链接云资源快速构建Serverless应用。"print(",".join(jieba.cut(str)))print(jieba.analyse.extract_tags(str,topK=20,withWeight=False,allowPOS=()))print(jieba.analyse.textrank(str,topK=20,withWeight=False,allowPOS=('ns','n','vn','v')))如果__name__=='__main__':app.run(debug=True)这段测试代码比较有意思，包含了最常用的请求方法，参数传递方法，还有简单的接口和稍微复杂一点的接口。本地性能在本地运行后，通过Postman进行三个简单的接口测试：Post参数传递：Get参数传递：通过Flask-Component部署性能接下来我们将这段代码部署到云函数中：通过Flask-Component部署，可以参考腾讯给出的文档，Github地址https://github.com/serverless...yaml文档内容：FlaskComponent:component:'@gosls/tencent-flask'inputs:region:ap-beijingfunctionName:Flask_Componentcode:./flask_componentfunctionConf:timeout:10memorySize:128environment:variables:TEST:valevpcConfig:subnetId:''vpcId:''apigatewayConf:protocols:-httpenvironment:releaseDeploymentcompleted接下来测试我们的目标三个接口Get通过路径传递参数：Postparametertransfer:Getparametertransfer:通过上面的测试可以看出，通过Flask-Component部署的云函数也可以有几种常用的请求形式和参数传递提供表格。可以说，一般情况下，用户的Flask项目可以通过腾讯云提供的Flask-component快速部署到Serverless架构中，并且可以运行得比较好。简单的性能测试接下来进行一波简单的性能测试。首先购买一台云服务器，将这部分代码部署到云服务器上。云上买个服务器，保守买个1核2G，然后配置环境，服务就可以运行了：通过Post设置简单的测试：然后测试接口：接口测试完成的很顺利：可以通过界面测试结果部分可视化：同时统计数据：通过上图和表格可以看到，服务端测得的整体响应时间比云函数的响应时间要快。并且可以看出函数中存在冷启动。一旦发生冷启动，响应时间将增加20倍以上。由于上面的测试，它只是一个非常简单的界面。接下来我们测试一个稍微复杂一点的界面，使用jieba分词的界面，因为jieba分词的界面是存在的：测试结果：可视化结果：通过jieba界面的测试可以看出，虽然服务器也会因为分词组件的初始化导致响应时间变慢，整体速度还是远低于云函数。那么问题来了，是功能本身性能有问题，还是加入Flask框架+APIGW响应集成后有问题？接下来，做一组新的接口测试。函数中直接返回内容，不做额外处理。看函数+API网关的性能和服务端在正常情况下的性能，可以看出虽然最小和平均耗时差别不是很大，但是最大耗时基本一致。可以看出框架的加载会导致函数冷启动的时长变得极其可怕。接下来使用Python代码对Flask框架进行并发测试：对函数进行3次压测，每次300并发：============taskend===========total:301,succ:301,fail:0,except:0responsemaxtime:1.2727971077responsemintime0.573610067368============任务结束============总计：301，成功：301，失败：0，除外：0响应最大时间：1.1745698452响应最小时间0.172255039215===========任务结束============总计：301,succ:301,fail:0,except:0responsemaxtime:1.2857568264responsemintime0.157210826874在服务器上进行3次压测，每次并发300:============taskend============total:301,succ:301,fail:0,except:0responsemaxtime:3.41151213646responsemintime0.255661010742===========任务结束===========总计：301，成功：301，失败：0，除外：0响应最大时间：3.37784004211响应最小时间0.212490081787===========任务结束============总计：301,succ:301,fail:0,except:0responsemaxtime:3.39548277855responsemintime0.439364910126通过这个wav在压力测试中，我们可以看到这样一个奇怪的现象，即功能和服务器预热完成后，连续3次并发发出301请求。功能整体性能优于服务器。这也说明了Serverless架构下弹性伸缩的一个非常重要的性能。对于传统的服务器，如果我们的并发量很高，很容易严重影响整体的服务，比如响应时间变长，无响应，甚至服务器直接挂掉。但是在Serverless架构下，这种弹性伸缩的能力是云厂商帮我们做的，所以当并发量达到一定程度的时候，Serverless架构的优势就会更加明显。总结：Flask可以很简单的采用serverless架构。用户基本可以按照原生Flask开发习惯开发Flask项目，尤其是使用Flask开发接口服务的项目，可以很方便的迁移到Serverless架构上。在将整体框架迁移到Serverless架构时，可能需要注意几个额外的点：如果接口很多，可能需要根据消耗资源较多的接口来设置内存大小。以我的例子为例，当使用非jieba接口时，最小内存（64M）是可以使用的。使用jieba接口时，需要256M内存，而整个工程是一体的，只能设置一个内存，所以为了保证工程的可用性，整体设置为256M内存。这样如果其他三个接口的访问量比较多，资源消耗可能会相对增加。所以，如果条件允许，可以考虑把资源消耗比较大的接口提取出来；对资源和文件上传的支持可能不是很友好，尤其是云函数+API网关的双重收费，所以建议在对象存储中放一些Flask中的静态资源，修改文件上传逻辑优先上传为对象存储，可以参考之前的文章：【实践与践行】Serverless如何上传文件？frame越大，或者frame中的资源越多，function冷启动时间可能会越长。这一点非常值得关注。刚才的测试过程中，非框架下，最大耗时是平均耗时的3倍，加载Flask框架和jieba的前提下，最大耗时是平均耗时的10+倍！如果能保证功能都是热启动，那还好，一旦出现冷启动，可能会有一定的影响。由于用户发起的请求是从客户端到API网关再到函数，再从函数返回到API网关，再返回到客户端，这个过程显然比直接访问服务器的链接要长得到的结果，所以在实际测试过程中用户数的表现不是很好。经过多次测试，基本上1核2G的服务器比功能的表现要好。但是当并发量增加的时候，可以看到函数的性能实现了很大的反超，一度超过了这个1核2G的服务器。那么这里有一个有趣的结论：对于极小规模的请求，功能是按量付费。虽然在性能上有一定的劣势，但按量付费在价格上有一定的优势；优势也逐渐凸显。相信随着时间的发展，Serverless架构会越来越成熟，目前可能还存在或多或少的问题，但在不久的将来，一定会不负众望。
