问题背景

假如我们开发一个短视频服务，我们可以将服务简单地划分为下列几个部分。

• 视频服务：视频的上传和下载。
• 社交服务：关注、私信和评论等传统的社交服务。
• 商品服务：周边商品和增值服务，比如会员服务。
• 评价服务：点赞视频、收藏视频、点赞评论等。

我们不可能只让用户再网页上刷视频，要支持很多个平台，简单地可以分为下面两个。

• WEB 服务（网页）
• APP 服务（手机上的软件）

如果我们要部署这四类服务，肯定不能将其部署在同一个机器或者机房里，原因如下。

• 单个机器的能提供的服务量有限，大量的用户使用时无法及时处理。
• 一旦机房出现意外，所有的服务都会失效，容错性太低。

所以我们就把这四种服务部署在物理位置距离适当的四个机房中。真实情况要比这个复杂得多，比如我可能会在许多个机房中部署同一个服务，防止某个机房出现意外时对应的服务失效，但这对本文来说不重要。

现在我们部署好了全部的服务，可以让 APP 和网页调用我们服务来让用户刷视频了。

看起来是不是没什么问题？以 WEB 端为例，存在下列问题。

• 需要调用四类完全不同的服务，而且通常它们的调用方式无法保证一致，加大了开发难度。WEB 开发者需要写四套调用代码，而服务的开发者需要为两个平台提供两套接口。前后端代码的耦合性不可避免地提高，提升维护难度。
• 用户的一次操作可能多调用多个服务，意味着发起多次网络请求，如果这些请求还必须按照确定的顺序执行，响应时间会很长，降低用户体验。

实践中，服务的划分可能更多，对应的调用方式会更加复杂，必须做出改变。

如何解决？

上面的例子中，我们发现出现问题的原因是我们总是不可避免地需要同时用到多种服务，那么有什么解决办法呢？

很容易想到如果把这四类服务合并为一类服务是不是就可以了？其实这回引入更多的问题。

• 不同的服务对硬件的需求不同，例如视频服务不需要很高的硬件配置，但带宽已经要足够；社交和评价服务通常涉及到复杂的数据查询，需要强大的计算和 I/O 性能；商品服务需要极高可靠性，其服务器的部署方式可能都比较特殊，同时对性能也有较高的要求。
• 软件层面就是代码的耦合问题，简单来说就是大幅度提高开发和维护成本。

既然合并服务不可行，那么把服务的调用合并起来怎么样呢？听起来不错，这就是 API 网关的作用了。

API 网关

如果你有计算机网络的理论基础，你肯定知道 “网关” 这个概念，在 OSI 模型的网络层中，网关通常指路由器，因为它可以实现局域网间的数据互通。API 网关的作用也类似，即接受客户端的请求，转发客户端的请求，转发服务端的响应给客户端。

那么这和客户端直接请求有什么区别呢？一大区别就是 API 网关可以将不同服务的接口聚合成一个接口，客户端只要请求一次，API 网关就可以根据请求向若干个服务发起请求，等到请求完成后，一起返回给客户端。

如图所示，这样做有下列优点。

• API 网关屏蔽了不同服务之间调用差异，统一了调用方式，降低开发和维护成本。
• 无需发起多次网络请求，提升了响应时间，保证用户体验。
• API 网关层面可以进行更多的操作，比如安全检查，前后端只需要专注于业务逻辑即可。

那么有什么缺点呢？缺点就是 API 网关一定要十分可靠，否则一旦它出现故障，所有的服务就算正常运行，客户端也无法调用它们。

可靠既包含性能保证，也要有容灾保证。为了保证这两点，我们通常不会只部署一个节点的网关，而是部署很多个节点，这样既能保证性能，又有容灾能力。