API Gateway

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

在 Web 开发的早期，构建软件应用程序非常简单：编写代码，将其打包到单个可执行或可部署的存档中，然后在服务器上运行。这种方法被称为单体架构，几十年来一直很好地服务于该行业。 然而，随着应用程序发展成为拥有数百名开发人员和数百万并发用户的大型企业平台，单体应用程序开始显示出其局限性。部署变得缓慢且危险，数据库成为瓶颈，代码库变得过于复杂，任何单个开发人员都无法理解。 为了解决这些扩展瓶颈，行业转向微服务架构。开发人员不是构建单个巨型应用程序，而是将系统分解为一组小型、独立且松散耦合的服务，这些服务通过 HTTP/REST、gRPC 或消息代理等轻量级协议进行通信。 在本文中，我们将分析微服务为现代应用程序带来的主要优势、它们带来的严峻挑战，以及如何确定该架构是否适合您的下一个项目。 1. 单体架构与微服务架构 在深入讨论细节之前，让我们先形象地了解这两种设计范式之间的根本区别。 在单体中，所有模块（例如，用户管理、产品目录、订单处理）共享相同的执行空间并写入单个共享数据库。在微服务设置中，每个服务都在自己的进程中运行，管理自己的私有数据库，并公开一个干净的 API。 API 网关 充当客户端的单一入口点，将请求路由到适当的后端服务。 2. 微服务的好处 采用微服务架构具有几个引人注目的优势，使其成为大规模现代系统的首选： A. 独立部署性和发布速度 在整体应用程序中，对结账系统进行微小的更改需要重建和重新部署整个应用程序。如果一个团队的功能被破坏，整个版本就会被阻止。 通过微服务，每个服务都有自己独立的 CI/CD 管道。运输服务团队每天可以部署更新十次，而无需与库存或支付团队协调，从而大大提高了功能交付速度。 B. 细粒度可扩展性 在单体应用程序中，如果结帐流程在黑色星期五期间遇到巨大的流量峰值，则必须水平扩展整个应用程序。这会为空闲模块消耗不必要的 CPU 和内存。 微服务允许有针对性的扩展。您可以启动 50 个订单和付款服务实例来处理负载，同时保持用户或通知服务以最少的资源运行，从而节省大量云托管成本。 C. 技术灵活性（多语言编程） 由于微服务通过标准化 API 协议（REST、gRPC）进行通信，因此团队不会被锁定在单一技术堆栈中： 用户服务可以用Go编写，以实现高性能的内存管理。 推荐引擎可以使用Python来获取其丰富的机器学习库。 支付网关可以用Java编写，以实现企业稳定性。 每个团队都可以为他们的具体问题选择最好的工具。 D. 故障隔离和系统弹性 如果单体应用程序中发生内存泄漏，整个进程就会崩溃，从而导致整个系统中断。 在微服务架构中，如果推荐服务由于错误而崩溃，应用程序的其余部分仍保持完整功能。用户仍然可以浏览产品、将商品添加到购物车并完成付款。故障是孤立的。 E. 团队协调和自治（康威定律） 康威定律指出，组织设计的系统模仿其通信结构。大型庞然大物通常会导致庞大的跨职能团队互相踩踏。 微服务允许组织将工程部门分解为小型、自治的“双比萨团队”。每个团队都拥有一个端到端的服务——从设计和编写代码到部署和数据库维护。