当选择将应用程序构建为一组微服务时，需要确定应用程序客户端如何与微服务交互。在单体应用程序中，只有一组（通常是重复的、负载均衡的）端点。然而，在微服务架构中，每个微服务都会暴露一组通常是细粒度的端点。在本文中，我们将讨论一下这对客户端与应用程序之间的通信有什么影响，并提出一种使用API网关的方法。

让我们想象一下，你要为一个购物应用程序开发一个原生移动客户端。你很可能需要实现一个产品详情页面，上面展示任何指定产品的信息。

例如，下图展示了在Amazon Android移动应用中滚动产品详情时看到的内容。

虽然这是个智能手机应用，产品详情页面也显示了大量的信息。例如，该页面不仅包含基本的产品信息（如名称、描述、价格），而且还显示了如下内容：

购物车中的件数；

订单历史；

客户评论；

低库存预警；

送货选项；

各种推荐，包括经常与该产品一起购买的其它产品，购买该产品的客户购买的其它产品，购买该产品的客户看过的其它产品；

可选的购买选项。

当使用单体应用程序架构时，移动客户端将通过向应用程序发起一次REST调用（GET api.company.com/productdetails/<productId>）来获取这些数据。负载均衡器将请求路由给N个相同的应用程序实例中的一个。然后，应用程序会查询各种数据库表，并将响应返回给客户端。

相比之下，当使用微服务架构时，产品详情页面显示的数据归多个微服务所有。下面是部分可能的微服务，它们拥有要显示在示例中产品详情页面上的数据：

购物车服务——购物车中的件数；

订单服务——订单历史；

目录服务——产品基本信息，如名称、图片和价格；

评论服务——客户的评论；

库存服务——低库存预警；

送货服务——送货选项、期限和费用，这些单独从送货方的API获取；

推荐服务——建议的产品。

我们需要决定移动客户端如何访问这些服务。让我们看看都有哪些选项。

客户端与微服务直接通信

从理论上讲，客户端可以直接向每个微服务发送请求。每个微服务都有一个公开的端点(https ://<serviceName>.api.company.name）。该URL将映射到微服务的负载均衡器，由它负责在可用实例之间分发请求。为了获取产品详情，移动客户端将逐一向上面列出的N个服务发送请求。

遗憾的是，这种方法存在挑战和局限。一个问题是客户端需求和每个微服务暴露的细粒度API不匹配。在这个例子中，客户端需要发送7个独立请求。在更复杂的应用程序中，可能要发送更多的请求。例如，按照Amazon的说法，他们在显示他们的产品页面时就调用了数百个服务。然而，客户端通过LAN发送许多请求，这在公网上可能会很低效，而在移动网络上就根本不可行。这种方法还使得客户端代码非常复杂。

客户端直接调用微服务的另一个问题是，部分服务使用的协议不是Web友好协议。一个服务可能使用Thrift二进制RPC，而另一个服务可能使用AMQP消息传递协议。不管哪种协议都不是浏览器友好或防火墙友好的，最好是内部使用。在防火墙之外，应用程序应该使用诸如HTTP和WebSocket之类的协议。

这种方法的另一个缺点是，它会使得微服务难以重构。随着时间推移，我们可能想要更改系统划分成服务的方式。例如，我们可能合并两个服务，或者将一个服务拆分成两个或更多服务。然而，如果客户端与微服务直接通信，那么执行这类重构就非常困难了。

由于这些问题的存在，客户端与微服务直接通信很少是合理的。

使用API网关

通常，一个更好的方法是使用所谓的API网关。API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、“请求整形（request shaping）”与管理、静态响应处理。

下图展示了API网关通常如何融入架构：