当互联网开始时，只有一个HTTP服务器的概念，它可以提供静态网页。这很快就发展成了应用服务器，使用HTTP服务器作为应用的反向代理来提供网络应用或Servlets。虽然这些应用在当时很不错，但它们变得太大，无法在面向服务的架构（SOA）中与其他应用/服务进行整合，这导致了企业服务总线（ESB）的产生。

什么是ESB？

ESB实现了SOA中相互作用的软件应用程序之间的通信系统。作为一个架构，ESB可以被认为是整合企业应用的一个中央平台。它也可以被认为是一种架构，允许通过一个共同的通信总线进行通信，该总线由服务提供者和使用者之间的各种点对点连接组成。

ESB在应用程序之间的高级协议通信（XML到JSON，反之亦然）方面促进敏捷性和灵活性。这种高级协议通信的主要目标是以可维护的方式实现复杂服务或应用景观的企业应用集成（EAI）。ESB的一些主要职责是在服务之间路由消息，监测和控制服务之间的路由消息，控制服务的版本，并提供数据转换和安全等商品服务。ESB通常被用来促进服务之间的内部通信，但并不局限于这种用例。

什么是API网关？

API网关本质上是美化的反向代理，为反向代理提供更多的定制和灵活性。API网关作为一个API前端，协调API请求，执行流量策略（即节流、缓存）、安全策略（即授权、认证），收集流量分析，并协调转换引擎，以便即时修改请求/响应。API网关通常被视为外部请求和内部服务之间通信的入口点，因此它被称为API网关。然而，在内部使用API网关，可以促进政策的标准化方面的巨大回报。

API网关是一个新的ESB吗？

API网关是对ESB的重新发明吗？是，也不是。尽管API网关可以提供很多相同的功能（安全、数据转换、路由），但它是以协调的方式，而不是以点对点或广播的方式。API网关和ESB可以并存，因为它们的主要职责与预期目的相重叠，而且它们被内部和外部通信的关注所分开。

对动物来说，相当于ESB的是神经系统与循环系统的结合。当一个器官需要与另一个特定的器官沟通时，它使用神经系统来发送一个点对点的信息。当一个器官需要向其他可能感兴趣的器官广播信息时，它向血液中释放一种荷尔蒙，以发送一个多播信息。当一个信息从身体的任何地方进入大脑时，大脑会告诉身体如何反应。例如，如果您不小心碰到一个热炉子，您皮肤中的神经会向您的大脑发送一个疼痛的信息。大脑然后发送一个信息回来，告诉您的手的肌肉拉开。API网关在协调互动的方式上相当于大脑。

虽然API网关可以被认为是一个大脑，但这并不意味着它不需要或不被神经系统所增强。因此，当看到目前的情况时，API网关并不是一个新的ESB，而是ESB原始概念的增强。

存在的API网关

在过去，有尼安德特人发现了火，从火中他们发现了烹饪，从烹饪中他们能够活得更长。随着他们寿命的延长，他们开始想要更多的东西，而不仅仅是一个山洞，于是他们开始建造。首先我们有房子（HTTP服务器），然后是部落（反向代理），然后是村庄（ESB），然后我们建立了城镇。城镇小到每个人都知道发生了什么，并能提供帮助，同时又大到需要一个集中的方式来管理城镇中发生的发展。大多数公司都是城镇的规模，他们有很多领域的知识和产品，一个集中的API网关可以满足他们的需求，而且他们不需要关心其他城镇发生了什么。

在目前的情况下，有很多成熟的API网关产品，如Kong、APIGEE、KrakenD、Tyk.io和IBM API Connect（以前是Strongloop）。这些产品中的每一个都有自己的优势和劣势，包括价格、可维护性、可扩展性和定制化。

API网关的未来

虽然很多公司享受他们平静的小镇，但也有一些公司正在演变成城市。当从一个城镇演变成一个城市时，建筑物的数量成倍增长，规划城市的工作对一个集中的联系人来说变得太大，所以市长不得不雇用一个团队来处理规划。

随着微服务架构中的服务协调变得越来越困难，API网关领域的新发展已经出现，以利用科技的其他最新发展。

无服务器

功能即服务（FaaS）（即亚马逊的Lambda、OpenWhisk）是不久前才创建的，但最近已经变得稳定，成为利用API网关的一个卖点。当您分解一个API网关时，它实际上是一个功能的堆栈，这些功能相互连接以满足一个请求。以这种方式思考API网关，导致了使用FaaS平台来促进API网关功能。目前有几个平台，但其中一个被大量使用的是Serverless框架。这已被证明是简单的API网关的一个很好的用例，特别是如果您已经在使用FaaS技术来满足其他业务需求。这确实意味着您的API网关需求的每一个方面都必须进行编码，一般由您的公司来完成。使用无服务器技术的想法是，您不需要运行您自己的基础设施。这对某些人来说是一个卖点，但这也意味着您要受供应商的网络、政策和运营能力的制约。使用像谷歌/AWS这样的大型供应商的FaaS是最理想的，但并不是每家公司都能接受由其他人来托管他们的数据，特别是由于任何数据泄露都是导致公司灭亡的公关噩梦。

服务网格

由于容器化是为了消除运行一个完整的操作系统来承载一个应用程序的开销而变得流行，它很快就被滥用了，现在所有东西都是自己的容器。每个应用程序都是自己的容器，这个问题催生了一些公司在任何时候都有几千个容器在运行。在一次会议上，一位发言者提到，在生产中，他们有超过4000个容器，但只有400名工程师，这意味着每个工程师负责10个生产系统。这对API网关来说是个问题，因为在目前的情况下，大多数网关都是手工注册与之沟通的每个服务，以及如何处理对每个服务的请求（安全和流量策略）。

随着公司创建的容器数量的这种大规模增长，容器编排发展到开始启用服务网状结构。服务网状结构这个术语经常被用来描述构成这种应用程序的微服务网络以及它们之间的互动。随着服务网状结构的演变，以协调逻辑服务中连接的容器数量，需要将它们自动注册到一个网关中。Istio被开发为一个协调工具，用来管理服务网格以及Envoy。

API网关和服务网状结构之间肯定有一些重叠，即请求路由、组成、认证、速率限制、错误处理、监控等。也就是说，服务网状结构的目的是用于内部服务与服务之间的通信与策略执行，而API网关主要是用于外部客户与服务的通信。就像ESB被用作API网关一样，服务网状结构也可以被用作API网关，但更适合取代ESB的工作，与API网关一起工作，将服务暴露给外部消费者。

挎斗门

所有技术中的一个趋势模式是组件运动。在这个运动中，每一个开发的东西都被分析为一个组件或由几个组件组成的高阶组件。这些组件是现代应用程序的构建块。这种基于组件的软件工程（CBSE）甚至已经在通常是集中式基础设施的API网关领域找到了自己的方式。这种模式允许一个应用程序获得API网关的主要功能，同时并排生活，而不是拥有一个历史上自上而下的基础设施。这种方法允许采用分布式方法来执行组织层面的政策。

侧车网关的一些例子是Ambassador、Istio，甚至Kong也采用了侧车方式作为一种能力。

API第一。迎接风暴的到来

API优先设计是一种策略，其首要任务是开发一个将目标开发者的利益放在首位的API，然后在此基础上构建产品（网站、移动应用或SaaS软件）。

这种设计策略使产品能够在用户（开发者）决定如何利用产品方面实现充分的灵活性。这种使用可能超出了它的设计范围，但由于这种灵活性，新的用例被不断发现。这种策略被许多软件、建筑等领域的工程师所考虑。让我们以原始的避难所为例。它们的预期用途是让人类能够经受住自然因素的考验。最终，人类开始使用庇护所来安置他们的财产，这超出了庇护所所提供的用例，但并不违反庇护所的设计方面。庇护所的这种用例导致了对房屋的重新设计，以增加更多的功能，而不放弃其作为一个用来抵御自然因素的庇护所的初衷。

为简化起见，可以这样想。您建造了一个原始的住所，它可以保护您免受自然因素的影响。这个世界是一个更温暖、更干燥的地方。

现在，您们部落中的另一个人开始建造一个附属房间，与您们的庇护所相互作用。然后，第三个人看到庇护所提供的温暖和干燥，决定为您的庇护所建造第二层。很快，您有很多人都在建造具有横向依赖关系的附属建筑，而这些附属建筑的建造节奏都是不同的。如果在API领域没有应用纪律，可能会发生的是集成失败的恶梦。

为了避免这些整合失败，并承认您的庇护所是建造过程中的一流艺术品，您希望其他人能够对照庇护所的设计合同工作，而不干扰所开发的原始空间。

摘要

您知道有很多使用API网关的例子，以及您为什么要使用Kong。在下一章中，我们将更仔细地研究Kong，同时将它与现有的竞争性API网关进行比较。