微服务架构中API网关的角色


【编者的话】本文主要讲述了Mashape的首席技术执行官Palladino对API网关的详细介绍,以及API网关在微服务中所起的作用,同时介绍了Mashape的一款开源API网关Kong。

API网关提供商Mashape的首席技术执行官Marco Palladino预测,尽管它们在命名方面存在差异,但新出现的服务网格并不完全不同于API网关,两者之间的相似性会随着时间的推移而不断增长。

Palladino指出,实际上这两种技术提供的功能很相似。API网关,比如Amazon Web Services的API网关或Mashape的开源API网关Kong,在过去的十多年来主要用于映射外部流量到内部资源,而最近开发的服务网格——比如Lyft’s EnvoyUber’s Catylist——主要是在微服务架构中代理内部资源。

“当你想到网关的时候,你通常会想到一个集中的层,一个额外的跳在网络上处理附加的功能。但这并不一定是真的,”在上周洛杉矶举行的2017年MesosCon上Palladino发表演讲时这么说。网关还可以提供一种有效的方式来处理跨微服务之间的通信。他说:“你也可以在现有的微服务上运行Kong,摆脱额外的跳跃,减少延迟。”
e0701645-kong01.jpg

在过去的10年里,API一直是一种受欢迎的通信交互方式,Docker使其易于设置微服务架构,其中应用程序和服务是由较小的可交换组件组成的。但这些组件之间需要一种方式进行发现与调用。这就是API网关的作用。

API网关“可以成为一个抽象层,它位于这些微服务中每个请求的访问路径上,”Palladino说道。

网关巩固了通往系统常用功能的所有路径,比如身份验证或者服务发现,通过插件都能被网关识别。“插件是一种有效的中间件功能可以动态应用于所有的微服务上,”他讲到。

API网关可以聚合服务请求和这些特性。客户端可以做出一个响应,网关可以将其分解为多个请求,节省了客户端自身调用的带宽。网关同样还可以跟踪这些请求。

立足整体式应用实现微服务,就如同强求活鸡取卵一般,几乎不具可行性。——@thefosk #MesosCon

——The New Stack(@thenewstack)2017年9月14号

当一个组织开始把一个单体应用拆分为微服务时,网关可以将对客户端的影响最小化。“网关就像装载单体应用前的一个窗帘。客户端只会处理网关,而你可以在窗帘后面解耦你的单体应用,不必担心更新你的客户端,”他说道。

他说:“当你没掌控你的客户端的时候这个特别有用”。

传统上,API网关在组织网络的边缘上被使用,处理的流量大部分来自于单体应用和外部客户端之间的交互。然而微服务架构将大部分的流量转移到内部网络,因为不同的微服务之间要进行交互。“你可以有外部的客户端使用案例,但这成为了当前消费微服务的众多客户端之一。”

构建在Nginx这高性能的服务器上,Mashape的Kong是使用最广泛的开源API网关,一个月超过20W运行实例,Palladino讲到。使用Kong,Nginx被扩展到中间件上,可以通过JSON RESTful调用进行动态配置。

原文链接:The Role of API Gateways in Microservice Architectures(翻译:康良)

0 个评论

要回复文章请先登录注册