聊聊API网关的作用

Open API。企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。

微服务网关。微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。

API服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。

面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。

内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。

内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

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

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

Kong，Kong是基于Nginx+Lua进行二次开发的方案，https://konghq.com/

Netflix Zuul，Zuul是Spring Cloud的一个推荐组件，https://github.com/Netflix/zuul

Orange，这个开源程序是国人开发的， http://orange.sumory.com/

Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/

阿里云API网关，https://www.aliyun.com/product/apigateway/

腾讯云API网关， https://cloud.tencent.com/product/apigateway

基于Nginx+Lua+OpenResty的方案，可以看到Kong，Orange都是基于这个方案。

基于Netty、非阻塞IO模型。，通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。

基于Node.js的方案， 这种方案是应用了Node.js天生的非阻塞的特性。

基于Java Servlet的方案，Zuul基于的就是这种方案，这种方案的效率不高，这也是Zuul总是被诟病的原因。

从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要10ms以下。系统需要采用非阻塞的IO，如epoll，NIO等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js的响应式编程和基于Java体现的RxJava和Future。

网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。

多套网关应该支持同一管理平台和同一监控中心。如：一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

Kong是基于Ngnix+Lua的，从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。

Zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配Zuul的监控和管理系统。

Orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。