1. API网关
当你决定将应用作为一组微服务时,需要决定应用客户端如何与微服务交互。在单体式程序中,通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中,每一个微服务暴露一组细粒度的服务提供点。当客户端完成某个业务的时候,需要同时调用多个微服务,如下图所示:
如果这些服务需要客户端分别调用才能完成,会增加请求的复杂度,同时也会带来网络调用性能的损耗。因此,针对微服务的应用场景就推出了 API 网关的调用。
在客户端与微服务之间加入 API 网关,客户端直接给这API 网关发送请求,由于后者完成对其他三个微服务的调用并且返回结果给客户端。
客户端直接与各个微服务通信的缺点:
- 某些复杂场景下客户端可能需要发起多次调用才能得到想要的资源,增加客户端的复杂度
- 要求各个微服务使用web友好的协议(HTTP、WebSocket等)
- 由于客户端和微服务耦合,很难重构或拆分微服务
因此通常来说,一个更好的解决办法是采用API Gateway的方式。
API Gateway是一个服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构,并且提供API给各个客户端。它还可能有其他功能,如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。
API Gateway负责请求转发、合成和协议转换。
- 进入系统的唯一节点,所有的客户端请求都要先经过API Gateway,然后在将这些请求路由到对应的微服务
- 经常通过调用多个微服务以及聚合多个微服务的结果来处理一个请求
- 在web协议与内部使用的非Web友好型协议间进行转换,如HTTP协议、WebSocket协议。
- 封装内部系统的架构,并且提供API给各个客户端
- 授权、访问评论限制、监控、负载均衡、缓存、请求分片和管理、静态响应处理等
2. API 网关的使用场景
- 面向 WebApp,这部分的系统以网站和 H5 应用为主。通过前后端分离的设计,将大部分的业务功能都放在了后端,前面的 Web App 只展示页面的内容。
- MobileApp,这里的 Mobile 指的是 iOS 和 Android,设计思路和 WebApp 基本相同。区别是 API 网关需要做一些移动设备管理的工作(MDM)。例如:设备的注册,激活,使用,淘汰等,全生命周期的管理。由于移动设备的特殊性,导致了我们在考虑移动设备请求的时候,需要考虑请求,设备,使用者之间的关系。
- 面向合作伙伴的 OpenAPI,通常系统需要将自身数据、能力等作为开发平台向外开放,通常会以rest的方式向外提供,最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等,必然会有一个统一的入口进行管理,这正是API网关可以发挥作用的时候。
- 企业内部可扩展 API,企业有很多遗留系统,要全部抽取为微服务器改动太大,对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用,因此需要对系统间服务调用进行管理,清晰地看到各系统调用关系,对系统间调用进行监控等。
- 面向 IOT 设备,会接收来自 IOT 设备的请求,特别是工业传感器等设备。这里需要考虑协议转换和数据过滤。
3. API Gateway的优点和缺点
API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务,客户端直接跟gatway交互更简单点。API Gateway提供给每一个客户端一个特定API,这样减少了客户端与服务器端的通信次数,也简化了客户端代码。
- 内外隔离
API网关作为企业系统边界,隔离外部API与内部微服务API。内部系统只接受 API 网关转发过来的请求。而网关通过白名单或校验规则,对访问进行了初步的过滤。它同时可以避免将内部的敏感信息暴露给外部的客户端
- 系统解耦
内部微服务系统能够独立和灵活的调整,不用担心影响功能本身。业务各个微服务可以随时做伸缩性调整,更换IP等操作等等。
内部微服务可以从使用不用通讯协议,技术来实现,而由API网关提供统一的接口、协议来暴露服务
注意:从解耦的情况出发,服务的编排不适合在网关层进行。对服务的编排,其实是提供了一种业务能力,对于这种情况,可以在微服务之上再提取一个业务服务来实现。
- 降低微服务的复杂度
微服务中有一些常见的要点,如授权,访问控制和调用频次限制。这每个点都需要每个服务区增加额外的时间去实现它们。API网关将这些要点从你的代码中提取出来,允许你的服务只关注于它们需要关注的任务。
- 脚手架
API网关除了请求的路由、转发外,还需要提供负载均衡、全局流控、动态路由、访问控制、权限校验、限流熔断、埋点监控、A/B测试、黑名单控制等功能。这些功能的实现方式,往往随着业务的变化不断调整。例如权限控制方面,早期可能只需要简单的用户 + 密码方式,后续用户量大了后,可能会使用高性能的第三方解决方案。又例如,针对不同的监控方案,需要记录不同的日志文件。
所以,这些能力不能一开始就固化在网关平台上,而应该是一种可配置的方式,便于修改和替换。这就要求网关层提供一套机制,可以很好地支持这种动态扩展。
API Gateway也有一些缺点。
- 由于API网关需要额外的配置,你的部署架构需要更多的编排和管理能力。
- 在发布阶段需要管理路由的配置,以保障外部API被正确的路由到微服务上。
- 除非很好的使用高可用,可扩展的架构,否则API网关将会变成瓶颈和单点
性能问题 API 网关作为逻辑上的单点,一旦发生问题,将造成服务的不可用,对企业来说可能造成的致命的影响。即使短时间的不可用,也会给企业带来直接的经济损失。所以,如何保证 API 网关的 7x24 小时的稳定运行,网关的自动伸缩、API 的热更新等问题,都是网关需要考虑的。
对于微服务架构大家经常说的最多的就是去中心化的架构,而实际上在微服务架构里面的API网关仍然是中心化的架构模式,所有的API接口都要经过网关这个点。
4. API网关的基本功能
API 生命周期管理功能
覆盖 API 的定义、测试、发布的整个生命周期管理,便捷的日常管理、版本管理,支持热升级和快速回滚。
开发和使用支持功能
提供页面调试工具,自动生成 API 文档和 SDK,大大降低人力成本。
安全防护功能
API 请求到达网关需要经过严格的身份认证、权限认证,才能到达后端服务。支持算法签名,支持 SSL 加密。
流量控制功能
- 可控制单位时间内 API 允许被调用次数。用来保护企业的后端服务,实现业务分级和用户分级。
- 支持对 API 流控,您可以根据 API 的重要程度来配置不同流控,从而保障重要业务的稳定运行;
- 支持用户、应用和例外流控,您可以根据用户的重要性来配置不同流控,从而可以保证大用户的权益;
- 流控粒度:分钟、小时、天。
请求管理功能
- 可根据配置进行参数类型、参数值(范围、枚举、正则、Json Schema)的校验,减少后端对非法请求、无效请求的资源消耗和处理成本。
- 可以在 API 网关定义参数映射规则,网关通过映射规则将后端服务通过映射翻译成任何形式,以满足不同用户的不同需求,从而避免功能重复开发。
监控告警功能
- 提供实时、可视化的 API 监控,包括:调用量、调用方式、响应时间、错误率,让您能够清楚的了解 API 的运行状况和用户的行为习惯。
- 支持自定义报警规则,来针对异常情况进行报警,降低故障处理时间。
- 提供可订阅的数据分析报表和智能分析。
5. 参考资料
http://dockone.io/article/482
http://tech.youzan.com/gateway/
http://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247486230&idx=1&sn=f8d9bba498cb0cebe98e61eb2b7678ba&source=41#wechat_redirect