4.3 KiB
2、使用 API 网关
本书七章节是关于设计、构建和部署微服务，第一章介绍了为微服务架构模式。它探讨了使用微服务的优点和缺点，以及尽管如此，微服务通常是复杂应用的理想选择。该系列的第二篇文章将探讨使用 API 网关构建微服务。
当您选择将应用程序构建成为一组微服务时，您需要决定应用程序客户端将如何与微服务进行交互。单体应用程序只有一组端点（endpoint），通常使用复制（replicated）结合负载均衡来分配流量。
然而，在微服务架构中，每个微服务都暴露一组通常比较细颗粒的端点。在本文中，我们将研究如何改进客户端通信，并提出一个使用 API 网关的方案。
2.1、简介
我们假设您正在为一个购物应用开发一个本地（native）移动客户端。您可能需要实现一个产品详细信息页面，用于展示给定商品的信息。
例如，图 2-1 展示了在 Amazon 的 Android 移动应用中的滚动产品信息时所看的内容。
即使这是一个智能手机应用，产品详细信息页面展示了很多信息。例如，不仅有基本的产品信息，如名称、描述和加价格，页面还展示了：
- 购物车中的物品数量
- 订单历史
- 客户评论
- 低库存警告
- 配送选项
- 各种推荐，包括了买了这个产品的客户经常买的其他产品
- 选择性购买选项
在使用单体应用架构的情况下，移动客户端通过对应用程序进行单个 REST 调用来检索此数据，例如：
GET api.company.com/productdetails/productId
负载均衡器将请求路由到几个相同应用程序实例中的其中一个。之后，应用程序查询各个数据库表并返回响应给客户端。相比之下，当使用微服务架构时，产品详细页面上展示的数据由多个微服务拥有。以下是一些可能拥有特定商品页面展示的数据的微服务：
- 订单服务 - 订单历史
- 目录（catalog）服务 - 基本的产品洗脑洗，如产品名称、图片和价格
- 评价服务 - 客户评价
- 库存服务 - 低库存警告
- 配送服务 - 配送选项、期限和费用，由配送方的 API 单独提供
- 推荐服务 - 推荐类目
我们需要决定移动客户端如何访问这些服务。让我们来看看这些方式。
2.2、客户端与微服务直接通信
理论上，客户端可以直接向每个微服务发送请求。每个微服务都有一个公开的端点：
https://serviceName.api.company.name
该 URL 将映射到用于跨可用实例分发请求的微服务负载均衡器，要检索特定的产品页面信息，移动客户端将向上述的每个微服务发送请求。
不幸的是，这种方式存在着挑战和限制。一个问题是客户端的需求与每个微服务暴露的细粒度的 API 不匹配。此示例中，客户端需要进行七次单独的请求。如果在更加复杂的应用中，它可能需要做更多的工作。例如，Amazon 展示了在产品页面渲染中如何牵涉到数百个微服务。虽然客户端可以通过 LAN 发送许多请求，但在公共互联网下效率低下，在移动网络肯定是不切实际的。
客户端直接调用微服务的另一个问题是有些可能使用了不是 web 友好的协议。一个服务可能使用 Thrift 二进制 RPC，而另一个则可能使用 AMQP 消息协议。这两个协议无论是对于浏览器或者防火墙都是不友好的，最好是在内部使用。应用程序应该在防火墙之外使用 HTTP 或这 WebSocket 之类的协议。
这种方法的另一个缺点是它难以重构微服务。随着时间推移，我们可能会想改变系统怎样划分为服务。例如，我们可能会合并两个服务或者将服务拆分为两个或者更多。然而，如果客户端直接与服务进行通信，实施这类的重构将变得非常困难。
由于这些问题，很少有客户端直接与微服务进行通信。
待续……