当企业服务总线遇到云服务

转载本文需注明出处：微信公众号EAWorld，违者必究。

前言：

本文主要介绍企业服务总线的常见应用场景，与大家共同探讨在云环境、微服务中传统企业服务总线所面临的问题，结合普元企业服务总线产品向大家分享我们该如何解决这些问题。

目录：

1.企业服务总线简介

2.传统的ESB应用场景

3.云服务对ESB提出的新要求

4.普元ESB产品介绍

1.企业服务总线简介

企业服务总线（ESB）是企业应用集成在SOA理念下的一种实现方式，ESB是SOA架构中实现服务间智能化集成与管理的中介，在逻辑上与SOA所遵循的基本原则保持一致,依据SOA架构原则对服务集成和服务管理的要求，创建了一个SOA集成架构，能够深入管理服务，并能方便扩展到整个企业应用。

ESB是分布式的、基于消息的、遵循开放标准的集成解决方案。ESB的角色是在各种IT资源——如企业中各种异构应用系统、平台和服务之间进行可靠的通讯时提供可用的基础设施。如下图所示，企业服务平台为企业应用提供了一个统一的平台，采用SOA松耦合的思想来进行企业应用集成，通过灵活的服务接口和Adapter，方便SOA应用、异构应用、特殊协议应用的集成，这种松耦合、有效灵活的架构提供了很好的扩展性。

ESB除了从技术上为各个应用提供解耦、集成的能力外，在业务上提供对其承载的服务进行管理的能力，支持对接口服务的全生命周期管理，全面提升IT系统的集成能力，通过能力开放为业务的持续创新提供支持。

ESB支撑了服务集成的演变过程：

1、解耦：将现有的业务系统采用SOA架构和标准化技术进行功能和部署的解耦；

2、集成：因为业务的关联性，解耦伴随着需要解决集成问题，通过引入企业服务总线（ESB）对接口服务进行管控；

3、服务治理：通过在ESB基础之上建设服务治理平台，实现接口服务全生命周期管理，全面提升IT系统集成能力；

4、能力开放：基于服务集成平台的能力，汇聚互联网的创新力量，推动业务的持续性创新发展。

2.传统的ESB应用场景

在企业服务集成过程中往往面临着以下四个层面的问题：

1、技术架构层面

系统接口关系复杂、开发与维护代价高昂。

2、管理流程层面

缺乏有效的工具，服务接口难以实现透明化管理。

3、规范制度层面

由于规范制度的不完善，造成核心IT资产很难做到自主管控。

4、组织保障层面

由于缺乏工具及有效的手段，容易造成过程中组织层面岗位、职责定义不清晰，使得服务集成过程更加困难重重。

ESB作为服务治理体系中的核心部件，为解决上述四个层面的问题提供平台与工具支持：

1、技术架构层面

基于ESB的服务治理体系中，ESB通过统一的、标准的服务接口，为集成的业务系统建立了清晰的系统边界，提高了系统灵活性和稳定性，提升了业务系统的能力开放。

2、管理流程、规范制度层面

在ESB的服务管理体系中，得以对服务的状态、使用情况及服务生命周期进行管理，并在技术及管理两个方面进行规范化控制。

3、组织保障层面

组织层面以ESB提供的服务管理、服务生命周期管理为基础划分为治理小组、服务提供者、服务消费者三个维度，不同维度的角色即可明确划分其责任范围。

治理小组：推动和实施服务治理活动，确保管理体系和平台工具的执行，监控服务接口的运行情况，评估服务治理的绩效，保证服务治理最终实现业务目标和需求。在系统中完成应用系统名称的注册和注销；完成对服务接口注册申请审批、变更审批、注销审批，定期检查和审计服务接口使用情况和状态。

服务提供者：服务接口的提供方责任人，负责提供服务接口，保障服务接口运行稳定、可靠。

服务消费者：服务接口的调用方责任人，负责按照规范进行服务接口调用。

3.云服务对ESB提出的新要求

在当前微服务遍地开花，“上云”成为关键词的时刻，以下问题便浮现了出来：

1、微服务下还需要ESB吗？

这个问题的答案是肯定的；有些观点是在微服务中各个服务之间通过注册中心寻址，接口交互采用相同的RESTful或RPC协议，即便是有外部服务只要通过网关就可以接入，因此不需要ESB；但事实是一个企业内的所有系统内部及系统间都满足这个条件的是很少的，即便是一家新的企业正在从头开始建设自己的IT系统，也可能会由于采购的不同供应商的系统而出现不同系统服务的协议不一致或新业务需要对某些现有服务进行编排的情况，在此情况下ESB便是解决问题的最好方案，否则将可能又回到系统间点对点调用的无序状态。

在得出这个结论的同时，也对ESB提出了新的要求，那就是在对接微服务时微服务实例的数量不固定，存在动态扩缩容的情况，因此需要支持通过微服务注册中心实现对服务实例的寻址，并且支持微服务实例同样通过注册中心实现对ESB发布的服务的调用。

2、ESB“上云”能做什么？

对于云服务使用方企业来说，在企业IT系统“上云”的过程中，将企业原来内网的系统迁移到云服务环境中去，这样系统服务就从原本内网相对封闭安全的环境放到了公网开放的环境，增加了安全风险，在这时，除了云服务商一般提供的对服务端口级别的安全策略对系统的保护外，可以通过ESB的能力提供服务级、用户级的安全防护；同时除了作为服务集成的平台外也可以将ESB作为开放服务平台将“上云”的服务进行包装、编排后作为开放服务对外提供。

对于云服务提供商来说，为用户提供了服务集成组件、服务开放组件以及更完善的安全防护选择。

3、ESB如何“上云”？

ESB“上云”需要解决这样几个关键点。

（1）租户隔离

在云服务环境中，为每个租户提供完全隔离的ESB实例，保障不同租户间的ESB服务的完全隔离。

（2）动态扩容

在云服务环境中，支持运行引擎根据系统压力进行动态扩缩容。

（3）便捷的服务配置

在云服务环境中，能够快速在线实现服务的代理、转换等配置，减少对离线开发工具的依赖。

4.普元ESB产品介绍

Primeton ESB是普元基于多年对大型企业的IT建设及分布式计算和集成能力的认识和技术积累而推出的服务整合产品，是部署和实现SOA的理想工具，支持协议转换、消息转换、消息路由、服务编排、服务注册、服务查找、服务监控等功能。

Primeton ESB 产品主要包含：

（1）Primeton ESB Studio：主要提供各种服务(中介服务、穿透服务、编排服务等)的开发、调试以及属性设置、导出等，为便捷快速地开发各种服务提供可能；

（2）Primeton ESB Server：提供了多协议的支持以及为服务运行提供了高性能、高可靠的运行环境，方便的扩展机制，为Primeton ESB 融入企业IT环境提供了有效支撑及管控手段，同时不依赖于J2EE容器的特性大大提升了性能；

（3）Primeton ESB Governor：提供了独立和集群环境中的ESB Server进行管理，同时对于服务全生命周期进行管理；对引擎运行状态及服务调用状态进行监控；

此处主要介绍产品的服务器管理、在线服务注册、离线服务模型开发部署、访问控制、统计监控等。

1、服务器管理

在服务器管理中可对ESB Server运行实例进行管理，在云服务环境中可通过第三方注册中心（如：Zookeeper）自动添加。

2、在线服务注册

对于HTTP穿透、WS穿透、HTTP转JMS、JMS转HTTP等服务可在线快速通过配置实现服务的发布。

下边以HTTP穿透为例：

（1）创建通道，配置ESB服务的端口及此端口对应的服务类型

（2）注册服务代理URI、服务提供方URI、服务提供方业务地址等

（3）配置服务路由规则、请求报文转换规则、响应报文转换规则等。

（4）在线完成配置就可以通过客户端调用注册的服务

3、离线服务模型开发部署

当需要进行复杂服务编排时，可以通过Studio进行开发测试，开发测试完成后导出ecd部署包，通过管理平台的服务模型部署功能导入后就可以通过客户端调用该服务。

4、访问控制

• IP白名单：控制允许进行服务访问的IP地址。只有平台配置过的IP才能进行服务访问，能够阻止非法IP的访问请求。
• IP黑名单：控制不允许进行服务访问的IP地址。只有不在黑名单列表的IP才能进行服务访问，能够阻止非法IP的访问请求。
• 访问权限：控制服务提供者的服务可以由哪些消费者系统访问，未配置的消费者系统不能访问该服务。
• 访问频度：控制每个服务配置单位时间访问次数的上限，对访问次数已达到上限之后的服务，在统计时间段内的请求都予以拒绝，直至本统计时间段结束；服务访问频度达到阈值时会进行告警，显示出现服务访问流量异常的服务的基本信息、异常信息等。
• 访问流量：控制每个服务的单次请求包大小和单位时间内的请求包大小总和，对超过阈值的请求予以拒绝；服务访问流量达到阈值时会进行告警，显示出现服务访问流量异常的服务的基本信息、异常信息等。
• 访问超时：控制每个服务配置访问时长上限，对于超过访问时长上限的服务，系统将发服务调用时间过长告警。

5、统计监控

管理平台中通过首页的图表信息可以实时或根据条件监控系统运行情况，包括系统总请求量、平均响应时间、异常交易数、系统告警数、调用方及被调用方系统数和地址数、响应时间TOP10、请求量TOP10、ESB Server系统CPU/内存使用情况等。

通过统计监控相关功能可以查看具体的交易日志、异常交易、调用链日志及告警详情等。

更多产品相关信息，请访问普元官网http://www.primeton.com查看或咨询我们。

精选提问：

问1：服务总线目前开源的产品有哪些？

答：目前开源的服务总线有Mule、ServiceMix等。

问2：和API网关的区别？

答：API网关可以认为是一个简化的ESB，服务转发、安全管控、流量控制、服务治理等都是一样的，只是网关往往只包含HTTP、RPC协议，部分还包含数据发布能力，而ESB则包含更多，比如ftp、jms、tcp以及自定义扩展等。

问3：SOA和微服务有什么区别？为什么不采用微服务而是用ESB？

答：微服务是SOA发展到一定程度后产生的一种架构方法，所以说微服务也是SOA。"为什么不采用微服务而是用ESB"这个问题并不存在，既然微服务是技术发展产生的新的架构方法，自然是有其价值的，并不推荐“不采用微服务”，相应的如果系统采用的是微服务架构，并且系统与外部系统的交互通过网关就可以支持，那么就没必要在用ESB，而如果系统在和外部系统服务的交互中网关无法满足要求，比如需要接入的接口存在多种协议，尤其是一些缺少维护的老系统提供的服务，那么ESB就能方便的进行适配，或者让将网关扩展成“ESB”或者搭建一个“类ESB”的接入层。

问4：将服务纳入输入总线，与老旧系统直接调用服务相比，调用效率影响大不大，或者影响效率的有哪些因素？

答：通过总线作为服务集成平台，在服务转发过程中中安全控制、日志记录等对于调用效率影响是很小的，我们的产品在压测中性能影响在5%以内，除了常见的服务转发外，ESB平台还支持报文转换、协议转换、多个服务进行编排等，在存在服务编排的情况下效率的影响程度会取决于编排的复杂度。

问5：Primeton ESB是普元基于多年对大型企业的IT建设及分布式计算和集成能力的认识和技术积累而推出的服务整合产品，请问服务总线是否具备分布式计算及分布式部署的能力，服务总线和分布式是什么关系？

答：普元ESB的部署模式上支持多节点部署，可以根据业务情况快速的部署新的节点进行扩容，也可以将自身作为一个服务节点注册到分布式架构的注册中心中去；在去中心化的分布式架构中，ESB可以作为外部服务接口的接入管理服务，通过ESB将外部服务地址等对其他服务隐藏，其他服务在需要调用外部服务时只需要调ESB。

问6：服务总线技术与Docker容器技术、微服务之间是什么关系，能否理解为其是一个微服务管理平台；服务总线上云对云的环境要求一般是什么样的？

答：服务总线主要负责服务管理及接入接出，Docker容器技术、微服务这些更多的解决的是IT系统架构、应用开发架构、快速扩缩容等方面的问题，ESB只管理服务接口的接入接出、安全控制、流量控制等，所以并不能完全作为微服务的管理平台。服务总线上云对云环境没有特殊的要求，只要满足系统正常的运行环境软硬件要求即可，比如JDK、容器内操作系统、内存、CPU等。

问7：现在有的厂商提出数据共享平台替代传统的ESB服务，想请教一下老师，数据共享平台与ESB之间的区别?

答：这两个之间的区别主要在于平台的接入源的不同，数据共享平台的接入源一般是数据仓库、数据文件或其他数据来源，而ESB对于接入的服务类型是没有要求的，可以是数据类的接口，比如数据共享平台发布出来的数据服务，也可以是计算类服务，比如AI算法服务。

问8：现在都在提倡DEVOPS，这种怎么看?

答：DEVOPS是项目管理过程方面的方法、工具，与ESB所解决的问题完全不同，普元有DEVOPS相关的产品，如果想要了解可以通过官网www.primeton.com或售前进行咨询。

问9：服务总线通俗的作用是什么，怎么能让企业一下子明白是什么；服务总线对老旧系统如何进行服务管控？

答：服务总线最基本的作用就是为企业内大量系统服务间的交互做中介，统一管理、适配不同的接口，减少接入系统对服务提供方接口协议、实现技术的依赖，并通过统一的平台实现对各个接口服务的权限控制，调用监控以实现对服务的管控。