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网关上承载的功能越来越多，如何让这些功能之间更好的隔离以及让二次开发变得更加简单？插件，是完美的解决方案。因此，现在主流的API网关均采用插件来实现各种功能，比如在ApacheAPISIX中叫做Plugins,在Envoy中则称之为Filters,它们的含义是相同的。插件化可以让网关的开发者不再关心底层实现，用较少的开发资源就可以实现一个新的功能。数据面和控制面的分离。在第一代API网关的实现中，数据面和控制面是在同一个进程中实现的，这样足够简单，但也带来了很大的安全隐患。由于数据面是直接对外提供服务的，如果被黑客入侵，就有机会获取到控制面的数据（比如SSL证书）和控制权，造成更大的破坏。因此，现在大部分的开源APl网关，都是将两者分别部署的，中间通过关系型数据库或者etcd来进行配置的管理和同步。以ApacheAPlSIX为例，下面的架构图，诠释了以上两个创新：ControlPlane(CP)云原生时代下的挑战过去十年，IT领域最大的技术变革就是云原生。诞生于2013年的Docker拉开了云原生的帷幕，从此裸金属、虚拟机开始被容器所替代，单体架构开始被微服务所替代。但是云原生并不是简单的技术革命，其背后的推动力主要来自互联网产品的快速发展和激烈竞争，云原生相关的技术生逢其时，迅速流行并替代了之前的很多技术组件和方案。具体到API网关在云原生中的挑战，主要来自以下两个方面：单体架构到微服务的转型在微服务架构逐渐被开发者认可和落地后，该架构释放了巨大的技术红利：每个微服务可以按照自己的节奏进行升级和发布，不需要担心与其他服务的耦合。产品的迭代因此变得敏捷，每天都可以进行几十次甚至几百次的发布。但与此同时，微服务的发展也带来了一些副作用，比如：API和微服务的数量从最初的几十个，增长到几千个，甚至几万个；出现故障时如何快速定位是哪一个APl引起的？如何保证API的安全？如何做到服务熔断和服务降级？API网关无法独立解决安全性、可观察性、灰度发布等问题。它需要与Prometheus>ZipkinSkywalking>Datadog>Okta等众多开源项目和SaaS服务合作，为企业提供更好的解决方案。动态和集群化管理容器和Kubernetes的普及，让动态成为所有云原生基础组件的标准特性。在Kubernetes的环境中，容器在不断的生成和销毁，弹性伸缩成为一个必选项而不是可选项。想象一个场景：一家互联网电商公司做了一次促销，大量的用户在一个小时内涌入，促销结束后就会离开。对于传统架构的公司来说，他们需要事先采购一批物理服务器，来应对这些高峰时候的APl流量；但是对于云原生架构的公司来说，就可以随时使用公有云上的弹性资源，根据APl请求的数量，自动的调整网络、计算、数据库等资源的规模即可。那么伴随着容器弹性伸缩而来的技术挑战如下：上游服务不断更换IP地址和端口;IP黑白名单的频繁更新;服务健康的及时检测和异常处理;APl的频繁发布;服务注册和发现的及时性;SSL证书的热更新和自动轮转。想要解决上述这些挑战，均需要依赖于动态。以NGINX为代表的第一代APl网关，动态能力是非常弱的。因为NGINX是本地静态配置文件驱动的，所以变更任何配置都需要重启NGINX服务才能生效，这在云原生时代是不能被企业接受的。这就是第一代API网关的技术痛点之一。在中国，有一家类似微软OffiCe365的SaaS办公软件公司-WPS,他们有数百台物理机在运行着APaCheAPISIX,有近万核CPU在处理来自客户端的APl请求，每天处理数百亿次API请求。在这个超大规模的APl网关环境下，开发者不可能去逐个修改每一个APl网关的配置然后Reload,他们希望有一个统一的控制台来操作整个集群。可惜的是，第一代API网关诞生的年代，并没有这么大的实例规模，也就没有考虑集群管理的需求。下一代API网关的发展上述挑战和痛点，逐渐催生了新一代的API网关。和第一代API网关不同的是，云原生时代诞生的下一代API网关是在开源社区的驱动下快速成长的。借助社区和众多开源贡献者的力量，这些API网关有机会形成一个正向的迭代和进化：更快速的收集一线开发者及用户的需求和痛点在开源项目中尝试解决这些问题开源项目变得更加好用，吸引更多开发者使用于是，我们看到下一代API网关突破了传统网关的负载均衡和反向代理的定位，而是承担起了API和流量的连接、调度、过滤、分析、协议转换、治理、集成等更多的职责。支持更低成本的二次开发同时，让开发者能够以更低的成本进行二次开发，也成为了下一代APl网关的亮点。集成是APl网关的重要功能之一，对于下游是协议解析和各种协议的转换，包括GraphQLgRPC、Dubbo等；对于上游是集成Okta、Keycloak>Datadog.Prometheus等身份认证、可观测性服务，以及公司内部的认证、日志、审计等服务。APl网关不可能覆盖集成过程中所有的组件，这时候不可避免地需要开发者通过插件的方式进行二次开发，来满足自己的业务需求。不同的APl网关提供了不同的二次开发的编程语言和开发方式，ApacheAPISlX和Kong都可以使用Lua来编写原生插件，Envoy是使用C+编写原生插件。同时，ApacheAPISlX还可以使用GoPython、NodeJava和Wasm来编写插件，这些主流的开发语言已经可以覆盖绝大部分开发者了。APIGatewayAPISIXKongEnvoylanguagesforcustompluginsLuaGoJavaPythonNodeWasmLuaGoWasm(notopensource)C+LuaWasmDevelopmentdifficultyLowMediumHigh开发者不必去学习Lua和C+,就可以使用自己熟悉的编程语言在下一代APl网关上进行开发，这让基础组件的开发变得更加简单。开源和易于二次开发，是下一代的APl网关最重要的特点，它把更多的选择权留给了开发者自身,同时，开发者也可以更加放心的在多云、混合云的环境下使用API网关，不用担心被云供应商锁定。基于双十一的API网关流量处理场景这里，我们用一个具体的例子来解释下现代API网关的作用。在双十一时，电商都会有各种各样的商品促销活动，这段时间的API请求量是平时的几十倍。让我们先来看下如果没有API网关将会是怎样的技术架构：可以看到，在Order和Payment服务中，身份认证和日志记录功能是重复的。一个电商的服务，一般会有数千个不同的服务组成，这时候就会有大量的代码和功能是重复开发的。下面是增加了APl网关之后的架构图：从上图可以看到，我们在API网关层统一了公共的服务，后端服务只需要关心自身业务，为弹性伸缩提供了更多可能。当促销开始时，客户端大量API请求涌入API网关的时候，后端服务需要进行快速的弹性伸缩，为了保障关键业务不受突发流量的影响，我们需要在API网关上识别恶意爬虫并实现限流限速、服务降级和熔断。此时，我们可以暂时关闭部分服务，比如商品评价、快递查询等。但是库存信息、购买功能、支付功能等核心业务是绝对不能出现故障的，因此我们需要通过K8s来管理容器服务，再生成更多的服务副本来保证它的正常运行。此时API网关需要将客户端的API请求路由到新生成的副本服务，并且自动移除出现故障的服务，如下图所示。总结API网关并不是一个新的基础中间件，而是在产品快速迭代和技术架构的变迁中，变得越来越重要。而下一代云原生API网关的出现则解决了企业用户在集群管理，动态，生态，可观测性以及安全性等方面的痛点。APl网关不仅可以处理API的流量，也可以来处理KubernetesIngress和服务网格的流量,进一步降低开发者的学习成本，帮助企业更好的统一管理流量。APl网关的技术形态和发展趋势在软件架构设计中很多都采用“层''的结构，所以有这样一句名言：”计算机领域的任何问题都可以通过增加一个间接的中间层来解决:APl网关便是这样一个中间层，无论是早期银行证券系统的前置机，还是随着微服务架构模式发展而演化出来的APl网关，它都是作为APl访问的统一接入的中间层。今天我们从以下四点来聊一聊API网关：微服务经典的四层架构API网关模式常见的开源APl网关网关在容器技术和K8S主导的云原生时代将如何演进1 .微服务经典的四层架构单体应用中有一个典型的MVe分层技术，把系统分为数据层、展示层和业务逻辑层，在这种模式下我们比较关注应用自身。而到微服务时期，每个微服务除了数据和业务逻辑之外，往往要依赖下游服务的API,同时自身也会提供APl给上游服务，微服务之间相互协作提供整体的系统能力。此时，除了微服务本身之外更加关注整个上下游，为了统一APl接入和避免公共能力的重复建设，设计了网关路由层；为了更加解耦，不至于微服务牵一发而动全身，又独立出一个BFF层(BackendForFront)t,这就是典型的四层架构：前端层、网关层、BFF层、微服务层。借用netflix的系统架构为例来说明一下，早期netflix四层架构如下图：用户体验房路由屋Wiumii BFF粕服务用用户体验层：支持各种不同的前端设备，给用户良好的使用体验。网关路由层：使用ZUUl网关作为服务路由层，同时兼具安全、监控、熔断、限流等横切功能。ZUUI网关无状态集群部署，前置AWSELB做负载均衡。边界APl层：服务剪裁聚合层，也就是BFF层，当然在netflix内部并不叫BFF,而是称其为边缘服务层(EdgeServiceLayer),将后端微服务适配到不同的前端体验。微服务层：核心领域服务，也称为中间层(MIddleTier)服务。随着业务的更加复杂，边界APl层一方面随着微服务层的变动而频繁修改,给开发测试带来巨大的工作量，于是独立出一层隔离变化。Client 网关BFFAPl聚合层做服务层无论是四层还是五层，netflix服务入口流量都是由ZUUl一夫当关，作为边缘网关，将外部流量调度到内部服务，俗称南北流量调度。当然，边缘网关作为外部流量进入内部服务的第一道“关卡”，天然适合承载安全认证、流量控制等通用功能，这也就引出了另一个话题：APl网关模式！2 .APl网关模式APl网关是定义在外部服务进入内部服务入口处的一种服务，类似于面向对象设计的外观模式，它封装了应用程序的内部架构，为客户端提供统一的API,下面示意图展示了客户端、APl网关和内部服务之间的关系。作为入口层，API网关在架构设计中占尽“地缘”优势。一方面，就像城堡的大门，可以承载访客的身份认证、权限控制、路线引导（路由）、人流控制（排队机制/关闭通道等）、访问记录等功能；另一方面，后端APl需要的通用功能比如重试机制、熔断、限流、降级等也可以放到这一层，避免各个微服务重复建设。下表大概罗列一下APl网关所承载的功能。当然，表格并没有完全覆盖APl网关的全部功能，也不是说一个APl网关必须具备罗列的所有功能才行。在具体场景中，根据需求来选择和取舍。基础功能其他功能请求路由（静态/动态）身份验证路径重写访问授权协议转换速率限制API聚合指标收集请求日志负载均衡缓存服务降级证书/加解密处理服务重试安全策略（黑白名单等）然而，在一个足够复杂的业务场景里，APl网关所承载的功能还不止上表所罗列的范围。随着业务发展和系统演进，API网关系统变得越来越复杂，此时API网关进一步拆分，根据功能属性和业务耦合性拆分为流量网关和业务网关（也叫微服务网关）。流量网关：跟具体的后端业务服务完全无关，比如安全策略、全局性流控策略、流量分发策略等，其功能跟Web应用防火墙（WAF）非常类似，可基于NginxZOpenResty的ngxjua模块开发。业务网关：与后端服5和业务有一定关联性，并且一般被直接部署在业务服务的前面。业务网关一般部署在流量网关之后，业务系统之前，比流量网关更靠近服务。我们大部分情况下说的API网关，狭义上指的是业务网关。并且如果系统的规模不大，我们也会将两者合二为一，使用一个网关来理所有的工作。随着这种经典的双层模型在越来越多的公司和业务领域发挥出重要的作用，也促使越来越多的成熟方案开源回馈社区，如果只是想简单使用可以拿来主义，若是想完全把控或者有自己业务诉求可以选择稳定可靠方便扩展的来进一步研发。3 .常见的开源APl网关如果百度谷歌一下的话会发现可选择的API网关灰常多，按语言分类常见的开源网关大概有五大类：语言开源网关Nginx+LuaOpenResty,Kong,Orange,ABTestinggateway等JavaZuulZuuI2SpringCloudGateway、KaazingKWG»graviteeDromaraSoUI等GoJanusxIagongziGrpc-gateway.GIoo,istiogateway等.netOcelotnodejsExpressGatewayMicroGateway按照目前成熟度和使用广泛程度来划分的话，主流的有这样四个：OpenRestyKongZuulSpringCloudGateway3.1 OpenrestyOpenResty爨于Nginx,集成了Lua语言和Lua的各种工具库，可用的第三方模块，这样我们就在Nginx既有的高效HTTP处理的基础上，同时获得了Lua提供的动态扩展能力。3.2 KongKong基于OPenResty,是一个云原生、快速、可扩展、分布式的微服务抽象层(MicroserviceAbstractionLayer),也叫API网关，在ServiceMesh里也叫API中间件(APIMiddleware)05)RBAC(WORKSPACESANDTtAMS)3.3 ZuulZuul是Netflix开源的API网关，项目地址，它的主要设计目标是动态路由、监控、弹性和安全，其内部原理可以简单看做是很多不同功能filter的集合。Zuul1.x基于同步10,也是SpringCloud全家桶的一部分，可以方便的配合SpringBoot/SpringCloud配置和使用。在Zuul1.x里，filter的种类和处理流程可以参见下图，最主要的就是pre,routing,post这三种过滤器，分别作用于调用业务服务API之前的请求处理、直接响应、调用业务服务API之后的响应处理。Zuul2.x最大的改进就是基于NettyServer实现了异步10来接入请求，同时基于NettyClient实现了到后端业务服务APl的请求。这样就可以实现更高的性能、更低的延迟。此外也调整了filter类型，将原来的三个核心filter显式命名为：InboundFilter>EndpointFilter和OutboundFilter3.4 SpringCloudGatewaySpringCloudGateway基于JaVa8、Spring5.0、SpringBoot2.0>ProjectReactor,是一个构建在springcloud生态系统之上的API网关。一般认为是ZuulLx的升级版和代替品，它基于Netty异步IO实现了一个简单、比Zuul1.x更高效的、与SpringCloud紧密配合加API网关。SpringCloudGateway里明确的区分了Router和Filter,它旨在提供一种简单有效的方法来路由到API,内置了很多开箱即用的横切功能，包括路由、断路器、限流、黑白名单、负载均衡、auth等，并且都可以通过SpringBoot配置或者手工编码链式调用来使用。MoMeAppMkfoServkeIMkr。SCViC2Mkro5rvkt)项目地址，另外搜索下关于SPringcloudgateway有很多分析文章和开源的demo可以参考。3.5 如何选择？如何选择上面四个成熟的开源网关呢？脱离场景的情况下其实无法做正确选择的，我们要具体分析。kong性能优秀，非常适合做流量网关，同样是基于nginx和lua,Kong在Openresty基础上做了很多扩展，对于service、route>upstreamconsumerplugins的抽象，也是自研网关值得借鉴的。但是，对于复杂系统，不建议业务网关用Kong,或者更明确的说是不建议在Java技术栈的系统深度定制Kong或OpenResty,主要是工程性方面的考虑。毕竟维护IUa脚本的工作量和成本不低。SpringCloudGateWay对于Java技术栈来说比较方便，可以复用业务系统的一些组件。LUa不方便，不光是语言的问题，更是复用基础设施的问题。另外,对于网关系统来说，性能不是差一个数量级，问题不大，多加2台机器就可以搞定。目前来看ZUUI2的坑还是比较多的，因此作为java技术栈，比较建议使用SpringCloudGateway作为基础骨架。4 .云原生时代网关将如何演进在容器技术和k8s主导的云原生时代，k8s已然是云OS,在这个云原生生态里也衍生出了一些新兴的网关方案。4.1 Ingress首先要从k8singress讲起，ingress作为一个k8s的一个资源，本身就是一个具备7层反向代理的组件，作为集群流量的入口，扮演边缘路由器(edgeroute)的角色。换句话说，ingress可以把进入集群的请求转发的集群内对应的服务上。所以，配合一个类似nginx的反向代理或者LB就可以完成把外部流量转发到内部服务的网关功能。这部分详细的解释和dem。会在后续的文章里逐步展开，本文只做简单介绍。在云原生第一篇中曾经介绍过K8S的CRD工作模式，一个资源必然会有一个controller来管理，ingress资源是有IngreSSCOntrOner来管理的。它实时感知IngreSS路由规则集合的变化，再与ApiServer交互，获取Service>POd在集群中的IP等信息，然后发送给反向代理Web服务器，刷新其路由配置信息，这就是它的服务发现机制。下面是一个工作原理示意图：Ingrets4.2 NginxIngress把上面Ingress原理图中的反向代理换成nginx,再配合NginxIngressContrOner来动态调整配置便是NginxIngreSS,其工作原理可以简单描述为:NginXingress控制器通过和APIServer交互，动态感知集群中ingress规则变化，然后读取它并生成的Nginx配置写入nginx的etcnginx.conf文件中，reload使配置生效。以此达到域名分配置和动态更新的问题。下面是一个网上找的示意图，图中右下角只画了iptable来规则来选择pod并不完全，但不妨碍我们理解nginxingress的工作原理。4.3 TraefikTraefik是一个用Golang开发的轻量级的Http反向代理和负载均衡器，作为后起之秀，他天然拥抱kuberneteo使用Traefik不用创建Ingresscontroller对象，它直接k8s的ApiServer通信，实时感知集群中IngreSS定义的路由规则集合和后端SerViCe/Pod的变化，自动热更新Traefik后端配置。同时还提供了友好的控制面板和监控界面，不仅可以方便地查看Traefik根据Ingress生成的路由配置信息，还可以查看统计的一些性能指标数据，如：总响应时间、平均响应时间、不同的响应码返回的总次数等。另外，Traefik还支持丰富的annotations配置，可配置众多出色的特性，例如：自动熔断、负载均衡策略、黑名单、白名单。4.4IstioIngressgateway我们知道envoy作为istio的数据面有两种工作模式：作为中心代理，代理集群的南北流量，也就是入口流量，负责流量分发、流量治理类的工作。这种模式下，envoy一般就是负载均衡设备或者api网关的基础数据面，在非istio场景里比较有代表的ambassador,gloo作为业务进程的Sidecaro当有业务请求访问业务的时候，流量会劫持到SideCarenVOy中，之后再转发到业务进程。当业务访问其他业务时，请求流量会被拦截到SideCarenvoy中，再被转发到目标服务。IstioIngressGateway是Envoy第一种模式的代理封装，在servicemesh环境中也是一个不错的选择。使用IStiOGateWay(EnVOy)做南北流量调度，同时使用SideCar(EnVOy)做东西流量治理。下面是一个示意图：选择这种方案的一个好处是统一到envoy,前提是你的基础设施底座已经具备服务网格这个条件。另一个好处，如果你们微服务场景下使用了不同的语言和技术栈去实现特定的服务，这种方案可以做到技术栈解耦。但用istioingressgateway做网关也有局限性：它比较适合做基础的流量控制，比如限流/重试/熔断等，而和业务相关的比如身份认证、鉴权等比较难做。当然如果团队有这个技术栈，能做基于envoy(c+技术栈)的扩展研发，或许可以定制一些插件。否则通用的基础流量调度能力放在envoy,业务网关还需要选择另一个方案，两种方案并存会增加不少复杂性。4.5 新的动向除了上面介绍的几个云原生环境里基于K8S的网关方案之外，还有不少其他方案，比如ambassador,gloo,其实前文写到的kong也是。业界有不少在K8S集群基于服务网格的网关探索和实践的案例，比如蚂蚁无线网关基于MOSN的mesh化改造，再比如网易基于envoy的网关演进等等。如果说上面一些方案只是技术底座的不同，并没有改变网关的属性和功能定义，也没有改变传统的流量网关和微服务网关的双层模型来分别做南北流量和东西流量的调度。那么新的一种探索趋势的确是东西南北流量调度以及服务治理合二为一，以此减低资源使用和运维成本。下图是网上找的合二为一的网关示意图，这大概也许就是对云原生网关的最新定义。l*2",l匡1国ht1ps网也亚足见JDaaS的凡负贵东西南北向流吊调度理念和想法都是很美好的，对于很多正在往k8s平台走的公司来说也许亲自打造还有不小距离。但完成云原生改造的希望也许也并不遥远，不久前阿里云就上线了这样一款云原生网关，对于云上的用户来说有兴趣可以调研一下是否可以直接引入使用。相信其他云厂商也都会逐步推出类似的技术产品。而对于我们技术同学来说，学习远没有止境。