API网关个人分析中会用到如下三种场景。java
一、Open API编程
企业须要将自身数据、能力等做为开发平台向外开放,一般会以rest的方式向外提供。最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。api
Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等,必然会有一个统一的入口进行管理,这正是API网关能够发挥做用的时候。缓存
二、微服务网关安全
微服务的概念最先在2012年提出,在Martin Fowler的大力推广下,微服务在2014年后获得了大力发展。服务器
在微服务架构中,有一个组件能够说是必不可少的,那就是微服务网关,微服务网关处理了负载均衡,缓存,路由,访问控制,服务代理,监控,日志等。微信
API 网关在微服务架构中正是以微服务网关的身份存在。网络
三、API服务管理平台架构
上述的微服务架构对企业来讲有可能实施上是困难的,企业有不少遗留系统,要所有抽取为微服务改动太大,对企业来讲成本过高。并发
可是因为不一样系统间存在大量的API服务互相调用,所以须要对系统间服务调用进行管理,清晰地看到各系统调用关系,对系统间调用进行监控等。
API网关能够解决这些问题,咱们能够认为若是没有大规模的实施微服务架构,那么对企业来讲微服务网关就是企业的API服务管理平台。
一个企业随着信息系统复杂度的提升,必然出现外部合做伙伴应用、企业自身的公网应用、企业内网应用等。
在架构上应该将这三种应用区别开,三种应用的安排级别、访问方式也不同。
所以在个人设计中将这三种应用分别用不一样的网关进行API管理,分别是:API网关(OpenAPI合伙伙伴应用)、API网关(内部应用)、API网关(内部公网应用)。
以下图所示:
一、对于OpenAPI使用的API网关来讲,通常合做伙伴要以应用的形式接入到OpenAPI平台,合做伙伴须要到 OpenAPI平台申请应用。
所以在OpenAPI网关以外,须要有一个面向合做伙伴的使用的平台用于合做伙伴,这就要求OpenAPI网关须要提供API给这个用户平台进行访问。
以下架构:
固然若是是在简单的场景下,可能并不须要提供一个面向合做伙伴的门户,只须要由公司的运营人员直接添加合做伙伴应用id/密钥等,这种状况下也就不须要合做伙伴门户子系统。
二、对于内网的API网关,在起到的做用上来讲能够认为是微服务网关,也能够认为是内网的API服务治理平台。
当企业将全部的应用使用微服务的架构管理起来,那么API网关就起到了微服务网关的做用。
而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理,那么API网关起到的就是API服务治理的做用。
架构参考以下:
三、对于公司内部公网应用(如APP、公司的网站),若是管理上比较细致,在架构上可能由独立的API网关来处理这部份内部公网应用。
若是想比较简单的处理,也能够是使用面向合做伙伴的API网关。
若是使用独立的API网关,有如下的好处:
面向合做伙伴和面向公司主体业务的优先级不同,不一样的API网关能够作到业务影响的隔离。
内部API使用的管理流程和面向合做伙伴的管理流程可能不同。
内部的API在功能扩展等方面的需求通常会大于OpenAPI对于功能的要求。
基于以上的分析,若是公司有能力,那么仍是建议分开使用合做伙伴OPEN API网关和内部公网应用网关。
一、对于Open API平台的API网关,我分析只能选择API网关做为解决方案。
业界没有发现比较好的能够用来做为Open API平台的入口的其余方案。
二、对于做为微服务网关的API网关,业界的选择能够选择的解决方案比较多,也取决于微服务器的实现方案,有一些微服务架构的实现方案是不须要微服务网关的。
(1)Service Mesh
这是新兴的基于无API网关的架构,经过在客户端上的代理完成屏蔽网络层的访问,这样达到对应用层最小的改动。
当前Service Mesh的产品还正在开发中,并无很是成熟可直接应用的产品。发展最迅速的产品是Istio。建议你们密切关注相关产品的研发、业务使用进展。
(2)基于duboo架构
在这个架构中一般是不须要网关的,是由客户端直接访问服务提供方,由注册中心向客户端返回服务方的地址。
公有云解决方案:
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老是被诟病的缘由。
若是要选择一款已有的API网关,须要从如下几个方面去考虑。
一、性能与可用性
若是一旦采用了API网关,那么API网关就会做为企业应用核心,所以性能和可用性是必需要求的。
从性能上来讲,须要让网关增长的时间消耗越短越好,我的以为须要10ms如下。
系统须要采用非阻塞的IO,如epoll,NIO等,网关和各类依赖的交互也须要是非阻塞的,这样才能保证总体系统的高可用性,如:Node.js的响应式编程和基于java体现的RxJava和Future。
网关必须支持集群部署,任务一台服务器的crash都应该不影响总体系统的可用性。
多套网关应该支持同一管理平台和同一监控中心。如:一个企业的OpenAPI网关和内部应用的多个系统群的不一样的微服务网关能够在同一监控中心进行监控。
二、可扩展性、可维护性
一款产品总有不能知足生产需求的地方,所以需求思考产品在如何进行二次开发和维护,是否方便公司团队接手维护产品。
三、需求匹配度
须要评估各API网关在需求上是否能知足。
好比:若是是OpenAPI平台须要使用API网关,那么须要看API网关在合做伙伴应用接入、合做伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能知足要求。
若是是微服务网关,那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。
四、是否开源?公司是否有自开发的能力?
现有的开源产品如kong,zuul,orange都有基础的API网关的核心功能,这些开源产品大多离很好的使用有必定的距离
好比:没有提供管理功能的UI界面、监控功能弱小,不支持OpenAPI平台,没有公司运营与运维的功能等。
固然开源产品能获取源代码,若是公司有比较强的研发能力,能hold住这些开源产品,通过二次开发kong、zuul应该仍是适应一些公司,不过需求注意如下一些点:
kong是基于ngnix+lua的,从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。
zuul由于架构的缘由在高并发的状况下性能不高,同时须要去基于研究整合开源的适配zuul的监控和管理系统。
orange因为没有被大量使用,同时是国内我的在开源,在可持续性和社区资源上不够丰富,出了问题后可能不容易找到人问。
另外kong提供企业版本的API网关,固然也是基于ngnix+lua的,企业版本能够购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。
五、公有云仍是私有云
如今的亚马逊、阿里、腾讯云都在提供基础公有云的API网关,固然这些网关的基础功能确定是没有问题,可是二次开发,扩展功能、监控功能可能就不能知足部分用户的定制需求了。
另外不少企业由于自身信息安全的缘由,不能使用外网公有网的API网关服务,这样就只有选择私有云的方案了。
在需求上若是基于公有云的API网关只能作到由内部人员为外网人员申请应用,没法作到定制的合做伙伴门户,这也不适合于部分企业的需求。
若是做为微服务网关,大多数状况下是但愿网关服务器和服务提供方服务器是要在内网的,在这里状况下也只有私有云的API网关才能知足需求。
综合上面的分析,基础公有云的API网关只有知足一部分简单客户的需求,对于不少企业来讲私有云的API网关才是正确的选择。
来源:https://www.jianshu.com/p/e30587bb9b06