浅聊 API 网关

作者:fanniemeng

背景

很多人一说API网关,都是从微服务架构开始说起,说其是现在微服务架构中必备的一个标配组件,其实在微服务概念流行之前,API网关的就已经诞生了,如银行、证劵等领域常见的前置机系统,解决访问认证、报文转换、访问统计等;而我今天的切入点是从API-centric的应用的兴起。

API-centric

随着移动应用apps的风靡,应用程序开发人员需要简单地访问后端功能和数据;将后台的功能具体化有助于apps与系统交互。对一个企业, APIs的地位从‘最好能够具有‘转变为’必须具备‘,APIs也已成为了主流。

那开发人员眼有中的API是什么样子的?

1.前端和后端真正的分离 前端专注于页面展示的开发,通过约定好的api和后端交互,以及对api结果的处理逻辑;后端专注于各类api实现,返回指定类型的数据(json,xml等),这样前端和后端可以作为独立的项目进行并行的开发,由于更加专注和独立,所以对于代码质量和开发效率都是有很大好处的;

2.为多平台提供服务 基于api的应用,由于独立性,对服务的对象没有要求,可以是web项目,可以是移动app,可以是其他别的系统等等,这些终端通过api调用进行数据交互和数据处理,所以适用性更广。

图1 API-Centric 应用

那再回来聊的主题API网关

它的作用在于提供统一的入口来访问内部的API, 隔离外部访问与内部系统。集成了非业务性的功能(如安全检查、频次限制、API监控、日志上报等),API生命期管理、请求的转发、合成、协议转换、服务发现等多种功能。从图2就可以看出API网关功能以及在业务所处的位置。

图2 API网关业务应用示意图

API网关需要考虑的因素

  1. 性能问题

作为流量入口,所有请求经由网关,对请求进行检查及决策,通过验证后进行反向代理转发到后端的server进行处理,可想而知,这对性能的要求是特别高的,尤其针对互联网中海量的用户要与后端交互,如果不能保证性能,就只能通过堆机器来水平扩容,无疑会加大投入的设备成本;像目前业务已有不少高性能的方案,如有在JVM上,基于NIO框架 的SpringCloud Zuul、构建在Node.js事件循环,回调机制的 IBM、有基于Openresty事件驱动型、协程的KONG, ORANGE 、也有基于件驱动型、协程的Tyk 。

2.高可用

API网关不可用将会是致命的影响,要通过冗余部署、自愈、多维度监控告警,确保API网关7*24小时的稳定运行;

3.扩展性

API网关是业务性比较强的一个组件,如报文的转换、认证、验证等, 所以它提供了一个脚本架,业务可以自行去扩展及变动;

4.服务发现

后端服务的IP存在很大的变动性,尤其是微服务化后应用基于docker,对获取服务的位置提出了挑战,大家可能会提公司的Cl5,这个确实可以解决部分场景的服务发现,但如果是后端是在docker中,变动性比较大,cl5解决不了,这就要启用集群的服务发现了。

5.缓存处理

可用来缓存变化频率不大及大部分用户看到的共同数据,同时也可以用来处理后端故障迟迟无数据返回时将缓存数据返回,保障用户的体验。

6.服务调用

支持进程间同步及异步的通信模块,可根据后端server情况支持所需要的通信机制。

业界常用的API网关方案对比

图3 业界已有方案对比

这里看一个示例orange,通过对其内部实现进行分析,来看看其是如何实现API网关的功能?

Orange是基于openresty, 而openresty是寄生在nginx上,Nginx 性能极高,Nginx 先天的事件驱动型设计、全异步的网络 I/O 处理机制、极少的进程间切换以及许多优化设计,都使得 Nginx 天生善于处理高并发压力下的互联网请求。Nginx 的稳定性也在各大网站得到验证。官方提供的常用模块都非常稳定,每个 worker 进程相对独立,master 进程在 1 个 worker 进程出错时可以快速“拉起”新的 worker 子进程提供服务。支持热部署,可以不停机更新配置文件、更新日志文件、更新服务器程序版本。

而Openresty复用了nginx的诸多特性,同时暴露了nginx处理的各个阶段的钩子,业务可以灵活的在各阶段去挂载自己的业务,如下图4所示,orange将各个功能插件巧妙的挂载到nginx的各个执行阶段,如可在access阶段做身份验证、安全、流量控制等,在proxy阶段,转发流量做反向代理等等。

在规则增、修、删上这些方案大都提供API接口来实现,可通过curl API来实现规则的变换,为便捷操作这块大部分方案都配套有Dashboard管理操作界面,可直接在上面进行操作,其原理也是通过模拟发送API来实现。

图4 orange内部实现

而orange的流量刷选则是通过对相关参数进行正则匹配来实现,规则可以重叠生效,图5显示的就是orange的内部流量刷选规则。

图5 流量刷选规则

API网关的优点:

  1. 给服务加一层安全保护 可在这一层做sql注入、CRSF攻击防范等WAF层面的安全保护;
  2. 对外提供统一的通信协议,如HTTP或restful api, 屏蔽内部的通信协议 系统内部可采用自身熟悉的通信协议,如Protobuf 或RPC等;
  3. 降低代码耦合度、降低开发成本 将非业务性功能如访问控制(黑白名单)、频次限制等集中在网关层处理,开发只需关注自己本业务的需求实现即可,降低了开发成本;
  4. 可灵活灰度及新功能测试 通过细粒度的流量识别,进而反向代理,业务可灵活灰度及AB测试;
  5. 服务发现 随着后端server变动甚至云化,对服务发现提出了新挑战,通过在API网关实现服务发现可以简化客户端的实现。
  6. 减少客户端与后台server的交互 随着微服务化API更加细粒度,这势必会加大客户端对后台server的访问次数,如做一些返回数据合并,让客户端通过一次请求在API网关处合并需要的数据一次性返回等,但这一块业务性太强,像业界的方案很少有做一块的,大部分实现是在API网关后端加了一个BBF(backend for frontend)来做数据的整合;
  7. 对API进行管理;

缺点:

得开发、部署、维护一个开可用的API网关组件;

总结:

不管是由于APIs的普及,还是作为微服务架构中的一员,实现API网关是很重要的。在具备对请求做决策判断后的转发、协议转换、路由等基本功能外还需要有良好可扩展性。在功能实现时要尽可能的跟业务层解耦。作为一个高可用、伸缩性强的组件,优缺点并存,但相对其带来的功能这些缺点是可以容忍的。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ITCloud的专栏

聊聊腾讯云TStack上云Oracle的应用

能否利用TStack的计算、网络和存储能力,将Oracle运行在X86服务器,IP网络,云存储的“云化”架构上,去掉IOE架构中的I和E呢?

9.4K1
来自专栏IT笔记

单体转向微服务架构-网关篇(一)

2596
来自专栏Rainbond开源「容器云平台」

开源PaaS Rainbond的架构与实现

回顾云计算产业技术的发展,IaaS层虚拟化的逐步成熟,解决了过去使用物理计算集群所面对的资源提供者和使用者之间的耦合问题,一定程度上降低了交付应用和创造业务价值...

900
来自专栏james大数据架构

零代码如何打造自己的实时监控预警系统

概要 为什么要做监控 线上发布了服务,怎么知道它一切正常,比如发布5台服务器,如何直观了解是否有请求进来,访问一切正常。 当年有一次将线上的库配置到了Beta,...

3336
来自专栏北京马哥教育

性能调优概述,这是一篇最通俗易懂性能调优的总结!

精彩早知道 作者概述 什么是性能调优?(what) 为什么需要性能调优?(why) 什么时候需要性能调优?(when) 什么地方需要性能调优?(where) ...

3995

实用微服务

如今,微服务是软件体系结构领域中最受欢迎的热门词汇之一。有许多材料都在介绍微服务的基本原理以及它的好处,但教你如何在企业场景中使用微服务的资料就十分少了。

1114
来自专栏EAWorld

普元容器云关键设计和实践之路

目前,DevOps,微服务与容器云,可以说是炙手可热的三大话题,甚至可以说它们是云时代企业新一代IT架构的三大基石也不为过。微服务主要解决的是开发期的设计问题,...

944
来自专栏Java架构师历程

优步微服务架构 – 构建和部署应用程序

从我之前的博客,你必须已经对微服务架构有了基本的了解。在本博客中,您将深入了解架构概念并使用优步案例研究来实现它们。

793
来自专栏云计算D1net

IT人士需要了解的云中容器的术语

如今如果没有提及容器,就很难谈论云计算。无论技术新手还是经验丰富的专家,都需要了解与云中容器相关的这些关键术语。 随着云计算中容器的普及,更多的组织选择不考虑...

34111
来自专栏后端技术探索

一步步构建大型网站

今天我们来谈谈一个网站一般是如何一步步来构建起系统架构的,虽然我们希望网站一开始就能有一个很好的架构,但马克思告诉我们事物是在发展中不断前进的,网站架构也...

672

扫码关注云+社区