API网关和ESB的区别

Posted 2021-04-21 Axway

作者简介

    

    徐晨亮（Sam），Axway资深架构师、高级讲师，从业十余年，丰富的API实战经验、独到的API战略理念，深入理解API与微服务、API经济及其发展趋势。

前言

当企业在进行其数字转型（DX）的旅程时，一个非常不同寻常的时间节点是：他们开始寻找到API网关和API全生命周期管理（APIM）解决方案，这也是企业在大量使用API进行数字化业务之前最重要的一个点。APIM对API生命周期管理的价值是毫无疑问的，但在较早的十字路口经常会问到这个问题：  

如果我有ESB（企业服务总线），为什么需要API网关（APIGW）？很多功能看起来都一样！  

如果您也面临着同一情况，那么我们帮您一起解决顾虑。

API网关和ESB - 我们的企业需要什么？

从表面上看，API网关和ESB共享许多相同的功能和许多相同的功能。事实上，在描述其功能的一个子集时，我经常听到称为“轻量级ESB”的API网关。但是，如果您还没准备好接受API程序，为什么还需要API网关？API网关对已经以ESB为中心的企业应用程序集成（EAI）策略的价值是什么？为了理解价值，我们首先谈谈数字化转型以及我们今天看到的一些不断变化的要求。

数字转型（DX）和ESB

ESB长期以来一直是执行EAI任务的关键工具。他们提供了一个抽象层，允许不同的A2A（应用程序到应用程序）和S2S（系统到系统）接口和流程的编排和集成，重点是以规范化方式（Web Service）公开服务和重用。这种工具多年来一直运作良好，但近来我们看到一些范式转变正在改变世界各地企业的需求。

转向以消费为中心的使用

我们以一个大型城市的隧道系统打个形象的比喻。大型城市精心设计了隧道系统，它的成本很高，但最终作为一个专门建立的解决方案，从一个点（市中心）到另一个点（外围村镇），它是城里出行最好的选择。但是，如果我想到某个隧道到不了的地方怎么办？一旦我走出隧道的另一端，有一个完整的村镇可以探索，隧道尽头有地标，表演，购物等等。餐馆是城市的主题之一，每天都有无数的餐馆在开张和关张，也许我想在同一个老地方吃饭，或者我想去新的地方，也许我想去那个我经常去的披萨店，但后来又想尝试一些新的东西，用来自街区周围咖啡店的一些奶油来完成我的用餐，所以我想探索一个全新的用餐体验，而不是试图回到我所知道的市镇。

企业应用程序集成（EAI）很像这种体验。毫无疑问，在不使用隧道系统的情况下穿越整个大型城市可能是一种令人筋疲力尽的体验，通过将外围村镇与隧道相连接，它可以提供连接并促进交通的效率，就像EAI策略中的ESB一样。但是如果隧道没带我到我想去的地方怎么办？我应该提交请求并等到新隧道建成吗？考虑到维护它的成本，这对城市来说是否是正确的决定？移动隧道的出口有多困难，它会造成什么类型的破坏？好吧，也许这个比喻有点极端，但你明白了。隧道是一种很好的方式来获得点对点并为城市基础设施提供价值，但最终要消耗城市的服务，我需要一个网格到城市街道，让我到达我想去的地方。我不想让别人告诉我，我只能消费隧道出口处的东西，我想尽可能快地探索和尝试新事物，那我应该怎样做不会因为等待新的隧道而受到阻碍？

企业希望同时完成以下任务：

·       提高开发人员的工作效率

·       实现全渠道体验和通过数据/服务获利的新方法，以及系统和应用程序的更多内部重用

我们已经看到了以“消费”为中心的用例的兴起。多年来，对于企业来说一直建设和经营自身的“集成工厂”（IntegrationFactory），而不是“集成能力”（Integration Enabler）为中心。这就意味着每当需要系统连接起来时，IT部门有责任并且要花费很高成本去实施，而且要花很长一段时间做管理。

然而今天，事情看起来有点不同。我们已经看到了HIP（HybridIntegration Platform）https://www.axway.com/en/products/amplify/hybrid-integration-platform的爆炸式增长，有很多新的趋势出现：

·       技术领域（例如内容协作平台）

·          用户角色（云集成商，数字原生代等）

·      接入端点（传感器，物联网，移动设备，内/外部云服务等）。

这些新的角色带来了指数级的新的人为驱动的技术要求，将所有这些端点连接到不断增长的技术领域，同时这些技术领域变得更少孤立和更加集成。

重点是：

·       便捷的访问能力

·       自助服务和快速原型设计，以支持最快的上市时间，以增加收入

·       高生产力

·       不断创新

让IT部门成为提供每个集成点的一站式服务不再是可行的策略。ESB最终成为每个项目的瓶颈，破坏了业务逻辑和开发人员的独立性，因为ESB团队必须参与每个项目的实施。

例如，每次发生以下事件时，ESB团队必须参与构建，公开和维护新集成：

·       出现了一种新的消息格式

·       上线新的应用程序

·       当需要消费一些新的API时，需要创建新的流程或重新编排才能使用

从人力资源角度来看，这种方法不仅不可持续，而且每一次新的集成都需要额外的基础设施来支持每个新的编排或流程，从成本的角度来看，这也是一个糟糕的选择。

在今天的不断泛化和可替换性世界中，由于有更多的渠道和接入端点，这种情况根本无法维护。为了支持银行保持相关性所需的灵活性，传统IT必须从“集成工厂”（构建每个抽象和连接）转变为“集成能力”（Integration Enabler）。他们必须放弃一些旧有的管理思维模式-即IT拥有每个连接和流程，而是转变为专注于自助服务。他们应该启用API目录，例如新的AxwayAMPLIFY Central（AMPC）统一API目录或银行使用Axway APIPortal自建的门户网站，以支持内部开发人员，业务分析师，消费者和第三方应用程序提供商的发现和协作。它们应该支持集成所有的业务用户使用的第三方应用程序和服务（例如消费金融公司、汽车金融公司、消费分期平台、网络借贷平台、互联网巨头、助贷平、消费场景平台等），以支持业务人员的创新用途。

 

通过实现以消费者为中心的使用，组织可以带来很多好处：

·       TTM（Time to Market）的效率，生产力和上市时间都有所提高，整体降低了与启用新ESB流程相关的成本。

·       通过断开传统的IT驱动集成方法，还有另一个好处。这种“集成能力”的文化，使开发人员和其他用户能够构建更灵活的客户端界面，通过去除集中式系统上的支持依赖性，可以实施API-First的理念和管理流程。

·       这种文化还允许开发人员更改消费API的服务契约和业务逻辑，而无需在ESB上进行冗长的更改管理过程，或者必须根据ESB支持的内容修改客户端体验。

同时，您的客户和消费者不限定必须是外部或第三方，这些好处也适用于为您的企业用户构建的内部应用程序！在这个拥有移动设备和大型应用程序商店的时代，每个人都希望获得无缝且功能丰富的用户体验（UX）。为实现这一期望，开发人员需要通过自助服务实现灵活性和敏捷性，避免因为传统ESB带来的瓶颈。

当我们看EAI时，要接受当今以“消费为中心”的理念可能是一个值得思考的话题。“隧道”为您提供方向，结构和控制。但是当您开始设定用户可以随意在城市里移动，并随时随地消费服务时，情况会发生明显变化，“高度控制”让位于“高生产率和灵活性”。但这并不意味着安全性的降低，恰恰相反，随着接入端点（传感器，物联网，移动设备，内/外部云服务等）的复杂多样，以及技术领域的改变，传统的ESB也无法满足企业的安全性和合规要求，而API网关则是为新技术领域而生，天然支持互联网场景的安全性，例如API Key，Oauth2等。

通过数字政策和业务可见性的治理，需要与企业微服务战略保持一致，我们将在下面详细介绍。ESB仍然具有很强的价值，可以提供坚固的隧道，让您到达目的地，但在这个新的数字时代，范式转换依赖于以“消费为中心”的使用，带有API网关（API Gateway）的API管理平台（API Management Platform）提供自助服务和灵活性来支持您的企业要求。从“集成工厂”（IntegrationFactory）模式转变为“集成能力”（Integration Enabler）模式，支持多样化和不断变化的需求集，而不是成为每个项目的瓶颈。

分解单体应用-低耦合，高内聚

我在上面中提到了HIP（Hybrid Integration Platform）,看到如此多的新用户角色和接入端点的爆炸式增长，这些角色推动了对新的集成方式的需求，许多此类活动主要集中在外部和新设备，新的云服务，新收入模式和新合作伙伴等。话虽如此，尽管这些外因驱动因素正在推动支持企业外部新技术范式的需求，但企业内部也正在迅速发生变化。

多年来，我们开始看到单体的巨石开始崩溃。ESB的成功很大程度上是因为我们看到其全面的功能，以及使应用程序适用于SOA（面向服务的体系结构），它们带来了如此多的价值，但单体应用的分解并没有止步于此。从有状态的SOA Web服务开始，到目前无状态REST API-允许以新的和令人兴奋的方式使用这些服务，不仅推动了上述的以“消费”为中心的使用，而且还创造了新的挑战和要求。例如，现在企业和IT必须合作实现很多业务场景：

·       通过新的编排，功能以及来自许多服务的功能的集成，持续部署以支持敏捷性和创新

·       将混合（Hybrid）世界（本地/私有云/公有云等）中快速发展和采用的技术整合到当前和新的服务和应用中

·       支持细粒度缩放功能的能力，进一步分解为微服务

现在，整体架构的变化还在继续，从集中管理编排（同步）转变为事件驱动架构编排（异步）。

ESB非常擅长实现企业内部高度重用的专用业务逻辑。即使在我们看到分解为更小和更独立的组件的世界中，将应用程序和功能与持久性编排结合在一起也是许多业务流程的关键功能。虽然REST API提供了重用的灵活性，但某些服务受益于高度控制和结构化的流程和消息，这些流程和集成并不意味着必须要被打破，解耦并用于创新解决方案，这些是构建许多企业产品基础的核心和基础流程。话虽如此，分解单体架构的范式的巨变正在发生，这些范式一旦被采用，对您的组织具有重要价值。

在分解的架构中，我们期望看到广泛的解耦。我们将其分解为其各部分的总和而不是仅提供单个目标功能集（高内聚），而不是单个服务提供许多功能（低内聚），通常部署为微服务。这种方法允许功能的粒度可扩展性，更灵活的使用，更容易更换或更改组件而不会影响更大的解决方案。当更大的功能完全包含在单个应用程序中时，或者集成是专门用于实现特定逻辑（高耦合）的。就如同采用ESB一样，您的解决方案变得更加脆弱，因为通过严格的编排和高耦合，任何变化都将在整体上产生巨大的共鸣效应，您无法轻松地精细扩展和替换组件，任何变化都需要很大代价。

随着我们消除高耦合，我们提高了生产力，灵活性和创新。然而，这一结果不仅来自于远离应用程序中的低内聚性，而且还来自组件如何连接以及流程如何操作。我们越来越多地看到从经典业务流程（由同步和高度结构化的操作执行定义）迁移到编排（由新的Axway PolicyStudio编排引擎支持），通过允许组件之间的异步和独立通信来定义。我们越来越多地看到从紧密集成的流程转向事件驱动的架构。通过将事件发布到队列，可以删除组件之间紧密绑定的依赖关系，允许更换组件，并以新方式使用数据，而无需严格定义应用程序如何耦合在一起。

ESB不会消失，但它们也是专门用于实现组件之间受控和紧密集成的范围之内，它们是一种中央总线，可实现服务之间的高度结构化集成。根据定义，这种情况是应用范式转向分解架构的对立面。话虽如此，您最终希望将所有这些粒度组合在一起，无论是从大量松散耦合和高度内聚的组件构建复合API，还是将细粒度API编排在一起以提供更高级别的抽象API。全生命周期API管理解决方案，例如Axway作为AMPLIFY平台的一部分的APIM解决方案，允许您围绕这些分解组件之间的访问和通信实施治理和可观察性，通过这样做，您可以公开组件，为开发人员，合作伙伴和第三方提供访问功能，以创新和意想不到的方式使用它，同时保持松散耦合和高度凝聚的架构范式的好处。

结论

ESB对于任何企业的EAI战略都很重要，但新的颠覆性数字和混合模式带来了新的需求。为了保持足够的灵活性以保持与市场和用户的相关性，您必须摆脱IT构建每个连接的手动“集成工厂”（Integration Factory）思维模式，而要力争成为“集成能力”（IntegrationEnabler）提供者。使用如此多的方法连接如此多的新组件，业务分析人员、开发人员和第三方用户的自服务是必须的，API网关则是此策略的核心，与ESB协同工作，提供企业发展所需的全部功能，并提供最佳的客户体验。

 

本文参考资料来源于：

https://www.axway.com/en/products/api-management

https://apifriends.com/api-management/api-gateways-esbs-enterprise-comparison/

关于Axway

作为世界公认的智能安全数据交换技术的创始者，Axway专注于Business Interaction Network方面的解决方案，已经有近30年行业经验。

扫描二维码关注Axway

扫描下方二维码，了解更多解决方案或安排约见Axway技术专家