API网关跟ESB的联系与区别

1 相关名词剖析

  随着互联网的快速发展，企业的IT建设也是飞速发展的，但是在建设企业信息化时没有统筹考虑，建设往往不成体系、重复开发、烟囱式的建设，造成了资源的冗余和浪费，为了针对这些问题逐渐诞生了SOA、ESB、微服务、API网关以及REST等技术，现针对技术点总结如下。

 1.1 API网关剖析

API 网关是一个服务器，也可以说是进入系统的唯一节点。这与面向对象设计模式中的 Facade 模式很像。API 网关封装内部系统的架构，并且提供 API 给各个客户端。它具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能。

API网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过 API网关，然后由它将请求路由到合适的微服务。API网关经常会通过调用多个微服务并合并来处理一个请求。它可以在 WEB协议与内部使用的非WEB协议之间相互转换。API网关还能为每个客户端提供一个定制的API，通常它会向移动客户端暴露一个粗粒度的API，以产品详情的场景为例，API网关可以提供一个端点使移动客户端可以通过一个请求获取所有的产品详情。API网关通过调用各个服务（产品信息、推荐、评论等等）并合结果来处理请求。API网关主要功能如下：

• 使用API网关有优点也有不足，其中使用API网关的最大优点是：

1. 它封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。
2. API网关为每一类客户端提供了特定的API，这减少了客户端与应用程序间的交互次数，还简化了客户端代码。

• API网关的不足之处在于：

3. API网关增加了一个我们必须开发、部署和维护的高可用组件。
4. API网关变成了开发瓶颈。为了暴露每个微服务的端点，开发人员必须更新 API 网关。API网关的更新过程要尽可能地简单，否则为了更新网关，开发人员将不得不排队等待。

1.2 ESB服务总线

其主要作用是作为企业信息系统的“龙骨”来集成各业务系统，实现异构系统的互联互通，用来拉取、调度各个业务系统的数据，一般被称为企业服务总线。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。
通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。充当缓冲器的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，不用在应用程序或者数据发生变化时，改动服务代码。
ESB产品作为一个产品化的产物，不仅仅是解决一些基础的问题，产品自身还会在项目中不断完善和发展。ESB会把各行各业的解决方案用到的内容逐渐丰富到产品中，随着项目、行业的增多ESB的功能也越发丰富，可以应对不同行业的不同需求，随着近期微服务的兴起，ESB也进行迭代更新，我们的ESB更新了微服务的开发、编排、注册等功能，下文则是微服务的主要介绍。

1.3 微服务剖析

微服务是近些年被广泛提及的一个概念，微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是将功能发布成服务，应用程序通过调用不同的服务来实现业务，这种设计架构称之为微服务。

一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用；有的微服务则通过网页 UI 实现。在运行时，每个实例通常是一个云虚拟机或者 Docker 容器。
微服务主要是经过组件分离各自拥有立的生命周期，并且按需进行扩展，这种方式打破了组件之间的技术依赖，允许每个服务各自选择最合适的技术进行实现，每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。不同的服务甚至可以采用不同的编程语言来实现，一定程度上微服务使技术方案变得更加灵活，在使用过程中开发、测试、部署等环节十分便捷，整体是以松耦合高内聚的形式存在，符合IT技术思想。

1.4 微服务架构

微服务架构MSA可以理解为一个轻量级的服务治理方案，也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。

微服务架构优点如下：

1. 微服务架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供 API 服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务相对简单，即使用现在技术重写以前代码也不是很困难的事情。
2. 微服务架构模式使得每个微服务独立部署，开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度，譬如 UI 团队可以采用 AB 测试并快速部署变化。微服务架构模式使得持续化部署成为可能。
3. 微服务架构模式使得每个服务独立扩展。根据每个服务的规模来部署满足需求的实例。甚至可以使用更适合于服务资源需求的硬件。比如可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服务，而在 EC2 memory-optimized instances 上部署内存数据库。

微服务架构有优点当然也有不足之处，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之，微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要，适当的技术用在适当的场景，才能发挥合适的价值。

1.5 SOA架构剖析

SOA架构：SOA架构是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足响应市场或客户需求的多样化、多变性。
SOA架构泛化来看映射的是整体企业架构，企业架构又分为业务架构和IT架构，IT架构又分为应用架构、数据架构、技术架构。在SOA项目中，借鉴企业架构之道，并通过SOA技术架构和应用架构将业务系统构建和整合，并纳入整体企业IT治理体系中。SOA技术架构图如下：

1.6 Restful剖析

Open API即开放API，也称开放平台。所谓的开放API是服务型网站常见的一种应用，网站的服务商将自己的网站服务封装成一系列API应用编程接口开放出去，供第三方开发者使用，这种行为就叫做开放网站的 API，也称OpenAPI。随着这几年微服务概念的兴起，另一个名词出现在了我们面前，那就是Restful。而现在很多第三方开放平台的API都是Restful风格的API，而作为开发人员也经常听人说起Restful，REST这个概念是在2010年提出的，是HTTP协议的一位主要设计者提出的 Representational State Transfer（表现层状态转化）思想。REST概念的提出者认为改变应用的互动风格比改变互动协议对整体表现有更大的影响，这就称之为表现层状态转化，即REST它只是一种架构思想。

REST代表的就是表现层状态转化，这个表现层状态该如何转化呢，Restful本质上是基于HTTP的，以不同的HTTP动词来访问资源，再以Json对象返回结果。我们以不同的HTTP动词来代表不同的操作类型，如：GET（请求）、POST（创建）、PUT（更新）、DELETE（删除），所以表现层的状态转化实质上靠的是HTTP动词来实现的。

2 适用场景分析

2.1 网关适用场景

API网关能够支撑各个场景下开放 API 的需求，支持将API开放给合作伙伴、开发者，实现企业核心能力的货币化，建立API生态，支持将API适配多端，如：移动、互联网、物联，实现系统前后端分离；支持内部系统整合模块化、微服务化。

2.1.1 API资产

面对用户日益膨胀而又碎片化的需求，企业需要不断探索新的商业模式，来解决客户一系列的场景化问题。通过API网关提供标准的API服务，让其他开发者将不同API服务组合整合到自己的应用中，衍生出新的服务，促进企业建立商业生态、跨界创新。

2.1.2 API生态

如今企业面临更多的挑战，企业发展需要可靠的合作伙伴。企业与合作伙伴以 API 的形式进行服务、能力和数据的交互，系统与系统直接对接，达成深度合作，建立牢固的合作关系。将API接入阿里云市场以API的形式开放能力、服务、数据供广大开发者采购使用，产生价值，在API市场，采购第三方成熟的能力和服务，避免平铺式开发，专注专业，借力发展。

2.1.3 多端兼容

随着移动、物联网的普及，API需要支持更多的终端设备，以扩充业务规模，但同时也带来系统复杂性的提升。通过API网关可以使API适配多端，企业只需要在API网关调整API 定义，无需做额外工作。企业只需维护一个服务体系，面向多端输出，只需调整API定义，即可实现对APP、设备、web端等多种终端的支持，这就避免多个场景多套API，大大降低管理运维成本。

2.1.4 系统集成

在快速发展的过程中往往不成体系、重复开发、烟囱式建设，造成资源冗余和浪费，通过API网关对系统间接口进行规范统一，用标准化的接口实现系统集成。

通过上面四个场景可见，API网关的作用还是很大的，可以统一管理API，使用统一的API平台来统一管理这些API接口，提供统一通信协议、API文档以及SDK，将大大提升公司内部部门间协作的效率。

2.2 ESB适用场景

2.2.1 应用集成

实现异构系统的对接，连接现有各孤立的应用系统。包括服务之间的信息交换，协调各种应用和数据之间的服务传输协议，转换应用数据和服务之间的消息/数据格式，任何的应用系统都是通过应用集成平台与其它系统交互的。

• 典型场景：

1. 费用报销与薪资对接；
2. 生产系统与ERP系统对接；
3. 业务和财务一体化，应用系统跟财务系统凭证对接。

2.2.2 数据集成

负责业务数据上传、汇聚，基础数据（主数据）的下发、分发。AEAI ESB应用集成平台作为数据交换平台支持应用间批量数据交换和数据库间的数据交互，包括数据的抽取、转换和导入操作。同时MDM不需要向不同的业务系统请求主数据的获取、同步，只需要通过AEAI ESB进行数据分发、下发等操作即可获取这些数据。

• 典型场景：

1. 企业数据整合或数据中心建设；
2. 数据交换平台项目，辅助主数据管理项目做基础数据分发。

2.2.3 服务平台

用于微服务体系架构中的Rest服务开发、API网关、服务代理、服务监控、服务统计、服务超市。具体表现为分布式部署的ESB（可以放置于Docker容器中），实现微服务体系架构下的Rest服务开发、Rest服务组合、Rest服务代理，通过管理控制台注册代理其它系统提供的Rest服务，提供对Rest服务的运行监控、服务的启停功能、对代理服务每次调用情况的监控等。

• 典型场景：

1. 前后端分离技术架构下，做为Rest服务的开发平台；
2. OpenAPI运作模式下的服务治理、监控、统计、流量控制。

2.2.4 平台协同

从业务系统实时获取相关数据，为Portal提供数据服务、BPM提供数据回写，协作MDM、IDM做数据分发，为其它平台提供数据基础和服务注册查询。ESB企业服务总线对SOA整合架构的实现起到支撑作用，数据门户中，ESB从业务系统实时获取相关数据以XML或者JSON格式为门户平台中各图表组件、表格组件提供数据服务；业务流程重组中，ESB负责从各异构系统中动态获取表单数据，以JSON方式为BPM提供业务数据，在流程审批操作时，实现业务数据状态的回写等。

• 典型场景：

1. 企业业务流程重组项目支撑BPM实现应用对接机制；
2. 统一门户中为图表、列表、表格等前端展现组件提供数据服务；
3. SOA综合集成项目，支撑各个平台，为其提供服务。

3 区别联系分析

3.1 ESB与API网关联系

SOA是一种理念，它的主要特性是面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。但是SOA并没有定义出具体的实现方式，目前有两套SOA理念的实现方式：中心化和去中心化，这两套架构并没有优劣之分，还是要针对企业的根本诉求。
SOA中心化的实现方式就是ESB，ESB的根本诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送给服务消费者。AEAI ESB企业服务总线不但可以解决异构系统的集成难题，随着微服务的兴起，ESB还可以开发微服务，设计微服务接口的限流、代理、转发以及安全等功能，但是ESB并不是微服务中的API网关，微服务可以理解为是ESB中重要的一部分。
SOA去中心化实现方式的根本诉求是扩展性，实现方式就是微服务。分布式服务框架，主要有dubbox、spring cloud，实现后端服务治理的功能。

3.2 ESB与API网关区别

现从ESB和API网关的使用场景、传输对象、服务契约、实现方式、交互性以及安全层次进行区别分析。

使用场景在2模块已经详细介绍，在此不做过多赘述，从传输对象上讲ESN传输的是XML、JSON以及消息格式，而网关是传递JSON对象格式。ESB是将自己服务和接口契约发布到服务注册中心，一边服务使用者可以发现和访问该服务，网关则是通过文档进行约束。
在其实现方式上二者也是有很大区别的，ESN可以通过Http、WS、MQ、Restful等方式实现，而网关是通过Http及Restful实现，较为单一。
在功能上二者的区别如下。

ESB提供了服务总线的基础架构，提供系统一致性、安全性、可靠性，以及性能和扩展能力保障的基础技术手段。ESB提供了基础的集成服务，包含了应用集成、数据集成。提供内置的各种公用服务。例如渠道认证服务，日志服务等公用服务。ESB提供了服务配置管理的前台工具集合，并提供行业的服务规约标准。ESB提供了多角度的系统实时监控与交易报表，提供用户定制的告警。提供了多种安全机制并支持和第三方安全系统的有效集成，提供有效的安全监控机制。
在功能上API网关有API的全生命周期的管理，包括API的创建、发布、下线和删除等生命周期管理功能。其调试工具使用页面调试工具验证API的连通。在限流上用于管控API的请求频率、用户的请求频率和应用的请求频率，流量控制的时间单位可以是秒、分钟、小时或天，并且允许设置特殊的应用。在监控功能上可以监控API请求次数、API调用延迟和API错误信息。

4 AEAI ESB特性

应用集成平台主要作为企业信息系统的“龙骨”来集成各业务系统，一般称之为企业服务总线（Enterprise Service BUS，ESB），在数通畅联软件的产品家族中应用集成平台命名为AEAI ESB。

• 产品特性如下：

1. AEAI ESB支持容器化部署、多租户管理、支持REST微服务服务开发、编排、注册；
2. AEAI ESB企业服务总线提供API网关运作模式下的服务治理、监控、统计以及流量控制；
3. AEAI ESB企业服务总线自带集成样例可快速上手；
4. AEAI ESB企业服务总线提供灵活的业务日志及日志配置机制；
5. 产品提供丰富强大的组件堆，如：Http Rest、Soap、WebService、FTP、数据库操作、消息队列、主题收发，可以满足客户绝大多数的业务场景；
6. 平台除了预置丰富典型组件完成常规对接功能，同时内置通用的数据适配、协议适配、协议接入、消息转换、消息路由等组件，可以满足各种复杂的业务集成场景；
7. 平台基于设计器可以以图形化、拖拽方式方式创建服务及消息流程，设计器直接连接服务器使用一键热部署、即时断点调试；
8. 对于有事务特性的信息， AEAI ESB的事务机制能够为用户提供多种粒度的事务控制；
9. 对于并发量大、数据量大的需求场景，AEAI ESB的服务集群机制可以方便完成集群配置工作；
10. 平台支持认证、授权主流机制和规范，确保所有用户安全地访问应用集成平台提供的服务；
11. 产品通过各种机制保证ESB能适应各种复杂的外部环境。