共计 2884 个字符，预计需要花费 8 分钟才能阅读完成。
简介：Spring Boot Serverless 实战系列第四篇来啦，本文将向大家介绍如何对 Serverless 利用进行性能调优。
SpringBoot 是基于 Java Spring 框架的套件，它预装了 Spring 的一系列组件，让开发者只须要很少的配置就能够创立独立运行的应用程序。在云原生的世界，有大量的平台能够运行 SpringBoot 利用，例如虚拟机，容器等。但其中最有吸引力的，是以 Serverless 的形式运行 SpringBoot 利用。我将通过一系列文章，从架构，部署，监控、性能、平安等 5 个方面来剖析 Serverless 平台运行 SpringBoot 利用的优劣。为了让剖析更有代表性，我抉择了 github 上 star 数超过 50k 的电商利用 mall 作为示例。这是系列文章的第四篇，向大家展现如何对 Serverless 利用性能调优。
实例启动速度优化
在之前的文章实战教程中，置信大家都感触到 Serverless 的便捷之美，只需上传代码包和镜像就可能轻松上线一个弹性高可用的 Web 利用。然而它仍存在首次启动“冷启动延时”的问题，Mall 利用实例的启动大概 30 秒左右，用户会感触较长时间的冷启动延时，在这个“即时时代”应用程序响应慢多少会有些瑕不掩瑜。（“冷启动”是指函数服务于特定调用申请时的状态，当一段时间没有申请后，Serverless 平台则会回收函数实例；等到下一次再有申请时，零碎会再次实时拉起实例，这个过程称之为冷启动。）
在优化冷启动之前，咱们先要剖析分明冷启动各个阶段的耗时。首先在函数计算（FC）控制台的服务配置界面，开启链路追踪性能。
对 mall-admin 服务发动申请，胜利后查看 FC 控制台，咱们可能看到相应的申请信息。留神敞开“仅查看函数谬误”，这样才会显示所有申请。指标监控和调用链路数据收集会存在肯定延时，如果没有显示，请期待一会再刷新。找到冷启动标记的申请，点击“更多”下的“申请详情”。
调用链路会显示冷启动各个环节的耗时。冷启动蕴含以下几个环节：
- 代码筹备（PrepareCode）：次要是下载代码包或者镜像。因为咱们曾经启用了镜像减速性能，不须要下载全副的镜像，因而这一步的延时十分短。
- 运行时初始化（RuntimeInitialization）：从启动函数开始，到函数计算（FC）零碎探测到利用端口就绪为止。这两头蕴含了利用启动工夫。在命令行执行 s mall-admin logs 查看相应的日志工夫，咱们也能看到 Spring Boot 利用的启动须要花大量的工夫。
- 利用初始化（Initialization）：函数计算提供了 Initializer 接口，用户能够将一些初始化逻辑放在 initializer 中执行。
- 调用延时（Invocation）：解决申请的延时，这个延时十分短。
从上述链路追踪图来看，实例启动工夫是瓶颈，咱们能够采取多种形式来优化。
1.1. 应用预留实例
Java 类利用广泛启动较慢。利用在初始化时，也须要和很多内部服务交互，耗时较长。这类流程是业务逻辑须要的，很难优化延时。因而函数计算提供了预留实例性能。预留实例的起停由用户本人管制，没有申请也会常驻在那，因而不会有冷启动的问题，当然用户须要为整个实例的运行付费，即使实例没有解决任何申请。
在函数计算控制台，咱们能够在“弹性伸缩”页面为函数设置预留实例。
用户在控制台中配置最小和最大实例数。平台会预留最小实例数目的实例，最大实例是指该函数下实例的下限。用户也能够设置定时预留和按指标预留的规定。
创立预留规定后，零碎就会创立预留实例。当预留实例就绪后，咱们再拜访函数就不会有冷启动。
1.2. 优化实例启动速度
提早初始化
在 Spring Boot 2.2 及更高版本中，能够开启一个全局提早初始化标记。这将进步启动速度，但代价是第一个申请的延迟时间可能变长，因为须要期待组件首次初始化。
可在 s.yaml 中为相干利用配置以下环境变量
SPRING_MAIN_LAZY_INITIATIALIZATION=true
敞开优化编译器
默认状况下，JVM 有多个阶段的 JIT 编译。尽管这些阶段能够逐步进步利用的效率，但它们也会减少内存应用的开销，并减少启动工夫。对于短期运行的 Serverless 利用，请思考敞开此优化，以就义长期效率换取更短的启动工夫。
可在 s.yaml 中为相干利用配置以下环境变量：
JAVA_TOOL_OPTIONS=”-XX:+TieredCompilation -XX:TieredStopAtLevel=1″
s.yaml 中设置环境变量示例：
如下图所示，对 mall-admin 函数配置环境变量。而后执行 sudo -E s mall-admin deploy 部署。
登录实例查看环境变量是否配置正确
在控制台函数详情页的申请列表中找到对应的申请，点击更多中的“实例详情链接”。
在实例详情页中点击“登录实例”。
在 shell 界面中执行 echo 命令，查看对应的环境变量是否设置正确。
留神：对于非预留实例，一段时间没有申请后，函数计算零碎会主动回收实例。此时无奈再登入实例（下面的实例详情页面中的登录实例按钮会变灰）。所以请执行调用后，在实例被回收之前尽快登录。
配置正当的实例参数
当咱们抉择了利用实例规格，比方 2C4G 或者 4C8G，接下来咱们心愿晓得一个实例解决多少申请能够既能充分利用资源又可能保障性能。当解决的申请超过一个限度后，零碎可能疾速弹出实例，保障利用性能平滑。如何度量实例过载有多个维度，例如 qps 超过肯定阈值，或者实例 CPU/Memory/Network/Load 等指标超过阈值等等。函数计算应用实例并发度（Instance Concurrency）来作为实例负载的度量和实例伸缩的根据。实例并发度（Instance Concurrency）是指一个实例能同时执行的申请数。例如将实例并发度设置为 20，则意味着一个实例在任意时刻最大能同时执行 20 个申请。
留神：请辨别实例并发度和 QPS 的区别。
应用实例并发度来度量负载有如下劣势：
- 零碎可能迅速统计实例并发度指标值进行扩缩容。CPU/Memory/Network/Load 等实例级别的指标通常是后盾统计，须要破费数十秒的指标统计后能力进行伸缩，难以满足在线利用的弹性伸缩要求。
- 在各种条件下，实例并发度指标都可能稳固的反映零碎负载高下。如果以申请延时作为指标，零碎难以辨别是实例过载导致延时变大，还是上游服务成为瓶颈导致延时变大。例如一个典型的 Web 利用，通常会拜访 MySQL 数据库。如果数据库成为瓶颈，申请延时变大，此时扩容岂但毫无意义，而且会压垮数据库，让状况更加好转。QPS 和申请延时相干，也会有上述问题。
实例并发度作为伸缩根据尽管有上述长处，但用户经常并不知道该设置多大的实例并发度。我举荐依照下述流程确定正当的并发度：
- 将利用函数的最大实例数设置为 1，确保压测到单个实例的性能。
- 应用负载压测工具对利用进行压测，查看 tps 和申请延时等指标
- 逐渐调大实例并发度，如果性能依然良好，则持续调大；如果性能不合乎预期，则调小并发度。
原文链接
本文为阿里云原创内容，未经容许不得转载。
