阿里云Serverless低成本API服务搭建完全指南：从架构选型到成本优化

引言：Serverless如何重新定义API服务的成本边界

在传统云服务器架构下，搭建一个API服务意味着需要预先购买固定规格的ECS实例，无论实际请求量是高是低，都得为整台服务器付费。这种模式对于流量不确定的项目——无论是初创产品、个人Side Project，还是企业内部的低频调用场景——都存在显著的资源浪费。Serverless架构的出现彻底改变了这一局面：开发者只需为实际使用的计算资源付费，无请求时不产生费用，这种按量付费模式让API服务的成本曲线从固定支出变成了与业务量正相关的弹性支出。

阿里云Serverless产品体系以函数计算（Function Compute，简称FC）和Serverless应用引擎（Serverless App Engine，简称SAE）为核心，配合API网关、对象存储OSS等生态产品，为开发者提供了一套完整的低成本API服务构建方案。本文将从架构选型、代码开发、部署实践、成本优化、生产运维五个维度，系统讲解如何利用阿里云Serverless搭建生产可用的低成本API服务。

需要先登录阿里云控制台，点击：阿里云控制台

一、产品选型：函数计算FC与Serverless应用引擎SAE的抉择

1.1 函数计算FC：轻量级API的首选

函数计算是阿里云最早推出的Serverless计算服务，采用事件驱动模型。当HTTP请求、数据库变更等事件触发时，云平台自动分配计算资源执行函数，执行完毕后立即释放资源。开发者只需编写函数代码并上传，无需关心服务器购买、自动伸缩等运维操作。

FC的核心优势在于其极致的弹性与细粒度的计费。函数计算平台提供按量付费能力，以及毫秒级别的计费粒度。对于API服务这种请求量波动较大的场景，FC能够根据请求量自动扩缩容——请求高峰时自动创建更多实例，请求低谷时回收闲置实例，确保资源利用率最大化。FC支持多种运行时环境，包括Python、Node.js、Java、Go等，开发者可以使用熟悉的编程语言编写业务逻辑。

1.2 Serverless应用引擎SAE：微服务架构的Serverless化

SAE是阿里云面向应用托管场景推出的Serverless平台，向上抽象了应用的概念，支持以代码包和镜像方式部署应用并进行托管。与FC的函数级别粒度不同，SAE以应用为单位进行管理，更适合运行Spring Cloud、Dubbo等微服务架构的应用。

SAE的核心价值在于"零代码改造"——传统Spring Boot应用可以几乎不做修改地部署到SAE上，无需学习和适配函数编程模型。SAE支持秒级的自动弹性伸缩，可根据配置的定时策略或监控指标策略自动调整实例数量。SAE还内置了微服务治理能力，包括服务注册与发现、配置管理、全链路灰度等，适合有一定规模的微服务项目。

1.3 选型决策矩阵

FC和SAE的选择取决于业务场景的复杂度：

• 轻量API服务（推荐FC）：单个或少数几个API接口、业务逻辑相对独立、不需要复杂的微服务治理。FC的函数粒度更灵活，按调用计费更精细，冷启动后响应快，适合大部分API服务场景。
• 微服务架构（推荐SAE）：多个微服务应用相互调用、需要服务注册发现、配置管理和灰度发布等能力。SAE提供了完整的微服务运行环境，迁移成本低。

对于绝大多数API服务场景——尤其是本文聚焦的低成本API搭建——函数计算FC是更优的选择。其按实际调用计费的模型能够最大化成本效益，尤其适合流量不确定的项目。

二、开发API服务：Python FastAPI完整示例

2.1 环境准备

在开始之前，确保完成以下准备工作：

• 注册阿里云账号并完成实名认证
• 在阿里云控制台中开通函数计算服务
• 安装阿里云CLI工具：pip install aliyun-python-sdk-core aliyun-python-sdk-fc
• 配置CLI工具：运行 aliyun configure 并按提示输入AccessKey ID、AccessKey Secret和Region信息

2.2 创建FastAPI应用

下面是一个完整的FastAPI应用示例，实现了一个带有多路由的RESTful API服务：

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Optional
import json
import uvicorn

app = FastAPI(title="Serverless API Service", version="1.0.0")

# 请求体模型
class ItemCreate(BaseModel):
    name: str
    price: float
    description: Optional[str] = None

# 内存存储（演示用，生产环境建议使用数据库）
items_db = {}
item_id_counter = 1

@app.get("/")
async def root():
    return {"message": "Welcome to Serverless API Service", "status": "running"}

@app.get("/health")
async def health_check():
    return {"status": "healthy", "service": "api-gateway-demo"}

@app.post("/items")
async def create_item(item: ItemCreate):
    global item_id_counter
    item_id = item_id_counter
    items_db[item_id] = {
        "id": item_id,
        "name": item.name,
        "price": item.price,
        "description": item.description
    }
    item_id_counter += 1
    return {"status": "success", "item": items_db[item_id]}

@app.get("/items/{item_id}")
async def get_item(item_id: int):
    if item_id not in items_db:
        raise HTTPException(status_code=404, detail="Item not found")
    return items_db[item_id]

@app.get("/items")
async def list_items():
    return {"items": list(items_db.values()), "count": len(items_db)}

@app.delete("/items/{item_id}")
async def delete_item(item_id: int):
    if item_id not in items_db:
        raise HTTPException(status_code=404, detail="Item not found")
    deleted = items_db.pop(item_id)
    return {"status": "deleted", "item": deleted}

# 函数计算HTTP触发器入口函数
def handler(event, context):
    """
    函数计算HTTP触发器入口函数
    event: HTTP请求事件
    context: 函数计算上下文
    """
    from mangum import Mangum
    asgi_handler = Mangum(app)
    return asgi_handler(event, context)

2.3 代码解析

上述代码实现了一个完整的CRUD API服务：

• FastAPI应用：使用FastAPI框架构建RESTful API，自动生成OpenAPI文档（访问 /docs 可查看）
• 数据模型：使用Pydantic定义请求体模型，实现自动数据验证
• 路由定义：实现了创建、查询（单个/列表）、删除等标准CRUD操作
• 错误处理：使用HTTPException返回标准的HTTP错误响应
• 入口函数：handler函数是函数计算的调用入口，通过Mangum适配器将FastAPI应用转换为ASGI处理器，兼容函数计算的HTTP触发器调用方式

2.4 部署到函数计算

将上述代码部署到函数计算需要以下步骤：

步骤一：准备依赖

创建 requirements.txt 文件，包含以下依赖：

fastapi==0.104.1
uvicorn==0.24.0
mangum==0.17.0
pydantic==2.5.0

步骤二：打包代码

将所有代码文件和 requirements.txt 打包为 zip 文件：

zip -r api-service.zip . -x "*.pyc" "__pycache__/*"

步骤三：创建服务和函数

使用阿里云CLI创建服务和函数：

# 创建服务
aliyun fc CreateService --serviceName my-api-service --region cn-hangzhou

# 创建函数
aliyun fc CreateFunction --serviceName my-api-service \
  --functionName my-api-function \
  --handler index.handler \
  --runtime python3.10 \
  --code '{"zipFile": "file:///path/to/api-service.zip"}' \
  --memorySize 512 \
  --timeout 30

步骤四：创建HTTP触发器

为函数创建HTTP触发器，获得公网访问地址：

aliyun fc CreateTrigger --serviceName my-api-service \
  --functionName my-api-function \
  --triggerName http-trigger \
  --triggerType http \
  --triggerConfig '{"methods": ["GET", "POST", "PUT", "DELETE"], "authType": "anonymous"}'

三、API网关：安全高效地对外开放函数

函数计算是一个事件驱动的服务，将API网关与函数计算服务对接后，即可通过API形式安全地对外开放函数，并且解决认证、流量控制、数据转换等问题。

3.1 API网关与函数计算的对接方式

API网关目前支持两种形式的函数计算服务：HTTP函数和事件函数。对于Web API服务，推荐使用HTTP函数方式对接。

对接流程：

第一步：创建Web函数

在函数计算3.0控制台中创建一个Web函数。Web函数本质上是一个运行HTTP服务的函数，可以直接处理HTTP请求并返回HTTP响应。

第二步：创建后端服务

在API网关中定义后端服务，并配置后端服务地址来对接函数计算服务。登录API网关控制台，在左侧导航栏选择"后端服务"，单击"创建后端服务"。在创建后端服务弹框中，填写配置信息并确定。然后在后端服务定义页面配置触发路径的访问地址并发布。

第三步：创建API

在API网关控制台上创建API。关键配置包括：

• API分组：建议API分组与函数计算在相同的地域。如果函数计算与API不在同一地域，将通过公网访问函数计算服务，产生额外的流量费用。
• 后端配置：选择"使用已有的后端服务"，后端服务类型选择"Function Compute"。
• 产品版本：Function Compute 3.0。
• 函数类型：HTTP函数。
• 后端服务：选择已创建的后端服务。
• HTTP Method：如果后端函数支持多个方法，选择"ANY"。

3.2 安全认证配置

API网关提供了多种认证方式保障API安全：

• 阿里云APP认证：使用AppCode进行安全调用，适用于移动应用和Web应用。
• JWT认证鉴权：为HTTP触发器配置JWT认证鉴权，可以确保仅持有有效JWT的客户端才能访问函数。
• 签名认证：在自定义域名上启用签名认证，API网关在转发请求前验证每个入站请求的签名。

四、成本构成与优化策略

4.1 函数计算FC的成本构成

函数计算提供了试用额度、按量付费和资源包三种计费方式，计费项统一为CU使用量。CU使用量涵盖以下资源消耗：

• 函数调用次数：每次函数调用产生的费用
• 活跃vCPU使用量：函数执行期间vCPU资源的消耗
• 内存使用量：函数执行期间内存资源的消耗
• 磁盘使用量：临时磁盘空间的消耗
• 活跃GPU使用量（如使用GPU实例）

函数计算提供了慷慨的免费额度：每月前100万次调用免费，超出后按量计费。对于大多数个人项目和初创产品，这个免费额度已经足够覆盖日常使用。

4.2 API网关的成本构成

API网关的Serverless实例适用于中小规模的生产环境，使用费用由两部分构成：

• API调用量费用：API网关收到的所有API请求均为有效调用，会计入收费范围
• 公网出访流量费用：API网关转发请求到后端服务时产生的公网流量

4.3 成本优化策略

策略一：充分利用免费额度

函数计算每月提供100万次免费调用和400,000 GB-s的资源使用量。对于日均请求量在3万次以内的API服务，基本可以做到零成本运行。

策略二：内网通信降低流量成本

API网关与函数计算部署在同一地域时，通信走内网，不产生公网流量费用。这是降低API服务成本最关键的措施之一。务必确保API网关和函数计算在同一个Region（如cn-hangzhou）。

策略三：按量模式与预留模式的合理选择

函数计算的CPU实例和GPU实例均支持按量模式和预留模式。按量模式根据请求时长计费，适合请求量波动大的场景。预留模式从实例启动完成开始计费到实例释放为止，适合对冷启动敏感的生产环境。

策略四：购买CU资源包

对于有稳定请求量的API服务，购买CU资源包可以进一步降低成本。函数计算提供CU资源包月包和年包，所有资源使用量按照转换系数转换为CU使用量后从资源包中抵扣。

策略五：合理设置函数规格

根据API的实际计算需求选择合适的内存和超时时间。过高的规格配置会导致不必要的费用支出。对于大多数轻量级API，512MB内存和30秒超时已经足够。

4.4 成本估算示例

以一个日均10,000次请求的API服务为例，假设每次请求平均执行时间100ms，内存配置512MB：

• 函数调用次数：每月30万次，在免费额度（100万次/月）内，费用为0
• 资源使用量：30万 × 0.1秒 × 512MB = 15,360 GB-s，在免费额度（400,000 GB-s/月）内，费用为0
• API网关调用：30万次调用，Serverless实例按量计费，费用极低
• 总成本：接近0元

即使超出免费额度，按量付费的单价也非常低廉。这就是Serverless架构在成本端的核心优势——用多少付多少，没有闲置浪费。

五、生产环境关键议题

5.1 冷启动优化

冷启动是Serverless架构中常见的性能问题。当函数长时间无业务流量后，所有按量实例将被平台释放，之后的第一个请求会触发冷启动——平台需要更多时间来拉起函数实例服务该请求。

优化方案一：配置最小实例数

通过设置函数的最小实例数大于0，可以提前锁定弹性资源，有效避免函数调用高峰期间因实例冷启动导致的请求延迟问题。还可以配置指定时间段或指定指标利用率达到设定阈值后对最小实例数进行扩缩容，在保障性能的同时提高实例利用率。

优化方案二：预留模式实例

当使用弹性管理功能配置了预留实例，函数计算会按照配置在调用请求到来之前预先构建实例，避免造成冷启动。预留模式实例启用闲置模式后，在没有请求时会被函数计算冻结其vCPU资源，进入闲置状态——闲置状态下不产生vCPU费用，能节省大量成本。

优化方案三：代码优化

减少函数初始化阶段的耗时操作（如加载大模型、建立数据库连接池等），可以显著缩短冷启动时间。将耗时的初始化操作放到函数外部（全局作用域）执行，利用函数计算的实例复用机制减少重复初始化。

5.2 安全防护

RAM权限管理

使用RAM子账号进行最小权限授权，避免主账号AccessKey泄露带来的风险。为不同的函数和服务分配不同的RAM角色，遵循最小权限原则。

API网关认证

通过API网关的认证机制保护API安全。生产环境建议启用JWT认证或签名认证，确保只有授权的请求才能访问后端函数。

流量控制

在API网关层面配置流量控制策略，防止恶意刷量和DDoS攻击。可以按API、按用户、按IP等多维度设置限流规则。

5.3 监控与告警

函数计算提供了完善的监控能力：

• 函数级监控：查看每个函数的调用次数、执行时间、错误率等指标
• 日志服务：函数计算自动将日志输出到阿里云日志服务（SLS），便于问题排查
• 告警配置：在云监控中配置告警规则，当错误率、延迟等指标超过阈值时及时通知

六、实战案例：从零到一的完整实践

以一个真实场景为例——为个人博客搭建一个访问统计API服务。需求如下：

• 记录每篇博文的访问次数
• 提供获取热门文章列表的接口
• 日均请求量约5000次
• 成本目标：月均控制在5元以内

架构方案：

• 使用函数计算FC（Python Runtime）承载业务逻辑
• 使用阿里云Tablestore（表格存储）作为数据存储
• 使用API网关对外开放API接口
• 全部部署在cn-hangzhou地域，内网通信

核心代码片段：

from fastapi import FastAPI, HTTPException
from tablestore import OTSClient, Row, Condition, UpdateTable
import os
import json

app = FastAPI()

# 初始化Tablestore客户端
ots_client = OTSClient(
    endpoint=os.environ.get('OTS_ENDPOINT'),
    access_key_id=os.environ.get('OTS_ACCESS_KEY_ID'),
    access_key_secret=os.environ.get('OTS_ACCESS_KEY_SECRET'),
    instance_name=os.environ.get('OTS_INSTANCE_NAME')
)

@app.post("/api/stats/{post_id}")
async def record_view(post_id: str):
    """记录博文访问"""
    # 使用原子计数器更新访问量
    row = Row([('post_id', post_id), ('views', 1)])
    try:
        ots_client.update_row('blog_stats', row, Condition('IGNORE'))
        return {"status": "recorded", "post_id": post_id}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

@app.get("/api/stats/top")
async def get_top_posts(limit: int = 10):
    """获取热门文章列表"""
    # 查询并排序
    # ... 省略具体实现
    return {"top_posts": []}

# 函数计算入口
def handler(event, context):
    from mangum import Mangum
    return Mangum(app)(event, context)

成本分析：

• 函数计算：日均5000次调用，月均15万次，在免费额度内 → ¥0
• Tablestore：按量计费，少量数据存储和读写 → 约¥2-3/月
• API网关：Serverless实例按调用量计费 → 约¥1-2/月
• 总成本：约¥3-5/月

这个案例充分展示了Serverless架构在低成本API服务场景下的巨大优势。

七、总结

阿里云Serverless产品体系为开发者提供了一套完整的低成本API服务构建方案。通过合理的产品选型（FC vs SAE）、充分利用免费额度、内网通信降本、按需配置函数规格，开发者可以用极低的成本搭建生产可用的API服务。

核心要点回顾：

• 产品选型：轻量API选FC，微服务架构选SAE
• 开发部署：FastAPI + Mangum适配器，一行命令部署到FC
• API网关：同地域内网通信免流量，多种认证方式保障安全
• 成本优化：免费额度 + 按量付费 + CU资源包，极致降本
• 生产就绪：预留实例解决冷启动，RAM+API网关认证保障安全

Serverless架构不仅改变了API服务的成本结构——从固定支出变为弹性支出，更让开发者能够将精力从基础设施运维中解放出来，聚焦于业务逻辑本身。对于初创项目、个人Side Project以及企业内部的低频API场景，阿里云Serverless无疑是当前最具性价比的选择之一。

常见问题解答

问1：函数计算FC和Serverless应用引擎SAE应该如何选择？

轻量级API服务（单个或少数几个接口）推荐使用FC，其函数粒度更灵活，按调用计费更精细。如果是Spring Cloud或Dubbo等微服务架构，需要服务注册发现、配置管理等能力，则推荐使用SAE，可以实现零代码改造迁移。

问2：如何解决函数计算的冷启动问题？

可以通过三种方式优化：一是配置最小实例数大于0，提前锁定弹性资源；二是使用预留模式实例，在请求到来前预先构建实例；三是优化代码，减少函数初始化阶段的耗时操作。

问3：API网关和函数计算不在同一地域会产生什么影响？

如果不在同一地域，API网关将通过公网访问函数计算，会产生公网流量费用，同时网络延迟也会更高。建议将API网关和函数计算部署在同一地域（如cn-hangzhou），走内网通信以降低成本并提升性能。

问4：函数计算的免费额度是多少？超出后如何计费？

函数计算每月提供100万次免费调用和400,000 GB-s的资源使用量。超出免费额度后，按CU使用量计费——调用次数约0.0000125元/次，资源使用约0.000045元/GB-秒。对于大多数个人项目和中小规模API服务，免费额度通常足够使用。

问5：如何进一步降低API服务的成本？

主要策略包括：确保API网关与函数计算同地域以实现内网通信免流量；购买CU资源包抵扣资源使用量；根据实际需求合理设置函数的内存和超时规格，避免过度配置；对于稳定的请求量，考虑使用预留模式结合闲置模式进一步优化成本。

问6：FastAPI应用如何部署到函数计算？

使用Mangum适配器将FastAPI应用转换为ASGI处理器，在handler函数中调用Mangum(app)即可。然后将代码和依赖打包为zip文件，通过阿里云CLI或控制台上传创建函数，最后配置HTTP触发器获得访问地址。