这是一个创建于 1091 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景
目前在做一个平台型的项目，需要开放部分 API 给外部开发者使用，在架构设计上有些疑问。
疑问
- 这套暴露的 API 是直接把现有的业务 API 加一种鉴权方式（比如 OAuth2 ，开发者 token 之类的）给暴露出去呢，还是需要新写一套 API 呢？
- 对于目前比如阿里云这些平台的开放 API ，有大佬清楚是如何设计的么，他们前端页面会是也调用的同样的 API 吗？
 |
1
Oktfolio 2021-12-23 16:44:27 +08:00
走 API Gateway 加鉴权。至于复用，个人偏向于新写一套 API 。
|
 |
2
thinkershare 2021-12-23 16:57:42 +08:00
开放 API 属于应用层, 业务属于领域层, 网关还在更上层, 所以肯定是分开哈
|
 |
3
br_wang 2021-12-23 16:58:27 +08:00
「隔离」挺重要的。即使不重新开发，重新部署一套也是有必要的。
|
 |
4
v2orz 2021-12-23 17:31:31 +08:00
APIgateway
开放的和自己用的肯定不走一条道 |
 |
5
NewConn 2021-12-24 14:33:08 +08:00  1
我们改过 3 次
最开始：对外和内部走一个 gateway ，同一套服务；网关有鉴权，但是只有对内页面会重定向到单点登录，对内的后台接口和对外接口，都通过 header 参数后门绕过； 第一次改：对外和对内同一个网关，同一套代码；对外和对内用不同的 CI 参数(主要就是数据库只读 /读写不同)，不同的机器部署； 第二次改：对外接口有超大返回值，比如一次返回 6G 的 JSON(这不是关键)。对外接口返回时间长，占用网关的并发；网关的超时时间必须设置的很长，兼容对外接口，影响界面。所以网关也拆分成 2 个了。 第三次改：对外接口设置黑名单，必须统一 OAUTH 鉴权，header 带动态 token ；不在黑名单的接口，保持 header 参数绕过鉴权 |
Select Language