企业官网建设流程全解析

• 示例工程
• 教程
• 后端

导读

本文基于aws-doc-sdk-examples仓库中的 kotlin/services/autoscale/README.md 及其配套源码，系统讲解如何使用 AWS SDK for Kotlin 完成 Amazon EC2 Auto Scaling 的核心生命周期管理。读者将掌握：如何创建 Auto Scaling 组、通过 Waiter 轮询等待组就绪、查询实例与组状态、启停指标采集、动态调整期望容量与最大容量、查看扩缩容活动、终止实例以及强制删除组的完整实战流程，并了解基于 JUnit 5 与 AWS Secrets Manager 的自动化测试方案。

Amazon EC2 Auto Scaling 用于根据你定义的条件自动增加或移除 EC2 实例，从而维持应用可用性。本仓库中的 Kotlin 示例以一个端到端 Scenario 为主线，把 12 个常用 API 操作串联起来，覆盖了一个 Auto Scaling 组从创建到销毁的完整生命周期。

代码示例概览与前置说明

示例所在位置与运行形态

仓库中与本文对应的核心代码位于：

• 场景主程序：AutoScalingScenario.kt
• 自动化测试：AutoScalingTest.kt
• 构建脚本：build.gradle.kts

其中AutoScalingScenario.kt以suspend fun main作为入口，通过命令行参数接收 4 个必需配置，属于"单场景多命令"（Scenario）型示例——这正是 README 中分类为Scenario（Multiple commands）的原因。

凭据与开发环境

README 明确指出：所有示例统一使用ProfileCredentialsProvider作为凭据提供方，即从本地 AWS 配置文件（~/.aws/credentials）读取访问密钥。运行前需要先完成 SDK for Kotlin 开发环境搭建与凭据配置，仓库源码的 KDoc 注释也指向同一份环境准备文档。

需要特别强调两点：

1. 示例会在你的 AWS 账户和指定 Region 上执行真实操作，可能产生费用，具体收费参见 AWS Pricing；
2. 部分操作是破坏性的（如删除 Auto Scaling 组、终止实例），README 明确警告"Be very careful"，建议在实验时创建独立的测试专用资源，并遵循最小权限（least privilege）原则，只授予完成任务所需的最低 IAM 权限。

从 AutoScalingScenario.kt 的源码看，所有客户端都显式指定了region = "us-east-1"，这也是示例的默认测试区域。

命令行参数

运行场景程序需要传入 4 个参数，格式与含义如下：

<groupName> <launchTemplateName> <serviceLinkedRoleARN> <vpcZoneId>

若参数个数不为 4，程序会打印上述用法说明并调用exitProcess(1)退出（见 AutoScalingScenario.kt）。

场景流程：Auto Scaling 组的完整生命周期

AutoScalingScenario.kt的 KDoc 注释清楚列出了 12 个操作步骤，构成了整个 Scenario 的执行主线：

1. 使用AutoScalingWaiter创建 Auto Scaling 组；
2. 获取指定 Auto Scaling 组并返回实例 ID；
3. 用实例 ID 描述该实例；
4. 启用指标采集（Metrics Collection）；
5. 描述 Auto Scaling 组；
6. 描述账户限额（Account Limits）；
7. 更新 Auto Scaling 组以增加实例数量；
8. 获取指定 Auto Scaling 组并取得实例数量；
9. 列出组内发生的扩缩容活动（Scaling Activities）；
10. 终止组内某个实例；
11. 停止指标采集；
12. 删除 Auto Scaling 组。

主程序在步骤间穿插了两个delay(60000)（等待 1 分钟），源码注释解释了原因："Wait 1 min for the resources, including the instance. Otherwise, an empty instance Id is returned"——即 EC2 实例启动需要时间，若不等待，步骤 2 可能拿到空实例 ID（此时程序会打印错误并退出，见 AutoScalingScenario.kt）。

关键 API 操作详解与源码印证

下面按场景执行顺序，逐一解读每个操作对应的 Kotlin 实现。所有操作均通过AutoScalingClient完成，客户端通过AutoScalingClient { region = "us-east-1" }构造并以.use { }自动释放资源。

1. 创建 Auto Scaling 组 + Waiter 等待就绪

createAutoScalingGroup函数（AutoScalingScenario.kt）是场景的第一步：

val request = CreateAutoScalingGroupRequest { autoScalingGroupName = groupName availabilityZones = listOf("us-east-1a") launchTemplate = templateSpecification maxSize = 1 minSize = 1 vpcZoneIdentifier = vpcZoneIdVal serviceLinkedRoleArn = serviceLinkedRoleARNVal } // 该对象为 Waiter 调用所需 val groupsRequestWaiter = DescribeAutoScalingGroupsRequest { autoScalingGroupNames = listOf(groupName) } AutoScalingClient { region = "us-east-1" }.use { autoScalingClient -> autoScalingClient.createAutoScalingGroup(request) autoScalingClient.waitUntilGroupExists(groupsRequestWaiter) println("$groupName was created!") }

关键点：

• 组名、可用区（us-east-1a）、启动模板、minSize/maxSize（均为 1）、VPC 子网 ID、service-linked role ARN 一起作为创建请求的核心参数；
• LaunchTemplateSpecification { launchTemplateName = ... }通过名称引用启动模板，模板内部定义了 AMI、实例类型等实例规格；
• 创建完成后立即调用waitUntilGroupExistsWaiter，以轮询方式等待组真实存在，而不是"发出请求即返回"，这保证后续getSpecificAutoScaling能取到组信息。

Waiter 来自aws.sdk.kotlin.services.autoscaling.waiters.waitUntilGroupExists包（见文件头部的 import）。

2. 获取指定组与实例 ID

getSpecificAutoScaling（AutoScalingScenario.kt）调用describeAutoScalingGroups，遍历返回组内实例并回传第一个实例的 ID：

response.autoScalingGroups?.forEach { group -> println("The group name is ${group.autoScalingGroupName}") println("The group ARN is ${group.autoScalingGroupArn}") group.instances?.forEach { instance -> instanceId = instance.instanceId.toString() } }

3. 描述指定实例

describeAutoScalingInstance（AutoScalingScenario.kt）使用上一步拿到的实例 ID 调用describeAutoScalingInstances，打印该实例的lifecycleState（生命周期状态，如Pending、InService、Terminating等）。

4. 启用指标采集

enableMetricsCollection（AutoScalingScenario.kt）：

val collectionRequest = EnableMetricsCollectionRequest { autoScalingGroupName = groupName metrics = listOf("GroupMaxSize") granularity = "1Minute" }

• metrics指定要采集的指标，示例使用GroupMaxSize（组最大实例数）；
• granularity = "1Minute"表示以 1 分钟为粒度聚合指标，这是 Auto Scaling 指标采集的常用粒度。

5. 更新 Auto Scaling 组

updateAutoScalingGroup（AutoScalingScenario.kt）将组最大容量更新为 3，并再次使用 Waiter 等待更新生效：

val groupRequest = UpdateAutoScalingGroupRequest { maxSize = 3 serviceLinkedRoleArn = serviceLinkedRoleARNVal autoScalingGroupName = groupName launchTemplate = templateSpecification }

注意更新请求同样携带启动模板与 service-linked role ARN——更新操作是按请求中的字段覆盖配置的，因此必须完整传入希望保留的配置项。

6. 设置期望容量

setDesiredCapacity（AutoScalingScenario.kt）：

val capacityRequest = SetDesiredCapacityRequest { autoScalingGroupName = groupName desiredCapacity = 2 }

将组的期望实例数设为 2。结合第 5 步maxSize = 3与初始minSize = 1，组现在允许在 1～3 之间弹性伸缩，期望容量为 2，即组会保持 2 个在运行实例。

7. 列出扩缩容活动

describeScalingActivities（AutoScalingScenario.kt）调用describeScalingActivities，打印每条活动的activityId与details，用于审计组内每一次扩容/缩容事件。

8. 终止组内实例

terminateInstanceInAutoScalingGroup（AutoScalingScenario.kt）：

val request = TerminateInstanceInAutoScalingGroupRequest { instanceId = instanceIdVal shouldDecrementDesiredCapacity = false }

• shouldDecrementDesiredCapacity = false表示终止实例后不减少期望容量，组会按策略再启动新实例补位，这一参数直接决定终止后组的"补位"行为。

9. 停止指标采集

disableMetricsCollection（AutoScalingScenario.kt）与启用操作对称，通过metrics = listOf("GroupMaxSize")关闭对应指标的采集。

10. 强制删除 Auto Scaling 组

deleteSpecificAutoScalingGroup（AutoScalingScenario.kt）：

val deleteAutoScalingGroupRequest = DeleteAutoScalingGroupRequest { autoScalingGroupName = groupName forceDelete = true }

forceDelete = true表示即使组内仍有实例也强制删除。这是典型的破坏性操作，README 特别强调运行删除/修改类操作时要格外小心。

其他常用 API：查询组列表与账户限额

场景中还包含了另外两个查询类操作，可独立使用：

• describeAutoScalingGroups(groupName)（AutoScalingScenario.kt）：按组名查询并打印组的healthCheckType，请求中还可通过maxRecords = 10限制返回数量；
• getAutoScalingGroups(groupName)（AutoScalingScenario.kt）：打印组的名称、ARN，以及组内每个实例的 ID 与lifecycleState；
• describeAccountLimits()（AutoScalingScenario.kt）：调用describeAccountLimits，打印当前账户在 Auto Scaling 方面的限额信息——maxNumberOfAutoScalingGroups（最大组数配额）与numberOfAutoScalingGroups（当前实际组数），可用于在创建资源前检查配额余量。

构建与运行方式

项目的构建配置位于 build.gradle.kts，核心要点：

• 使用 Kotlin JVM 插件，Kotlin 版本2.1.0，Java 目标版本为 17；
• 通过 AWS SDK for Kotlin BOM（版本1.5.63）统一管理依赖，引入aws.sdk.kotlin:autoscaling与aws.sdk.kotlin:secretsmanager；
• 使用 okhttp 与 CRT 两种 HTTP 客户端引擎，满足常规与高性能场景；
• 测试框架为 JUnit 5（org.junit.jupiter:junit-jupiter:5.9.2），测试任务启用useJUnitPlatform()，并输出 passed/skipped/failed 事件；
• 集成 ktlint 插件（org.jlleitschuh.gradle:ktlint-gradle:10.3.0）用于代码风格检查。

在本地依次执行gradle build与gradle run（或从 IDE 直接运行main），并在运行main时传入 4 个命令行参数即可启动场景。

自动化测试：AutoScalingTest 与配置准备

README 的 "Testing" 一节说明：Kotlin 示例对应一个名为AutoScaleTest的测试类，使用 JUnit 5 运行，位于src/test/java目录。在当前仓库中，Kotlin 版本的测试实现位于 AutoScalingTest.kt（源码目录为src/test/kotlin），整体结构与该说明一致。

测试执行形态

• 测试类通过@TestInstance(TestInstance.Lifecycle.PER_CLASS)与@TestMethodOrder(OrderAnnotation::class)保证实例复用与执行顺序；
• 唯一的@Order(1)测试testScenario以runBlocking包裹，逐条复刻主场景的 12 步流程（创建 → 等待 → 获取实例 ID → 描述 → 启用指标 → 更新组 → 描述组 → 账户限额 → 设期望容量 → 获取组 → 扩缩容活动 → 终止实例 → 停指标 → 删组）；
• 每次运行时，测试会通过Random生成随机数字追加到groupName与groupNameSc之后，避免与已有资源冲突；
• 测试从 IDE（如 IntelliJ）或命令行均可运行，运行过程中会打印成功/失败消息（例如Test 3 passed这类提示）。

WARNING：运行 JUnit 测试会操作真实 AWS 资源并可能产生费用，请务必使用测试专用账户或资源。

测试配置值的两种来源

README 说明测试运行前必须在config.properties（位于resources文件夹）中定义以下值，缺失任何一项都会导致测试失败：

需要说明的是：README 中的属性文件描述沿用了 Java 版本示例（javav2/example_code/autoscale）的说明文字；而在当前 Kotlin 测试实现中，读取方式已升级为从 AWS Secrets Manager 读取。从 AutoScalingTest.kt 的源码可以看到：

• 测试在setUp()中通过getSecretValues()读取名为test/autoscale的 Secret；
• Secret 的 JSON 结构由内部类SecretValues定义，包含groupName、groupNameSc、launchTemplateName、vpcZoneId、serviceLinkedRoleARN五个字段，与 README 的属性键一一对应；
• 读取过程使用SecretsManagerClient（region = "us-east-1"）调用getSecretValue，再由 Gson 反序列化为SecretValues对象；
• 源码中还保留了"如果你更倾向于用 config.properties 文件获取测试所需 AWS 值，请取消注释该代码块"的注释，说明两种配置来源均可。

因此，无论走哪种方式，你都需要提前准备上述 5 个真实值（建议把敏感配置存入 Secrets Manager 的test/autoscale中）。

与 Java 版本的关系

README 明确指出，Kotlin 示例源自 Java 版本场景：文档中给出的参考链接指向 javav2 的 AutoScalingScenario.java。对比两份实现可以发现，Kotlin 版本在 API 调用、参数结构与场景步骤上与 Java 版本保持一致，区别主要体现在：

• Kotlin 使用 DSL 风格的请求构造（Request { field = value }）而非 Java 的withXxx()setter 链；
• Kotlin 客户端通过AutoScalingClient { region = ... }构造，Java 则使用 Builder；
• Kotlin 场景中的delay(60000)直接对应 Java 版本的线程等待逻辑；
• Java 版本的场景还借助CloudFormationHelper创建启动模板等前置资源，而 Kotlin 版本将launchTemplateName等作为命令行/测试参数直接传入。

附：其他 Auto Scaling 操作示例

除场景外，javav2/example_code/autoscale 目录还提供若干独立的单操作示例（Kotlin 场景中的各个函数均可独立复用，原理相同）：

• CreateAutoScalingGroup.java—— 单独创建 Auto Scaling 组；
• DeleteAutoScalingGroup.java—— 删除 Auto Scaling 组；
• DescribeAutoScalingGroups.java/DescribeAutoScalingInstances.java—— 查询组与实例；
• DetachInstances.java—— 从组中分离实例。

小结

本文围绕 kotlin/services/autoscale/README.md 及其配套源码，完整还原了 AWS SDK for Kotlin 操作 Amazon EC2 Auto Scaling 的场景化实践：从参数准备、Waiter 等待、核心 API 调用链，到基于 JUnit 5 与 Secrets Manager 的自动化测试配置。掌握这套流程后，你既可以把AutoScalingScenario.kt当作可运行的端到端演示，也可以将其中的 12 个函数拆解为生产代码的参考实现。

运行这些示例前请始终记住：它们操作真实 AWS 资源并可能产生费用，请使用最小权限的 IAM 角色，并在测试专用资源上实验。

• 示例工程
• 教程
• 后端