利与弊 - 传统框架要不要部署在 Serverless 架构上

Serverless架构发展的速度可以说是非常的迅速，而且Serverless的发展也是有一套自己的独特的打法，这种打法在一定程度上，让很多开发者不适应，尤其是传统的Web框架无法在Serverless架构上直接应用的问题。但是随着大家对Serverless架构的了解，也逐渐的有很多工具，可以帮助用户快速部署传统的Web框架到Serverless架构上，那么这种做法，到底有多大的意义，是否合理的呢？



通过对腾讯云的SCF进行研究，对其主推的开发者工具：Serverless Framework进行研究，我们可以看到，其可以帮助用户快速部署一些Web框架，例如Django，Flask，Express，Koa等，根据Github和NPM的下载量也可以看到（数据是个人统计，统计渠道单一，未必准确，仅作参考）：





整体来说还是有一定量的，但是这些框架真的就适合跑在Serverless架构上么？或者说在哪些情况下适合跑在Serverless架构下呢？



当然，以下观点更多是自己的主观想法比较多，还希望大家可以一同沟通交流：



首先从整体上来说，我是不太赞同这些框架部署在Serverless架构上。原因基本可以总结为6点：



1. 传统框架开发的很多项目，可能会有一些静态文件资源，在云主机上这些静态资源可能不会有什么问题，但是Serverless架构上，这些资源如果被部署在函数中，那么就意味着每次打开一个网页，都可能会出发这个函数很多次，例如用了Flask框架，将所有静态资源也都部署到了函数上，每次请求网页的时候有html页面1个，各类静态资源20个，那么这个函数就要被触发21次，而且这个时候收费的是API网关和函数，这部分流量相对来说比对象存储的流量更贵，所以静态资源更推荐存储到对象存储中；



1. 传统框架拥有的一些能力在Serverless架构下可能无法被更好的支持。例如文件上传功能，以腾讯云的云函数为例，通过API网关到云函数最大可以上传的文件大小为6M，而且比较合理的处理方法是将文件Base64进行处理之后上传，如果想通过函数比较优雅的上传文件，可以通过函数与对象存储组合实现上传功能；除此之外，传统的一些Web框架，可能会利用一些本地的缓存，或者在内存中缓存一定的内容等，而这些操作在Serverless架构下都是不太合适，可能会产生额外的问题等；



1. 传统框架部署到Serverless架构上，可能要进行一些额外的设置，以腾讯云的Serverless服务为例，需要将API网管设置称为响应集成，而响应集成相对来说可能比直接返回结果性能会低一些。



1. 传统我们开发一个项目，可能都会在一个Project内完成，例如我们一个项目涉及到了40个接口，其中有39个接口是增删改查，只需要三四十M的内存就可以，而另一个接口涉及到了很复杂的逻辑，可能要512M的内存，那么此时，我们把所有的服务都部署到一个函数中，这个函数的最低内存就要设置成512，相对39个内存消耗比较小的接口而言，用户的成本会疯狂上升，如果我们开发的时候建立多个项目，将不同类型的/消耗的接口分开，那么对于开发者来说也不是一个很好的感受；



1. 问题排查能力，在不考虑外接一些日志系统的前提下，单纯就Serverless中函数计算本身的日志能力，如果整个框架部署上去之后。一旦出现问题，请求的定位，问题的排查都将会是噩梦一样的存在；



1. 一般情况下，一个框架部署都会有一些可能我们本身用不到的依赖，但是这些依赖是框架所需要的，所以在将项目和依赖一起打包部署之后，函数的整个体积相对来说都是比较大的，这个时候，无论是部署难度还是遇到冷启动时候的性能，都应该不是开发者或者运维的同学想看到的。



当然，这里是简单的总结出来的6点，除此之外还有一些额外的问题，例如传统框架的直接部署，提高了并发量，占用了一定的并发"额度"等；



说到底，其实不推荐框架直接部署的原因就是因为这些框架在设计之初本身没有考虑过Serverless架构的一些特性，所以部署到Serverless架构可能存在大大小小的问题也是可以理解的，例如有一些框架主打的高性能，和Nginx等配合之后可以面对更大的并发等，但是并发在Serverless架构下，还真的和框架有太多的关系么？



那么为什么还会有很多人一直想将已有的框架部署到Serverless架构上？因为Serverless架构是一个新的技术，让开发者突然放弃已经有的习惯，已经有的一些能力，已经有的框架确实是一个灾难，那么即想用又没办法完全用怎么办呢？那就要对项目进行一些改动，但是，我相信，无论怎么改动都不应该算作最佳实践。



也许此时会有人问我，我已经有的项目，难道还要重新写？不应该直接框架迁移么？那么我想知道的是，项目大么，如果项目很大，你真的敢改造完成直接迁移么，迁移改造成本和上到Serverless架构上的维护成本，真的就比现在低么？如果项目小的话，那么重写与否问题貌似确实不是很大，当然，这里项目大小的范围确实是一个模糊的概念，我也不是说已有项目上Serverless架构就要重写，或者说重写才是最佳实践，我只是想说想表达：上Serverless架构的目的不是为了上Serverless架构，上之前一定要评估好上的意义和价值，以及后期维护的成本。



凡事不能一棒子打死，那么在我心中有哪些类型的项目比较适合上Serverless架构呢？我个人经过很多的深思熟虑总结出以下几个点：

1. 项目比较小，以腾讯云为例，至少加依赖压缩包的大小别超过200M；

2. 项目设计之初就充分考虑了分布式部署，例如所有的状态都会通过额外的存储来实现，例如redis等；

3. 项目是前后端分离的，所有的静态资源不在后端的框架中，后端的web框架拥有的也只有接口；

4. 所有的接口资源消耗等都是差不多的；

... ...



当然，我做的总结也未必是全的，更不是权威的，只是说，我个人在生产中，在开发过程中，对一些传统框架部署到Serverless架构上的个人看法。



诚然，Serverless架构是比较有趣的，发展的比较快的，是很多人看好和青睐的，但是传统框架上不上Serverless架构确实是要值得深思熟虑的一件事，否则费力上了，难道还要费力下掉不成？虽然很多云厂商给我们提供了Express，Koa，Flask等框架的一键上Serverless架构的工具，但是鞋子适不适合的脚，穿着舒服与否，只能穿鞋的人才知道，做鞋子的未必清楚。



诚然，Serverless架构给我们带来了很多的吸引力，无论是资源成本的节约，还是运维工作的降低，或者是弹性伸缩等能力的"天赋"，但是他也给我们带来了很多的坑，当我们把框架部署到Serverless架构上，这些优势真的还是优势么？那些坑到底有多大呢？我觉得这个是要值得考虑和评估的。



当然，我是热爱和支持Serverless架构的，我相信不久的将来会有框架或者说更多的框架是针对Serverless架构而设计的，但是至少在目前，我们要保持足够的冷静，尤其是要仔细思考：我的项目，或者说我用的框架，部署到Serverless架构上的意义是什么？



文章转自：https://www.serverlesschina.com/post/43.html