随着企业信息化程度的提高，越来越多的信息系统上线了。 这些系统在给企业带来利益的同时，也带来了困扰开发和维护人员的问题。 主要是系统分散、信息孤岛、交互复杂，维护成本过高。
说无益的话，就这样当干货。 请参阅下图：
假设目前有a、b、c、d、e、f、g七个业务系统。
各系统是独立的业务系统，系统的开发语言、使用的数据库、所需的执行环境也不同。 有用于自主开发的，也有用于外部采购的。
根据业务需求，各系统之间需要进行各种数据的交换。
为了更直观，我们假设它是目前华信内部常用的系统名称。 (实际上，公司内部的系统比上述系统多得多，而且关系更加复杂。
例如，假设a系统为HR系统，系统b为OA系统，c为ERP系统等。
为了与其他系统进行交互，每个系统都提供用于接收处理数据的web服务接口。 各系统在发送数据时需要调用其他系统的接口。 以HR系统为例，新员工入职时，首先将员工信息输入本地系统并分别通知。 PM、OA、CAPA、CRM等系统要求对方也添加有关其员工的信息，必要时向其他系统返回适当的信息。 于是，形成了密密麻麻的蜘蛛网。
直观上，让我们来看看HR系统需要调用的接口。
编号对象系统数据方向接口内容
1 PM输出人员的基本信息、人员职位、人员组织。
2办公自动化输出人员的基本信息、人员职位、人员组织。
3 ERP输出人员基本信息、人员职位、人员组织。
4 CAPA输出人员的基本信息、人员职位、人员组织。
5电子邮件输出人员的基本信息、人员职位、人员组织。
6 CRM输出人员的基本信息、人员职位、人员组织。
7 Consume输出人员的基本信息、人员职位、人员组织。
既然有输出，就一定有输入，但这里不列举。
每个系统都提供很多接口。 可以想象当前数据交换这一部分的复杂性和代码量。 对编码人员和业务人员来说这是一个严峻的考验。 每次添加系统或更改现有业务都会成为噩梦。
我们现在的目标是以面向服务的方式，实现异构、分布式APP应用系统之间松散耦合的统一共享，以及互联的消息传递平台
直觉上，我们想要这样的东西：
幸运的是，以前的结构看起来很混乱，但他们是基于SOA的。
现在，让我们重新梳理一下我们面临的问题和需求：
交换很多数据，拉动全身
各业务系统的接口是公开的，安全性很差
业务逻辑在多个位置重复，浪费开发资源
困难的业务修正，无法迅速开始新业务
开发质量难以控制
业务系统工作量大
简而言之，我是业务系统。 我不想和那么多业务系统同时扯上关系。 一多就晕。 我想只和一个系统交流。 举个接近生活的例子吧。 我是普通员工。 今天卡不好用。 不能与办公自动化、广告、消费等相关人员单独交往。 你只需要对一个人再说一遍，等待结果。
这中间的消息平台是什么呢？ 没错，是她的ESB。
ESB的特征
1 .面向服务的体系结构-分布式APP应用由可复用服务组成；
2 .面向消息的体系结构-在APP应用之间通过ESB发送和接收消息
3 .在事件驱动的架构和APP应用之间异步生成和接收消息；
ESB是在SOA架构中实现服务间智能集成和管理的中介。
这简直就是为了解决我的问题而产生的。
看看我们需要做什么：
1、接收数据：接收各系统发送的数据。 这里采用对外公开web服务的方式。
2、处理数据：对接收到的数据进行相应的转换处理，以匹配不同的目标系统。 例如，a系统的性别字段存储0、1，b系统存储男性、女性。
3、发送数据：根据业务规则将其发送到相关系统，调用对方提供的服务。
现在看起来很好。 目前，各业务系统只需对外公开数据接收的服务即可。 另外，只需要调用ESB提供的一系列web服务，而不需要按顺序调用每个系统的web服务。 工作量大幅减少。 为了通知ESB我的数据将被发送到该系统，ESB接收方有一个标识目标系统。
好了，大家都很开心，这么做真的可以吗？ 比较一下。
改造前改造后
发送数据以调用每个系统提供的接口。 只调用ESB提供的接口。
接收数据是自身提供的，是自身提供的
数据处理业务系统自行处理ESB统一处理
目标只需要根据需要直接调用对方接口并通知ESB
调用系统压力时产生的压力ESB接收侧的压力较大
日志和错误
各系统自行处理 ESB处理安全性 各系统间接口公开 接口仅对ESB公开
来一个实际的例子：
公司组织机构调整，此次涉及1000人，这些人不光人员组织信息变动，还有职位信息变动，还有部分人的基本信息进行了变动（比如更换了手机号，增加了学历信息），此次信息修改的发起者是HR系统，方式是在零时统一执行，接收方有10个系统。那么未改造前HR会调用接口：1000人*3处变动*10个系统=30000次。
改造后HR会调用接口：1000人*3处变动*1个系统=3000次。
与此同时PM系统要对这些人所对应的项目信息进行处理，并通知5个系统。假设平均每个人有2条项目信息需要处理。那么就是1000人*2处变动*5个系统=10000次调用。
改造后PM系统会调用：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系统已经可以轻松应对公司内部的各系统间的数据交互工作，由于将业务分发规则纳入到系统中，可以动态的进行数据流程管理，各业务系统各司其职，系统开发和运维人员可以把精力完全投入在自身系统当中。系统的安全性、实时性、有效性和可扩展性都得到了很大的提高。
技术就像围城：城外的人想进去，城里的人真会玩！