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

《API网关作用与技术形态和发展趋势 (课件).docx》由会员分享，可在线阅读，更多相关《API网关作用与技术形态和发展趋势 (课件).docx（18页珍藏版）》请在课桌文档上搜索。

1、APl网关的用处API网关我的分析中会用到以下三种场景。OpenAPE企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。OPenAPl开放平台必然涉及到客户应用的接入、APl权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。微服务网关。微服务的概念最早在2012年提出，在MartinFoWler的大力推广下，微服务在2014年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，

2、服务代理，监控，日志等。APl网关在微服务架构中正是以微服务网关的身份存在。APl服务管理平台。上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的APl服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。APl网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的APl服务管理平台。APl网关在企业整体架构中的地位一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，

3、在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。因此在我的设计中将这三种应用分别用不同的网关进行APl管理，分别是：API网关（OPenAPl合伙伙伴应用）、API网关（内部应用）、APl网关（内部公网应用）。企业中在如何应用APl网关1、对于OPenAPI使用的APl网关来说，一般合作伙伴要以应用的形式接入到OPenAPl平台，合作伙伴需要到OPenAPl平台申请应用。因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。如下架构：合作伙停设合伙W用的当然如果是在简单的场景下，可能并

4、不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。2、对于内网的APl网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的APl服务治理平台。当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。而当企业只是将系统与系统之间的调用使用restapi的方式进行访问时使用APl网关对调用进行管理，那么APl网关起到的就是API服务治理的作用。架构参考如下：访问方开发人员3、对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致,在架构上是可能由独立的API网关来处理这

5、部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的APl网关。如果使用独立的APl网关,有以下的好处：面向合作伙伴和面向公司主体业务的优先级不一样，不同的APl网关可以做到业务影响的隔离。内部APl使用的管理流程和面向合作伙伴的管理流程可能不一样。内部的APl在功能扩展等方面的需求一般会大于OPenAPl对于功能的要求。基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPENAPI网关和内部公网应用网关。APl网关有哪些竞争方案1、对于OPenAPl平台的APl网关，我分析只能选择APl网关作为解决方案，业界没有发现比较好的可以用来作为OPenAPl平台的入口的其他

6、方案。2、对于作为微服务网关的APl网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的。ServiceMesh,这是新兴的基于无APl网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前SerViCeMeSh的产品还正在开发中，并没有非常成熟可直接应用的产品。发展最迅速的产品是Istioo建议大家密切关注相关产品的研发、业务使用进展。个慢o93r 方 3msmc MMhmrswrat . tSrvcMh可以对汰尢NHK力.Btt.”9MSEc MMh . -WlrZipkinSkywalking

7、DatadogOkta等众多开源项目和SaaS服务合作，为企业提供更好的解决方案。动态和集群化管理容器和Kubernetes的普及，让动态成为所有云原生基础组件的标准特性。在Kubernetes的环境中，容器在不断的生成和销毁，弹性伸缩成为一个必选项而不是可选项。想象一个场景：一家互联网电商公司做了一次促销，大量的用户在一个小时内涌入，促销结束后就会离开。对于传统架构的公司来说，他们需要事先采购一批物理服务器，来应对这些高峰时候的APl流量；但是对于云原生架构的公司来说，就可以随时使用公有云上的弹性资源，根据APl请求的数量，自动的调整网络、计算、数据库等资源的规模即可。那么伴随着容器弹性伸缩

8、而来的技术挑战如下：上游服务不断更换IP地址和端口;IP黑白名单的频繁更新;服务健康的及时检测和异常处理;APl的频繁发布;服务注册和发现的及时性;SSL证书的热更新和自动轮转。想要解决上述这些挑战，均需要依赖于动态。以NGINX为代表的第一代APl网关，动态能力是非常弱的。因为NGINX是本地静态配置文件驱动的，所以变更任何配置都需要重启NGINX服务才能生效，这在云原生时代是不能被企业接受的。这就是第一代API网关的技术痛点之一。在中国，有一家类似微软OffiCe365的SaaS办公软件公司-WPS,他们有数百台物理机在运行着APaCheAPISIX,有近万核CPU在处理来自客户端的APl

9、请求，每天处理数百亿次API请求。在这个超大规模的APl网关环境下，开发者不可能去逐个修改每一个APl网关的配置然后Reload,他们希望有一个统一的控制台来操作整个集群。可惜的是，第一代API网关诞生的年代，并没有这么大的实例规模，也就没有考虑集群管理的需求。下一代API网关的发展上述挑战和痛点，逐渐催生了新一代的API网关。和第一代API网关不同的是，云原生时代诞生的下一代API网关是在开源社区的驱动下快速成长的。借助社区和众多开源贡献者的力量，这些API网关有机会形成一个正向的迭代和进化：更快速的收集一线开发者及用户的需求和痛点在开源项目中尝试解决这些问题开源项目变得更加好用，吸引更多开

10、发者使用于是，我们看到下一代API网关突破了传统网关的负载均衡和反向代理的定位，而是承担起了API和流量的连接、调度、过滤、分析、协议转换、治理、集成等更多的职责。支持更低成本的二次开发同时，让开发者能够以更低的成本进行二次开发，也成为了下一代APl网关的亮点。集成是APl网关的重要功能之一，对于下游是协议解析和各种协议的转换，包括GraphQLgRPC、Dubbo等；对于上游是集成Okta、KeycloakDatadog.Prometheus等身份认证、可观测性服务，以及公司内部的认证、日志、审计等服务。APl网关不可能覆盖集成过程中所有的组件，这时候不可避免地需要开发者通过插件的方式进行二

11、次开发，来满足自己的业务需求。不同的APl网关提供了不同的二次开发的编程语言和开发方式，ApacheAPISlX和Kong都可以使用Lua来编写原生插件，Envoy是使用C+编写原生插件。同时，ApacheAPISlX还可以使用GoPython、NodeJava和Wasm来编写插件，这些主流的开发语言已经可以覆盖绝大部分开发者了。APIGatewayAPISIXKongEnvoylanguagesforcustompluginsLuaGoJavaPythonNodeWasmLuaGoWasm(notopensource)C+LuaWasmDevelopmentdifficultyLowMedi

12、umHigh开发者不必去学习Lua和C+,就可以使用自己熟悉的编程语言在下一代APl网关上进行开发，这让基础组件的开发变得更加简单。开源和易于二次开发，是下一代的APl网关最重要的特点，它把更多的选择权留给了开发者自身,同时，开发者也可以更加放心的在多云、混合云的环境下使用API网关，不用担心被云供应商锁定。基于双十一的API网关流量处理场景这里，我们用一个具体的例子来解释下现代API网关的作用。在双十一时，电商都会有各种各样的商品促销活动，这段时间的API请求量是平时的几十倍。让我们先来看下如果没有API网关将会是怎样的技术架构：可以看到，在Order和Payment服务中，身份认证和日志记

13、录功能是重复的。一个电商的服务，一般会有数千个不同的服务组成，这时候就会有大量的代码和功能是重复开发的。下面是增加了APl网关之后的架构图：从上图可以看到，我们在API网关层统一了公共的服务，后端服务只需要关心自身业务，为弹性伸缩提供了更多可能。当促销开始时，客户端大量API请求涌入API网关的时候，后端服务需要进行快速的弹性伸缩，为了保障关键业务不受突发流量的影响，我们需要在API网关上识别恶意爬虫并实现限流限速、服务降级和熔断。此时，我们可以暂时关闭部分服务，比如商品评价、快递查询等。但是库存信息、购买功能、支付功能等核心业务是绝对不能出现故障的，因此我们需要通过K8s来管理容器服务，再生

14、成更多的服务副本来保证它的正常运行。此时API网关需要将客户端的API请求路由到新生成的副本服务，并且自动移除出现故障的服务，如下图所示。总结API网关并不是一个新的基础中间件，而是在产品快速迭代和技术架构的变迁中，变得越来越重要。而下一代云原生API网关的出现则解决了企业用户在集群管理，动态，生态，可观测性以及安全性等方面的痛点。APl网关不仅可以处理API的流量，也可以来处理KubernetesIngress和服务网格的流量,进一步降低开发者的学习成本，帮助企业更好的统一管理流量。APl网关的技术形态和发展趋势在软件架构设计中很多都采用“层的结构，所以有这样一句名言：”计算机领域的任何问题

15、都可以通过增加一个间接的中间层来解决:APl网关便是这样一个中间层，无论是早期银行证券系统的前置机，还是随着微服务架构模式发展而演化出来的APl网关，它都是作为APl访问的统一接入的中间层。今天我们从以下四点来聊一聊API网关：微服务经典的四层架构API网关模式常见的开源APl网关网关在容器技术和K8S主导的云原生时代将如何演进1 .微服务经典的四层架构单体应用中有一个典型的MVe分层技术，把系统分为数据层、展示层和业务逻辑层，在这种模式下我们比较关注应用自身。而到微服务时期，每个微服务除了数据和业务逻辑之外，往往要依赖下游服务的API,同时自身也会提供APl给上游服务，微服务之间相互协作提供

16、整体的系统能力。此时，除了微服务本身之外更加关注整个上下游，为了统一APl接入和避免公共能力的重复建设，设计了网关路由层；为了更加解耦，不至于微服务牵一发而动全身，又独立出一个BFF层(BackendForFront)t,这就是典型的四层架构：前端层、网关层、BFF层、微服务层。借用netflix的系统架构为例来说明一下，早期netflix四层架构如下图：用户体验房路由屋Wiumii BFF粕服务用用户体验层：支持各种不同的前端设备，给用户良好的使用体验。网关路由层：使用ZUUl网关作为服务路由层，同时兼具安全、监控、熔断、限流等横切功能。ZUUI网关无状态集群部署，前置AWSELB做负载均衡

17、。边界APl层：服务剪裁聚合层，也就是BFF层，当然在netflix内部并不叫BFF,而是称其为边缘服务层(EdgeServiceLayer),将后端微服务适配到不同的前端体验。微服务层：核心领域服务，也称为中间层(MIddleTier)服务。随着业务的更加复杂，边界APl层一方面随着微服务层的变动而频繁修改,给开发测试带来巨大的工作量，于是独立出一层隔离变化。Client 网关BFFAPl聚合层做服务层无论是四层还是五层，netflix服务入口流量都是由ZUUl一夫当关，作为边缘网关，将外部流量调度到内部服务，俗称南北流量调度。当然，边缘网关作为外部流量进入内部服务的第一道“关卡”，天然适合

18、承载安全认证、流量控制等通用功能，这也就引出了另一个话题：APl网关模式！2 .APl网关模式APl网关是定义在外部服务进入内部服务入口处的一种服务，类似于面向对象设计的外观模式，它封装了应用程序的内部架构，为客户端提供统一的API,下面示意图展示了客户端、APl网关和内部服务之间的关系。作为入口层，API网关在架构设计中占尽“地缘”优势。一方面，就像城堡的大门，可以承载访客的身份认证、权限控制、路线引导（路由）、人流控制（排队机制/关闭通道等）、访问记录等功能；另一方面，后端APl需要的通用功能比如重试机制、熔断、限流、降级等也可以放到这一层，避免各个微服务重复建设。下表大概罗列一下APl网

19、关所承载的功能。当然，表格并没有完全覆盖APl网关的全部功能，也不是说一个APl网关必须具备罗列的所有功能才行。在具体场景中，根据需求来选择和取舍。基础功能其他功能请求路由（静态/动态）身份验证路径重写访问授权协议转换速率限制API聚合指标收集请求日志负载均衡缓存服务降级证书/加解密处理服务重试安全策略（黑白名单等）然而，在一个足够复杂的业务场景里，APl网关所承载的功能还不止上表所罗列的范围。随着业务发展和系统演进，API网关系统变得越来越复杂，此时API网关进一步拆分，根据功能属性和业务耦合性拆分为流量网关和业务网关（也叫微服务网关）。流量网关：跟具体的后端业务服务完全无关，比如安全策略、

20、全局性流控策略、流量分发策略等，其功能跟Web应用防火墙（WAF）非常类似，可基于NginxZOpenResty的ngxjua模块开发。业务网关：与后端服5和业务有一定关联性，并且一般被直接部署在业务服务的前面。业务网关一般部署在流量网关之后，业务系统之前，比流量网关更靠近服务。我们大部分情况下说的API网关，狭义上指的是业务网关。并且如果系统的规模不大，我们也会将两者合二为一，使用一个网关来理所有的工作。随着这种经典的双层模型在越来越多的公司和业务领域发挥出重要的作用，也促使越来越多的成熟方案开源回馈社区，如果只是想简单使用可以拿来主义，若是想完全把控或者有自己业务诉求可以选择稳定可靠方便扩

21、展的来进一步研发。3 .常见的开源APl网关如果百度谷歌一下的话会发现可选择的API网关灰常多，按语言分类常见的开源网关大概有五大类：语言开源网关Nginx+LuaOpenResty,Kong,Orange,ABTestinggateway等JavaZuulZuuI2SpringCloudGateway、KaazingKWGgraviteeDromaraSoUI等GoJanusxIagongziGrpc-gateway.GIoo,istiogateway等.netOcelotnodejsExpressGatewayMicroGateway按照目前成熟度和使用广泛程度来划分的话，主流的有这样四个

22、：OpenRestyKongZuulSpringCloudGateway3.1 OpenrestyOpenResty爨于Nginx,集成了Lua语言和Lua的各种工具库，可用的第三方模块，这样我们就在Nginx既有的高效HTTP处理的基础上，同时获得了Lua提供的动态扩展能力。3.2 KongKong基于OPenResty,是一个云原生、快速、可扩展、分布式的微服务抽象层(MicroserviceAbstractionLayer),也叫API网关，在ServiceMesh里也叫API中间件(APIMiddleware)05)RBAC(WORKSPACESANDTtAMS)3.3 ZuulZuu

23、l是Netflix开源的API网关，项目地址，它的主要设计目标是动态路由、监控、弹性和安全，其内部原理可以简单看做是很多不同功能filter的集合。Zuul1.x基于同步10,也是SpringCloud全家桶的一部分，可以方便的配合SpringBoot/SpringCloud配置和使用。在Zuul1.x里，filter的种类和处理流程可以参见下图，最主要的就是pre,routing,post这三种过滤器，分别作用于调用业务服务API之前的请求处理、直接响应、调用业务服务API之后的响应处理。Zuul2.x最大的改进就是基于NettyServer实现了异步10来接入请求，同时基于NettyCli

24、ent实现了到后端业务服务APl的请求。这样就可以实现更高的性能、更低的延迟。此外也调整了filter类型，将原来的三个核心filter显式命名为：InboundFilterEndpointFilter和OutboundFilter3.4 SpringCloudGatewaySpringCloudGateway基于JaVa8、Spring5.0、SpringBoot2.0ProjectReactor,是一个构建在springcloud生态系统之上的API网关。一般认为是ZuulLx的升级版和代替品，它基于Netty异步IO实现了一个简单、比Zuul1.x更高效的、与SpringCloud紧密配

25、合加API网关。SpringCloudGateway里明确的区分了Router和Filter,它旨在提供一种简单有效的方法来路由到API,内置了很多开箱即用的横切功能，包括路由、断路器、限流、黑白名单、负载均衡、auth等，并且都可以通过SpringBoot配置或者手工编码链式调用来使用。MoMeAppMkfoServkeIMkr。SCViC2Mkro5rvkt)项目地址，另外搜索下关于SPringcloudgateway有很多分析文章和开源的demo可以参考。3.5 如何选择？如何选择上面四个成熟的开源网关呢？脱离场景的情况下其实无法做正确选择的，我们要具体分析。kong性能优秀，非常适合做

26、流量网关，同样是基于nginx和lua,Kong在Openresty基础上做了很多扩展，对于service、routeupstreamconsumerplugins的抽象，也是自研网关值得借鉴的。但是，对于复杂系统，不建议业务网关用Kong,或者更明确的说是不建议在Java技术栈的系统深度定制Kong或OpenResty,主要是工程性方面的考虑。毕竟维护IUa脚本的工作量和成本不低。SpringCloudGateWay对于Java技术栈来说比较方便，可以复用业务系统的一些组件。LUa不方便，不光是语言的问题，更是复用基础设施的问题。另外,对于网关系统来说，性能不是差一个数量级，问题不大，多加2

27、台机器就可以搞定。目前来看ZUUI2的坑还是比较多的，因此作为java技术栈，比较建议使用SpringCloudGateway作为基础骨架。4 .云原生时代网关将如何演进在容器技术和k8s主导的云原生时代，k8s已然是云OS,在这个云原生生态里也衍生出了一些新兴的网关方案。4.1 Ingress首先要从k8singress讲起，ingress作为一个k8s的一个资源，本身就是一个具备7层反向代理的组件，作为集群流量的入口，扮演边缘路由器(edgeroute)的角色。换句话说，ingress可以把进入集群的请求转发的集群内对应的服务上。所以，配合一个类似nginx的反向代理或者LB就可以完成把外

28、部流量转发到内部服务的网关功能。这部分详细的解释和dem。会在后续的文章里逐步展开，本文只做简单介绍。在云原生第一篇中曾经介绍过K8S的CRD工作模式，一个资源必然会有一个controller来管理，ingress资源是有IngreSSCOntrOner来管理的。它实时感知IngreSS路由规则集合的变化，再与ApiServer交互，获取ServicePOd在集群中的IP等信息，然后发送给反向代理Web服务器，刷新其路由配置信息，这就是它的服务发现机制。下面是一个工作原理示意图：Ingrets4.2 NginxIngress把上面Ingress原理图中的反向代理换成nginx,再配合Nginx

29、IngressContrOner来动态调整配置便是NginxIngreSS,其工作原理可以简单描述为:NginXingress控制器通过和APIServer交互，动态感知集群中ingress规则变化，然后读取它并生成的Nginx配置写入nginx的etcnginx.conf文件中，reload使配置生效。以此达到域名分配置和动态更新的问题。下面是一个网上找的示意图，图中右下角只画了iptable来规则来选择pod并不完全，但不妨碍我们理解nginxingress的工作原理。4.3 TraefikTraefik是一个用Golang开发的轻量级的Http反向代理和负载均衡器，作为后起之秀，他天然拥

30、抱kuberneteo使用Traefik不用创建Ingresscontroller对象，它直接k8s的ApiServer通信，实时感知集群中IngreSS定义的路由规则集合和后端SerViCe/Pod的变化，自动热更新Traefik后端配置。同时还提供了友好的控制面板和监控界面，不仅可以方便地查看Traefik根据Ingress生成的路由配置信息，还可以查看统计的一些性能指标数据，如：总响应时间、平均响应时间、不同的响应码返回的总次数等。另外，Traefik还支持丰富的annotations配置，可配置众多出色的特性，例如：自动熔断、负载均衡策略、黑名单、白名单。4.4IstioIngress

31、gateway我们知道envoy作为istio的数据面有两种工作模式：作为中心代理，代理集群的南北流量，也就是入口流量，负责流量分发、流量治理类的工作。这种模式下，envoy一般就是负载均衡设备或者api网关的基础数据面，在非istio场景里比较有代表的ambassador,gloo作为业务进程的Sidecaro当有业务请求访问业务的时候，流量会劫持到SideCarenVOy中，之后再转发到业务进程。当业务访问其他业务时，请求流量会被拦截到SideCarenvoy中，再被转发到目标服务。IstioIngressGateway是Envoy第一种模式的代理封装，在servicemesh环境中也是一

32、个不错的选择。使用IStiOGateWay(EnVOy)做南北流量调度，同时使用SideCar(EnVOy)做东西流量治理。下面是一个示意图：选择这种方案的一个好处是统一到envoy,前提是你的基础设施底座已经具备服务网格这个条件。另一个好处，如果你们微服务场景下使用了不同的语言和技术栈去实现特定的服务，这种方案可以做到技术栈解耦。但用istioingressgateway做网关也有局限性：它比较适合做基础的流量控制，比如限流/重试/熔断等，而和业务相关的比如身份认证、鉴权等比较难做。当然如果团队有这个技术栈，能做基于envoy(c+技术栈)的扩展研发，或许可以定制一些插件。否则通用的基础流量

33、调度能力放在envoy,业务网关还需要选择另一个方案，两种方案并存会增加不少复杂性。4.5 新的动向除了上面介绍的几个云原生环境里基于K8S的网关方案之外，还有不少其他方案，比如ambassador,gloo,其实前文写到的kong也是。业界有不少在K8S集群基于服务网格的网关探索和实践的案例，比如蚂蚁无线网关基于MOSN的mesh化改造，再比如网易基于envoy的网关演进等等。如果说上面一些方案只是技术底座的不同，并没有改变网关的属性和功能定义，也没有改变传统的流量网关和微服务网关的双层模型来分别做南北流量和东西流量的调度。那么新的一种探索趋势的确是东西南北流量调度以及服务治理合二为一，以此减低资源使用和运维成本。下图是网上找的合二为一的网关示意图，这大概也许就是对云原生网关的最新定义。l*2,l匡1国ht1ps网也亚足见JDaaS的凡负贵东西南北向流吊调度理念和想法都是很美好的，对于很多正在往k8s平台走的公司来说也许亲自打造还有不小距离。但完成云原生改造的希望也许也并不遥远，不久前阿里云就上线了这样一款云原生网关，对于云上的用户来说有兴趣可以调研一下是否可以直接引入使用。相信其他云厂商也都会逐步推出类似的技术产品。而对于我们技术同学来说，学习远没有止境。