API 网关只是用来保护或路由 API 的吗

这有必要过网关吗？

强行过度设计总是必要的

API Gateway 实际上是做熔断、负载均衡等业务的，静态页放在其后也不是不可以。

静态资源为什么要经过 API 网关？ LZ 究竟想解决什么问题？

Kong 有啥功能，google 一下不行？

静态页面用 nginx 更合适

@index90 这样一个可以解决同域的问题，另外对外统一入口，比如 demo.com/site1,demo.com/site2

我在考虑网关能不能保护静态网页，比如用户没有登录，通过网关进行校验

可以是可以，但是没有人会这样做吧，对服务器压力很大的。
部分静态页面还好，但是所有静态资源都放到 gateway 后面，试想想一个页面几十上百的页面元素，每个元素都要校验，机器会扛不住的。

建议 LZ 还是学一下 CORS 和动静分离策略吧

@index90 恩，看来还是要多学习下“动静分离策略”

API 网关当然只跟 API 有关系啊

静态资源还是要用静态资源的方式

两个例子:

1. Mock OPTION method.
2. 鉴权.

1 能减轻 Lambda 调起的次数, 避免无效的消耗.
2 除了上面的好处外, 还有简化逻辑的功能.

已经在用 Kong 的路上越走越远了

@razertory 朋友能不能介绍下 KONG 或 分享下体验，KONG 是免费的吗，可以部署在 windows 服务器上吗或如何部署，管理端是 web 形式的，上手简单吗

@daijinming 本质上 Kong 就是 Nginx + Lua 部署应该没啥问题。
我这边主要用来做请求限制，cors 和 jwt 避免每个 API Service 都做一套相同的逻辑。上手还是蛮简单的，调 API 或者配一个 kong-dashboard （ web 管理端）就 ok

不是，甚至可以做更多的功能

1、认证；
2、权限；
3、安全；
4、业务统一，all 杂牌子 API to 统一 API ；
5、审计；

网关主要的功能就是路由，或者说只有经过网关的流量，才能被均衡地分配到不同的服务实例。没有网关，你就必须直接访问服务实例，就无法进行流量的动态分配。
至于别的功能，API 调用审计和身份认证放在网关上实现也说得过去。但很多人把鉴权也放到网关上面，我个人认为是不合适的。因为虽然接口 url 可以作为资源的特征来进行基于 url 的鉴权，但这样一来 url 里面就不能有 PathParam 就不能用了。而且也不能用 GET/PUT/DELETE 这些方法了，硬要用也不是不行，但要注意使用不同的 url，还不如统一 POST 来的简单。

一般 API 接口

@xuanbg 很有参考价值的一席话