sucaiwa的博客

这一讲我分享了在开发 Serverless 应用过程中的一些实践经验。你需要根据 Serverless 应用的特点，按照 Serverless 的思维编写 Serverless 代码。Serverless 的性能优化核心在于减少冷启动耗时。你可以通过多地域多可用区部署进一步提升稳定性，并通过日志服务等记录应用日志并配置监控报警指标。Serverless 应用的安全风险主要是攻击面和攻击方式越来越复杂，所以需要对用户输入进行过滤、对云上数据进行加密、对用户和角色权限进行管控、对资源操作和变更进行监控。

可以看到，基于 Serverless 开发 Restful API 的整个代码非常简单，每个函数只负责一个独立的业务，职责单一、逻辑清晰。关于这一讲，我想强调这样几个重点：基于 Serverless 开发 API 时，建议你使用 API 网关进行 API 的管理；对于数据库等第三方服务，建议对其基本操作进行封装，这样更方便进行扩展；Serverless 函数需要保持简单、独立、单一职责。

这一讲，我首先为你介绍了常用的身份认证方案，并分析了这些方案的特点，以及如何在 Serverless 架构中使用这些方案。然后我带你从0到1实现了一个 Serverless 的登录注册应用，通过该场景实践，让你深入理解 Serverless 中的身份认证。Serverless 应用的身份认证，本质上是要将有状态的认证方案改为无状态的。如何改为无状态呢？使用共享存储来保存登录状态，比如将 Session 信息存储到 Reids，这样应用就不用存储状态了；使用无状态的身份认证方案，比如 JWT。

这一讲，我们学习了怎么把传统应用迁移到 Serverless，并且我通过将 Express.js 框架 Serverless 化的例子，为你详细介绍了应该如何把一个传统 Web 服务迁移到 Serverless。关于这一讲的内容，我想要强调这样几点：传统应用迁移到 Serverless，需要考虑内存缓存、身份认证、持久化存储、Web 服务 Serverless 化等改造点；如果一个应用本身就是分布式部署的，且在架构上是计算和存储分离的，则比较容易迁移到 Serverless；

这一讲，我从成本分析、成本优化和成本控制三个角度，详细讲解了 Serverelss 应用成本方面的相关知识。整体而言，基于 Serverless 架构，我们不用再为闲置的服务器付费，只为实际使用的资源付费就可以了。同时你还可以通过提高 Serverelss 应用的性能，进一步优化成本。由于 Serverless 应用通常依赖 FaaS 之外的触发器、数据源和 BaaS 服务，所以在分析和控制 Serverelss 应用的成本时，也需要关注这些云服务的成本。

今天，我针对 11 讲提及的10个主要风险，分享了一些实践经验，希望让你有所收获，因为11 讲和 12 讲的信息偏多，所以我整理了一张导图，帮你回顾上两讲的重点内容：由于国外 Serverless 技术起步比较早，大家对安全性也比较重视，所以国外已经有一些第三方的 Serverless 安全性相关的产品，比如CloudGuardAquasec，而国内目前几乎是一片空白，很多安全防护方案都需要开发者自己建设，所以“怎么提高 Serverless 应用的安全性？

不管是传统应用还是 Serverless 架构的应用，都存在安全风险，因此你要先深入了解应用架构中的风险点，这样才能对症下药，解决问题。关于今天这一讲，我想要强调以下几点：在云上运行的应用，云厂商负责计算、网络、存储等底层资源的安全性，应用所有者负责应用本身的安全性；Serverless 安全性面临的主要挑战是：越来越多的攻击面、越来越复杂的攻击方式、可观测性不足以及传统安全测试方法和防护方案不适用于 Serverless 架构；对于 Serverless 架构的安全风险需要深入理解，才能更好地规避。

在这一讲的开头，我提到了 Serverless 应用的性能优化主要是围绕冷启动进行的，此外我们也可以针对代码运行时进行优化。对今天学习的内容做个总结，就可以得到 Serverless 性能优化的一些实践方案：提前给函数预热；使用预留资源；减小代码体积、减少不必要的依赖；执行上下文重用；为函数设置并发；选择冷启动耗时少的编程语言；为函数设置合适的内存。而这也是我今天想要强调的重点。

单元测试一直是困扰 Serverless 开发者的一大难题。在本节课中，我首先展示了一段难以编写单元测试的代码示例，然后讨论了为什么 Serverless 应用编写单元测试难、应该如何编写易测试的代码，以及如何编写单元测试，最后介绍了我在编写单元测试过程中的一些最佳实践。Serverless 应用由于其分布式、依赖云服务、事件驱动等特性，导致编写单元测试很困难；为了方便编写单元测试，需要将业务逻辑和依赖的云服务分离开来；编写单元测试时，需要考虑速度、隔离性、单一职责等因素，避免单元测试成为开发的负担；

运行时（Runtime）是程序运行时所依赖的环境（环境包括任何库、框架或平台）。FaaS 中的运行时，就是你创建函数时指定的运行环境，比如函数计算的 Node.js 运行时，就包括 Node.js 运行环境以及一些内置的模块，如 ali-oss、tablestore，此外还有 Java 运行时、Python 运行时等。那自定义运行时就是你可以在 FaaS 自定义一个运行环境，如 TypeScript，然后你就可以使用 TypeScript 来编写代码并部署到 FaaS 平台上运行。

由于不同编程语言包管理机制不同，安装依赖的方式也不尽相同，但本质上，都是需要将依赖安装到应用项目中，并且随项目一起部署到 FaaS 平台。当然，如果你已经开始使用一些开发框架，你可能已经发现开发框架也在解决依赖安装问题，让用户尽可能更低成本完成应用开发。关于这一讲，我想要强调这几个点：Serverless 应用的代码依赖和系统依赖都需要安装在项目中，并和应用代码一起部署到 FaaS 平台；FaaS 对代码体积大小有限制，所以最好要精简依赖体积；

在我看来，开发框架的意义就在于帮助开发者提升 Serverless 应用的开发效率， 因此一个 Serverless 开发框架最主要的就是要实现应用管理、应用调试、应用部署等功能。而在Serverless Framework 和 Fun 这两个开发框架中：Serverless Framework 特点是功能完善、支持平台丰富。但由于 Serverless 平台尚且没有统一标准，所以支持多平台难度极大，也导致其对国内产品支持不够友好；Fun 的特点是只为函数计算服务，因此有很多针对函数计算的特定功能。

这一讲，我通过一个案例为你介绍了 Serverless 应用的运行原理。相比而言，传统应用部署在服务器上后是持续在线的，这样的好处是请求到来时，可以直接进行处理，无须启动应用；坏处则是需要一直消耗硬件资源，如果应用很长时间都没有请求，那大部分时间资源都是浪费的。如果传统应用想要实现按需启动，则需要先启动一个虚拟机、再初始化应用运行环境、然后再启动应用，整个过程耗时达到分钟级，对业务而言显然不可接受。

你能发现，在 HTTP 触发器中函数定义是 function(request, response, context)，在 API 网关触发器中，函数定义是 function(event, context) ，所以，函数定义本质上是由触发器和编程语言决定的。标准的函数定义是 function(event, context)。event 是事件对象。在 Serverless 中，触发器被称为“事件源”，英文是 event，这解释了为什么函数参数名是 event。触发器不同，event 的值可能不同。

关于“ Serverless 到底是什么？”的文章很多，观点也很多，为了让你学会区分，对这个概念有一个准确的认知，我准备了这样一节课，希望你有所收获。这一讲我提到了 Serverless 、Serverless 架构和 Serverless 平台，其中，Serverless 是架构思想；基于 Serverless 思想的软件架构，就是 Serverless 架构；Serverless 平台指云厂商的 Serverless 相关的产品。广义上来讲，

今天是我们第一节课，我想和你聊一聊 Serverless 架构兴起的原因。Serverless 是最近几年业界很火的技术名词，你可以在国内外各种技术大会上看到它的身影，主流云服务商也不断地推出 Serverless 相关的云产品和新功能（比如 AWS Lambda、阿里云函数计算、腾讯云云函数），各种关于 Serverless 的商业和开源产品也层出不穷（比如 Serverless Framework、OpenFaaS、kubeless）。

你好，我是老蒋，一个在前端摸爬滚打 7 年的老兵，目前是国内某一线大厂的资深软件工程师。2017 年国内 Serverless 技术刚刚兴起，我就开始使用和推广 Serverless 了，当时，我的团队负责很多前端中后台系统的研发，后端为了方便扩展就把接口设计得很原子化，导致前端渲染一个页面要发几十个请求，前后端联调很痛苦，沟通成本非常高，开发效率也很低。为了提升前端开发效率和页面加载性能，我们用 Node.js 开发了很多 BFF（Backend for Frontend）应用来做接口的聚合裁剪。