【转】聊聊API网关的作用

API 网关的用处

API 网关我的分析中会用到以下三种场景：

1. Open API。企业需要将自身数据、能力等作为开发平台向外开放，通常会以 rest 的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的 QQ 开发平台、微信开放平台。Open API 开放平台必然涉及到客户应用的接入、API 权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是 API 网关可以发挥作用的时候。
2. 微服务网关。微服务的概念最早在 2012 年提出，在 Martin Fowler 的大力推广下，微服务在 2014 年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API 网关在微服务架构中正是以微服务网关的身份存在。
3. API 服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的 API 服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。API 网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的 API 服务管理平台。

API 网关在企业整体架构中的地位

一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。因此在我的设计中将这三种应用分别用不同的网关进行 API 管理，分别是：API 网关（OpenAPI 合伙伙伴应用）、API 网关（内部应用）、API 网关（内部公网应用）。

企业中在如何应用 API 网关

1. 对于 OpenAPI 使用的 API 网关来说，一般合作伙伴要以应用的形式接入到 OpenAPI 平台，合作伙伴需要到 OpenAPI 平台申请应用。因此在 OpenAPI 网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求 OpenAPI 网关需要提供 API 给这个用户平台进行访问。如下架构：

   

   当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用 id/密钥等，这种情况下也就不需要合作伙伴门户子系统。

2. 对于内网的 API 网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的 API 服务治理平台。当企业将所有的应用使用微服务的架构管理起来，那么 API 网关就起到了微服务网关的作用。而当企业只是将系统与系统之间的调用使用 rest api 的方式进行访问时使用 API 网关对调用进行管理，那么 API 网关起到的就是 API 服务治理的作用。架构参考如下：

   

3. 对于公司内部公网应用（如 APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的 API 网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的 API 网关。如果使用独立的 API 网关，有以下的好处：

   • 面向合作伙伴和面向公司主体业务的优先级不一样，不同的 API 网关可以做到业务影响的隔离
   • 内部 API 使用的管理流程和面向合作伙伴的管理流程可能不一样
   • 内部的 API 在功能扩展等方面的需求一般会大于 OpenAPI 对于功能的要求

基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴 OPEN API 网关和内部公网应用网关。

API 网关有哪些竞争方案

1. 对于 Open API 平台的 API 网关，我分析只能选择 API 网关作为解决方案，业界没有发现比较好的可以用来作为 Open API 平台的入口的其他方案
2. 对于作为微服务网关的 API 网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的

   • Service Mesh，这是新兴的基于无 API 网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前 Service Mesh 的产品还正在开发中，并没有非常成熟可直接应用的产品。发展最迅速的产品是 Istio。建议大家密切关注相关产品的研发、业务使用进展

     

   • 基于 duboo 架构，在这个架构中通常是不需要网关的，是由客户端直接访问服务提供方，由注册中心向客户端返回服务方的地址。

     

API 网关解决方案

私有云开源解决方案如下

1. Kong 是基于 Nginx+Lua 进行二次开发的方案
2. Netflix Zuul 是 spring cloud 的一个推荐组件
3. orange 是一个基于 OpenResty / Nginx 的国产 HTTP API Gateway

公有云解决方案

1. Amazon API Gateway
2. 阿里云 API 网关
3. 腾讯云 API 网关

自研解决方案

1. 基于 Nginx+Lua+ OpenResty 的方案，可以看到 Kongorange 都是基于这个方案
2. 基于 Netty、非阻塞 IO 模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。
3. 基于 Node.js 的方案。这种方案是应用了 Node.js 天生的非阻塞的特性。
4. 基于 java Servlet 的方案。zuul 基于的就是这种方案，这种方案的效率不高，这也是 zuul 总是被诟病的原因。

企业怎么选择 API 网关

如果是要选择一款已有的 API 网关，那么需要从以下几个方面去考虑：

1. 性能与可用性

   如果一旦采用了 API 网关，那么 API 网关就会作为企业应用核心，因此性能和可用性是必须要求的。

   • 从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要 10ms 以下。系统需要采用非阻塞的 IO，如 epoll，NIO 等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js 的响应式编程和基于 java 体现的 RxJava 和 Future。
   • 网关必须支持集群部署，任务一台服务器的 crash 都应该不影响整体系统的可用性。
   • 多套网关应该支持同一管理平台和同一监控中心。如：一个企业的 OpenAPI 网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2. 可扩展性、可维护性

   一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。

3. 需求匹配度

   需要评估各 API 网关在需求上是否能满足，如：如果是 OpenAPI 平台需要使用 API 网关，那么需要看 API 网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等 OpenAPI 核心需求上去思考产品是否能满足要求。如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。

4. 是否开源？公司是否有自开发的能力？

   现有的开源产品如 kong，zuul，orange 都有基础的 API 网关的核心功能，这些开源产品大多离很好的使用有一定的距离，如：没有提供管理功能的 UI 界面、监控功能弱小，不支持 OpenAPI 平台，没有公司运营与运维的功能等。当然开源产品能获取源代码，如果公司有比较强的研发能力，能 hold 住这些开源产品，经过二次开发 kong、zuul 应该还是适应一些公司，不过需求注意以下一些点：

   • kong 是基于 ngnix+lua 的，从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。
   • zuul 因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配 zuul 的监控和管理系统。
   • orange 由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。

   另外 kong 提供企业版本的 API 网关，当然也是基于 ngnix+lua 的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。

5. 公有云还是私有云

   现在的亚马逊、阿里、腾讯云都在提供基础公有云的 API 网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因，不能使用外网公有网的 API 网关服务，这样就只有选择私有云的方案了。

   在需求上如果基于公有云的 API 网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。

   如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的 API 网关才能满足需求。

综合上面的分析，基础公有云的 API 网关只有满足一部分简单客户的需求，对于很多企业来说私有云的 API 网关才是正确的选择。