【编者的话】本文主要讲述了Mashape的首席技术执行官Palladino对API网关的详细介绍，以及API网关在微服务中所起的作用，同时介绍了Mashape的一款开源API网关Kong。
本文讲的是微服务架构中API网关的角色API网关提供商Mashape的首席技术执行官Marco Palladino预测，尽管它们在命名方面存在差异，但新出现的服务网格并不完全不同于API网关，两者之间的相似性会随着时间的推移而不断增长。
Palladino指出，实际上这两种技术提供的功能很相似。API网关，比如Amazon Web Services的API网关或Mashape的开源API网关Kong，在过去的十多年来主要用于映射外部流量到内部资源，而最近开发的服务网格——比如Lyft’s Envoy或Uber’s Catylist——主要是在微服务架构中代理内部资源。
“当你想到网关的时候，你通常会想到一个集中的层，一个额外的跳在网络上处理附加的功能。但这并不一定是真的，”在上周洛杉矶举行的2017年MesosCon上Palladino发表演讲时这么说。网关还可以提供一种有效的方式来处理跨微服务之间的通信。他说：“你也可以在现有的微服务上运行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调用进行动态配置。
原文链接：The Role of API Gateways in Microservice Architectures（翻译：康良）
原文发布时间为：2017-10-12
本文作者：kl2422
原文标题：微服务架构中API网关的角色