实战：基于ESB的企业系统集成教程.docxVIP

实战：基于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的。 现在重新梳理一下我们面对的问题和需求： 多对多的数据交换，牵一发动全身 各业务系统的接口对外公开，安全性差 业务逻辑多处重复，浪费开发资源 难以进行的业务修改，无法快速推出新业务 开发质量难以控制 业务系统工作量很大 简单说：我是一个业务系统，我不想同时和那么多业务系统打交道，多了我会晕的，我只想跟一个系统有交互。举个贴近生活的例子：我是名普通员工，我今天刷卡不好用了，你不能让我分别去跟Dpark、Pms、门禁、车场、消费等等那些相关人员去打交道，我只想跟一个人说一遍，然后等候结果就行了。 这个中间的消息平台应该是什么呢？没错，就是她ESB。 ESB的特点 面向服务的架构 - 分布式的应用由可重用的服务组成； 面向消息的架构 - 应用之间通过ESB发送和接受消息； 事件驱动的架构 - 应用之间异步地产生和接收消息； ESB就是在SOA架构中实现服务间智能化集成与管理的中介。 这简直就是为了解决我的问题而生的东西。 现在看一看我们都需要做什么： 接收数据：接收各系统发送过来的数据，这里采用对外发布webservice的方式。 处理数据：对接收的数据进行相应的转换处理，以匹配不同的目标系统。举例：A系统中的性别字段中存储的是0，1 而B系统中是男，女。 发送数据：根据业务规则将其发送给相关系统，调用对方提供的服务。 现在看起来好多了。现在各业务系统只需要对外公开数据接收的服务就可以了。并且只需要调用ESB提供的一套webservice就可以，不用依次去调用每个系统的webservice。工作量大幅减少。为了让ESB知道我的数据要发送给那个系统，在ESB接收端有一个标识 TargetSystem用以标识目标系统。 好了，大家都很开心，但是，这样做真的已经很好了吗？我们通过对比来看一下。 改造前改造后发送数据调用各系统提供的接口。只调用ESB提供的接口。接收数据由自身提供由自身提供数据处理业务系统自己处理ESB统一处理目标系统按需直接调用对方接口只需通知ESB系统压力被调用时产生压力ESB接收端压力巨大日志及错误各系统自行处理ESB处理安全性各系统间接口公开接口仅对ESB公开来一个实际的例子： 公司组织机构调整，此次涉及1000人，这些人不光人员组织信息变动，还有职位信息变动，还有部分人的基本信息进行了变动（比如更换了手机号