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

【上海尚学堂的话】：本文主要讲述了Mashape的首席技术执行官Palladino对API网关的详细介绍，以及API网关在微服务中所起的做用，同时介绍了Mashape的一款开源API网关Kong。

API网关提供商Mashape的首席技术执行官Marco Palladino预测，尽管它们在命名方面存在差别，但新出现的服务网格并不彻底不一样于API网关，二者之间的类似性会随着时间的推移而不断增加。

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

“当你想到网关的时候，你一般会想到一个集中的层，一个额外的跳在网络上处理附加的功能。但这并不必定是真的，”Palladino上周在洛杉矶举行的2017年MesosCon上发表的讲话。网关还能够提供一种有效的方式来处理跨微服务之间的通讯。他说：“你也能够在现有的微服务上运行Kong，摆脱额外的跳跃，减小延迟。”

在过去的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调用。(上海尚学堂java培训原做，请多多支持关注，陆续发布java相关技术文章）