Serverless使用经验

Posted 2023-01-22

方案选型

比较适合

数据处理计算的场景

如果是大流量数据，且没有峰谷显著特性的话，你完全可以使用

事件触发类场景

FaaS 诞生就常用的领域了。它的特性在于“流量的不稳定”，有就触发，没有就缩容至 0。如果你的业务场景比较轻量，且流量不稳定，那么“精益成本”（按需使用，按量付费）的 Serverless 就是你的最佳选择。 

应用后端服务

区别于传统的微服务应用，应用后端服务更多的是对于微服务的一种补充，多用于相对独立、架构简单的业务应用。比如小程序、H5 活动页、BFF 的场景，它印证了 Serverless“快速交付”这一特点。

有状态的场景

有状态的场景打破了之前狭义上

传统服务升级

服务架构集成了

我们之前选入的场景，都具有“运维门槛较高需要免运费和全托管”“流量变化较大需要弹性伸缩”“轻量应用需要快速交付”“流量不确定需要能缩容至 0，按需使用按量付费”的特性，那么反过来，比如延时非常敏感的、SLA 级别极高的场景，比如类似网页搜索、银行交易，就不太建议使用 Serverless 技术了。

资源评估

虽然

第一，服务一天跑下来，是否存在明显的空闲期或者具备明显的“峰谷”现象？

第二，具备第一点后，是否选择了合适的资源规格去计算、对比各个方案费用？

这两点适用于所有选用 Serverless 技术的产品。

拿函数计算来说，它的收费是按照调用次数、资源使用耗时和出网流量来计算的。从各个云厂商的计价表可以看出，主要的费用来自于这三点中的资源使用耗时，而“资源耗时 = 内存大小 * 运行时间”。

从公式可以看出，资源的耗时成本是和内存大小、运行时间成正比关系的。在资源评估阶段，先说内存大小的问题。之前遇到一个客户，他的调用次数每天大概是 50W 次，每次执行在 3 秒左右，但费用还不低。

通过平台监控，我们发现他为了处理少部分数据量计算比较大的文件，准备的是 1G 的内存，这个数量只有不到 1000 次的调用量。在不同的内存资源下，费用相差

调用速度

影响调用速度的因素:

1.代码包太大，引入了不必要的依赖包：这种情况尤其在

2.运行时的影响：使用Java，导致出现偶发的超时错误，发现就是冷启动的时候耗时较长，后来干脆替换成了 Python 就没有这种问题。尽管在阿里云等厂商对 Java 的运行时做了优化，但Java 的耗时除了在冷启动，在 Invocation 阶段也比 Golang 要长。

3.调用下游服务返回慢：函数是按照使用次数和时长来计费的，抛开这个不说，函数的超时时间设定的限制，如果太慢的下游服务返回，会出现超时错误。不仅浪费成本，还使得服务体验不好。

4.代码习惯问题：比如引入不必要的框架，确实可以加快开发的速度，但也会影响服务的速度；另外，就是不必要的循环和

总结下来，攻克这些问题需要做的就是两件事，一个是函数特性的优化，另一个是函数之间的协作优化。那么，作为一名

在函数特性优化方面：

尽可能减少不必要的代码依赖，优化代码体积，提升代码的下载和加载速度； 

选择性能较高的运行时，提升函数的启动速度，比如

合理利用本地缓存，对于比较大的数据，可以适当缓存在挂载路径中；

预留实例。Serverless 的实例在没有流量进来的时候，是会缩容掉的，那么下次再有流量进来，就会进入冷启动的流程，可以在成本允许的范围内对部分延时敏感性较高的函数设置一定的实例进行预留和分策略加载；

请求预热。通过配置一个定时触发器的方式，来主动调用函数来请求预热，设置的时间间隔可以根据云厂商的实例回收时间来灵活配置。

开发模式。尽量让自己的代码在一层的处理逻辑中，以“平铺”的方式解决，避免层层嵌套、循环、停顿这种在微服务或者脚本上经常使用的习惯发生。

针对函数之间的协作：

尽可能使用异步调用，尤其是级联的函数调用避免同步调用下游服务产生的耗时，因此在选型的时候得要注意评估；

一个函数只做一件事情，也就是说要根据业务进行合理的函数粒度拆分。在成本、复用性、性能上都存在其必要性。

提升服务的体验。如果是一个

开发技巧

开发工具的选择

开发工具一般分为三种，本地开发工具 CLI、WebIDE 和 IDE 插件集成。其中，WebIDE 的能力更偏向支持轻量化的在线开发管理，IDE 插件的能力更偏向照顾那些使用成熟 IDE 的技术人员，如 VSCode 的开发人员。

编码技巧

一方面，是资源的初始化复用思想；另一方面，是函数业务的调用和设置细节。

基于标准运行时构建的函数其实是基于一个代码框架运行的。平台提供给你的是一个

正确的做法应该把它单独拎出来，放到一个函数中，然后单独调用一次，这样在函数实例被回收之前，如果有新的请求过来，就可以直接复用了。

这个解决方案不仅利用了

资源的初始化这个关键问题非常关键，一旦处理不好，可能还会导致资源服务的连接超限等问题；

常见的业务逻辑TOP5问题

首先，print 日志的时候尽可能少而精。如果你使用的是云平台，直接 print“event”这种整个结构体很可能会撑爆日志的限制。所以，尽量打印出需要的业务字段。

其次，尽量使用异步策略代替微服务形态下的异步框架。假如在原生的微服务中使用

再次，调用下游服务的接口，设置的超时时间一定要小于函数的超时时间。否则会因为短板在下游，而造成一次请求超时。浪费成本不说，也会让服务不稳定。

另外，要将公共代码放到层上。它类似于我们平时的公共类库，可以让具体的函数代码包更轻量。

最后，提前设置并发数的上限。一般云厂商都会设置默认的实例并发数，比如阿里云

线上运维

稳定性方面，云厂商设置的异步调用策略，可以确保失败后的请求重试，预留实例可以确保流量突增的响应及时性。除此之外，对重要接口采用轮训模拟请求的方式进行探活检测，当出现连续 N 次出现问题的时候，就会报警和切换到备用集群、备用区域。你会发现，在 Serverless 云厂商还不是很完善的情况下，作为一个开发者，可以基于“免运费”之上做一层“运维保险”。

可观测方面，通过指标、日志、链路三大支柱实现一个监测系统的机制，从使用的经验上，建议“活”用云厂商关联的支撑服务。他们的监控仪表盘足以支撑常用的指标，还可以通过关联的报警服务、链路追踪服务来更全面地“问诊”服务。