如何正确理解api网关

微服务这么火，随之api网关常常被提到。那么什么才是api网关？这个问题也一直困扰着我。前几周在csdn数据库大会上与沪江的一个架构师就这个问题探讨了一下。使我对于api网关的认识清晰了很多，所以在本文梳理一下我的思路并总结，希望能够帮助到还一直迷糊的朋友。

使用api网关的原因

在网上关于说明使用api网关的原因，无外乎如下几种：

• 负载均衡
• 减少客户端与服务端的直接调用
• 容错
• 服务发现与注册
• 统一认证
• 等等…

api网关分类

api网关可能没有分类，只是我理解硬性的将其归类。
如果只需要负载均衡、减少客户端与服务的直调、容错这几项功能，那么nginx可以直接提供服务，并且它的使用方式与nginx的反向代理使用方式没有任何区别，所以这时也会不清nginx提供的是反向代理功能还是api网关功能，反正是能够满足你的业务需求。

然后再加以对nginx进行的其他不满足功能进行扩展，比如Kong就属于这一类框架解决方案。这类框架它的使用，对应的URL地址一般情况是根据业务进行分组，然后使用nginx的URL路由到后端相应的业务服务器。

这种框架与我所理解的api网关有所区别，我的概念中即然为api网关，它的URL地址则不应当变化。即前端用户始终请求一个固定地址,类似http://host:port/gateway/gateway.如果是通过这种方式，则网关服务器接收到请求需要路由，路由的参数只能通过请求参数或协议头传递过来。对于这种情况的路由，nginx好像搞不定，所以只能自主开发。

我们将这两种实现进行归类，以nginx的多地址路由实现方式归为类别一，即KONG属于此类框架;以固定URL地址的网关归结为类别二。

维服务的框架spring cloud,它也提供一个api网关zuul,根据我对于它的了解，它也归为类别一。了解了几个开源的关于api网关的使用功能都归结为类别一。那么为什么它们都是以这种方式开发，而没有使用固定的URL地址，有人可能会说api网关就是这样，没有你说的那种类别二，难道是我的理解有误？但是支付宝支付网关，京东支付网关都是以固定的URL这种形式进行提供。

那么类别一与类别二有什么区别呢？

我们发现在开源的api网关解决方案中都是采用类别一的形式，相比类别二，它的扩展性很好、路由规则很容易更改。但是它的使用让我有点蒙，因为我分不清它与反向代理到底有什么区别，因为前端依然需要知道N多的URL地址，然后进行调用，可能是我太较真。
类别二，对于前端调用，他们只需要知道一个固定的URL地址，通过传参不同的参数，网关对其服务进行路由。我认为这种方式更方便，这也仅仅只是我认为，因为这里需要传递额外的路由参数，所以总体来说，并不比类别一简单（不好意思在这里我又较真了一次）。

如何选择

我们如何进行选择呢？个人的理解，如果你想快速的搭建一个api网关平台，你还是选择类别一吧，比如KONG,ZUUL.如果你想了解类别二的实现方式，可以参考我的github https://github.com/zhuzhong/gateway。