微服务-API网关-整体架构思考

最新推荐文章于 2025-03-19 14:05:41 发布

Make Dream Happen

最新推荐文章于 2025-03-19 14:05:41 发布

阅读量878

点赞数 1

分类专栏：微服务

本文链接：https://blog.youkuaiyun.com/haohzhang/article/details/108084759

版权

本文深入探讨了API网关在微服务架构中的重要性，介绍了API网关的主要功能，如身份认证、权限控制、协议转换、限流、熔断降级和API聚合等，并详细阐述了API网关在不同场景下的应用，包括面向Web App、Mobile App、Partner OpenAPI和IoT SmartDevice。此外，还讨论了API网关的高可用和性能优化策略，并对比分析了Tyk、Kong和Zuul等开源API网关方案的优缺点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

API网关介绍

API网关这个东西的提出其实已经有些年头了，以前主要是运用在开放平台这样的对外提供接口服务的部门，随着微服务概念越来越深入人心，API网关也越发的流行了。

现在各个部门都可以把自己的服务通过API网关暴露给其他部门或者公司外部使用，和Service Mesh一起作为微服务管理的标准解决方案。

API网关就是进入各个服务的统一入口，API网关里面管理着一堆微服务，外面的客户端想要访问里面的微服务就需要先通过API网关，然后API网关对请求处理之后再发送到各个微服务中去，微服务处理完请求后回应也要先经过API网关，然后再返回给客户端。

API网关的几种使用场景

面向Web App

这类场景，在物理形态上类似前后端分离，此时的Web App已经不是全功能的Web App，而是根据场景定制、场景化的App。

面向Mobile App

这类场景，移动App是后端Service的使用者，此时的API GW还需要承担一部分MDM（此处是指移动设备管理，不是主数据管理）的职能。

面向Partner OpenAPI

这类场景，主要为了满足业务形态对外开放，与企业外部合作伙伴建立生态圈，此时的API GW需要增加配额、流控、令牌等一系列安全管控功能。

面向Partner ExternalAPI

这类场景，业界提的比较少，很多时候系统的建设，都是为了满足企业自身业务的需要，实现对企业自有业务的映射。当互联网形态逐渐影响传统企业时，很多系统都会为了导入流量或者内容，依赖外部合作伙伴的能力，一些典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等，这些对于企业内部来说，都是一些外部能力。此时的API GW就需要在边界上，为企业内部Service 统一调用外部的API做统一的认证、（多租户形式的）授权、以及访问控制。

面向IoT SmartDevice

这类场景，业界就提的更少了，但在传统企业，尤其是工业企业，传感器、物理设备从工业控制协议向IP转换，导致具备信息处理能力的「智能产品」在被客户激活使用直至报废过程中，信息的传输不能再基于VPN或者企业内部专线，导致物理链路上会存在一部分公网链路。此时的API GW所需要满足的，就是不是前三种单向的由外而内的数据流，也不是第四种由内而外的数据流，「内外兼修」的双向数据流，对于企业的系统来说终端设备很多情况下都不是直连网关，而是进过一个「客户侧」的集中网关在和企业的接入网关进行通信。

我要讲解的是第一种场景：Web App。