原创声明

这是本人署名原创文章，未经许可不支持转载且请勿抄袭。本公众号的所有文章均原创。今天聊些不一样的话题，如果您感兴趣，欢迎关注！

如何搞副业赚钱、脱贫致富，我想这是诸位程序员都感兴趣的话题吧。毕竟，在任何互联网公司，技术都掌握在程序员手里，真正干活的也是程序员，凭什么咱们加班干活，被改需求玩弄于鼓掌间，最终只拿到跟其他岗位差不多的工资呢？如下图所示。

如果真出现上图情况，那我觉得你完全可以凭借技术实力，在业余时间做一些副业，脱贫致富。那么什么副业最赚钱？个人认为，对于程序员来说，最赚钱的副业还是开发完全属于自己的APP，自己运营和分配收益（分配给自己呀），不过要求比较高，需要兼具客户端和后台开发技能。因为只有这样才不会利益分配不均，不会别人都看着你干活，结果大家分钱都一样的问题。等副业做大再变成主业。

那么，开发自己的APP必然涉及到开发APP客户端和后台服务。因为一个能为用户提供价值的APP，当它发展到一定程度之后，必然需要用到一些后端服务。此时，我们就需要考虑如何搭建后台服务的问题了。云计算技术的出现大大降低了我们搞副业的门槛和成本，所以现在是一个非常有利的时机。例如，云服务器提供了弹性计算服务，可以降低IT成本（购买服务器、网络设备、带宽支出等），提升运维效率（不用自己安装操作系统，调试硬件等），我们只需专注于自己的核心业务即可，这不正是为程序员搞副业准备的有利条件吗？

那么怎么基于云计算技术来搭建后台服务呢？我们先来看一下目前有哪些方案。到目前为止，基于云计算搭建后台服务，可供选择的技术方案有云虚拟机、云服务器、容器服务和Serverless这4种选择。Java Magazine在2018年11-12月刊中针对Java开发者对这4种方案的使用情况作了一次统计，如下图所示。

在这些方案中，函数计算服务（即Serverless，有的供应商称为函数托管、函数服务等）是一种最近兴起的、基于Serverless的云服务，可以认为是第4代云计算技术（如下图所示）。其中，Serverless强势来袭，已经迅速占据了近10%的开发者份额，值得关注。我们分析一下基于Serverless技术搭建后台服务这种方案的优缺点有哪些，成本问题、性能问题，扩展性如何？迁移到其他技术方案的改造难度如何等。

我们如果想搭建后台服务，尽可能缩减各类成本，例如开发成本、运维成本、管理成本等，尤其是后台服务处于闲置状态而产生的不必要支出（如果我们租用云服务器或云虚拟机，不管服务是否被使用都要付钱），那么非常有必要研究一下函数计算这种新型云服务。

什么是函数计算

函数计算（Function Compute）是基于Serverless技术发展出来的一种事件驱动的、全托管式计算服务。使用函数计算服务后，我们无需管理服务器等基础设施，只需编写代码并且上传即可。函数计算服务会自动为我们准备好计算资源，并且以弹性的、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能。我们只需要为代码实际运行所消耗的资源付费，代码没有运行则不产生费用。以上特性总结成要点如下：

无需维护服务器等基础设施直接上传代码执行事件驱动方式执行按照实际运行情况计费，不运行则不产生费用自动准备计算资源以弹性可靠的方式执行函数计算的优缺点及风险

初步看上去，函数计算所提供的云服务非常美好，看上去既便宜又人性化，计费粒度很细，不需要创建服务器、搭建项目框架，可以极大提高开发效率，甚至当代码不运行的时候都不必付费。不过我们还是需要仔细分析一下函数计算，看它的优势到底怎样、有哪些风险。

首先，它的第1个优势是代码全托管，指的是无需管理、运维服务器，仅仅上传代码即可，让函数计算负责维护。这等于说是程序框架都帮我们搭建好了，我们只需要写业务领域的代码就行了（程序员职业生存空间再次被挤压？）。这个特性的确可以降低运维成本，因为开发速度可以更快，我们从对基础设施的管理工作中解放出来、节省了时间精力。但是这种部署方式会有什么风险呢？

假如它需要上传未编译源码而不是编译后代码，那么代码可能被他人看到。对于使用Node.js、PHP及Python等编程语言开发的项目来说，该问题值得关注。若是上传编译后代码，云服务后台也可能扫描、分析、篡改代码，导致核心业务的某些关键信息有被泄露的风险，或者被植入广告（不过可能性较小）。代码可能需要与云服务提供方API耦合，降低可移植性，增加迁移至其他平台的成本。所以，如果采用该方案，我们需要在本地项目中增加一个抽象层，隔离函数计算API。上传的代码在一个受限的环境中执行，不能随意访问一些系统资源，文件访问受到限制，这可能导致一些因为部署环境的问题而引发的bug，而且此类bug很难定位。

针对以上风险1和2，好消息是云服务商一般会提供代码加密和完整性校验功能，代码会被加密存储，至少不会被第三方看到（依然可被云服务商看到，如果不放心，可以在部署之前对代码做一些混淆加密）。而针对风险3，需要做好项目的分层架构，尽量把跟云服务API隔离；而针对风险4，目前也没有发现有什么好的解决办法，只能靠云服务商的日志和监控来定位问题，另外，尽量把代码写得简单清晰一些可以减少碰到此类问题的概率。

其次，该技术的另一个特性是按需付费。这种付费模式与租用云服务器或云虚拟机的模式不同，它是根据代码调用次数和执行时间计费的。对于这种特性，如果其计费模式、单价合理的话，那必然是一大好处，可以大大降低成本。如果计费不合理，例如单位调用次数或单位执行时间的价格设定得太高，反而会导致成本更高。此外，如果平台没有提供没有限流、防刷等保护策略，这种按调用次数和时间付费的模式还会造成资金损失。所以，针对这些问题，在采用函数计算之前，要详细研究云平台是否提供保护机制，而且还要让自己的服务不被恶意调用，此外还要给自己的代码设置好配置开关，当遇到风险时能够紧急应对（例如暂时关闭服务减少损失等）。

然后，函数计算应用的运行方式是事件驱动。做过后台开发的程序员都知道，Web应用一般需要先启动，执行一些初始化工作，然后常驻内存运行，等请求到来以后再处理每个请求，这样请求处理的延迟会比较低。那么函数计算这种事件驱动的方式显然改变了原来的执行方式，并且考虑到它"按需付费，不使用则不产生费用"，很可能是在第一次访问服务的时候再延迟初始化你的服务，当服务有较长一段空闲时间后，服务会被杀死。这在某些情况下可能会影响用户体验，所以在函数计算上部署的服务要轻量化一些。另外，除了需要上传代码，需要手动在云平台的管理界面上创建触发器、服务、函数等，手动操作比较多而且麻烦，不便于迁移，并且还容易被平台绑架，甚至遇到"杀熟"问题。

最后，该技术还支持弹性伸缩特性，可以实现毫秒级别的弹性伸缩和动态负载均衡，有效应对突发访问。这种特性保证了服务的高可用性，让服务稳定连续运行。这一点很好，但是云服务商真的会对你的应用负载给予很多支持吗？还有一种可能的风险就是，如果有人恶意发送大量请求，而云服务供应商又不提供限流、防刷等技术保障措施的话，那么就会产生很大风险。这意味着丧失了服务性能的自主控制权，把对性能优化等职责完全交给云服务商。

函数计算能构建什么类型的服务？

技术架构选型对应用有重大影响，所以在决定是否基于函数计算搭建后台服务之前，先要弄清楚它究竟可以开发哪种类型的服务，它能支撑起其何种复杂度的应用。用函数计算可以开发出一个非常复杂的电商平台，还是只能实现一些简单、轻量级服务？也许对于中小型开发者来说，一开始只需开发一个简单应用，但是当业务逻辑越来越复杂后，我们需要知道，用函数计算搭建的后端服务是否组织清晰、易于管理、性能有足够高的伸缩性。

针对这个问题，某云服务供应商有一段说明，"您可以快速构建任何类型的应用和服务，无需管理和运维"。我们都知道广告不能轻易相信，这个问题需要自己深入研究。我们前面分析过了，函数计算不适合部署敏感业务（因为担心泄密），而且有性能风险和难以定位bug的问题，所以只适合部署轻量级服务；它要求应用接入云平台API，导致业务代码被侵入，而且还要求在控制界面中手动配置服务和函数信息，这会增加迁移至其他平台的工作量，所以也不适合比较复杂的服务；再者，函数计算平台支持的编程语言较少，仅支持PHP、Python、Node.js和Java（Java还是OpenJDK执行环境）等，每个函数都有内存和最大执行时间等限制。所以，我们自己分析调研得出结论，函数计算并不能部署"任何类型的应用和服务"，而只适合简单、轻量级业务服务。

基于函数计算的开发步骤

假如打算采用函数计算搭建后台业务，那么代码的组织将以服务和函数为最小单位。实际上，函数计算与微服务架构对应。下面这张图是在某云服务供应商的帮助文档中找到的，从图中可以看出，基本上是以函数为最小单元，每次开发一个函数即可。

函数计算的执行环境

分析了某些云平台提供的函数计算服务，发现有这些限制：每个函数的内存使用量有最大限制，只能访问 /tmp目录下的所有文件，磁盘空间使用量也有最大限制，每个函数最大执行时间有限制（例如3秒）等。初步分析以后，感觉应该还是够用的。

适合的应用场景

根据网上的一些博客和文章，我搜集到一些可能的适用场景，例如静态网站管理、WordPress、个人媒体服务器(less!)、物联网Iot或家庭自动框架或项目等。个人认为，一些比较简单的、轻量级后台业务逻辑也可以用Serverless实现。

最终结论

最后总结下，函数计算虽然简化了开发过程、也降低了成本，但是可能让开发者感到没有必要学习后台、架构、分布式等知识，是一把双刃剑。假如业务发展到一定复杂度后，完全由云服务供应商控制计算资源可能影响服务运行。根据前面对函数计算的所有分析研究，个人认为，函数计算学习成本较低、开发速度快且无需管理服务器，比较适合项目初期。初期设计好项目结构，把依赖云服务API的部分隔离出来，等到以后服务越来越复杂之后，再迁移到其他平台就会容易很多。

假如你打算实际动手开发基于函数计算的后台服务，那么注意做好以下几点：

保护代码安全。在必要时，做好代码混淆保护。做好分层架构，把云平台的函数计算API隔离到一个单独的地方。为将来升级到云服务器做好准备。用文档记录部署过程。函数计算需要你在控制台中手动操作创建函数和服务，然后上传代码。如果步骤较多，则容易遗忘。当你对平台形成依赖，平台开始"杀熟"的时候，你迁移到其他平台时，如果没有文档会很麻烦。只部署轻量级的服务，函数计算基于事件驱动运行方式，也便于调试bug。只部署简单的服务。你恐怕不愿意手工配置几十上百个服务和函数吧？调用次数特别频繁的服务一定不能用函数计算（例如，发送短消息之类的）。

以上是本人经过大量实际调研得出的经验，主要供参考，尤其是中小型企业和个人开发者，当然，也包括搞副业的个人开发者。可能有些观点与实际不太符合，但是全都是站在开发者自身的立场上，欢迎批评指正。另外，函数计算是刚兴起没多久的技术，在未来，云服务商可能针对函数计算推出新特性，让本文所述的问题不复存在。