API管理的正确姿式--API Gateway

转载本文需注明出处：微信公众号EAWorld，违者必究。

 

数字化生态，以创新客户体验为核心，全部咱们身边能感知到的变化都来自于渐近的创新。这些创新须要试错，须要不断的升级，而且创新每每与咱们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优点之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务能够进行创新和实验。从而支撑了用户体验的不断升级，为实现企业数字化转型的过程，提供了技术架构层面的支撑。

 

咱们如今已经能够很方便的经过一些电子商城购买运营的合约机，而无需到营业厅亲自办理相关的业务，这就是API Gateway的一种底层支撑。因为运营商经过API Gateway向第三方的商务平台开放了与套餐、机型销售等服务，并经过流控、鉴权等机制保障相关的安全性，才使得这样方便流畅的购物体验得以实现。

 

对于MOBA手游类玩家来讲，“王者荣耀”是一款颇受欢迎的游戏。在一些场景下，咱们会感知到“不停机更新”“体验服更新”这两种不一样方式的更新形态，在底层，就是API Gateway或者相似技术的实现，支撑灰度发布，让一些新特性发布给体验服（好比传说中露娜的二技能变化，仅在体验服更新，实际上并未如传说中同样在S11赛季更新到正式服），或者特定的游戏用户，待功能完善或者稳定运行，再向正式服或者所有用户发布，让游戏玩家的体验能够更加流畅，甚至是无感知的升级。

 

这些只是微服务架构或者API Gateway所支撑的万千业务场景中的沧海一粟。

 

但微服务自己也会带来诸多问题，粒度小难以管理就是其中之一，本文即从这个角度，阐述了API Gateway所起到的做用和一些关键的技术要素。

 

以微服务为核心的分布式框架贯穿了普元数字化企业技术平台的APaaS层面，本文所介绍的API Gateway是其中的关键组成部分（图中标黄的部分）。

 

 

 

引言：

 

随着微服务的大红大紫，你们纷纷使用微服务架构来实现新系统或进行老系统的改造。固然，微服务带给咱们太多的好处，同时也带给咱们许多的问题须要解决。采用微服务后，全部的服务都变成了一个个细小的API，那么这些服务API该怎么正确的管理？API认证受权如何实现？如何实现服务的负载均衡，熔断，灰度发布，限流流控？如何合理的治理这些API服务尤为重要。在微服务架构中，API Gateway做为总体架构的重要组件，它抽象了微服务中都须要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助咱们解决不少API管理难题。

 

目录：

 

1、什么是API Gateway

2、为何须要API Gateway

3、API Gateway中一些重要的功能

4、API Gateway vs 反向代理

5、API Gateway对API的认证及鉴权

6、采用OAuth2方式认证的两种部署方式

7、总结

 

1、什么是API Gateway

 

                                                 （图片来自网络）

 

这张图，很是形象的解释了API Gateway和微服务的关系。作为听众，咱们只想听到美妙动人的音乐旋律，彻底不会在意音乐是怎么演奏的。而指挥家则根据乐谱负责指挥好每个演奏者，使每个演奏者之间配合默契，共同完成这场音乐演出。在微服务的世界里，API Gateway就如同一位指挥家，“指挥”着不一样的“演奏人”(微服务)。

 

 

 

咱们知道在微服务架构中，大型服务都被拆分红了独立的微服务，每一个微服务一般会以RESTFUL API的形式对外提供服务。可是在UI方面，咱们可能须要在一个页面上显示来自不一样微服务的数据，此时就会须要一个统一的入口来进行API的调用。上图中咱们能够看到，API Gateway就在此场景下充当了多个服务的大门，系统的统一入口，从面向对象设计的角度看，它与外观模式相似，API Gateway封装了系统的内部复杂结构，同时它还可能具备其余API管理/调用的通用功能，如认证，限流，流控等功能。

 

2、为何须要API Gateway

 

 

首先，Chris Richardson在http://microservices.io/中也说起到，在微服务的架构模式下，API Gateway是微服务架构中一个很是通用的模式，利用API Gateway能够解决调用方如何调用独立的微服务这个问题。

 

 

 

从部署结构上说，上图是不采用API Gateway的微服务部署模式，咱们能够清晰看到，这种部署模式下，客户端与负载均衡器直接交互，完成服务的调用。但这是这种模式下，也有它的不足。

 

• 不支持动态扩展，系统每多一个服务，就须要部署或修改负载均衡器。

• 没法作到动态的开关服务，若要下线某个服务，须要运维人员将服务地址从负载均衡器中移除。

• 对于API的限流，安全等控制，须要每一个微服务去本身实现，增长了微服务的复杂性，同时也违反了微服务设计的单一职责原则。

 

 

上图为采用API Gateway模式，咱们经过上图能够看到，API Gateway作为系通通一入口，实现了对各个微服务间的整合，同时又作到了对客户端友好，屏蔽系统了复杂性和差别性。对比以前无API Gateway模式，API Gateway具备几个比较重要的优势：

 

• 采用API Gateway能够与微服务注册中心链接，实现微服务无感知动态扩容。

• API Gateway对于没法访问的服务，能够作到自动熔断，无需人工参与。

• API Gateway能够方便的实现蓝绿部署，金丝雀发布或A/B发布。

• API Gateway作为系通通一入口，咱们能够将各个微服务公共功能放在API Gateway中实现，以尽量减小各服务的职责。

• 帮助咱们实现客户端的负载均衡策略。

 

3、API Gateway中一些重要的功能

 

 

下面咱们用图来讲明API Gateway中一些重要的功能：

 

• 负载均衡

   

 

 

 

在实际的部署应用中，当应用系统面临大量访问，负载太高时，一般咱们会增长服务数量来进行横向扩展，使用集群来提升系统的处理能力。此时多个服务经过某种负载算法分摊了系统的压力，咱们将这种多节点分摊压力的行为称为负载均衡。

 

API Gateway能够帮助咱们轻松的实现负载均衡，利用服务发现知道全部Service的地址和位置，经过在API Gateway中实现负载均衡算法，就能够实现负载均衡效果。

 

• 服务熔断

   

 

在实际生产中，一些服务颇有可能由于某些缘由发生故障，若是此时不采起一些手段，会致使整个系统“雪崩”。或因系统总体负载的考虑，会对服务访问次数进行限制。服务熔断、服务降级就是解决上述问题的主要方式。API Gateway能够帮助咱们实现这些功能，对于服务的调用次数的限制，当某服务达到上限时，API Gateway会自动中止向上游服务发送请求，并像客户端返回错误提示信息或一个统一的响应，进行服务降级。对于须要临时发生故障的服务，API Gateway自动能够打开对应服务的断路器，进行服务熔断，防止整个系统“雪崩”。

 

• 灰度发布

 

 

 

 

服务发布上线过程当中，咱们不可能将新版本所有部署在生产环节中，由于新版本并无接受真实用户、真实数据、真实环境的考验，此时咱们须要进行灰度发布，灰度发布能够保证总体系统的稳定，在初始灰度的时候就能够发现、调整问题，同时影响小。API Gateway能够帮助咱们轻松的完成灰度发布，只须要在API Gateway中配置咱们须要的规则，按版本，按IP段等，API Gateway会自动为咱们完成实际的请求分流。

 

 

4、API Gateway vs 反向代理

 

 

• 反向代理

 

 

在传统部署架构中，反向代理，大可能是用于多个系统模块间的聚合，实现负载均衡，外网向内网的转发。经过修改配置文件的方式来进行增长或删除节点，并重启服务才可生效。一般来讲，反向代理服务器只具有负载均衡、转发基本功能，若要须要其余功能，须要增长扩展或提供脚原本实现。

 

• API Gateway

 

 

在API Gateway部署模式中，API Gateway能够看做特殊的反向代理，是对反向代理服务器功能的扩充，同时API Gateway仅局限于服务API层面，对API作进一步的管理，保护。API Gateway不只提供了负载均衡，转发功能，还提供了灰度发布，统一认证，熔断，消息转换，访问日志等丰富的功能。

 

• 如何选择？

 

假若咱们实际运用中，不须要服务发现，服务动态扩容，服务熔断，统一认证，消息转换等一系列API Gateway功能，咱们彻底可使用反向代理服务器来部署微服务架构，固然若是这样作，如遇到增长或减小服务节点时，须要修改反向代理服务器配置，重启服务才能够生效。而当咱们可能不只仅须要负载均衡，内外网转发，还须要其余功能，又同时想实现一些各服务都须要的通用的功能时，这时候就改考虑API Gateway了。

 

 

5、API Gateway对API的

认证及鉴权

 

 

目前在微服务中，咱们还须要考虑如何保护咱们的API只能被赞成受权的客户调用。那么对于API的保护，目前大多数采用的方式有这么几种，分别为AppKeys，OAuth2 和 OAuth2+JWT，接下来咱们逐个了解下。

 

• 认证方式

   

1）AppKeys

 

 

目前采用AppKeys Auth认证的公有云API Gateway和数据开放平台居多，如阿里API Gateway，聚合数据等，这种认证模式是由API Gateway颁发一个key，或者appkey+appsecret+某种复杂的加密算法生成AppKey，调用方获取到key后直接调用API。这个key能够是无任何意义的一串字符。API Gateway在收到调用API请求时，首先校验key的合法性，包括key是否失效，当前调用API是否被订阅等等信息，若校验成功，则请求上游服务，返回结果。此处上游服务再也不对请求作任何校验，直接返回结果。采用AppKeys认证模式比较适合Open Service的场景。其中并不涉及到用户信息，权限信息。

 

2）OAuth2

 

 

大部分场景中，咱们仍是须要有知道谁在调用，调用者是否有对应的角色权限等。OAuth2能够帮助咱们来完成这个工做。在OAuth2的世界中，分为如下几种角色：Resource Owner，Client，Authorization Server，Resource Sever。上图是一个简单的OAuh2流程来讲明各个角色以前的关系。最终，App得到了Rory的我的信息。

 

3）OAuth2+JWT

 

OAuth2 + JWT流程跟OAuth2彻底一致。了解OAuth2的童鞋都应该知道，OAuth2最后会给调用方颁发一个Access Token，OAuth2+JWT实际上就是将Access Token换成JWT而已。这样作的好处仅仅是减小Token校验时查询DB的次数。

 

• OAuth2 with API Gateway

 

 

有那么多认证方式，加入了API Gateway后，该怎么作呢？在微服务的世界中，咱们每一个服务可能都会须要用户信息，用户权限来判断当前接口或功能是否对当前用户可用。

 

咱们能够将统一认证放在API Gateway来实现，由API Gateway来作统一的拦截和鉴权，结合上文所描述的认证方式中，OAuth2协议中能够携带用户信息，故采用OAuth2。

 

6、采用OAuth2方式认证的

两种部署方式

 

 

• VPC网络部署，服务内部授信

 

 

第一种，微服务部署在单独的VPC网络中，同时微服务互相授信，互相调用不须要验证请求是否合法。这种模式下，当调用请求通过API Gateway时，API Gateway会拿着调用者提供的Access Token到Authorization Server中认证，若Access Token合法，Authorization Server会返回当前Access Token所表明的基本信息，API Gateway获取到这些基本信息后，会将这些信息放置在自定义Header中请求上游服务，上游服务可获取这些基本信息来进行对应操做的权限判断。若是咱们对API Gateway跟Authorization Server验证Access token的过程当中，担忧有性能和效率损失，咱们能够将Access Token改成JWT token，由API Gateway持有公钥对JWT token进行解密，减小一次HTTP请求。可是这种作法不推荐，毕竟JWT基本信息是Base64的，能够被垂手可得的解密。

 

• 微服务互相不授信，不在VPC中

 

 

第二种，微服务互相不授信，彼此调用须要验证请求的合法性，这种模式为了更加安全，咱们须要内外token转换。首先，调用方经过OAuth2流程，获取到Access Token，当前Access Token是一串没有意义的字符串，咱们将它称为Reference Token。当调用方调用API时，此时API Gateway会拿着调用者提供的Access Token到Authorization Server中认证置换。此时，Authorization Server不会返回基本信息，而是返回一个包含基本信息的JWT Token，咱们将它称为ID Token。紧接着API Gateway会将JWT Token放到Request Header中，请求上游服务。上游服务获取到当前JWT token后，会请求Authorization Server获取到JWK，利用JWK对当前JWT Token进行校验，解密，最后，进行角色权限判断。微服务之间的互相调用，也必须将JWT Token放在Request Header中。

 

总结来讲，以上几种方式均可以完成认证，但具体采用什么方式认证，仍是取决于实际中对系统安全性的要求和具体的业务场景。

 

7、总结

 

 

API Gateway在微服务架构中起到了相当重要的做用。在文章中咱们介绍了什么是API Gateway以及为何须要API Gateway。API Gateway它做为微服务系统的大门，向咱们提供了请求转发，服务熔断，限流流控等公共功能，它又统一整合了各个微服务，对外屏蔽了系统的复杂性和差别性。

 

另外，咱们介绍了目前微服务架构中几种认证方案。结合API Gateway，咱们采用了OAuth2协议对API进行认证鉴权，同时又从在部署架构的角度上，介绍了两种不同的认证方式。

 

 

精选提问：

 

问1：springcloud 用哪一个组件？

 

答：因为基于SpringBoot2的Spring cloud F版还未release，现阶段springcloud GA版本使用Zuul。

不过，待Spring cloud F版GA后，建议多关注下Spring Cloud Gateway。它是spring团队基于netty重写的API Gateway组件，相对于Zuul性能较好

 

问2：微服务都是在spring cloud系列下  用springcloud自带的zuul仍是选择其余的好？

 

答：若是基于Spring cloud的话，仍是建议使用Spring cloud自带的Zuul，能大量减小咱们对spring cloud体系下微服务治理方案的集成时间。

 

问3：Zuul 是   spring cloud 的apigetway 组件吗？

 

答：目前，spring cloud GA版（最新为Edgware）的API Gateway组件为Zuul。

但即将GA的F版，Spring团队使用netty本身实现了API Gateway对外提供，若使用F版，咱们就能够进行选择，zuul和spring cloud gateway均可以。

 

问4：微服务调用系统外部服务  是否也要走Api gateway？

 

答：若是相似APIGateway上能够直接作编排的，那确实调用外部服务的某些时候，能够直接从API gateway走，可是 API gateway自己的切面是对外提供服务，具体仍是要要看业务场景。

 

问5：最后一种不授信，是否意味着微服务只信任本身亲自从auth Server拿到的用户信息？

 

答：没错，最后一种状况下，微服务都要对请求进行校验。这里须要说明下，不是微服务从auth server获取用户信息，而是微服务从auth sever获取jwk，经过jwk解密请求中JWT来获取信息，进行用户信息权限校验。

 

问6：api gateway 修改发布的问题，有什么好方法吗？整个系统的瓶颈都集中在了apiGateway

 

回答：API Gateway也是一个微服务，微服务最大的特性就是能够伸缩，集群，高可用，系统遇到瓶颈能够增长节点。我曾经参与的项目中，最终上线用户达到9万之多，此时咱们也只使用了2个API Gateway的节点。

 

问7：用spring cloud的话，是否是能够用zuul整合spring cloud oauth2认证受权中心服务，全部涉及获取token、刷新token、校验token的操做都在zuul上处理，后端业务服务不与认证受权中心作任何耦合呢？另外，有没有现有的比较好的api gateway整合UAA服务的项目或产品可参考呢？

 

答：目前，spring cloud oauth2只提供了oauth2的几种受权模式的基本实现，咱们仍是得根据本身的实际业务逻辑，进行定制化。若是将全部的Token的操做放在zuul上处理是能够的，如刚才ppt讲的第一种安全认证方式。目前据我了解的，没有什么好的例子够咱们参考。

 

问8：认证服务器帐号信息应该放在认证服务器，仍是放在业务里呢？

 

答：建议将用户帐户信息放在认证服务器中，成为单独服务，与业务解耦。

 

问9：请问，oauth2 认证后 用户信息 是放在token 中加密好，仍是单独提供接口查询好？

 

回答：两种方式均可以，一切仍是看咱们系统的具体实际业务需求。

 

问10：如何跟业务数据同步呢？好比你注册个帐号，咱们可能给他送1000块钱。这1000块钱存在单独的业务服务器。咱们确定是异步的吧，怎么保证消息处理的实时性啊。

 

回答：业务信息跟用户帐户是有一个映射关系存储的，存储在业务中。我刚所说的用户帐户信息管理，只涉及到用户基本信息，组织机构等等不涉及业务的信息。