实战：基于ESB的企业系统集成.doc

实战:基于ESB的企业系统集成
随着企业信息化程度的不断提高,越来越多的信息系统逐渐上线，这些系统在为企业带来效益的同时，也带来了一些让开发及维护人员头痛不已的问题,主要表现在系统分散，信息孤岛，交互复杂，维护成本太高.
多说无益，直接上干货，请看下图:
假设现在有A、B、C、D、E、F、G 7个业务系统.
各系统均为独立的业务系统,系统的开发语言、所使用的数据库、所需要的运行环境也不尽相同。有些为自主开发，有些为外部采购。
根据业务需求各系统间需要有各式的数据交互。
为了更加直观，现将其假设为华信内部常用的系统名称。（实际上公司内部的系统要远远多于上述内容，并且关系更为复杂）。
举例来说：假设A系统为HR系统，系统B为PMS系统、G为一卡通相关系统等等.
为了与其他系统交互，各系统均提供webservice接口，用来接收处理数据。每个系统在发送数据时需要调用其他系统的接口，以HR系统为例：当有新员工入职时，首先将员工信息录入到本地系统中,然后分别通知，PMS、内网、DPark、联系人、门闸、消费等等系统，要求对方也同时追加该员工的相关信息,并根据需要向其他系统返回相应信息。于是一张密密麻麻的蜘蛛网就成型了。
直观一点,我们看一下现在HR系统需要调用的接口：
编号
目标系统
数据方向
接口内容
1
PMS
输出
人员基本信息、人员职位、人员组织。..
2
内网
输出
人员基本信息、人员职位、人员组织..。
3
Dpark
输出
人员基本信息、人员职位、人员组织.。。
4
联系人
输出
人员基本信息、人员职位、人员组织。。。
5
邮箱
输出
人员基本信息、人员职位、人员组织。..
6
门闸、门禁
输出
人员基本信息、人员职位、人员组织。..
7
消费
输出
人员基本信息、人员职位、人员组织。..
既然有输出，就一定还会有输入，这里就不再列举。
每个系统都会提供很多的接口,可以想象,现在的数据交互这部分的复杂程度和代码量。对编码人员和业务人员这都是一个很残酷的考验.每次新增一个系统或者改动某些现有业务就是一次噩梦.
现在我们需要改变，我们目标是:
以面向服务的方式,实现异构、分布式应用系统之间松散耦合的集成共享、互联互通的消息传送平台
直观些，我们想要这样的东西：
值得庆幸的是，之前的结构看起来虽然很乱，但是他们是基于SOA的。
现在重新梳理一下我们面对的问题和需求:
n 多对多的数据交换,牵一发动全身
n 各业务系统的接口对外公开,安全性差
n 业务逻辑多处重复,浪费开发资源
n 难以进行的业务修改，无法快速推出新业务
n 开发质量难以控制
n 业务系统工作量很大
简单说：我是一个业务系统，我不想同时和那么多业务系统打交道,多了我会晕的，我只想跟一个系统有交互。举个贴近生活的例子:我是名普通员工，我今天刷卡不好用了,你不能让我分别去跟Dpark、Pms、门禁、车场、消费等等那些相关人员去打交道，我只想跟一个人说一遍，然后等候结果就行了。
这个中间的消息平台应该是什么呢？没错,就是她ESB.
ESB的特点
1. 面向服务的架构 - 分布式的应用由可重用的服务组成；
2. 面向消息的架构 — 应用之间通过ESB发送和接受消息；
3. 事件驱动的架构 — 应用之间异步地产生和接收消息;
ESB就是在SOA架构中实现服务间智能化集成与管理的中介。
这简直就是为了解决我的问题而生的东西.
现在看一看我们都需要做什么:
1、 接收数据：接收各系统发送过来的数据，这里采用对外发布webservice的方式。
2、 处理数据:对接收的数据进行相应的转换处理,以匹配不同的目标系统.举例：A系统中的性别字段中存储的是0，1 而B系统中是男，女。
3、 发送数据：根据业务规则将其发送给相关系统,调用对方提供的服务。
现在看起来好多了。现在各业务系统只需要对外公开数据接收的服务就可以了。并且只需要调用ESB提供的一套webservice就可以，不用依次去调用每个系统的webservice。工作量大幅减少.为了让ESB知道我的数据要发送给那个系统,在ESB接收端有一个标识TargetSystem用以标识目标系统。
好了，大家都很开心，但是,这样做真的已经很好了吗？我们通过对比来看一下。

改造前
改造后
发送数据
调用各系统提供的接口。
只调用ESB提供的接口.
接收数据
由自身提供
由自身提供
数据处理
业务系统自己处理
ESB统一处理
目标系统
按需直接调用对方接口
只需通知ESB
系统压力
被调用时产生压力
ESB接收端压力巨大
日志及错误
各系统自行处理
ESB处理
安全性
各系统间接口公开
接口仅对ESB公开
来一个实际的例子：
公司组织机构调整，此次涉及1000人，这些人不光人员组织信息变动,还有职位信息变动,还有部分人的基本信息进行了变动（比如更换了手机号,增加了学历信息），此次信息修改的发起者是HR系统，方式是在零时统一执行,接收方有10个系统。那么未改造前HR会调用接口：1000人*3处变动＊10个系统=30000次。
改造后HR会调用接口：1000人*3处变动＊1个系统=3000次。
与此同时PMS系统要对这些人所对应的项目信息进行处理，并通知5个系统.假设平均每个人有2条项目信息需要处理。那么就是1000人*2处变动*5个系统=10000次调用。
改造后PMS会调用：1000人＊2处变动＊1个系统=2000
变化非常的大,但是，但是。。.
改造后所有的压力都转到了ESB身上。上述两步ESB的接口被直接调用了5000次。然后ESB再通过各种处理转化，将这5000次的请求分别发送到其他系统,系统的压力非常大。并且这只是日常工作中的很常见的一种情况,很多时候，会有多个系统同时有大量数据的请求。ESB很容易因压力过大而出现暂时停止响应的情况。
在安全性上，ESB的接口对外公布，潜在的危险也很大。另外各个业务系统调用ESB接口时不了解ESB当时的压力。如果某个业务系统出现bug，比如死循环调用,会导致ESB服务器直接挂掉.各业务系统调用ESB接口的方式和错误处理方式都不同,很有可能造成许多未知的问题。当ESB停止响应时，所有业务系统都会报错。在ESB尚未恢复期间可能有大量的数据丢失，且难以恢复.
另外一点,现在个业务系统都被动的被要求知道自己数据的流向,他必须知道我的数据要到达哪些系统,一旦有新系统或原有系统有变化工作量也很大。原则上，这不应该是业务系统本身应该考虑的问题。现在我们要把这个问题简化，业务系统干好自己该干的事情，其他就不要操心了.
说了那么多其实就是四点1、性能 2、安全性 3、容错 4、数据流向处理
改进一下,解决上面的问题：
1、 性能：硬件支持。逻辑分层、物理分层.
2、 安全性：ESB接收数据由被动方式变为主动方式.
3、 容错：统一业务系统的发送端和接收端,业务系统端采用消息队列方式提供数据.
4、 数据流向：这个是业务问题，应该有专门的调度去处理,这部分功能加入到ESB中.
现在看一下改动过的效果：
发送端组件：统一的数据发送模式、统一的错误处理机制、日志及其他。
消息队列：存储业务系统需要发送的数据，等待ESB的提取。
接收端组件:统一的接收模式、统一的错误处理机制、日志及其他.
现在业务系统只需调用统一的组件即可。
再看ESB系统
收集服务：从各业务系统的获取消息队列中获取数据。
数据处理：根据需求进行数据的清洗、过滤、整合等等.
数据分发：根据规则将数据发送到指定的业务系统中去。
以上三部分功能分别部署在三台物理服务器上，来提高各自的使用效率。
ESB由被动转换为主动,现在我们可以根据ESB的负载情况来自动或手动的进行自我调节,甚至可以停止或启用某些流程.某个业务系统出现问题,不会影响到其他系统的运行，ESB出现问题，业务系统也可以正常运转，只是在ESB恢复正常之前他无法发送或接收新的数据，当ESB恢复时，会自动将业务系统中的数据获取并发送给相应目标。
下面给出一个相对完整的流程。
当然细节还有很多包括:
日志记录、错误处理、数据映射、流程管理、数据重发、规则管理等等.
经过上述改造，ESB系统已经可以轻松应对公司内部的各系统间的数据交互工作，由于将业务分发规则纳入到系统中,可以动态的进行数据流程管理，各业务系统各司其职，系统开发和运维人员可以把精力完全投入在自身系统当中.系统的安全性、实时性、有效性和可扩展性都得到了很大的提高。
技术就像围城：城外的人想进去，城里的人真会玩！
By智商无下限
mail： myi5iw＠163。com
SqlEditPlus最适合程序员使用的SQL编辑器
下载地址 :