Security

从单个整体应用程序过渡到微服务架构可以解决许多问题。它允许团队独立工作、单独部署服务并根据需要扩展系统的各个部分。然而，它也带来了一个新的挑战：客户如何与所有这些独立服务交互？ 如果您有十个、五十个或数百个微型微服务，移动应用程序或网页是否应该直接连接到其中的每一个？ 这就是 API 网关模式 的用武之地。在本指南中，我们将通过简单的文字和现实世界的类比来详细介绍 API 网关是什么、为什么需要它以及它如何简化您的微服务系统。 现实世界的类比：酒店接待员 想象一下您正在入住一家大型豪华度假酒店。度假村有许多不同的部门： 客房服务（干净的床单） 客房服务（食物） 礼宾部（预订旅游） 账单（用于支付账单） 如果您想要一条干净的毛巾，您不必穿过度假村试图找到客房服务大楼。如果你想吃晚饭，就不要敲厨房的门。相反，您可以致电前台接待员。 接待员听取您的请求，确定哪个部门可以解决，并为您联系或处理。 在这种情况下： 您 是客户端（移动应用程序或浏览器）。 接待员是API网关。 部门（客房服务、客房服务、计费）是微服务。 问题：客户端到服务的直接通信 在了解网关如何工作之前，让我们看看如果我们“不”使用网关会发生什么。 假设您的电子商务应用程序具有三个独立的微服务： 用户服务（管理个人资料） 产品服务（管理目录） 订单服务（管理结账） 如果没有 API 网关，客户端应用程序必须直接向每个服务的单独地址（IP 或 URL）发送单独的请求： 这种直接连接方法会带来几个主要问题： 太多端点：客户端应用程序必须记住三个单独的 URL。如果拆分服务或更改其地址，则必须更新客户端应用程序。 安全噩梦：每个微服务必须单独实现身份验证（检查登录令牌）、SSL 证书和防火墙规则。 网络开销：客户端可能需要通过慢速移动网络发出三个单独的网络请求才能加载单个页面（例如，获取配置文件、获取产品详细信息和获取订单历史记录）。 协议差异：您的客户端应用程序可能更喜欢使用 HTTP/JSON 等标准 Web 协议，但您的内部服务可能使用 gRPC 或 AMQP 等专用协议进行更快的通信。 解决方案：API 网关模式 API 网关 是位于客户端应用程序和内部微服务之间的辅助服务器。它充当所有传入请求的单一入口点。