Serverless是云原生的实现方式并把底层计算资源当成基础设施，每个产品的实现方式也不一样，但并不代表无服务器，只是底层服务器对用户透明并完全由厂商负责运维。

Serverless计算允许开发者专注于编写和部署代码，而无需管理服务器，自动按需扩展资源。

Serverless架构相比传统云计算，是在底层计算资源的基础上更高阶的抽象和使用，并允许开发者专注于编写和部署代码，而无需管理服务器，自动按需扩展资源。传统云计算对底层计算资源进行编排，但仍需客户运维。

冷启动一直是Serverless领域面临的优化难题之一，华为云创新提出了基于进程级快照的冷启动加速解决方案，致力于在用户几乎无感知的前提下，有效提升应用的冷启动性能。特别是Java应用冷启动速度慢的问题尤为突出，华为云在冷启动性能优化方面做到90%+性能提升。

以下几种类型的应用最适合迁移到 Serverless 架构：

1、事件驱动应用：包括 IoT 设备数据处理、文件上传后的图像处理、日志分析、视频直播/转码等，这些应用以事件驱动的方式执行服务，按需供给，开发者无需关注业务波峰波谷，节省闲时成本，最终降低运维成本。

2、Web 应用和移动后端：RESTful API 和 GraphQL等接口可以很好地与 Serverless 结合，实现按需计算和自动扩展。

3、微服务：Serverless 的无状态特性和自动扩展能力非常适合构建独立部署的服务单元。

4、定时任务：例如数据备份、报告生成、定期清理等工作，可以通过计划事件来触发 Serverless 函数执行。

5、AI/ML 推理：短期的机器学习模型推理任务，尤其是那些不需要长期占用资源的情况。

6、临时或阶段性项目：比如活动期间的限时促销、封闭测试等，这类应用可以在需求高峰期迅速扩展，并在非活跃期减少开销。

1、在高访问量情况下，Serverless 的初期成本优势明显。传统架构需要提前预估流量并采购和配置足够的服务器、存储设备和网络设备等硬件资源，这涉及到大量的资金投入。而 Serverless 无需预先购买这些硬件，只需在流量到来时根据实际使用情况付费，对于一些创业公司或者新上线的应用，这种方式可以大大减轻资金压力。

2、Serverless 的自动伸缩特性在高访问量下可以有效控制成本。尽管随着访问量增加，Serverless 的费用会相应上升，但它的增长是与实际的请求处理量紧密相关的。而传统架构为了应对峰值流量，往往会过度配置资源，在平时就会造成这些资源的闲置浪费，即使在高访问量期间，也可能因为架构不够灵活而无法充分利用资源。

3、如果应用处于长时间、稳定的高访问量状态，并且对性能有非常高的要求（例如要求极低的延迟），在某些情况下 Serverless 成本可能会高于传统架构，Serverless 的计费方式是基于函数执行次数和资源消耗，在长时间高负载下，这些费用可能会累积到一个较高的水平,Serverless 的冷启动和精细的计费方式可能会导致成本上升。

一、利用华为云Serverless函数托管服务FunctionGraph的自动伸缩功能

以 华为云FunctionGraph 为例，它会根据传入请求的速率自动调整函数执行实例的数量。当请求流量增加时， FunctionGraph 会自动启动更多的实例来处理请求；当流量减少时，会关闭多余的实例。这种自动伸缩是基于内置的算法，该算法会考虑请求的并发数、函数执行时间以及可用函数实例资源等多种因素。例如，假设一个基于 FunctionGraph 的 Web 应用，平时每秒只有 10 个请求， FunctionGraph 会维持少量的函数实例。但如果在促销活动期间，每秒请求数增加到 1000 个， FunctionGraph 会迅速启动足够多的实例来处理这些请求，确保应用的响应性能。

二、基于指标的伸缩管理，即监控关键指标

1、弹性实例数和并发数：

弹性实例数反映了单位时间内运行的弹性实例数量，并发数则表示在同一时刻正在处理的请求数量。这两个指标是监控伸缩性的基础。通过实时监控这些指标，可以提前预测流量的变化趋势，从而做好资源准备。

例如，使用云服务提供商提供的监控工具（如 华为云的AOM）来跟踪这些指标。当发现并发数持续上升，并且并发数接近设置的单函数最大实例数的阈值时，就可以考虑调整伸缩策略，如提高单函数最大实例数限制或增加预留实例数量。

2、函数执行时间和资源利用率：

函数执行时间直接影响用户体验，较长的执行时间可能导致用户等待时间过长。资源利用率（CPU、内存）则反映了函数运行的效率。如果发现函数执行时间过长或者资源利用率过高，可能需要优化函数代码，或者调整资源分配。

例如，一个日志加工函数在处理日志时执行时间过长。通过监控发现这个问题后，可以考虑优化算法来缩短执行时间，或者增加分配给函数的内存资源来提高处理效率。同时，监控资源利用率可以帮助企业确定是否有资源浪费的情况，例如，如果一个函数一直占用大量内存但实际使用很少，就可以适当减少分配的内存。

一、企业构建事件驱动的应用：

1、企业首先需要明确应用中的事件来源。事件源可以是多种多样的，例如用户App中的操作（如点击按钮、提交表单等）、消息队列中的消息（如来自其他系统的业务消息）等。梳理出所有可能的事件源，为后续的事件处理做好准备。

2、根据事件的类型和业务需求，编写相应的 Serverless函数来处理事件。每个函数应该具有明确的单一职责，例如，一个处理用户注册事件的函数可能负责验证用户输入的信息、将用户数据存储到数据库等操作。

以一个电商应用为例，当有用户下单的事件发生时，对应的 Serverless 函数会负责验证订单信息（包括商品库存检查、价格计算等）、生成订单记录、通知仓库发货等一系列操作。这些函数可以使用不同的编程语言编写，如 Python、Node.js 等，具体取决于企业开发团队的技能和应用的需求。

但对于复杂的业务场景，可能需要多个 Serverless 函数协同工作来处理事件。这时就需要进行事件流的编排，确定事件在不同函数之间的传递顺序和触发条件。可以使用工作流引擎或者事件编排工具来实现。

例如，在一个企业级的供应链管理系统中，一个采购订单事件可能首先触发库存检查函数，根据库存情况决定是否需要触发采购申请函数，采购申请批准后再触发供应商下单函数等。通过事件流编排工具（如 FunctionGraph的 workflow）可以清晰地定义和管理这些事件流程。

3、企业需要为事件处理过程中产生的数据选择合适的存储方案。对于临时的数据，可以使用内存存储（如在函数执行期间存储一些中间计算结果）、 缓存（如Redis）、消息（如Kafka） ；对于持久化的数据，如用户记录、业务订单等，可以使用数据库（如关系型数据库 MySQL）。

二、优化事件驱动的 Serverless 应用：

1、优化 Serverless 函数的代码是提高性能的关键。这包括减少函数的执行时间、降低资源消耗（如内存、CPU）。可以通过代码重构、算法优化、使用高效的库等方式来实现。

2、由于网络、系统等原因，事件处理可能会失败。企业需要建立重试机制，当函数执行失败时，自动进行重试。可以设置重试次数、重试间隔等参数，根据不同的事件重要性和失败类型来灵活调整。

3、成本优化，优化资源分配，确保 Serverless 函数使用的资源（如内存、执行时间）与实际需求相匹配。避免过度分配资源导致不必要的成本增加。可以通过性能测试和成本分析来确定最佳的资源配置方案。

例如，在一个测试环境中，模拟不同的流量场景，观察函数在不同资源配置下的性能和成本。通过分析结果，找到一个既能满足性能要求又能降低成本的资源分配点，如将一个函数的内存分配从 4096MB 降低到 1024MB，同时保证其在高流量情况下的执行时间仍在可接受范围内。

开发者可以基于以下关键策略：

1、使用日志聚合服务LTS收集和分析事件信息和错误日志，并确保日志信息结构化，便于读取和分析。

2、利用调用链工具比如APM等来追踪请求完整路径，识别性能瓶颈和故障点。

3、上报关键指标数据，比如成功率等，并设置告警及时通知。

Serverless将计算资源的管理抽象化，显著改变了传统的开发和部署流程，主要包括以下改变：

1、无服务器函数：开发者可以专注于编写业务逻辑，无需关心底层基础设施的配置和维护。

2、事件驱动：应用设计围绕事件触发，提高了系统的响应性和可扩展性。

3、按需资源：云服务自动分配和管理计算资源，开发者只需上传代码，无需手动部署或扩展服务器。

4、持续集成/持续部署（CI/CD）：Serverless环境与CI/CD工具的集成更加紧密，实现代码的自动测试、构建和部署。

建议掌握以下技能：

1、事件驱动编程：理解和设计基于事件触发的业务流程。

2、无状态设计：确保函数或服务能够独立处理请求，不依赖于会话状态。

3、微服务架构：将应用分解为独立的、可重用的组件，提高系统的灵活性和可维护性。

4、云服务API：熟悉云平台提供的API，如FunctionGraph等。

5、监控和日志工具：掌握如LTS、AOM等工具，用于监控和调试Serverless应用。

6、CI/CD工具：如Jenkins、GitLab CI、CircleCI等，用于自动化测试和部署流程。

7、容器技术：虽然Serverless主要关注函数级别的无服务器，但了解容器（如Docker）和容器编排（如Kubernetes）对于构建和部署微服务仍然重要。

1、使用模块化设计，将每个第三方服务的集成封装为独立的模块或函数，避免代码耦合，便于单独测试和维护。

2、针对第三方依赖，可以使用云服务提供的依赖包进行管理，使用平台提供的依赖包能力进行版本管理。

3、使用ServiceBridge函数作为BaaS访问统一入口，业务使用轻量SDK访问BaaS服务，无需关注连接逻辑。