Serverless现状和如何高效开发

汇总我近几年因项目原因在腾讯云针对serverless(腾讯云SCF)的提交工单最少三百个以上,上至SCF内部运营BUG, 下至腾讯云SDK 均被我找出过致命BUG, 甚至现在出现问题后,我都能直接定位出大致问题出现的原因,且通过工单验证基本是准确的.他们的客服甚至对我都熟悉。

很多大佬从技术理论和前途方面来讨论serverless ,但论及serverless的应用我可以拍着胸脯说,我是相当经验丰富的,本文我是从实战来说。

先说我的经历:

当很多人只是对serverless的前途有信心但是尚未敢真正用的时候，我已经用serverless真正开发了四五个项目了, 项目的客户端包含:小程序/web/IOS/Andriod ，其中两个已上线项目及规划中的一个电竞项目均包含这些客户端,服务端被我全部采用serverless，服务器完全抛弃了传统的服务器,全部使用的腾讯云serverless(腾讯云SCF), 并且为了适应项目需要,还自行开发了serverless的GUI开发部署运维工具,其效率可以说已经高于传统开发的模式.

本人专攻中小项目,因此本次解读大项目就不适应了

优势: 我个人认为在当前环境下,serverless对小项目产生的影响远远超过对大型项目的影响

1. 超低成本: 对于小项目来说,任何成本都是非常敏感的, 甚至几百块都可能会让甲方爸爸犹豫的,不要小看现在经济环境不好的大情况下企业对成本把控的决心, 我曾经一个房地产公司,一个流程的优化因需要一千左右,就决定放弃修正了,改由员工每日花费更多人力来处理,后面我会详细说我如何处理服务器成本,或者说如何各种白嫖, 极致的时候 我一个客户开发的系统因使用量不大,一年服务器全部费用(包含数据库)未超过10元。我现在的一个客户，之前他们由一个长沙软件公司来负责，对方也完全不替客户成本着想，硬件直接拉最高， CPU、内存和带宽常年在1%使用率，最高也未超过10%。
2. 低技术门槛: 小项目其报价低，开发成本低，且二三线以下城市需求大，若甲方公司寻找一线城市开发，报价会让甲方直接放弃，因此只能本地寻找软件公司，但本地软件公司的技术员工技术实力明显偏弱，正常实现功能已属难得，所以更谈不上稳定性和性能了，甚至参数他们都不了解了，这个我是切身感受的。serverless可以直接解决掉稳定性和性能，只要技术人员能正常开发完成业务逻辑即可。毕竟并发和服务器稳定就交给云服务商了，这样本地软件公司只要招聘到技术一般能实现业务逻辑的技术人员即可。因此可以说serverless是技术实力弱的软件公司的绝对福音。
3. 低知识广度：非大项目，其服务器软件（Nginx、Apache）均需要开发人员来安装部署，甚至运维都是直接找开发人员，普通的软件公司的人员对开发语言的掌握也只能说是可以开发业务逻辑而已，哪里还能掌握这些知识， 无非是搜索个安装文档，然后完全照搬安装完成，现在完全无需学习这方面知识了。

劣势：

其劣势也决定了难以被技术一般的人员所便捷使用。

1. 产品不够稳定：从我重度使用两三年情况来说，我发现腾讯云的底层稳定性尚不够好，甚至我碰到过VPC初始化失败的情况。
2. 框架缺乏：Serverless有自己的特点，现有框架有不合适的地方，但是尚未出现针对serverless优化出的框架，间接的提升了使用难度，比如本地化的单元测试问题。目前我的项目使用的是我自己开发的框架，达到了极速开发新项目，本地单元测试即等于服务端云调用结果的目的，但此框架未对广泛使用做特定优化，因此应用范围有限。
3. 数据库能力弱：每个云函数之间是隔离的，很难互相通信，或者说低成本通信，这个在数据库连接上尤为突出，传统的数据库连接池在serverless上基本失效，甚至我咨询了腾讯云SCF的内部后台人员，他们也没有合理、有效的解决方案。
4. 部署麻烦：腾讯云SCF最大的弊端就是部署更新的繁琐度，目前有两种部署方式（serverless framework cli和后台直接更新），SLS更新需要yaml配置文件，每个函数都需要独立yaml文件，文件内容不同且都需要暴露api key，因此项目中多个API时，其繁琐度导致效率非常低（根据我的实际经验和群友的说法）直接导致放弃使用SCF。我也是被迫自己开发了一套开发工具（simplescf）后才高效的开始使用serverless， 现在基本达到了一键点击秒级部署更新。

simplescf：我专门针对腾讯云SCF开发，实现了完全脱离腾讯云后台和繁琐的sls配置部署，采用一键式管理，全部可视化，包含了从开发、部署、运维、日志、层管理和团队协作。

此工具已经进行了三个大版本更新，每个版本均有理念级别的更新，第一个版本采用了我对serverless framework cli工具进行二次开发，所有配置采用GUI配置避免错误，不再需要yaml配置文件，取消了api key暴露问题，此版本具体介绍见http://simplescf.com。

第二个版本在开发完成尚未使用时被我直接抛弃，因为没有达到我心中“无需学习即可使用SCF”的目的。直接跳到第三版，完全修改了引导和使用，增加了一键部署到其他账户等功能，一定程度实现了目的。

以层为例：当前腾讯云的层使用很麻烦，比如多函数使用一个层时，若更新层则需要手动一个个的点击并更新，若删除也同样处理。

我的工具实现了函数绑定了层后：

1. 可以支持自动更新（层发布新版本，函数则自动同步更新，无需额外处理）。
2. 若想删除层，也可以支持所有函数自动解绑然后删除。
3. 若想降层版本，亦可实现绑定函数自动降版本。
4. 也支持将绑定了特定层的函数一键转移到其他版本。

以腾讯云的云函数为例，其他核心是SCF，但是封装的解决方案和产品太多了，五花八门，甚至微信云开发，其实就是对SCF的再次封装而已。

如何使用：

腾讯云的SCF最擅长的是计算，对文件上传等很是不合适和不适应，因此若想服务器采用serverless来开发，则不可以只依赖serverless，必须采用其他产品同时配合，最低的产品组合为：API网关+腾讯云存储COS+SCF+数据库。

COS：其中COS负责文件存储，尤其是文件的上传功能，使用COS的SDK来实现，不要通过SCF来进行转存，基本逻辑是通过COS的SDK上传后，将其链接地址再发送给SCF进行保存即可。不推荐将SCF的触发器配置到COS中自动触发，因为很容易造成异常执行。

白嫖逻辑：SCF有免费的使用量，对于访问量小的项目而言基本已经满足，COS是访问量收费，因此也容易控制成本，起码开发时时免费的。因此在白嫖中最大难度是数据库，腾讯云的TCB提供了免费数据库（每月有免费额度使用），基本也足够使用，不过最近他们降低了免费额。只是此数据库是mangodb的魔改版，不是关系型数据库，不太好使用，我甚至专门做了封装，实现了类似hibernate方式的调用，此后开发效率才开始高起来。

当API网关+腾讯云存储COS+SCF+TCB数据库搭配后，对于小规模应用可以说是近乎白嫖了，而对于访问量较大的而言，其性价比也是极高的，项目启动初期基本无需多大支持，而当业务量增大后，客户也舍得在服务器上进行支持了。Serverless可以让低工资的技术开发出高工资的技术才能实现的并发和稳定度，节省的成本已经足够填充服务器费用了。

我已经帮不少客户从传统服务器每年固定支出一万左右降至了使用serverless的一年服务费仅几百，甚至更低。

安全性：

最后说说安全性，对于互联网项目来说，安全是无法绕过的问题，远的说DDDOS攻击、系统攻击，近的说LOG4J攻击，使用serverless确实可以规避不少安全问题。

DDOS而言，现在的云服务器低成本的也只是安装防火墙，但是防火墙也只能在接收到数据包后才能处理，此时数据已经进来了，对系统已经产生了影响，再而言防火墙的封IP其实效果也不是那么好。系统攻击更好说了，serverless本质是购买计算能力而不是购买服务器，因此不存在系统攻击问题。

当采用微服务模式的时：

1. 腾讯云的SCF对整体的使用资源量进行了限制，因此遭遇攻击后，资源膨胀起来时，会迅速触碰到整体资源量限制，从而阻止资源的无限制扩张。
2. SCF可以设置单个函数的并发数（函数独占配额），当函数调用的并发数超过此限制后，即阻止此函数的资源膨胀，对Serverless的攻击是针对API的攻击，单个函数并发数的限制可以有效阻止攻击，若发现某个函数遭受攻击，直接设置为并发0，则攻击全部失效。
3. API网关实现了免费的基础攻击防御，经过配置后可以实现一部分的攻击防御。
4. 若实现了一键改部署，面临攻击时，我们也可以迅速停了当前的服务，重新部署一套出来，API网关也提供了免费的二级域名，无需还要进行备案等操作。

因此Serverless的机制合理使用，可以直接解决很大一部分攻击。

总结：

技术的趋势并非语言性能的越来越高效而是语言的越来越简化，开发速度的越来越高。我认为Serverless是符合发展趋势的，用马哲思想来说是新事物，是必然替代旧事务的，但不是直接替换，而是螺旋式上升，需要框架、工具等都跟上配套。

同时我个人认为他的率先使用是在小项目上，是被技术偏弱的人员所广泛采用，大型项目反而是谨慎保守的使用。