微服务架构模式之 API Gateway

大概三年前的这个时候,开始负责一个项目,是一个 P2P 产品的客户端的开发。需求很常见,基本就是需要 手机App(iOS, Android) 和 移动 H5页面。当时的一个项目背景是,已经存在多个由后端团队使用 Java 开发的微服务,承载着产品的核心业务逻辑,以及主数据的管理。这些已经存在的微服务,基本是按照领域模型划分,如会员服务,标的服务,账务服务,充值支付服务等,每个服务基本还提供相应的查询服务,另外还有一些实用工具类的,如短信服务。可以预见,在微服务架构下,一个寻常的 UI 页面,往往需要调用多个服务。而这仅仅是问题的一个方面。

让我们看看在微服务架构下,关于提供给客户端的 API 的设计,都有哪些方面的问题需要考虑

  • 微服务暴露的 API 粒度,通常不同于客户端的需求。微服务通常暴露细粒度的 API
  • 不同的客户端可能需要不同的数据
  • 不同客户端的网络性能可能不同。典型的如服务端渲染的 Web 应用程序,相较于移动客户端,可以在不影响用户体验的情况下,发起更多的请求,而区别就在于,LAN 比起移动网络,更快并且延迟低
  • 服务的实例数量和位置可能发生变化
  • 服务的划分可能随时间推移而变化
  • 服务可能使用多种协议,其中一些可能不是对 Web 友好的

考虑到这些因素,便很自然地考虑,引入一个中间层,服务于客户端,按需定制 API,减少请求次数,同时隐藏不必要的细节。


Use an API gateway

引入这一层抽象之后,前述问题的化解,都找到一个好的抓手

  • 客户端可以不受服务划分的变化的影响
  • 客户端可以不受服务的实例数量和位置变化的影响
  • 不同的客户端,可以有专属的 API,同时又共享底层的服务阵列和基础设施
  • 减少客户端发起请求的数量,进而提升了用户体验
  • 客户端不必调用多个服务而只需要与调用 API gateway
  • 协议转换,将任何内部的通讯协议,转换为 Web 友好的 API 协议

在前述的项目中,微服务之间使用了 Hessian 和 SOAP 协议,经过 API gateway 的协议转换,最终只以 REST 的方式暴露 API 给客户端。

这一层的引入,显然也有一些代价

  • 增加了系统复杂性。API gateway 作为一个代码工程,必然需要投入开发、部署和维护
  • 增加了响应时间。但对于大多数应用而言,LAN 网络中一个额外往返的成本是微不足道的

回到当时的项目中,那时还未了解到 API gateway 作为一种架构模式的存在,代码项目的名称是 web-api,但这个项目完整的承担了 API gateway 扮演的职责,有效地化解了微服务架构下,降低客户端的整体开发维护成本。

在技术选型上,实现 API gateway 常见的是采用事件驱动或者响应式的编程框架,当需要扩容应对高负载时,这是推荐的方式。在 JVM 上,可以考虑基于 NIO 的库,如 Netty,Spring Reactor 等。Node.js 也是个常见选择。


引入一点题外话,我当时对降低客户端的整体开发维护成本,还有另外一些思考,是关于沟通。日常的 UI 需求中,有不少其实是对后端微服务没有变更要求的,简单的比如,多显示一个字段,格式化显示金额,稍复杂的比如,页面呈现需要多组合一个既有的微服务,表单提交需要将部分信息反馈到另一个微服务等。对于这类需求,如果由后端团队来支持,一是会分散他们对领域服务和主数据管理的专注,二是考虑到 API gateway 这层比较薄的路由层/装配层,动态语言相比 Java 是更高效的选择。

再结合当时团队的情况,Java 开发人员普遍缺少基于 NIO 的库的开发经验,而且开发任务/风险已经偏重。而前端开发人员在编写前端组件以及实现前端构建时,都是在使用 Node.js,因此对于他们而言,使用 Node.js 上手 API gateway 的开发,门槛较低并且普遍有学习意愿。前端开发人员又是 UI 需求的直接受命人,对于前述的一大类 UI 变更需求,他们可以以最少的沟通成本,最少的信息传递失误,来高效的完成。

由此我组建了当时公司内第一个大前端部门,将前端团队和移动端团队纳入,将 API gateway 的实现和文档管理的职责纳入,大家共同围绕客户端的需求,保持较高的整体开发维护效率。此后,还在 API gateway 的基础上陆续添加了 API 版本管理,移动设备管理,客户端统计,缓存等一系列服务。


API gateway 还有很多的扩展点,试举一些例子

  • 客户端多协议。之前在携程做 App 时,客户端就是同时支持 HTTP 和 TCP 两种协议
  • 面向客户端支持 HTTP DNS / Direct IP。这个也是常见的客户端优化手段
  • 客户端的流控
  • 客户端认证和鉴权
  • 响应数据的脱敏
  • 客户端密钥管理
  • 客户端缓存协商
  • 客户端调用计量或计费。典型如 Open API

在 API gateway 这个领域,也有一些开源框架在活跃,如 Netflix Zuul,基于 Nginx 的 Kong 等,目前关注较少,就不展开介绍了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,482评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,377评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,762评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,273评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,289评论 5 373
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,046评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,351评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,988评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,476评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,948评论 2 324
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,064评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,712评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,261评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,264评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,486评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,511评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,802评论 2 345

推荐阅读更多精彩内容