实战:基于 ESB 的企业系统集成随着企业信息化程度的不断提高,越来越多的信息系统逐渐上线，这些系统在为企业带来效益的同时，也带来了一些让开发及维护人员头痛不已的问题,主要表现在系统分散，信息孤岛，交互复杂，维护成本太高.多说无益，直接上干货，请看下图:假设现在有 A、B、C、D、E、F、G 7 个业务系统.各系统均为独立的业务系统,系统的开发语言、所使用的数据库、所需要的运行环境也不尽相同。有些为自主开发，有些为外部采购。根据业务需求各系统间需要有各式的数据交互。为了更加直观，现将其假设为华信内部常用的系统名称。（实际上公司内部的系统要远远多于上述内容，并且关系更为复杂）。举例来说：假设 A 系统为 HR 系统，系统 B 为 PMS 系统、G 为一卡通相关系统等等.为了与其他系统交互，各系统均提供 webservice 接口，用来接收处理数据。每个系统在发送数据时需要调用其他系统的接口，以 HR 系统为例：当有新员工入职时，首先将员工信息录入到本地系统中,然后分别通知，PMS、内网、DPark、联系人、门闸、消费等等系统，要求对方也同时追加该员工的相关信息,并根据需要向其他系统返回相应信息。于是一张密密麻麻的蜘蛛网就成型了。直观一点,我们看一下现在 HR 系统需要调用的接口：编号目标系统数据方向接口内容1PMS输出人员基本信息、人员职位、人员组织。..2内网输出人员基本信息、人员职位、人员组织..。3Dpark输出人 员 基 本 信 息 、 人 员 职 位 、 人 员 组织.。。4联系人输出人 员 基 本 信 息 、 人 员 职 位 、 人 员 组织。。。5邮箱输出人员基本信息、人员职位、人员组织。..6门闸、门禁输出人员基本信息、人员职位、人员组织。..7消费输出人员基本信息、人员职位、人员组织。..既然有输出，就一定还会有输入，这里就不再列举。每个系统都会提供很多的接口,可以想象,现在的数据交互这部分的复杂程度和代码量。对编码人员和业务人员这都是一个很残酷的考验.每次新增一个系统或者改动某些现有业务就是一次噩梦.现在我们需要改变，我们目标是:以面对服务的方式,实现异构、分布式应用系统之间松散耦合的集成共享、互联互通的消息传送平台直观些，我们想要这样的东西：值得庆幸的是，之前的结构看起来虽然很乱，但是他们是基于 SOA 的。现在重新梳理一下我们面对的问题和需求:多对多的数据交换,牵一发动全身各业务系统的接口对外公开,安全性差业务逻辑多处重复,...
