引发学习革命的技术变革：论Serverless架构的深远意义

1、Serverless必将引发学习革命

由于IT领域的特点是“知识密集+问题密集”，知识繁多，技术更新很快，平时在上手练习的会遇到各种各样的问题，所以很多人把“解决问题”当做提升自我的关键途径。实际上，很多人把解决问题当做了提升自我的方式，这种思想大错特错。在工作中，很多情况下，我们碰到的问题都是工程类型的问题，例如：软件版本兼容问题，类库引用问题，配置参数问题。这种工程类的问题占据了我们大量的时间，虽然此类问题看似紧急，但是并不重要，对知识的积累往往不会产生多大的价值，试问哪个面试官会考察软件的安装，调试，升级呢？

如今Serverless架构已经喷薄而出，必将意义深远，引发一场学习革命。采用无服务器架构之后，工程问题将会大幅度的减少，从此之后，我们将从“问题密集”的现状中逃离苦海，专攻于“知识密集”，从而实现自我能力的飞跃式提升。

备注：熟悉网站的朋友一定对站长提出的“红黑鸟学习法”有所印象。正是因为工作中出现了太多的工程问题让人迷失了学习方向，而Serverless架构将会大幅度减少工作中碰到的工程问题。所以，站长认为Serverless将会引发一场学习革命。

2、什么是 Serverless

Serverless 架构，顾名思义为“无服务器架构”，是最近几年新冒出来的一种架构风格。无服务器，就是真的没有服务器了么？其实不然，对于 Serverless 来说，只是用户不用更多的去考虑服务器的相关内容了，无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题了。同时，也无需再对服务器进行运维了，无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。

用过阿里云的人都深有体会，触目惊心的漏洞和安全风险，总是人的心不得安宁，时常在半夜被告警短信所惊醒：

而Serverless 架构则可以高枕无忧，一觉睡到大天亮，岂不乐哉。

话又说回来，没有服务器，如何来将程序、应用运行起来呢？这里要介绍的是Serverless架构包含的两个概念：函数即服务，Function as a Service，FaaS；后端即服务，Backend as a Service，BaaS。

3、函数即服务 FaaS

函数即服务 FaaS，作为一种新的计算能力提供方式，让用户抛弃了对服务器的配置和管理，仅需编写和上传核心业务代码，交由平台完成部署、调度、流量分发、弹性伸缩等能力。FaaS 的出现，会从底层开始变革计算资源的形态，提供了一种新的方式来提供计算资源，同时也会给软件架构与应用服务部署带来新的设计思路，进一步降低云计算的使用门槛，推动全行业在服务架构上的创新步伐。

4、后端即服务 BaaS

后端即服务 BaaS，其实大家已经使用很久了，这里的后端，指的就是各种云产品和云服务，例如对象存储 COS，消息队列 CMQ，云数据库 CDB，云缓存 CRedis，甚至到各种以 API 形式提供的服务。这些产品或服务，用户直接开通即可使用，无需考虑部署、扩容、备份、优化、安全等各种运维工作，做到了开箱即用，无需自己去进行服务器或应用的维护和管理，因此同样也是Serverless的一部分。

5、为什么要 Serverless

介绍了什么是 Serverless，但是为什么会出现 Serverless，或者为什么要使用 Serverless 呢？我们可以从三个方面来看看，这三个方面可以类比为：天时，地利，人和。

天时，这里突出的时，即时间。传统的服务器模式，应用上线前，还得完成服务器准备，环境部署，数据库准备，存储准备等各种工作；上线后，还得面临计算扩容，存储扩容，数据库维护和扩容等各种运维工作。这这个过程中，应用上线和迭代的时间、节奏，受限于各种准备和维护工作。而利用 Serverless，通过使用云函数（Serverless Cloud Function，SCF），专注于完成业务相关的核心代码，通过直接使用 COS，CDB，CMQ，CRedis 等产品，解决数据存储，数据库，消息队列，缓存等问题，不再费心运维，而专注在业务开发和迭代上，能更快的完成应用上线，在这个互联网加速发展的时代，做到一步领先，步步领先。

地利，这里突出的利，即费用支出。传统的服务器模式，无论有没有用户正在访问，应用始终要保持运行，而在有用户访问时，又要关注服务器的资源使用率，在使用率达到一定程度时就要考虑扩容，避免突发访问量导致的资源不足。在这个过程中的费用，始终是有一部分为未使用的计算资源而支付。而 Serverless 架构，能确保所有的费用，都是用在了实际的程序运行、数据存储、用户访问中。云函数（Serverless Cloud Function，SCF）的计费方式，就是通过函数的调用次数和执行时间来统计费用，有用户访问或事件产生，才会有函数执行，才会有费用计算；相反，没有函数执行时，则没有费用支出。同理，其他的相关云产品，也是类似，例如 COS 仅收取存储、外网流量的费用，CMQ 仅收取请求次数、外网流量费用，CRedis 仅按实际使用内存大小收费。据测算，根据不同用户的应用压力情况，Serverless能为用户带来 30%~70% 的费用节省程度。

人和，这里突出的是人。传统的服务器模式，运维人员要投入大量的精力去维护服务器、数据库、存储等各种基础设施，解决各种集群、分布式系统的搭建问题，而实际运维解决自身应用问题的时间，可能只会占到很小一部分，而开发人员除了对自身业务应用的开发外，也需要投入时间，解决可能存在的各种外围系统的问题。而 Serverless 架构，无需运维人员再投入到基础设施中去了，而开发人员也可以全面关注业务系统的开发。Serverless产品，可以让开发人员直接编写业务逻辑核心代码，利用微服务架构，快速上线应用。CMQ，CDB，COS，CRedis 各种云产品，无需搭建配置，开通即可使用，而将基础运维工作交由云来完成。在这种情况下，脱离了基础运维的运维人员，可以提升自身视野，从更高角度来看待运维工作，实现业务运维；而开发人员，可以充分利用 Serverless 架构，提升整个应用或业务的集成能力。

6、怎么用 Serverless

COS、CMQ、CDB、CRedis 这类 BaaS 型云产品，由于面世的时间已经很长，对其使用的方式，基本和原有使用 MySQL、Redis 等产品相同，或者通过产品提供的 API、SDK 直接访问使用。而 SCF 云函数，作为 FaaS 产品，有着稍有不同的使用方式。

事件触发：云函数（Serverless Cloud Function，SCF）的工作模式为事件触发，因此要考虑好触发方式。例如，利用 SCF 来处理图片生成缩略图，就可以利用 COS 事件，在图片文件上传 COS 后，上传事件就能自动触发函数执行，来生成新的缩略图并再次存入 COS 中。

无状态服务：函数需要是无状态（Stateless）的，缓存、日志、数据库等全部通过 CRedis、COS、CDB 这类云产品来支持，这样才能保证在业务请求突增时服务能迅速扩展。

微服务：事件驱动（Event-Driven）和无状态（Stateless）属性正是微服务架构所需要的。因此，在一开始就将自身的应用设计为微服务架构，解耦各模块间关联，使得应用成为可生长可进化的系统。

无服务器云函数：云函数（Serverless Cloud Function，SCF） 实现独立开发、简化测试和加速部署，能够助力公司在关键时期快速上线和迭代，为初创期的产品提供了很好的解决方案。

7、参考与创新点

本文参考自腾讯云团队发表的相关技术文档，然后融入了站长自身的工作经历，最后将Serverless架构出现的技术变革上升到学习革命。从技术变革升华为学习革命，即是本文的创新点。