这是本人署名原创文章，未经容许不支持转载且请勿抄袭。本"大众年夜众号的所有文章均原创。本日聊些不一样的话题，如果您感兴趣，欢迎关注！
如何搞副业赢利、脱贫致富，我想这是诸位程序员都感兴趣的话题吧。毕竟，在任何互联网公司，技能都节制在程序员手里，真正干活的也是程序员，凭什么咱们加班干活，被改需求玩弄于鼓掌间，终极只拿到跟其他岗位差不多的人为呢？如下图所示。
如果真涌现上图情形，那我以为你完备可以凭借技能实力，在业余韶光做一些副业，脱贫致富。那么什么副业最赢利？个人认为，对付程序员来说，最赢利的副业还是开拓完备属于自己的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。只支配大略的做事。你恐怕不愿意手工配置几十上百个做事和函数吧？调用次数特殊频繁的做事一定不能用函数打算（例如，发送短之类的）。以上是本人经由大量实际调研得出的履历，紧张供参考，尤其是中小型企业和个人开拓者，当然，也包括搞副业的个人开拓者。可能有些不雅观点与实际不太符合，但是全都是站在开拓者自身的态度上，欢迎批评示正。其余，函数打算是刚兴起没多久的技能，在未来，云做事商可能针对函数打算推出新特性，让本文所述的问题不复存在。
