方案选型
比较适合 Serverless 技术的场景，通常由数据处理计算、应用后端服务、事件触发处理、有状态服务和传统服务升级 5 个维度组成。
数据处理计算的场景
如果是大流量数据，且没有峰谷显著特性的话，你完全可以使用 Spark、Flink 这样的技术来处理，只有在峰谷显著的时候，Serverless 的“极致弹性”才有发挥的余地。也就是，数据场景，流量变化较大、需要算力动态调配的时候，选用 Serverless。
事件触发类场景
FaaS 诞生就常用的领域了。它的特性在于“流量的不稳定”，有就触发，没有就缩容至 0。如果你的业务场景比较轻量，且流量不稳定，那么“精益成本”（按需使用，按量付费）的 Serverless 就是你的最佳选择。
应用后端服务
区别于传统的微服务应用，应用后端服务更多的是对于微服务的一种补充，多用于相对独立、架构简单的业务应用。比如小程序、H5 活动页、BFF 的场景，它印证了 Serverless“快速交付”这一特点。
有状态的场景
有状态的场景打破了之前狭义上 Serverless 无状态的特性，让长进程、多任务、有状态需求的交互也能在 Serverless 下完成。
传统服务升级
服务架构集成了 SpringBoot、SpringCloud、Dubbo 等框架的情况，就可以考虑通过 Serverless 托管服务的模式转型了。另外如果希望省去 K8s的运维和容量的规划成本，考虑 Serverless 的容器转型，也可以划分在这类场景中。
我们之前选入的场景，都具有“运维门槛较高需要免运费和全托管”“流量变化较大需要弹性伸缩”“轻量应用需要快速交付”“流量不确定需要能缩容至 0，按需使用按量付费”的特性，那么反过来，比如延时非常敏感的、SLA 级别极高的场景，比如类似网页搜索、银行交易，就不太建议使用 Serverless 技术了。
资源评估
虽然 Serverless 具备按需使用、按量付费的特点，但这并不能说明 Serverless 的架构所产生的费用就比传统服务低。
第一，服务一天跑下来，是否存在明显的空闲期或者具备明显的“峰谷”现象？
第二，具备第一点后，是否选择了合适的资源规格去计算、对比各个方案费用？
这两点适用于所有选用 Serverless 技术的产品。
拿函数计算来说，它的收费是按照调用次数、资源使用耗时和出网流量来计算的。从各个云厂商的计价表可以看出，主要的费用来自于这三点中的资源使用耗时，而“资源耗时 = 内存大小 * 运行时间”。
从公式可以看出，资源的耗时成本是和内存大小、运行时间成正比关系的。在资源评估阶段，先说内存大小的问题。之前遇到一个客户，他的调用次数每天大概是 50W 次，每次执行在 3 秒左右，但费用还不低。
通过平台监控，我们发现他为了处理少部分数据量计算比较大的文件，准备的是 1G 的内存，这个数量只有不到 1000 次的调用量。在不同的内存资源下，费用相差 4 倍。在第一个函数 Func1 中判断一下文件大小，如果超过 256MB 承受的范围，就通过异步策略发往下一个函数 Func2 处理，这个函数设置为 1GB，就可以在比较低的成本下完成业务处理。所以，在资源评估时，依据情况合理地进行函数拆分，也是至关重要的。
调用速度
影响调用速度的因素:
1.代码包太大，引入了不必要的依赖包：这种情况尤其在 Java 的开发者中特别常见，要善于用 exclude 去掉一些不相关的依赖。
2.运行时的影响：使用Java，导致出现偶发的超时错误，发现就是冷启动的时候耗时较长，后来干脆替换成了 Python 就没有这种问题。尽管在阿里云等厂商对 Java 的运行时做了优化，但Java 的耗时除了在冷启动，在 Invocation 阶段也比 Golang 要长。
3.调用下游服务返回慢：函数是按照使用次数和时长来计费的，抛开这个不说，函数的超时时间设定的限制，如果太慢的下游服务返回，会出现超时错误。不仅浪费成本，还使得服务体验不好。
4.代码习惯问题：比如引入不必要的框架，确实可以加快开发的速度，但也会影响服务的速度；另外，就是不必要的循环和 Sleep 关键字在代码中的使用，这些都是在设计函数代码架构和逻辑中格外需要注意的。
总结下来，攻克这些问题需要做的就是两件事，一个是函数特性的优化，另一个是函数之间的协作优化。那么，作为一名 Serverless 平台的用户，具体可以做些什么呢？
在函数特性优化方面：
尽可能减少不必要的代码依赖，优化代码体积，提升代码的下载和加载速度；
选择性能较高的运行时，提升函数的启动速度，比如 Golang 语言；
合理利用本地缓存，对于比较大的数据，可以适当缓存在挂载路径中；
预留实例。Serverless 的实例在没有流量进来的时候，是会缩容掉的，那么下次再有流量进来，就会进入冷启动的流程，可以在成本允许的范围内对部分延时敏感性较高的函数设置一定的实例进行预留和分策略加载；
请求预热。通过配置一个定时触发器的方式，来主动调用函数来请求预热，设置的时间间隔可以根据云厂商的实例回收时间来灵活配置。
开发模式。尽量让自己的代码在一层的处理逻辑中，以“平铺”的方式解决，避免层层嵌套、循环、停顿这种在微服务或者脚本上经常使用的习惯发生。
针对函数之间的协作：
尽可能使用异步调用，尤其是级联的函数调用避免同步调用下游服务产生的耗时，因此在选型的时候得要注意评估；
一个函数只做一件事情，也就是说要根据业务进行合理的函数粒度拆分。在成本、复用性、性能上都存在其必要性。
提升服务的体验。如果是一个 HTTP 网站，服务响应越慢，用户的流失也就越严重，间接上你的页面访问和流量也会降低，最后影响的是营收。
开发技巧
开发工具的选择
开发工具一般分为三种，本地开发工具 CLI、WebIDE 和 IDE 插件集成。其中，WebIDE 的能力更偏向支持轻量化的在线开发管理，IDE 插件的能力更偏向照顾那些使用成熟 IDE 的技术人员，如 VSCode 的开发人员。
编码技巧
一方面，是资源的初始化复用思想；另一方面，是函数业务的调用和设置细节。
基于标准运行时构建的函数其实是基于一个代码框架运行的。平台提供给你的是一个 handler 的入口函数，你可以直接在这个函数里编写你的业务代码逻辑。但如果函数需要和资源打交道，那么就需要在执行存储操作之前先建立连接。如果在 handler 函数中写了如下一段连接数据库的代码，想一想，这会有啥问题？是不是每次请求过来都要重新连接做一遍这个操作？如果这是一个偶尔触发一次的函数，可能看不出问题。但如果一旦并发量比较高的服务场景，就会极大的影响性能，还可能导致数据库的连接句柄超限。
正确的做法应该把它单独拎出来，放到一个函数中，然后单独调用一次，这样在函数实例被回收之前，如果有新的请求过来，就可以直接复用了。
这个解决方案不仅利用了 FaaS 平台的实例复用技术，也在实例复用的基础上复用了资源对象。如果还想进一步优化，也可以在给数据库对象 db 赋值和获取的时候判断是否为 Null 值。类似地，像 kafkaClient、redisClient 等中间件资源的初始化都可以这样进行。
资源的初始化这个关键问题非常关键，一旦处理不好，可能还会导致资源服务的连接超限等问题；
常见的业务逻辑TOP5问题
首先，print 日志的时候尽可能少而精。如果你使用的是云平台，直接 print“event”这种整个结构体很可能会撑爆日志的限制。所以，尽量打印出需要的业务字段。
其次，尽量使用异步策略代替微服务形态下的异步框架。假如在原生的微服务中使用 Python 的 Tornado 框架，会发现 FaaS 形态的 Serverless 是很难发挥其异步的价值的。这个时候，可以直接选用FaaS 平台的异步处理框架。
再次，调用下游服务的接口，设置的超时时间一定要小于函数的超时时间。否则会因为短板在下游，而造成一次请求超时。浪费成本不说，也会让服务不稳定。
另外，要将公共代码放到层上。它类似于我们平时的公共类库，可以让具体的函数代码包更轻量。
最后，提前设置并发数的上限。一般云厂商都会设置默认的实例并发数，比如阿里云 FC 限定 300 * InstanceConcurrency，百度智能云 CFC 限定单实例 100 等，这对于一个并发量稍微高一点的生产应用来说是不够的，需要提前设置，申请扩大并发度。
线上运维
稳定性方面，云厂商设置的异步调用策略，可以确保失败后的请求重试，预留实例可以确保流量突增的响应及时性。除此之外，对重要接口采用轮训模拟请求的方式进行探活检测，当出现连续 N 次出现问题的时候，就会报警和切换到备用集群、备用区域。你会发现，在 Serverless 云厂商还不是很完善的情况下，作为一个开发者，可以基于“免运费”之上做一层“运维保险”。
可观测方面，通过指标、日志、链路三大支柱实现一个监测系统的机制，从使用的经验上，建议“活”用云厂商关联的支撑服务。他们的监控仪表盘足以支撑常用的指标，还可以通过关联的报警服务、链路追踪服务来更全面地“问诊”服务。
标签：Serverless,经验,服务,函数,场景,调用,使用,代码 From： https://www.cnblogs.com/muzinan110/p/17056985.html