Serverless落地学习路线：我是怎么入门的

最近半年，一直在研究Serverless，从最开始的一脸懵，到现在能在项目中落地，走了不少弯路，也积累了一些经验。

Serverless这两年，很火，很多人都在讨论，说它是云的下一个时代，能让开发者，只关注业务逻辑，不用管服务器，不用管运维，不用管扩缩容，听起来很美好。但真正入门，才发现，Serverless不是银弹，有它的优势，也有它的局限，要落地，还是有不少坑要踩的。

今天这篇文章，就来分享一下，我的Serverless落地学习路线，我是怎么入门的，踩了哪些坑，有哪些经验，希望能给想学习Serverless的朋友一些参考。

一、我为什么要学Serverless

先说说，我为什么要学Serverless。

最开始，是因为公司的一个项目，要做一个活动页面，流量不稳定，平时没什么流量，活动的时候，流量会突然暴涨，可能是平时的几十倍，甚至上百倍。

如果用传统的架构，买服务器，搭环境，部署应用，那平时，服务器大部分时间，都是闲置的，浪费钱；活动的时候，流量暴涨，服务器又扛不住，要临时扩容，很麻烦，也来不及。

这时候，有人推荐，用Serverless，说Serverless，按量付费，没流量的时候，不花钱；流量来了，自动扩容，能扛住高并发，而且，不用管服务器，不用管运维，很适合这种，流量波动大的场景。

就这样，我开始接触Serverless，最开始，是抱着试一试的心态，没想到，一研究，就发现，Serverless确实很有意思，也很有前景，就开始系统地学习，然后，在项目中落地，一路走来，收获很多。

二、什么是Serverless

在说学习路线之前，先简单说说，什么是Serverless，很多人，刚接触的时候，都会有误解，以为Serverless，就是没有服务器，其实不是的。

Serverless，翻译过来，是无服务器架构，但不是说，真的没有服务器，而是说，开发者，不需要关心服务器，不需要管理服务器，服务器的事情，都交给云厂商来做，开发者，只需要写业务代码，上传上去，就能运行，其他的，比如服务器的购买、配置、运维、扩缩容、容错，都不用管。

Serverless，主要包含两个部分，一个是FaaS（Function as a Service，函数即服务），另一个是BaaS（Backend as a Service，后端即服务）。

FaaS，就是把业务逻辑，写成一个个函数，上传到云平台，事件触发的时候，函数就执行，执行完，就释放资源，按执行的次数和时间，付费。比如，AWS Lambda、阿里云函数计算、腾讯云SCF、Azure Functions，这些都是FaaS。

BaaS，就是把后端的一些通用能力，做成服务，直接调用，不用自己开发和维护，比如，数据库、存储、消息队列、用户认证、短信服务、邮件服务等，这些，都可以用云厂商提供的BaaS服务，直接调用，不用自己搭。

Serverless的核心思想，就是让开发者，只关注业务逻辑，其他的，都交给云平台，这样，能大大提高开发效率，降低运维成本，也能更好地应对，流量的波动。

当然，Serverless，也不是万能的，它有它的适用场景，也有它的局限，后面会详细说。

三、我的学习路线：从入门到落地

我的Serverless学习路线，大概分为四个阶段，入门、深入、实战、落地，每个阶段，都有不同的重点，也踩了不同的坑。

第一阶段：入门，搞清楚基本概念

最开始，是入门阶段，主要是搞清楚，Serverless的基本概念，它是什么，能做什么，有什么优势，有什么局限。

这个阶段，我主要做了这几件事：

看官方文档：我选的是阿里云函数计算，因为国内的云厂商，阿里云的Serverless，做得比较早，也比较成熟，文档也比较全。我先把阿里云函数计算的官方文档，从头到尾，看了一遍，搞清楚了，基本概念、核心功能、使用方法、计费方式等。
看入门教程：除了官方文档，我还看了一些，入门教程和博客，了解别人是怎么入门的，有哪些注意事项，少走一些弯路。
跑第一个函数：看完文档和教程，我就动手，写了第一个函数，一个简单的Hello World，部署到阿里云函数计算，然后，触发它，看返回结果，成功之后，很有成就感，也对Serverless，有了直观的认识。
了解Serverless的适用场景和局限：入门的时候，一定要搞清楚，Serverless，适合什么场景，不适合什么场景，不要觉得，Serverless是银弹，什么都能做。比如，Serverless，适合流量波动大、事件驱动、短时运行的场景，不适合长时间运行、对延迟要求极高、有状态的场景。

这个阶段，大概花了一两周，主要是建立对Serverless的基本认识，搞清楚，它是什么，能做什么，不能做什么。

第二阶段：深入，理解核心原理和机制

入门之后，就进入了深入阶段，这个阶段，主要是理解Serverless的核心原理和机制，比如，函数的执行机制、冷启动、触发器、计费、调试、部署等。

这个阶段，我主要做了这几件事：

深入理解函数的执行机制：Serverless的函数，是事件触发的，事件来了，函数就启动，执行，执行完，就释放，不是一直运行的。这个机制，和传统的，一直运行的应用，很不一样，要深入理解，函数的生命周期，是怎么样的，什么时候启动，什么时候释放，实例是怎么复用的，这些，对后面的开发和优化，很重要。
搞懂冷启动：冷启动，是Serverless里，一个很重要的概念，也是一个很常见的问题。函数，第一次执行，或者很久没执行之后，再执行，需要重新启动实例，加载代码，初始化运行环境，这个过程，就是冷启动，冷启动，会导致延迟增加，影响用户体验。要搞懂，冷启动，是怎么产生的，有哪些因素，会影响冷启动的时间，怎么优化冷启动，这些，是Serverless开发中，必须要掌握的。
了解各种触发器：Serverless的函数，是由事件触发的，触发器，有很多种，比如HTTP触发器、定时触发器、对象存储触发器、消息队列触发器、数据库触发器等，每种触发器，都有不同的使用场景和配置方法，要了解，每种触发器，是怎么用的，适合什么场景，这样，在开发的时候，才能选择合适的触发器。
学会调试和部署：Serverless的调试和部署，和传统的应用，不太一样，因为函数，是运行在云平台上的，本地调试，和云端调试，都有一些特殊的方法。要学会，怎么在本地调试函数，怎么在云端调试函数，怎么部署函数，怎么版本管理，怎么灰度发布，这些，都是实际开发中，必须要掌握的。
了解计费方式，控制成本：Serverless，是按量付费的，用多少，付多少，虽然便宜，但如果不注意，也可能会产生，意想不到的费用。要了解，计费的方式，是按什么计费的，有哪些免费额度，怎么监控费用，怎么控制成本，避免，账单出来的时候，吓一跳。

这个阶段，大概花了一个月左右，主要是深入理解Serverless的核心原理和机制，掌握开发和调试的方法，为后面的实战，打下基础。

第三阶段：实战，做几个小项目

深入理解之后，就进入了实战阶段，这个阶段，主要是动手，做几个小项目，把学到的东西，用起来，在实战中，加深理解，积累经验。

这个阶段，我做了这几个小项目：

做一个简单的API接口：用HTTP触发器，做一个简单的API接口，比如，天气查询、翻译、短链接生成等，练习，函数的开发、部署、调试，以及，和第三方API的对接。
做一个定时任务：用定时触发器，做一个定时任务，比如，每天定时爬取数据，定时发送邮件，定时备份数据等，练习，定时触发器的使用，以及，函数的异常处理和重试机制。
做一个文件处理的应用：用对象存储触发器，做一个文件处理的应用，比如，用户上传图片，自动生成缩略图，自动加水印，自动压缩；用户上传视频，自动转码，自动截取封面等，练习，对象存储触发器的使用，以及，大文件处理的方法。
做一个简单的Web应用：用Serverless，做一个简单的Web应用，比如，留言板、待办事项、博客等，练习，用Serverless，做完整的Web应用，包括，前端、后端、数据库、存储等，了解，Serverless架构下，Web应用，是怎么开发和部署的。

这个阶段，大概花了一两个月，做了几个小项目，每个项目，都不大，但都覆盖了，Serverless的不同功能和场景，在实战中，踩了很多坑，也积累了很多经验，对Serverless的理解，也更深入了。

第四阶段：落地，在真实项目中使用

实战之后，就进入了落地阶段，这个阶段，主要是在真实的项目中，使用Serverless，解决实际的问题，在真实的场景中，检验学习的成果，也发现更多的问题，积累更多的经验。

我落地的第一个项目，就是最开始说的，那个活动页面，流量波动大，用Serverless，做后端的API接口，以及，一些图片处理的功能，效果很好，平时没流量，不花钱，活动的时候，流量来了，自动扩容，扛住了高并发，而且，开发速度很快，运维成本很低，第一次落地，就尝到了甜头。

后来，又在其他项目中，落地了Serverless，比如，定时任务、数据处理、消息通知、小程序后端等，越来越多的场景，开始用Serverless，也积累了更多的落地经验。

这个阶段，是持续的，一直在落地，一直在优化，也一直在学习，因为，Serverless，还在快速发展，新的功能，新的特性，不断出来，需要不断地学习，不断地实践。

四、学习Serverless，踩过的坑

在学习和落地Serverless的过程中，踩了很多坑，这里，分享几个，比较常见的坑，希望大家，能避免。

1. 冷启动的坑

冷启动，是Serverless最常见的坑，也是最影响体验的坑。函数，第一次执行，或者很久没执行之后，再执行，会有冷启动，延迟增加，用户体验不好，尤其是，对延迟要求高的场景，比如，API接口，冷启动，可能会导致，用户等待很久，甚至超时。

我最开始，做API接口的时候，就遇到了这个问题，用户第一次访问，要等好几秒，体验很差，后来，用了几种方法，优化冷启动，才解决了这个问题。

优化冷启动的方法，主要有这几个：

减少代码包的大小：代码包越小，加载越快，冷启动时间越短，要尽量，减少依赖，只打包需要的代码和文件。
选择合适的运行时：不同的运行时，冷启动时间不一样，比如，Node.js、Python，冷启动比较快，Java、.NET，冷启动比较慢，对延迟要求高的场景，尽量选，冷启动快的运行时。
预留实例：云厂商，一般都提供，预留实例的功能，可以预留一定数量的实例，一直运行，不会被释放，这样，就不会有冷启动了，但预留实例，是要收费的，相当于，买了常驻的服务器，成本会增加。
定时预热：可以用定时触发器，每隔一段时间，就调用一次函数，让实例，保持活跃，不会被释放，这样，也能避免冷启动，而且，成本很低，因为，调用函数的费用，很少。

2. 函数执行时间的限制

Serverless的函数，是有执行时间限制的，不同的云厂商，限制不一样，一般是，几分钟到十几分钟，超过时间，函数就会被强制终止。

我最开始，做一个数据处理的函数，处理大量的数据，执行时间，超过了限制，函数被强制终止，数据处理了一半，就停了，结果，数据不完整，出了问题。

后来，才知道，函数有执行时间的限制，不能用来，处理长时间的任务，对于长时间的任务，要拆分，分成多个小任务，或者，用其他的方式，比如，消息队列，异步处理，或者，用容器服务，来处理长时间的任务。

所以，在开发之前，一定要搞清楚，函数的执行时间限制，以及，其他的限制，比如，内存限制、代码包大小限制、并发限制等，避免，开发到一半，才发现，超出了限制，要返工。

3. 有状态的问题

Serverless的函数，是无状态的，函数执行完，实例就释放了，下一次执行，可能是一个新的实例，所以，不能在函数的内存里，保存状态，比如，全局变量、缓存、连接等，这些，在函数执行完之后，就可能丢失了，下一次执行，就没有了。

我最开始，就犯了这个错误，在函数里，用了一个全局变量，来缓存数据，结果，函数执行完，实例释放了，下一次执行，全局变量，就没了，缓存失效了，数据，又要重新加载，性能很差。

后来，才知道，Serverless的函数，是无状态的，不能在内存里保存状态，状态，要保存在外部，比如，数据库、缓存、对象存储等，函数执行的时候，从外部读取状态，执行完，把状态，存回外部。

而且，数据库连接，也是一样，不能在函数里，保存长连接，因为，函数执行完，实例释放了，连接也就断了，下一次执行，要重新建立连接，这样，性能很差，也可能会导致，数据库连接数过多，把数据库打挂。

对于数据库连接，一般有几种处理方式：

每次执行，建立连接，执行完，关闭连接：这种方式，简单，但性能差，每次都要建立连接，开销大。
用连接池，在实例复用时，复用连接：函数的实例，有时候会复用，实例复用时，连接池里的连接，也可以复用，这样，能提高性能，但要注意，实例不复用时，连接就失效了。
用Serverless专用的数据库代理：有些云厂商，提供了，Serverless专用的数据库代理，能管理连接，复用连接，提高性能，这种方式，比较推荐。

4. 调试的坑

Serverless的调试，比传统的应用，要麻烦一些，因为函数，是运行在云平台上的，本地的环境，和云端的环境，可能不一样，本地调试没问题，云端可能就有问题。

我最开始，调试函数，都是改完代码，部署到云端，然后，在云端测试，看日志，这样，效率很低，改一点代码，就要部署一次，很麻烦。

后来，学会了本地调试，用云厂商提供的，本地调试工具，在本地，模拟云端的环境，调试函数，这样，效率高了很多，改完代码，马上就能在本地调试，不用每次都部署。

但本地调试，也有局限，有些云端的服务，本地模拟不了，比如，对象存储触发器、消息队列触发器等，这些，还是要在云端调试。

所以，调试Serverless函数，要结合，本地调试和云端调试，简单的逻辑，在本地调试，复杂的，和云端服务相关的，在云端调试，这样，效率最高。

5. 监控和排错的坑

Serverless的函数，是事件触发的，执行完，就释放了，出了问题，怎么监控，怎么排错，也是一个坑。

我最开始，函数出了问题，不知道怎么排查，只能看日志，但日志很多，很分散，找起来很麻烦，而且，有些问题，日志里也看不出来，比如，性能问题，并发问题，冷启动问题等。

后来，才知道，Serverless，有专门的监控和排错工具，云厂商，一般都提供，函数的监控面板，能看到，函数的调用次数、执行时间、错误率、并发数等，还有，分布式追踪工具，能追踪，函数的调用链，看每个环节，花了多少时间，哪里出了问题。

而且，函数里，要打日志，关键的地方，要打日志，出了问题，才能通过日志，快速定位问题。日志，要规范，要有级别，比如，INFO、WARN、ERROR，方便查找和过滤。

所以，开发Serverless函数，一定要重视，监控和日志，做好监控，打好日志，出了问题，才能快速定位，快速解决。

五、Serverless的适用场景和局限

学习和落地了这么久，我觉得，Serverless，确实有很多优势，但也不是万能的，有它的适用场景，也有它的局限，要客观地看待，不要盲目跟风。

Serverless的优势：

不用管服务器和运维：开发者，只需要写业务代码，服务器的购买、配置、运维、扩缩容、容错，都不用管，大大降低了运维成本，也提高了开发效率。
按量付费，成本低：Serverless，是按执行的次数和时间，付费的，没流量的时候，不花钱，流量来了，才花钱，对于，流量波动大的场景，成本很低，比买服务器，划算很多。
自动扩缩容，能扛高并发：Serverless，能根据流量，自动扩缩容，流量来了，自动增加实例，流量走了，自动减少实例，能扛住高并发，也不会浪费资源。
开发效率高，能快速上线：Serverless，不用管服务器和运维，只需要写业务代码，开发效率很高，能快速上线，很适合，快速迭代，验证想法。
高可用，容错性好：云厂商，一般会保证，Serverless的高可用，函数，会部署在多个可用区，某个可用区出问题，其他可用区，还能继续服务，容错性很好。

Serverless的局限：

冷启动问题：函数，第一次执行，或者很久没执行之后，再执行，会有冷启动，延迟增加，影响用户体验，虽然可以优化，但不能完全避免。
执行时间和资源有限制：函数，有执行时间限制，一般是几分钟到十几分钟，不能用来，处理长时间的任务；还有，内存、代码包大小、并发数等，也有限制，不适合，复杂的、大型的应用。
不适合有状态的应用：函数，是无状态的，状态，要保存在外部，不适合，有状态的应用，比如，长连接、WebSocket、实时通信等，这些场景，用Serverless，会比较麻烦。
调试和排错比较麻烦：函数，运行在云平台上，本地调试，和云端调试，都有一些局限，调试和排错，比传统的应用，要麻烦一些。
厂商绑定问题：不同的云厂商，Serverless的实现，不太一样，函数的接口、触发器、配置，都有差异，用了某个云厂商的Serverless，再想迁移到其他厂商，会比较麻烦，有厂商绑定的问题。
不适合长时间运行的应用：函数，是短时运行的，执行完，就释放，不适合，长时间运行的应用，比如，Web应用的后端服务，一直运行的，用Serverless，成本可能会更高，也可能会有冷启动的问题。

Serverless的适用场景：

流量波动大的场景，比如，活动页面、营销系统、节假日的接口等。
事件驱动的场景，比如，文件上传处理、定时任务、消息通知、数据同步等。
短时运行的场景，比如，API接口、数据处理、图片处理、视频转码等。
快速迭代、验证想法的场景，比如，创业项目、MVP、内部工具等。
低流量的场景，比如，个人博客、小工具、小程序后端等，成本很低。

不适合的场景：

长时间运行的应用，比如，一直运行的后端服务、长连接应用等。
对延迟要求极高的场景，冷启动，会影响延迟。
复杂的、大型的应用，函数的限制，可能满足不了。
有状态的应用，比如，实时通信、游戏后端等。

所以，Serverless，不是银弹，不是什么都能做，要根据场景，选择合适的架构，不要盲目跟风，为了用Serverless而用Serverless。

六、给想学习Serverless的朋友的建议

最后，给想学习Serverless的朋友，一些建议：

1. 先搞清楚基本概念，不要上来就写代码

学习Serverless，先搞清楚，基本概念，它是什么，能做什么，有什么优势，有什么局限，适用什么场景，不适用什么场景，这些，搞清楚了，再动手写代码，不然，很容易，用错场景，踩很多坑。

2. 选一个云厂商，系统地学习

国内的云厂商，阿里云、腾讯云、华为云，都有Serverless服务，选一个，系统地学习，看官方文档，看教程，做练习，把一个云厂商的Serverless，学透了，其他的，也就触类旁通了。

3. 多动手，多实战

Serverless，是一门实践的技术，光看文档，光看教程，是学不会的，一定要多动手，多实战，做几个小项目，在实战中，加深理解，积累经验，踩过的坑，都是宝贵的经验。

4. 不要怕踩坑，踩坑是最好的学习

学习Serverless，肯定会踩很多坑，冷启动、执行时间限制、有状态的问题、调试的问题等，这些坑，都是正常的，不要怕，踩坑的过程，就是学习的过程，踩过的坑，越多，理解就越深，经验就越丰富。

5. 客观看待，不要盲目跟风

Serverless，确实有很多优势，但也不是万能的，有它的适用场景，也有它的局限，要客观地看待，不要盲目跟风，不要觉得，Serverless是下一个时代，就什么都用Serverless，要根据场景，选择合适的架构。

6. 关注社区，持续学习

Serverless，还在快速发展，新的功能，新的特性，新的框架，不断出来，要关注社区，关注技术动态，持续学习，不断更新自己的知识，才能跟上技术的发展。

七、写在最后

学习和落地Serverless，这半年，走了不少弯路，也踩了不少坑，但收获，也很多，不仅学会了一门新技术，更重要的是，对云计算，对架构，有了新的理解，新的认识。

Serverless，确实是一个，很有前景的技术，它让开发者，从服务器和运维中，解放出来，只关注业务逻辑，大大提高了开发效率，降低了运维成本，也让很多，以前做起来很麻烦的事情，变得简单了。

但Serverless，也不是银弹，不是什么都能做，有它的适用场景，也有它的局限，要客观地看待，根据场景，选择合适的架构，不要盲目跟风。

未来，随着技术的发展，Serverless，会越来越成熟，越来越完善，适用的场景，也会越来越多，我相信，Serverless，会成为云计算的一个重要方向，也会改变，我们开发应用的方式。

最后，用一句话，来结束这篇文章："技术，没有最好的，只有最合适的，Serverless也是一样，选对场景，用对地方，才能发挥它的最大价值。"希望这篇文章，能给想学习Serverless的朋友，一些参考和启发，也欢迎大家，在评论区，分享自己学习Serverless的经验和问题，一起交流讨论。