为什么微服务一定要有API网关？

微服务不能没有网关，就如同 Java 程序员不能没有IDEA、Eclipse。为什么呢？

之所以网关对微服务这么重要，主要有以下几点原因：

1. 解决 API 放哪里的问题

要知道，采用微服务架构的系统本身是由很多的独立服务单元组合起来的。而客户端要调用系统，则必须通过系统提供的各种对外开放的功能 API 来实现。

问题来了，这些 API 要放在哪里呢？直接放在组成系统的服务单元上行不行？

比如，在一套电商系统上，关于订单相关的 API ，放在组成订单服务的服务单元上；风控服务的 API ，放在组成风控服务的服务单元上。

好，咱们假设有这么一个场景，有一位用户想在这套电商系统上查看下商品详情。那么，这个查看商品详情的操作，就可能：

可以看到，就这么一个商品查看操作，就可能会调用许多服务的 API。

那这些 API 如果全部分散到各个服务单元上，供客户端调用，像查看商品这么简单的一次操作，客户端就可能需要远程访问好几次甚至十几次服务器。

微服务员自己有讲究把 API 的粒度划分得很细，也就是说，可能从商品服务上调用商品信息，不止是调用一次商品服务就够了，很可能需要多次对商品服务的不同 API 进行调用，才能获取到足够的数据。

这样一来，客户端需要访问服务器的次数就更多了，可能十几次都不够，得几十次。

这种多次访问服务器的行为，会极大延迟客户端的界面响应时间，很不现实。

所以，把 API 放到各个业务相关的服务单元上，看上去问题很大。

那为什么引入网关就能解决这个问题呢？

因为引入网关，就相当于在客户端和微服务之间加了一层隔离。通常，网关本身会和各个服务单元处于同一个机房，这样，客户端做业务操作的时候，只需要访问一次网关。然后剩下的事情，再由网关分别访问同在一个机房的不同的服务，再把拿到的数据统一在网关封装好，返回给客户端就好。

在一套微服务组成的系统里，除了必须的业务功能以外，还有为了系统自身的健壮与安全，以及微服务本身的管理，而必须引入的一些非业务功能。对于这些非业务又很重要的功能，我们统称为边缘功能。

还是拿电商系统为例，我们来看一些重要的边缘功能。

假设因为我们做了一次非常大的促销活动，导致流量过大，系统承载不了了。此时，为了保证系统本身的稳定，我们就需要把一些承载不了的流量给通过各种手段消化掉，一般的做法有三种：

限流：通过令牌桶等算法，把一些额外的流量挡在系统外面，不让其访问。
降级：由于系统可能已经过载了，此时，我们就放弃处理一些服务和页面的请求或者进行简单处理，比如直接返回一个报错。
熔断：有些时候，系统过载过度或者上线出了问题 bug，降级都解决不了问题。比如，缓存失效了，导致大量请求频繁访问了数据库，而这种频繁访问数据库可能造成了大量的 IO 操作，结果又影响了数据库所在的操作系统，同时，这个操作系统上又有着别的重要服务，直接也被影响了。对于这种连锁反应，我们称之为雪崩。而为了防止雪崩，我们就会坚决把缓存失效导致数据库被频繁访问的服务给停掉，这就是熔断。

可以看到，像限流、降级、熔断这些系统保障策略，最合适的地方应该是有一个集中的请求入口点，就像古时候，老百姓进城需要过城门那样。

当系统出现问题的时候，直接就在这个入口点做相应的操作即可。