aliyun-open-platform-api-gateway-architecture

阿里云开放平台概述

阿里云开放平台（open.aliyun.com）的官方定位是：

基于阿里云丰富完善的云产品体系落地”开放被集成”的业务策略。如果将阿里云看做一台巨大的计算机，数百个云产品看作各种组件（如CPU、磁盘、内存、网络等等），那么开放平台的使命就是帮助它们形成有机的整体，让开发者、企业、合作伙伴都能够基于这个操作系统简单、高效地开展自己的业务。

它不是某个单一产品，而是阿里云所有产品的”操作系统层”——负责统一 API、统一身份、统一治理、统一架构方法论。

---

六大功能模块详解

1. OpenAPI 开发者门户

地址： next.api.aliyun.com

统一的 API 搜索、调试、文档中心。所有阿里云产品（数百个）的 API 统一注册到 OpenAPI 门户，提供在线调试、自动生成多语言 SDK（Java/Python/Go/Node.js 等）、API 版本管理。

设计亮点：

• 统一网关架构：所有 API 调用经过统一的 API Gateway，负责鉴权、限流、路由
• 标准化元数据：每个 API 有标准化的 OpenAPI Metadata（参数、返回值、错误码），机器可读

2. Landing Zone 企业上云框架

帮助企业在上云前做好顶层规划，搭建安全、合规、可扩展的云上基础架构。核心流程：

graph LR
    A["搭建 Landing Zone"] --> B["账号工厂"] --> C["设置防护规则"] --> D["治理健康检测"]

步骤	做什么	原理
搭建 Landing Zone	云治理中心自动检测当前账号和资源目录情况，匹配初始化流程，一步步引导	自动化检测 + 模板化最佳实践
账号工厂	根据企业需要设置账号基线（baseline），批量交付新账号或应用到存量账号	Infrastructure as Code（IaC），基线模板 + 自动化脚本
设置防护规则	配置审计（Config）的防护规则，防止核心配置被误改	Policy as Code，类似 AWS Config Rules
治理健康检测	持续检测 IT 治理水平，提供改进引导	持续合规扫描 + 评分模型

涵盖 8 个领域：

1. 资源规划 — 多账号架构，避免管理风险
2. 财务管理 — 统一结算 + 内部分账机制
3. 网络规划 — 业务分区、隔离互通、混合云组网
4. 身份权限 — SSO、精细化的 RAM 策略
5. 安全防护 — 主机更新、病毒扫描、数据加密
6. 合规审计 — 操作日志统一收集、规则化审计
7. 运维管理 — 自动化运维体系
8. 自动化 — IaC（Terraform/ROS）驱动

3. Well-Architected 卓越架构

架构评审框架，帮助企业评估工作负载是否”优秀”。对标 AWS Well-Architected Framework。

五大支柱：

支柱	关注点
安全	网络安全、身份安全、主机安全、数据安全、威胁检测与响应
稳定	高可用、容灾、变更流程、部署架构、配置规范
成本	支出控制、资源选型、弹性扩缩不超支
效率	自动化变更、事件响应、运维标准化
性能	资源选型优化、性能监控、持续调优

通过问卷式评估 + 自动化检测，给出架构评分和改进建议。

4. 多账号架构

以资源目录（Resource Directory）为核心的多账号管理体系。

• 资源目录（RD） 是一个树形组织结构：Root → Folder → Account
• 支持 企业账号 和 云账号 两种成员类型
• 云 SSO 提供基于 RD 的统一身份认证
• 可信服务（Trusted Service） 机制：其他云产品（如 Config、ActionTrail）可以注册为 RD 的可信服务，获得跨账号访问权限

5. 凭证管理与安全

体系化的凭证安全治理方案，四大最佳实践：

实践	做法	原理
避免使用 Root 身份	主账号设复杂密码 + MFA，禁用主账号 AK	最小权限原则
独立身份分配	每人一个 RAM 用户 + SSO + 密码策略 + MFA	身份隔离 + 不可抵赖
临时凭据替代固定凭据	STS 临时 Token（时效可控）+ ECS 实例角色 + ACK RRSA	减少长期密钥暴露
固定凭据集中管控	AK 定期轮转、程序与 AK 一一对应、加密托管	凭据生命周期管理

6. 企业 IT 治理

持续的治理能力，核心产品矩阵：

产品	作用
资源目录	多账号组织结构
访问控制 RAM	身份与权限管理
云 SSO	统一单点登录
操作审计 ActionTrail	记录所有 API 调用和控制台操作
配置审计 Config	资源配置合规检测
配额中心	统一管理云产品配额
标签	资源分类与分账

---

分层解耦的”操作系统”架构

开放平台把数百个云产品当做”硬件组件”，自己充当”操作系统内核”：

graph TD
    subgraph OS["开放平台（OS 层）"]
        subgraph UNIFIED["统一能力"]
            API["统一 API<br/>Gateway"]
            ID["统一身份<br/>RAM/SSO"]
            GOV["统一治理<br/>Config/Audit"]
        end
        PRODUCTS["数百个云产品（ECS, OSS, RDS, VPC...）"]
    end
    UNIFIED --> PRODUCTS

每个云产品只需要实现自己的业务逻辑，通用能力（认证、授权、审计、API 管理）全部下沉到平台层。

---

API 网关架构全景

阿里云的 API 网关目前有三代产品线：

产品	内核	定位
原 API 网关（Serverless/专享实例）	自研网关引擎	API 全生命周期托管
云原生 API 网关	基于 Higress + Envoy	流量网关 + 微服务网关 + 安全网关三合一
AI 网关	基于 Higress	大模型 API 代理 + MCP Server + AI 治理

云原生 API 网关是 Higress 的企业版，经历多年双 11 考验。

原 API 网关请求处理流水线

graph TD
    REQ["客户端请求"]
    subgraph ENTRY["API Gateway 入口层"]
        SLB1["公网 SLB"]
        SLB2["VPC SLB"]
        SLB3["IPv6 入口"]
    end
    PARS["请求解析 & 路由匹配<br/>(域名 → API分组 → 具体API定义)"]
    PLUG["插件执行链（Pipeline）<br/>认证鉴权 → 限流降级 → 参数校验 → 签名验证"]
    MAP["参数映射 & 转换<br/>(用户参数 → 后端服务参数)<br/>+ 常量参数注入<br/>+ 系统参数注入 (CaClientIp等)"]
    ROUTE["后端路由 & 转发<br/>HTTP后端 / VPC内网 / FC函数 / OSS"]
    RESP["响应处理 & 日志记录<br/>(trace日志 + 链路追踪 + 监控指标)"]

    REQ --> ENTRY
    ENTRY --> PARS --> PLUG --> MAP --> ROUTE --> RESP

核心概念模型

graph TD
    subgraph GROUP["API 分组 (Group)"]
        D1["二级域名（测试用）"]
        D2["独立域名（生产用）"]
        D3["实例挂载"]
        subgraph APIS["API 列表"]
            A1["API-1<br/>定义 / 版本 / 授权"]
            A2["API-2<br/>定义 / 版本 / 授权"]
            A3["API-3<br/>定义 / 版本 / 授权"]
        end
    end
    subgraph APP["调用方身份：APP（应用）"]
        K["AppKey<br/>AppSecret"]
        AUTH["已授权API列表"]
    end
    APP --> APIS

调用者（APP）和 API 之间通过授权解耦。API 提供者创建 API → 创建签名密钥 → 绑定到 API → 授权给 APP → APP 用 AppKey/Secret 签名调用。

两种部署形态对比

维度	Serverless 实例	专享实例（VPC）
资源模型	多租户共享，弹性扩缩	单租户独享，固定资源
SLA	99.9%	99.95% ~ 99.99%
最大 RPS	2500/API分组	2500 ~ 60000
最大连接数	100000/域名	50000 ~ 1000000
超时上限	60s	3600s
出口 IP	不固定（共享）	固定独享
计费	调用次数 + 流量	实例规格 + 流量

---

云原生 API 网关架构（新一代，基于 Higress）

核心理念是四网合一：流量网关 + 微服务网关 + 安全网关 + AI网关统一，减少架构碎片。

控制面 / 数据面分离

graph TD
    subgraph CP["控制面 (Control Plane)"]
        K8S["K8s API Server"]
        ING["Ingress Controller"]
        CONSOLE["Higress Console<br/>(管理界面/API)"]
        ETCD["配置存储 (etcd)<br/>- 路由规则<br/>- 插件配置<br/>- 服务发现<br/>- 证书/策略"]
        K8S --> ETCD
        ING --> ETCD
        CONSOLE --> ETCD
    end
    subgraph DP["数据面（无状态，可水平扩展）"]
        D1["DP-1 (Envoy)"]
        D2["DP-2 (Envoy)"]
        DN["DP-N (Envoy)"]
    end
    ETCD -- "xDS/gRPC 推送" --> DP

数据面内部结构

graph TD
    L["Listener<br/>HTTP/TLS 监听"] --> R["Route<br/>路由匹配"] --> FC["Filter Chain<br/>插件链"] --> C["Cluster<br/>后端路由"] --> B["Backend"]

多注册中心服务发现

云原生网关支持多注册中心，这是它作为”微服务网关”的核心能力：

graph TD
    GW["云原生 API 网关 (Envoy)"]
    GW --> N1["Nacos 注册中心<br/>Spring Cloud / Dubbo 服务"]
    GW --> N2["ZooKeeper<br/>Dubbo 服务"]
    GW --> N3["Eureka<br/>Spring Cloud Netflix 服务"]
    GW --> N4["Consul<br/>HashiCorp 生态"]
    GW --> N5["K8s Service<br/>原生容器服务"]
    GW --> N6["固定 IP/域名<br/>传统服务"]
    GW --> N7["FC (函数计算)<br/>Serverless 函数"]

---

插件体系架构（最值得学习的设计）

插件执行模型

graph TD
    REQ["请求进入"]
    P1["认证鉴权<br/>JWT / OIDC / IDaaS"]
    P2["访问控制<br/>IP黑白名单 / 地域封锁"]
    P3["流量管控<br/>限流 / 降级 / 熔断"]
    P4["参数转换<br/>请求头改写 / 映射"]
    P5["安全防护<br/>WAF / CC 防护"]
    P6["自定义插件<br/>用户上传 WASM/Lua 插件（热更新）"]
    FWD["转发到后端"]

    REQ --> P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> FWD

WASM 沙箱扩展机制

云原生网关的插件基于 WASM (WebAssembly) 沙箱运行：

graph TD
    subgraph ENVOY["Envoy Proxy 进程"]
        subgraph WASM["WASM Runtime (VM)"]
            PA["Plugin A<br/>(Go/Rust)"]
            PB["Plugin B<br/>(Go/Rust)"]
        end
        ISOL["沙箱隔离<br/>- 内存隔离<br/>- CPU 限额<br/>- 崩溃不影响主进程"]
    end
    WASM --> ISOL

关键特性：

• 热更新：插件变更不需要重启网关，通过 xDS 推送新配置，WASM 模块热加载
• 语言无关：Go、Rust、C++ 编译成 WASM 都可以
• 沙箱隔离：单个插件崩溃不影响整个网关
• 每个用户每个 Region 限制 10000 个插件，单个插件元数据 50KB

---

统一 API Gateway 架构（开放平台底层）

所有阿里云产品的 API 调用都经过统一的 API Gateway：

graph TD
    CLIENT["调用方 (SDK / CLI / 控制台)<br/>SDK (Java/Python/Go/Node...)<br/>自动签名 + 自动拼装 HTTP 请求"]
    GW["统一 API Gateway (open.aliyun.com)<br/>1. 身份验证: AccessKey + Signature (HMAC-SHA1)<br/>　 Query: SignatureMethod, SignatureVersion, SignatureNonce, Timestamp<br/>2. 格式协商: Format=JSON/XML<br/>3. 版本路由: Version=2014-08-15 等<br/>4. Region 路由: RegionId=cn-hangzhou"]
    ROUTER["产品级路由 (Product Router)<br/>Action=DescribeInstances → ECS 后端<br/>Action=GetObject → OSS 后端<br/>Action=CreateDBInstance → RDS 后端<br/>Action=* → 数百个产品后端..."]
    SUB["限流 (QPS) / 审计日志 / 配额检查"]
    BACKENDS["ECS 集群 / OSS 集群 / RDS 集群 ..."]

    CLIENT -- HTTPS --> GW --> ROUTER --> SUB --> BACKENDS

统一签名协议

所有阿里云 OpenAPI 调用遵循同一套签名协议：

1. 构造规范化请求字符串 (Canonicalized Query String)
   - 所有参数按字母序排列
   - URL encode

2. 构造签名字符串
   STRING_TO_SIGN =
     HTTP Method + "&" +
     URL encode("/") + "&" +
     URL encode(Canonicalized Query String)

3. 计算 HMAC-SHA1 签名
   Signature = Base64(HMAC-SHA1(AccessKeySecret, STRING_TO_SIGN))

4. 将 Signature 附加到请求中

任何语言的 SDK 只需要实现这套签名算法，就能调用所有阿里云产品的 API。API Gateway 在入口处统一验签，后端产品不需要各自实现认证。

---

值得学习的设计模式总结

设计模式	在哪用的	为什么好
控制面/数据面分离	云原生网关 (Envoy xDS)	配置变更不影响数据面转发，网关可独立水平扩展
插件链 Pipeline	两代网关都用	关注点分离，新能力加插件即可，不动核心
WASM 沙箱扩展	云原生网关	安全隔离 + 热更新 + 语言无关
APP + 授权解耦	原 API 网关	API 提供者和调用者完全解耦，灵活授权管理
四网合一	云原生网关	流量网关 + 微服务网关 + 安全网关 + AI网关统一，减少架构碎片
统一签名协议	开放平台 API	一套签名打天下，数百产品零适配成本
多注册中心	云原生网关	异构微服务统一接入，不绑定服务发现方案
Serverless + 专享双形态	原 API 网关	小业务按量付费，大业务独享资源，同一套 API 管理体系
账号基线模板	Landing Zone	GitOps / IaC 思想在企业治理层面的应用，组织级策略代码化、自动化
可信服务委托	资源目录	解决多账号权限代理问题，RD 统一授权替代逐账号创建

Sources

No external sources for this entry.

Related

2026-07-01 · blog

mini-agent 双实例部署与免备案 API 暴露

本地 Arch + 阿里云 ECS 双实例运行 mini-agent：5 个配置开关切角色、/sync/* 端点做单向同步；公网入口用 Cloudflare Tunnel 主路径 + ECS nginx 共存路径，CF 橙云隐藏源站 IP 是『免备案』的真相。DevOps & 云原生 · 9 min read 2026-06-25 · blog

aliyun-account-system

系统梳理阿里云 RAM 账号体系：RAM 用户、用户组、角色三者的区别与选型，权限策略 JSON 结构与粒度层级，子账号与 RAM 用户的术语澄清，以及主账号 AK 收口的最佳实践。DevOps & 云原生 · 7 min read 2026-07-06 · blog

Nginx 从进程模型到健康检查完全指南

一篇打通 Nginx：Master/Worker 进程模型、IO 多路复用、HTTP 头部处理、11 个请求阶段、Gzip 压缩、负载均衡健康检查的全链路详解。DevOps & 云原生 · 25 min read