API网关作用与技术形态和发展趋势 (课件).docx

APl网关的用处API网关我的分析中会用到以下三种场景。OpenAPE企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。OPenAPl开放平台必然涉及到客户应用的接入、APl权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。微服务网关。微服务的概念最早在2012年提出，在MartinFoWler的大力推广下，微服务在2014年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。APl网关在微服务架构中正是以微服务网关的身份存在。APl服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的APl服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。APl网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的APl服务管理平台。APl网关在企业整体架构中的地位一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。因此在我的设计中将这三种应用分别用不同的网关进行APl管理，分别是：API网关（OPenAPl合伙伙伴应用）、API网关（内部应用）、APl网关（内部公网应用）。企业中在如何应用APl网关1、对于OPenAPI使用的APl网关来说，一般合作伙伴要以应用的形式接入到OPenAPl平台，合作伙伴需要到OPenAPl平台申请应用。因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。如下架构：合作伙停设合伙W用的当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。2、对于内网的APl网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的APl服务治理平台。当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。而当企业只是将系统与系统之间的调用使用restapi的方式进行访问时使用APl网关对调用进行管理，那么APl网关起到的就是API服务治理的作用。架构参考如下：访问方开发人员3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致,在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的APl网关。如果使用独立的APl网关,有以下的好处：面向合作伙伴和面向公司主体业务的优先级不一样，不同的APl网关可以做到业务影响的隔离。内部APl使用的管理流程和面向合作伙伴的管理流程可能不一样。内部的APl在功能扩展等方面的需求一般会大于OPenAPl对于功能的要求。基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPENAPI网关和内部公网应用网关。APl网关有哪些竞争方案1、对于OPenAPl平台的APl网关，我分析只能选择APl网关作为解决方案，业界没有发现比较好的可以用来作为OPenAPl平台的入口的其他方案。2、对于作为微服务网关的APl网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的。ServiceMesh,这是新兴的基于无APl网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前SerViCeMeSh的产品还正在开发中，并没有非常成熟可直接应用的产品。发展最迅速的产品是Istioo建议大家密切关注相关产品的研发、业务使用进展。个慢o93r 方 3msmc MMhmrswrat . ½tSrvcMh可以对汰尢NHK力.Btt.”9MSEc MMh . -Wlr<i HLIstio为此带来了集中式的控制面板.基于Duboo架构，在这个架构中通常是不需要网关的，是由客户端直接访问服务提供方，由注册中心向客户端返回服务方的地址。APl网关解决方案私有云开源解决方案如下：Kong,Kong是基于Nginx+Lua进行二次开发的方案NetflixZuuhZuul是SpringCloud的一个推荐组件Orange,这个开源程序是国人开发的自开发解决方案：基于NginX+Lua+OpenResty的方案，可以看到KOng,Orange都是基于这个方案。基于Netty、非阻塞IO模型。，通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。基于Nodejs的方案，这种方案是应用了Nodejs天生的非阻塞的特性。基于JaVaSerVIet的方案，ZUUl基于的就是这种方案，这种方案的效率不高,这也是ZUUI总是被诟病的原因。企业怎么选择APl网关如果是要选择一款已有的API网关，那么需要从以下几个方面去考虑。性能与可用性如果一旦采用了APl网关，那么APl网关就会作为企业应用核心，因此性能和可用性是必须要求的。从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要IOms以下。系统需要采用非阻塞的10,如epoll,NIo等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Nodejs的响应式编程和基于Java体现的RxJava和Futureo网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。多套网关应该支持同一管理平台和同一监控中心。如：一个企业的OPenAPl网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。可扩展性、可维护性一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。需求匹配度需要评估各APl网关在需求上是否能满足，如：如果是OPenAPl平台需要使用APl网关，那么需要看APl网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OPenAPl核心需求上去思考产品是否能满足要求。如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。是否开源？公司是否有自开发的能力？现有的开源产品如Kong,Zuul,Orange都有基础的API网关的核心功能，这些开源产品大多离很好的使用有淀的距离，如：没有提供管理功能的Ul界面、监控功能弱小，不支持OPenAPl平台，没有公司运营与运维的功能等。当然开源产品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源产品，经过二次开发KOng、ZUUl应该还是适应一些公司，不过需求注意以下一些点：Kong是基于Ngnix+Lua的，从公司的角度比较难于找到能去维护这种架构产品的人。需求评估当前公司是否有这个能力去维护这个产品。Zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配ZUUI的监控和管理系统。Orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。另外Kong提供企业版本的API网关，当然也是基于Ngnix+Lua的，企业版本可以购买他们的技术支持、培训等服务、以及拥有界面的管理、监控等功能。公有云还是私有云现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关，当然这些网关的基础功能肯定是没有问题，但是二次开发，扩展功能、监控功能可能就不能满足部分用户的定制需求了。另外很多企业因为自身信息安全的原因，不能使用外网公有网的API网关服务，这样就只有选择私有云的方案了。在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用，无法做到定制的合作伙伴门户，这也不适合于部分企业的需求。如果作为微服务网关，大多数情况下是希望网关服务器和服务提供方服务器是要在内网的，在这里情况下也只有私有云的APl网关才能满足需求。综合上面的分析，基础公有云的API网关只有满足一部分简单客户的需求,对于很多企业来说私有云的APl网关才是正确的选择。云原生时代，APl网关为何如此重要？APIApplicationProgramInterface,应用程序连接接口的缩写，作为数据传输流转的重要通道，APl网关更成为云原生时代的重要入口。APl是各个不同的应用程序和系统之间互相调用和传输数据的标准方式。在很多的开发团队中都是使用API-first的模式，围绕着APl来进行产品的迭代，包括测试、Mock、文档、API网关、DevPortal等，这就是APl全生命周期管理(FullLifeCycleAPIManagement)。API解决的问题在API出现之前，数据的传输和交换并没有标准的方式，大多数情况下是通过数据库、Excel表格、文本，或者是FTP,不同的系统和程序通过各种五花八门的方式来沟通。这些混乱的背后，隐藏了巨大的开发成本和安全隐患：权限控制、数据精细管控、限流限速、审计等，都只能用笨重的方式来解决。这就是计算机世界中的“巴别塔”(ToWerofBabel),因此只有解决了不同语言开发的系统以及不同存储方案带来的问题，才有机会构建足够复杂的产品。而API的出现，则成功地解决了巴别塔问题，开发者只需要关心其他系统对外暴露的API即可，无需关心底层实现和细节。我们熟知的手机App,网络游戏、视频直播、远程会议和IoT设备，都离不开终端设备与服务端的连接和数据传输，这些都是通过API完成的。为什么需要API网关API网关是API全生命周期管理的关键基础组件，负责生产环境中APl的配置、发布、版本回滚、安全、负载均衡等。API网关是所有终端流量的入口，负责把终端的APl请求路由到正确的上游服务进行处理，然后再把返回的数据返回给原始请求方，同时保证整个过程的安全、可靠和低延迟。在最开始API数量不多的情况下，API网关往往是一个由WebServer和上游服务两部分拼接而成的虚拟组件：由Apache和NGINX等组件完成最简单的路由转发、反向代理和和负载均衡，其他功能比如身份认证、限流限速等，则依靠上游服务自身进行实现。但随着API的数量越来越多，喜欢“偷懒”的开发者们发现了一个严重的问题：他们需要在不同的上游服务中，重复实现身份认证、限流限速、日志等通用的功能，这不仅会浪费开发资源，而且一旦需要修改这部分的代码，就需要修改很多代码，这是版本管理和升级维护的噩梦。怎么办呢？聪明的开发者们很快就找到了解决方案：把这些通用的功能抽象到一个统一的组件中，把上述的两层结构改为一层结构，从上游的逻辑代码中剥离与业务无关的功能，然后增强Apache和NGINX这类组件。这就是第一代API网关的诞生过程。让API网关承载更多非业务逻辑的功能，这就是APl网关一直以来的进化方向。在这个过程中，前端开发者和后端开发者们，为了让产品能够更快的迭代，就对APl网关提出了越来越多的需求，并不仅仅局限于负载均衡、反向代理、身份认证等传统功能，还在gRPC、GraphQL,可观测性等方面提出了很多新的功能。APl网关的作用为了让API网关更灵活高效，开发者们在底层上也做了非常多创新，比如:功能插件化。随着API网关上