关于SOA,ESB&EAI的痴话 博客分类: 基础建设 企业应用
献给每天把这三个词放在嘴边的二姐。
一些个人见解及看法,为了可以让零基础的二姐看懂,以下会有大段对技术人员不适的文字描述出现,请未婚人士移步。
名词定义
SOA
Service-Oriented Architecture,面向服务架构。
EAI
EAI(Enterprise Application Integration),企业应用集成
ESB
Enterprise Service Bus,即企业服务总线
这些是什么
孤岛一个又一个
应用程序的数量就和孩子的年龄一样,在比较小的时候,让人喜爱。但是一旦变大,厌烦的不得了。
举个例子,如使用者是一家银行汇款部门,那么维持正常工作的最小系统起码有,本币汇款系统,外币汇款系统,行内的会计系统,员工人事系统。
假设按照传统的思路做法,肯定是一个挨着一个做。拿本外币而言。但是可以说在最早的时代由于网络编程根本没有现在这么简单,这些系统往往是像太平洋里的一个个小岛,互相孤立。(信息孤岛的概念)。
就只拿会计流程来说,如果没有系统级别的连接,那么就会需要在A系统做点什么,然后靠人工再去B系统继续完成工作。说到这里似乎应该可以明白为什么90年代的电子打印凭证都会有2-4联,就是因为贷记可能是在一个系统能做,借记是在另外一个系统做。同理也可以解释CCEX是用来干嘛的。通俗点,为了连接两个小岛,居民们只好游过去。
刚开始岛不多,游泳可以强身健体。但是岛多了就不好玩了。业务量的增长和运营人员的增长不应该是线性的。如果这样科技就毫无价值了。
所以人民觉得需要造桥。
造桥的时代
慢慢让系统之间沟通即让两座小岛连接在一起的造桥技术开始有了,人们开始开始尝试不要游泳用使用桥梁来连接各个孤岛。慢慢的这个汇款系统可以直接通过一个按钮先做借记再做贷记,还保证比人做的更有效率更准确更安全。
体验到快感之后,人们就开始不断的给给各个系统搭桥,然后大家惊奇的发现,由桥梁在小岛间编织出了一张蜘蛛网。并且更加恐怖的是,有效桥2米宽,有些桥4米宽。当你开着卡车时你根本不知道走哪座桥才安全到达目的地,这样造成的结果就是又造了一座卡车开的过去的桥……
统一的造桥标准
后来民间组织了一个叫“桥路协会”的组织,他们制定了一套桥梁的标准(系统之间沟通的标准)。好比星巴克天天喊“我们卖的不是咖啡,是文化”一样,这个协会打着“我们卖的不是桥,是回家的服务”的旗号,把这个标准成为SOA。即无论你怎么使用材料造桥,只要你符合在统一的宽度,高度"就可以。
SOA就是一种设计的模型想法,它的最终目的就是减少在系统间重复沟通(同时存在A->C,A->B,B->C这样的链路),减少维护和在这体系中安插新组建的想法。可以说有点淡化各个子系统,强化整体母系统的趋势。认为子系统只是向母系统提供一种特定的“服务”。同时如果按照系统新的服务进来,也不会对现的体系造成太大的影响。
SOA只是一个又被包装的老感念,诚然现在主流的SOA的实现都是JAVA和C#通过WEB实现的,但是SOA肯定不只是WEB实现,因为在没有Java的年代,Cobra也是一种SOA思想的体现即与实现平台、语言无关。有统计的接口规范。
立交桥
古代的桥在同一个平面内最多存在一座桥。但是科技发达后,立交桥就被发明出来了。EAI/ESB的概念就在这个时代被提了出来。
这里要提一下EAI,我一直认为EAI的核心是消息转换、消息派发。
经典的EAI的拓扑有两种
一种是HUB模式,即所有的消息都集中到HUB在转发至目的地。
另一种是总线模式,所有应用平等的接入在骨干上进行点对点的通讯。
似乎这几年的趋势是在往总线拓扑发展。但是与SOA的核心价值相同的,其目的也是想找出一套统一的沟通模型让不同的结构、平台、语言的应用系统可以更好的利用现有资源,而不是重新再造一套出来。节约开发和维护成本。重点就在“集成”上。
再说说ESB,这个真是一个新名词。
ESB好似被新一代SOA概念一起提出来的。但是其核心价值不外乎“更容易、便宜地进行系统集成”。我不正确的解读ESB是一种为了SOA方案产生的平台产品。
那些又是什么
松耦合,紧耦合
举个例子,为了达到一个目的总有许多种解决方案,比如穿裤子和袜子。
有一个方案A是穿连裤袜,另一个方案B是穿袜子和裤子。
相对方案B来说,A就是紧耦合,因为你想换袜子必须把裤子一起换了。
但是A的优点也很明显,价格便宜,一次实施。
因为方案B你还要考虑是不是黑色的裤子是不是不能穿白色袜子的问题……