2、为什么须要ESB2-1、ESB与SOA2-1-1、SOA
SOA（Service-Oriented Architecture）中文全称“面向做事的架构”。放在当下的技能环境（2015/2016年），SOA并不是一个新的观点。但是在SOA刚盛行起来的2000年初（SOA的观点最初由Gartner Group在1996年提出），这个架构模型算就是非常盛行了。本小节笔者试图利用最平实的措辞向各位读者先容SOA观点中的几个核心内容。
首先SOA是一种架构模式思想，紧张环绕多个“做事”如何进行集成以达到某种目的进行谈论。那么SOA中所定义做事是什么意思呢？在业务系统中被发布出来供用户利用，能够完成一个完全业务过程的功能，便是做事。
做事着眼于完全的业务
从以上对“做事”的定义可以看出，做事的定义工具是业务系统中的完全业务功能。例如电商系统中“确认订单”这个功能便是一个做事、计费系统中“当月用度结算”功能便是一个做事；但是CRM系统中，须要完成“工单天生”功能所进行的“用户登录”动作就不是做事的定义，由于利用者进行“用户登录”是为了完成“工单天生”功能的权限验证步骤，并不是为了“登录”而登录。
做事的粒度虽然相对粗放，但却可控，目标是重用
接着谈论，“用户登录”这个功能在某些情形下也可以知足“做事”的定义：当用户中央系统为其他所有业务系统统一供应的“登录”做事被公布出来时。做事粒度的拆分完备依据业务系统中业务过程进行定义和剖析，以是做事的粒度都相对粗放。就像上一段笔墨中所举例的“用度结算”做事那样：可能完成“用度结算”功能，在计费系统内部须要完成 用户身份确认->上月用度查询->套餐清单查询->用度明细天生 这几个过程。但是这些每一个过程都不会有任何其它业务系统进行单独利用，也便是说是否单独公布这些处理过程对付其他业务系统来说没有任何意义。
如果在后续的业务变更/业务重编时，业务设计职员创造某一个业务系统须要单独利用计费系统的“上月用度查询”功能，这时就须要计费系统将这个功能作为一个独立的做事向第三方业务系统公布出来。这时，这个功能就知足了“做事”的定义。
集成的目的是形成一个新的做事
对企业内部（或者企业间）的业务做事进行集成，被集成的业务做事称之为原子做事，集成的目的是重用这些原子做事形成一个新的做事。这样担保了技能团队/业务团队能以最小的代价，最高的效率利用既有做事，但同时也对实现SOA架构思想的软件提出了更高的哀求。
SOA需担保屏蔽细节
利用SOA架构思想构建多个业务系统的集成关系，须要担保每个业务系统屏蔽细节。这些细节包括技能细节和业务细节。从技能细节层面看，无论业务系统利用哪种开拓措辞、哪种对外传输协议、哪种格式都可以利用SOA进行集成，并且能够在SOA架构的实现软件上完身分歧传输协议的转换和不同格式的转换；从业务细节层面看，SOA须要屏蔽业务系统的功能步骤细节。也便是说第三方系统只须要知道调用某一个做事就可以达到业务目的，至于供应做事的业务系统如何实现业务过程则无需关心。
SOA让各业务系统保持疏松
SOA架构模型为多个业务系统进行疏松集成供应了一个良好的思路：通过屏蔽各业务系统技能细节和业务细节，兼容各业务系统的不同传输协议和不同格式，可以让通过SOA进行业务集成的各个业务系统保持低耦合状态。这是由于所有协议和格式都处于开放状态，业务集成时各业务系统不须要单独进行额外的转换事情，乃至不须要为基于SOA的业务集成进行任何额外事情，也无须知道对方系统的存在。
如果您所在企业或者客户的业务系统还没有达到一个较高的繁芜等级，则不建议立即利用SOA架构模型进行业务集成。由于目前SOA架构模型的各种实现本身就具有一定的繁芜性。
2-1-2、ESBESB（Enterprise Service Bus）全名：企业做事总线，是SOA架构思想的一种实现思路。既然是一种思路，就有这一实现思路的详细考虑，以及须要办理问题的实际环境：
企业的信息化培植一样平常经历很永劫光的发展，少则5、6年多则10几年。以是我们看到某大型企业的信息系统最可能的情形是：存在着多个业务系统，乃至各业务系统卖力的功能职责还存在重叠。这些系统采取不同时期的编程措辞、编程框架、通讯协议、格式和存储方案。
例如，计费系统可能采取C++ 进行编写，对外调用功能采取CORBA；年久的CRM系统采取Delphi进行编写，同样利用CORBA发布调用功能，并且最近两年该企业刚对CRM系统利用C#措辞进行了一次升级，但是由于数据存储层的设计缘故原由，并没有将老系统的所有数据割接到新系统，以是目前两套CRM系统都在利用；最新开拓的财务联动系统，采取JAVA措辞开拓，并且不再采取运用程序窗口，改为利用浏览器进行页面展示和用户操作。这个财务联动系统多数对外的做事采取HTTP协议对外公布，还有一部分做事采取Thrift RPC对外公布……
由此可见，由于各种可见的和不可见的缘故原由，企业信息化系统的培植历史和现实存在每每纷繁繁芜。如果这些系统须要进行做事集成，但是又没有一个成熟稳定、兼随意马虎用的中间层进行折衷，那么要达到以上的调用哀求基本上不可能的（纵然实现也相称难以掩护和扩展）。
那么为了知足SOA架构思想的设计要点，达到既定的事情目标，ESB总线技能至少须要帮助这些业务系统完成以下事情：
无论业务系统向外部公布的做事利用哪种调用协议，都可以通过ESB技能进行兼容性转换。例如A业务系统的做事只接管Web Service SOAP形式的调用，B业务系统的做事却可以利用Thrift RPC进行调用（不必为了调用A业务系统而专门去适应A业务系统的协议）。在基于ESB做事的中间层帮助实现两种协议的转换。
无论调用协议携带哪一种描述格式，通过ESB中间层也可以实现相互转换。ESB中间层该当支持将JSON格式的信息描述转换成目标业务系统能够识别的XML格式，或者将XML描述格式转换成纯文本格式，又或者实现两种不同构造的XML格式的相互转换，等等……
既然ESB要对原子做事进行集成，考虑的问题就比较多了。首先，业务系统供应的做事可能会以一定周期发生变革，例如周期性的升级；失落控的业务系统乃至可能呈现完备无预兆无规律的做事变革，例如突发性数据割接导致做事接口变动。那么ESB的实现软件中该当有一套功能，能够担保在这样的情形下集成做事依然能够事情。其次，并不是业务系统所供应的所有做事都可以在ESB中进行集成，也并不是所有的做事都能被任何路由规则所编排。ESB该当有一套完全的功能来担保做事集成的安全性和权限。
作为被集成的业务系统，ESB中如何集成它供应的原子做事，前者是不须要关心的，
为了将多个做事通过ESB技能进行集成形成一个新的做事，ESB技能必须能够进行做事编排。做事编排的浸染便是明确原子做事实行的先后顺序、判断原子做事实行的条件、确保集成后的新做事能够按照业务设计者的哀求正常事情。下图示例了新做事“工单派发”通过多个业务系统供应的原子做事，按照设置的实行条件在ESB总线上进行事情的过程：
实际上ESB技能和本专题之前讲过的做事管理技能在架构层面属同一层：都是对SOA思想的实现思路。但是两者的运用处景和侧重点完备不一样。
2-2、ESB是EAI的进化ESB企业做事总线技能是在SOA架构之后涌现的，在这之前为了集成多个别系而利用最多的技能思路是EAI（Enterprise Application Integration）：企业运用集成。EAI技能并没有一个统一的标准，而是对不同企业集成业务系统手段的统一称呼。
2-2-1、EAI的特色
从上图可以看出，EAI紧张的浸染还是完成各中格式的转换。由于EAI紧张的利用场景是在上世纪八九十年代，以是如果从现在往回看EAI所支持的传输协议也是很有限的（不过肯定还是基于7层/5层网络协议的）。不过，在SOA架构思想涌现之前，EAI技能确实为企业实现业务系统集成供应了一个可行的思路。
须要把稳的是，EAI技能并不是SOA架构思想的一种实现。它涌如今SOA架构思想之前，最主要的是它短缺SOA的基本要素——着眼业务做事，粒度粗放但却可控：由于EAI中并没有流程编排的功能，以是这些原子做事并不能有机的结合在一起，形成新的做事，也无法在EAI中重新梳理业务过程，以便哀求原子做事进行相应的粒度拆分。
2-2-2、哪些特色得到了进化
上一小节已经提到，由于EAI技能涌现的韶光比较早，在那个时候基本上还没有太多行业标准的传输协议和格式，利用最多的便是XML格式，还有半构造化的文本数据。以是，在公司内部实现EAI技能时，一样平常不会考虑太多的行业标准，利用公司内部自定制的传输协议和格式就能够搞定。虽然这样做也有一定的好处，便是公司内部的业务团队都清楚这些自定制的格式代表的业务意义，降落了一定的沟通本钱。但这样做的问题也显而易见，如果日后须要和兄弟公司的业务系统进行集成，那么之前被节约的事情韶光又会被摧残浪费蹂躏。
成熟的ESB产品中就不会这样考虑问题，一样平常采取开放性的传输协议和格式。例如利用HTTP传输协议携带查询要求、利用FTP传输协议携带上传的文件信息；采取XMPP格式描述IM即时通讯内容，采取MQTT格式描述物联网设备采集内容、利用AMQP格式描述MQ的内容。
EAI没有流程编排的硬性哀求，也便是说他只面向数据转换过程，并不面向业务做事。以是各位读者可以这样看待这个问题：SOA架构思想涌现后，伟大的技能屌丝团队立马创造了面向做事的观点对EAI软件的培植性浸染，废寝忘食的为各种业已运行的EAI软件加入了各种面向做事的要素，最关键的便是加入了做事编排等面向做事的管理功能。实际上，以上情形便是现实中最真实的情形。
从EAI到ESB实际上是业务管理方法上的优化，但就像上文中提到的那样，并不是所有企业都适宜利用基于SOA架构思想的ESB技能。目前大部分企业的对内部业务系统的集成手段还是更贴切于EAI技能的定义，这是由于这些企业的业务系统还没有达到较高的繁芜度（涌现最多的情形便是他们只有一套必须的财务系统）。
以是，EAI并不是淘汰品，ESB也不是什么“跨时期”的伟大发明。后者便是前者不断完善的产物，把两者之间的关系说成“根本版”和“升级版”更为贴切。一些网络文章一味贬低EAI提升ESB的地位，这是禁绝确的，有的企业或者平台，还没有繁芜到必须利用ESB，那就可以不该用ESB技能。以是只有适宜自己架构才是空想的架构。如果是某个ESB厂商的软文，目的是什么就仁者见仁智者见智了。
2-3、ESB与循环依赖
ESB技能担保了各个业务做事的低耦合性，间接避免了各业务系统在集成时技能团队故意无意制造的做事循环依赖问题。
2-3-1、什么是循环依赖
首先我们要讲清楚什么是循环依赖，以及循环依赖的在程序设计层面、软件产品设计层面、顶层架构设计层面上可能涌现的场景。从观点模型上讲，只要两个或多个元素产生相互依赖关系，就可以算作产生了循环依赖：
上图是两个依赖关系精确的示例：A元素正常事情依赖于B元素的正常事情，或者A元素的正常事情依赖于B、C、D元素的正常事情。这里的A、B、C、D四个元素可以指代四段代码，也可以指代一个业务系统中四个功能模块，还可以指代顶层架构设计中的4个独立事情的业务系统。
循环依赖在逻辑层面上是一个有向循环图。上图中展示了两个缺点的依赖关系实例：A元素正常事情依赖于B元素正常事情的同时，B元素正常事情又依赖于A元素的正常事情。那么究竟哪个元素能够首先正常事情起来呢（先有鸡还是先有蛋）？右侧图展示了三个元素的循环依赖，A元素依赖于C元素，C元素依赖于D元素，D元素又依赖于A元素。那么A、C、D三个元素究竟哪一个元素才是底层的根本元素呢？
代码层面的循环依赖是开拓职员最随意马虎涌现的编码缺点，不过有的时候也不能全怪开拓职员，毕竟业务设计者从需求理解阶段可能就涌现了问题。以下示例了代码层面的循环依赖：
/ 此类依赖于BusinessB @author yinwenjie /public class BusinessA { private BusinessB bb; public BusinessA(BusinessB bb) { this.bb = bb; } ......}/ 此类依赖于BusinessC @author yinwenjie /public class BusinessB { private BusinessC bc; public BusinessB(BusinessC bc) { this.bc = bc; } ......}/ 此类依赖于BusinessA @author yinwenjie /public class BusinessC { private BusinessA ac; public BusinessC(BusinessA ac) { this.ac = ac; } ...... // 接下来我们试图实例化BusinessA... public static void main(String[] args) { // 怎么实例化BusinessA呢？ // new BusinessA(new BusinessB(new BusinessC(new BusinessA(！
程序员已经发疯！
)))) }}
实际上按照这样的引用构造和布局函数哀求，实例化BusinessA这件事情是永久无法完成的。
业务系统的功能间也可能涌现循环依赖。相对付代码层面的循环依赖，功能模块层面的循环依赖更能够影响一款业务系统的设计质量。笔者曾参与的一款软件，客户方曾经提出过这样的一个业务需求：
货运系统中在创建新的“发车单”时，必须选择空闲的司机和空闲的货车（当然货车类型是要判断的）。空闲的司机和空闲货车短缺任何一样都不能完成“发车单”的创建。但同时为了记录某辆货车上一次对应的“发车单”，客户哀求只能在创建新的发车单后，货车才能解除之前的“发车单”绑定关系，变成“空闲货车”。
那么问题来了，如果只有完成新的“发车单”创建后，货车才能解除和之前“发车单”的绑定关系，那么新创建“发车单”时，“空闲的货车”从哪里来呢？实际上客户方不懂技能，是我们在需求调研阶段碰着的算一个问题的问题，但关键看需求职员从哪个方面动手向用户阐明勾引用户对需求逻辑进行剖析。不一定用技能措辞直接见告用户，他的需求在技能层面上不符合逻辑。
多个业务系统在进行集成时，他们也可能会涌现循环依赖。特殊是参与集成的业务系统越多，这种循环依赖的情形就越随意马虎涌现：
在系统数量还没有达到一定数量时（常日来说这个阀值为4），系统间的循环依赖最可能是由业务职员/技能职员无意造成。这时，系统间的依赖关系还处于一个可控级别，纵然涌现系统间循环依赖的情形，技能团队/业务团队也可以快速进行纠正。但是，当参与集成的业务系统数量超过可掌握的阀值数量后，这个检讨和纠正事情就不再是人工可及的范围了。如下图所示的5个别系进行集成时，很随意马虎涌现系统间循环依赖的情形：
2-3-3、避免循环依赖
依赖颠倒原则可以帮助预防代码层面和功能模块层面的循环依赖。顶层架构层面的循环依赖问题，也可以遵照这个原则进行设计来避免。依赖颠倒原则在很多书本、网络资料上都有很详细的先容。基本上这个原则是在说两个点：高层次模块不应该依赖于低层次模块，模块的实现都该当依赖于抽象（接口），而抽象（接口）能够屏蔽功能设计上的细节。
如果您卖力的产品是遗留产品。在经由多个设计职员更替后，产品内部设计或多或少涌现了一些循环依赖问题，这时该怎么办？您要做的首先是检讨产品的哪些模块涌现了循环依赖，再思考修正方法。目前市情上有很多这样的工具，可以帮助您检讨代码层面和系统模块层面的依赖关系是否良好，这里笔者推举SonarQube。以下截图是笔者经历过的一个项目中，某个子模块通过SonarQube进行检测的结果：
呵呵，V0.0.9版本，看来还有多少个类的繁芜度偏高，解释模块中利用的设计模式还有改进空间。好吧，这个子系统只是开了一个头，目前已经发展到V0.5.3的版本号，代码行数也快靠近5万行了。不过作为这个子模块的作者之一，本人自认为包耦合度一贯掌握得很好，直到现在也没有涌现包循环依赖的情形。
在上一小节“功能层面的循环依赖”中我们举了一个司机-货车-发车单三个元素在业务功能层面的循环依赖问题。现在我们接着这个问题连续谈论。客户之以是要在新的“发车单”创建后，才解除货车和历史“发车单”的绑定关系，是由于用户担心软件失落去对历史“发车单”的跟踪能力，末了无法统计车辆利用率或者司机绩效情形。但实际上，客户完备无需担心涌现这样的情形，理解客户的真实想法后，需求职员就能勾引客户开辟一个新的日志模块，这个日志模块处于全体业务系统设计的更底层，专门跟踪各种历史行为，车辆的、职员的、财务的、货品的，都行：
我们可以用这种剥离循环依赖元素中底层能力的办法，办理循环依赖问题。这种办理思路不但适用于业务系统功能间的解耦，同样适用于代码级别或者系统顶层架构级别的解耦。
ESB为各个业务系统的集成供应了一个空想的中间层/根本层。通过从中间层/根本层抽离的底层能力，我们将所有业务系统的集成事情交由ESB完成：
把稳：虽然ESB承担了原来在系统内部完成的业务集成事情。但是根据依赖颠倒设计原则，ESB也只是依赖于各业务系统注册在ESB总线上的调用接口，业务系统中功能的详细实现对付ESB来说是透明的。
========================================== （接下文）
