Golang与云服务（如AWS、Azure）结合的应用实践_技术教程

Go 初始化AWS SDK v2客户端需显式调用config.LoadDefaultConfig并指定Region；Azure Blob需用azidentity.NewAzureCLICredential等凭证类型；K8s中IRSA需正确配置ServiceAccount annotation及SDK版本；S3并发上传须限制Concurrency、设置PartSize并复用Uploader实例。

如何用 Go 正确初始化 AWS SDK v2 客户端

Go 调用 AWS 服务失败，八成出在客户端初始化环节。v2 SDK 不再自动读取 ~/.aws/credentials 或环境变量，必须显式传入配置。

必须调用 config.LoadDefaultConfig（而非旧版的 session.Must），它会按顺序检查环境变量、共享凭据文件、EC2 实例角色等
若在 Lambda 中运行，LoadDefaultConfig 可直接使用，无需硬编码密钥；但本地开发时建议配好 AWS_PROFILE 或 AWS_ACCESS_KEY_ID 等环境变量
务必设置 Region：即使服务支持全局 endpoint（如 IAM），多数服务（S3、EC2、DynamoDB）仍需显式指定 region，否则报错 operation error XXX: failed to resolve service endpoint

cfg, err := config.LoadDefaultConfig(context.TODO(),
    config.WithRegion("us-west-2"),
)
if err != nil {
    log.Fatal(err)
}
client := s3.NewFromConfig(cfg)

Go 操作 Azure Blob Storage 的最小可行认证方式

Azure Go SDK（azblob）不支持类似 AWS 的链式凭据查找，默认只认连接字符串或显式 TokenCredential。生产环境应避免连接字符串硬编码。

推荐使用 azidentity.NewAzureCLICredential（开发）或 azidentity.NewManagedIdentityCredential（Azure VM / App Service / Function）
若用 Service Principal，需确保已通过 az ad sp create-for-rbac 分配了 Storage Blob Data Contributor 角色，仅靠 Application ID 和 Secret 不足以访问 Blob
Endpoint 格式必须为 https://.blob.core.windows.net，漏掉 .core.windows.net 或协议会导致 net/http: invalid header field name

cred, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
    log.Fatal(err)
}
client, err := azblob.NewClient("https://mystorage.blob.core.windows.net", cred, nil)
if err != nil {
    log.Fatal(err)
}

为什么 Go 程序在 Kubernetes Pod 里连不上 AWS STS？

典型现象是 AssumeRole 调用卡住或返回 InvalidClientTokenId，根源常在 IRSA（IAM Roles for Service Accounts）配置未生效。

K8s ServiceAccount 必须绑定 annotation：eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role，且该 Role 的 Trust Policy 明确允许 sts.amazonaws.com 和对应 OIDC provider
Go 程序必须使用 AWS SDK v1.43.0+ 或 v2.15.0+，旧版本无法识别 AWS_WEB_IDENTITY_TOKEN_FILE 和 AWS_ROLE_ARN 环境变量
Pod 内检查：cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token 是否存在且非空；env | grep AWS 应看到上述两个变量

并发上传大文件到 S3 时 CPU 占用异常高

用 s3manager.Uploader 默认配置上传 >100MB 文件，常导致 goroutine 泛滥和 GC 压力，不是带宽瓶颈而是内存分配问题。

必须限制并发数：Concurrency: 5（默认是 runtime.NumCPU()，容器内常为 1–2，但 K8s limit 下可能误读为 64）
禁用自动分块（LeavePartsOnError: true）仅用于调试；生产应设 PartSize: 5 * 1024 * 1024（5MB），太小会增加 HTTP 请求开销，太大则单 part 失败重传成本高
避免对每个文件都新建 Uploader 实例；复用一个实例更安全，它本身是线程安全的

真正棘手的是 multipart upload 的 abort 清理——如果上传中途 panic，未完成的 parts 会持续计费。必须用 defer uploader.AbortMultipartUpload 或显式监控 UploadID 并异步清理。