做开放平台这件事，很多团队一上来就纠结用什么框架，其实先该想清楚的是：你的API要对外暴露多少层？谁能调？调多少？这些问题没想明白，架构图画得再漂亮也白搭。
一、网关层：所有请求的唯一入口
开放平台必须有且仅有一个统一入口。不管是Spring Cloud Gateway、Kong还是APISIX，选哪个不重要，重要的是它要能干三件事：协议转换、请求路由、统一鉴权。别让每个后端服务自己去校验token，那会变成灾难。网关层把鉴权拦在最前面，后端服务只管业务逻辑。
落地建议：网关层配置统一的请求日志和响应日志，出问题时能快速定位是网关还是后服务的锅。日志保留7天足够，别占太多存储。
二、认证体系：别只用一把钥匙
API认证最常见的是API Key + Secret的HMAC签名方案。但实际业务中，你会发现不同接入方需求差异很大：有的只需要简单调用，有的要做OAuth2.0授权给终端用户，有的要走mTLS双向认证。
判断标准：如果接入方是B端企业，HMAC签名就够了；如果要让C端用户授权第三方应用访问数据，必须上OAuth2.0；如果是金融场景，mTLS是底线。
一个容易踩的坑：API Secret的存储要用加密而非明文，数据库里存密文，只在验证时解密。每对Key/Secret绑定明确的权限范围，别给一个key全量权限。
三、路由策略：按版本和服务做拆分
API版本管理推荐URL路径版本（/v1/xxx），简单直接。路由规则按服务名+版本号匹配，网关转发到对应后端集群。关键点在于灰度发布能力：新版本API先给5%的流量跑，验证没问题再全量切。
落地步骤：先在网关配置按header做流量分割，把带x-api-version=v2的请求路由到新版本集群。观察一周，错误率没变化再全量。
四、限流机制：保护后端也是保护接入方
限流一定要做两层：网关层做全局QPS限制，防止单一接入方打爆整个平台；服务层做单接口限流，防止某个高频接口拖垮同服务的其他接口。令牌桶算法适合大多数场景，突发流量能扛住。如果是秒杀类场景，换成漏桶更合适。
配额管理要和计费系统打通。免费接入方给1000次/天的基础配额，超出后返回429状态码并在响应头里带X-RateLimit-Remaining，让接入方知道还剩多少额度。
五、监控告警：架构的最后一道防线
Prometheus + Grafana的组合够用了。核心监控指标就四个：QPS、平均响应时间、错误率、限流触发次数。告警阈值设定：错误率超过1%立即告警，平均响应时间超过500ms告警。
别等到接入方投诉才发现问题。主动监控加上日志追踪，平台运营效率会高很多。