混合软件生态系统中API网关使用及最佳实践咨询

1. 此场景下API网关是否为必要架构层，是否属于冗余？ #

不是冗余，反而属于高性价比的必要层。

• 你这套内部系统有10个独立后端，用网关做统一入口，客户端只需要记住一个网关地址，不用维护多个服务的访问配置，大幅降低内部使用和运维的复杂度；
• 可以把认证、日志、限流这些通用逻辑集中在网关实现，不用每个后端重复开发；
• 后续如果要调整后端部署地址、拆分或合并服务，客户端完全不用改动，这对内部系统的迭代灵活性很重要。
  哪怕流量低，这些管理上的便利远大于网关带来的一点点资源开销。

2. 当前API网关在用户登录成功后签发JWT令牌，后续请求由网关校验后转发至后端服务，是否需搭建独立认证服务？ #

当前场景下不需要额外搭建独立认证服务。
你的用户规模小（峰值150人），内部系统的认证逻辑简单，网关直接签发和校验JWT足够用，还能减少架构复杂度和运维成本。
如果后续有扩展需求，比如要对接企业LDAP、增加多因子认证，或者需要给其他内部系统共享认证能力，再考虑拆分出独立认证服务也不迟。

3. 后端服务置于防火墙后仅API网关可访问，若移除后端的JWT认证逻辑，存在网关被突破的风险，是否仍需后端校验令牌完整性？ #

必须保留后端的JWT校验逻辑。
网关被突破的风险确实低，但不是零——比如内部运维误操作打开了防火墙端口、网关配置漏洞被绕过，甚至某个后端被攻陷后横向访问其他服务，这时后端的JWT校验就是最后一道防线。而且校验JWT完整性的性能开销极小，完全没必要省这个步骤，能避免单点失效带来的全局安全风险。

4. 后端服务间需通信时，是否应全部通过API网关，还是采用服务间直接通信？相关最佳实践是什么？ #

最佳实践是优先服务间直接通信，特殊场景再走网关：

• 直接通信的优势是延迟低、不占用网关资源，内部服务间的调用逻辑和客户端请求差异大，没必要经过网关中转；
• 可以用本地DNS、配置中心或者简单的hosts配置来管理服务地址，实现内部服务发现；
• 如果需要对服务间调用做统一监控、限流，或者有跨服务的权限控制需求，再让这部分请求走网关，或者用轻量的服务网格工具来管理，但本地部署的话，直接通信+单独监控更简单。

5. 若需为不同应用建立WebSocket连接，是否需通过API网关处理？服务向客户端发消息时，先POST至网关再由网关转发的方案是否可行？ #

• WebSocket可以通过网关处理，只要你的网关支持WebSocket代理（比如Nginx、Kong这类主流网关都支持），这样能统一管理WebSocket连接的认证、限流和日志，不用每个后端单独处理；
• 服务先POST到网关再转发消息的方案完全可行，适合不需要超高实时性的场景，比如内部通知、消息推送。这种方式不用改动后端的推送逻辑，网关做统一转发即可；
• 如果是高实时性的场景（比如内部实时协作工具），直接由后端通过WebSocket长连接推给客户端更高效，能避免网关中转带来的延迟。另外要注意网关的WebSocket连接配置，比如超时时间、最大连接数，避免影响其他服务的正常访问。

内容的提问来源于stack exchange，提问作者Mark