ESB和SOA到底是什么？

ESB和其相关缩写SOA，是困惑之源。ESB是企业服务总线的缩写，而SOA的意思是面向服务架构。 但这样解析并没有太多的内在含义。所以这里尽可能的提供一些更多的信息，而不是仅仅从企业的角度的来介绍ESB和SOA。

真相

假设一下你通过银行前端的应用登入银行，会发生什么呢？

  1. 会显示你的名字

  2. 会显示你的账号余额

  3. 会展示你的信用卡和借记卡

  4. 会列出你的共同基金
    会列出一些你可能感兴趣的，预先被计算好的，有吸引力收益的借贷产品

现在，很可能所有这些模块都来自于不同的系统和应用，通过各种接口把数据展示出来（是HTTP?JSON? AMQP?XML? SOAP? FTP?CSV?都不重要）

  1. 是来自在linux和Oracle的CRM系统

  2. 是来自z/OS大型机的COBOL系统

  3. 据说是来自大型机，但是他们的嘴巴很紧，不肯告诉你任何事情，只提供CSV文件。

  4. 来自跑在Windows的混合着PHP和Ruby

  5. 来自Postgresql，Python和Java，跑在Linux和Solaris的
    现在的问题是，你怎么让前端的应用跟1到5交互呢？ 直接通信吗？ 不，你不会这样做的，你不会让他们直接对话的。
    为了让在这样的复杂的环境中还能保证通过增加一些系统进行扩展，不能直接通信。这是基本原则。
    在下图，每条不同宽度或者样式的线表示了app之间的调用

大家要注意到，我们还没展示高优先级的进程呢。（比如应用1调用应用2 ，然后根据应用6的返回成功与否来决定调用应用3或者应用5；如果应用1允许的话，应用4晚点还可以抓取从应用2生产的数据。 -_-||| ）。大家还需要注意到，我们说的是服务，不是服务器。每个系统都可能跑在10台的物理机器上，那么至少有60个物理部件需要相互通信。
还有一些显而易见的问题：
怎么分离接口？你的计划怎么展示？如果每个应用由不同的组去管理，怎么去协调更新或者计划中的停机时间？如果生产商或者部门一半的开发者都已经离开不在现场了咋办？
如果你觉得，你解决6个应用没有问题，那么30个呢？

你可以处理400个吗？2000个怎么样？每个应用都有自己独特的生态系统，都需要用10个物理服务器或者设备跑在上面。所以，就好比有2万个移动的群体散落在大陆上，并且有着各自的技术的或者文化的边界。 所有这些群体彼此之间需要不断的，持续的交换信息，聊天，一刻也停不下来。
对这种情况，有个很好的名字，叫一团糟。

怎么去清理这一团糟的东西？

首先，你得诚实的承认，事情已经发展到不可收拾的地步了。这样子在找补救措施的时候，你会感觉到没有那么内疚。好吧，事情已经发生了，你不知道怎么办。但是，有个机会，这团糟东西可以被清理干净。
这意味着对IT系统要做一些结构上的变更。另外，我们还要回忆一下以前的经验，系统和应用很少用来被创建成到处推送数据，他们是为了支持业务，无论你的业务是什么东西：它可以是银行业务，声音记录，无线电设备或者其他任何东西。
一旦你有了这两个清晰的理解， 你可以开始考虑建设或者重新设计你的系统服务。
服务是有趣的，能重用的，并且原子性的，它能提供为其他有需要的应用提供用途，但是它不会用点对点的方式直接暴露出来。我们尽可能给它最短的有意义的定义。
如果一个给定的功能系统要做成服务，需要满足以下这三个条件：

  1. 有趣 I nteresting

  2. 可重用 R eusable

  3. 原子性 A tomic
    因此，如果满足这三个条件，他可以也应该以服务展示给其他系统，而不是直接相连。
    我们通过一些例子来讨论IRA方法

如果你在过去的50年或更长的时间里面，做过程序开发，你会很明显的理解，提供了一个服务，就类似于在代码中提供一个API接口。
不同的是，你不是在处理单系统的子模块，而是在处理整个分布式系统的某个层级。

使用SOA架构，用ESB提供服务

当你理解系统并不直接交换信息，理解什么是服务，那么现在你可以开始使用ESB了。

ESB的工作就是提供和调用集成系统的服务。使用了ESB，在大多情况下，每个系统和ESB之间，只需要定义一个访问方法，一个接口。如果这样，像上面的表一样，你有8个系统，就会有16个接口（1个方向1个）需要被创建、维护、管理和关注。
如果没有ESB，你就需要56个接口需要去思考和处理。（假设每个系统都需要跟其他系统对话）少了40个接口意味着少花时间和金钱。这就是你周末不用那么神经紧张的原因之一。
基于这个事实，你应该迫切地考虑需要引进ESB。
如果一个系统需要重写，改变所有者，生产商或者部门分拆，这个是ESB的工作去处理这个变更。其他的系统都甚至不需要周知，因为他们与ESB的接口不变。
当你开始每天使用IRA服务，你可以考虑组合他们。
还记得上面的“把客户所有信息给我”的服务吗？你最好不要去创建这样的服务。虽然有时候你不得不处理客户端应用需要集成和汇总这样的信息。
这将是ESB的责任，去选择原子的服务组合成混合服务，提供给某些客户端系统需要的特定的数据组合。
随着时间的推移，大家开始明白，不再有数据库表、文件、批处理、功能、程序或记录。系统是架设在有趣的、可重用的、原子性的，由ESB提供的服务应用的架构之上。人们不会再考虑应用和系统之间直接传递东西。他们只会考虑ESB作为统一的接入网关，提供可以使用的有趣服务。他们甚至不在了理会谁能够提供什么，他们的系统只会关注ESB，处理与ESB相关的事情。
这需要时间，耐心和合作，但是这个是可行的。

但是要注意

毁掉SOA概念的最好的方法就是，推出ESB，就期待所有的事情自己顺顺利利。虽然ESB是一个了不起的想法，但很不幸，只是简单的安装ESB不会解决你太多问题。最好的方法，你还是要打扫一下你的毛毯（整理一下你的架构）。
像下图一样，如果不打扫，即使用了ESB也得不到任何好处。

（如果如上图构建你的系统），那么你的it维护人员就会厌恶这个系统（ESB），管理层虽然一开始会容忍ESB，认为他作为一个新系统，总会出点小问题，但是后来它就会成为一个笑柄（系统难以维护）。“什么？这就是你的新杀手锏？哈哈！”。如果ESB不是作为你IT大计划中的重要组成部分来推动事情发展的，那么这种结果不可避免。

ESB是只为银行或者类似的应用服务的吗？那么？

完全不是。只要是需要多数据源和多访问方法合作去获得一个有趣结果的情况，都是一个好的选择。
例如，从热传感器读取信息，并且发布到几个通道去，比如email警告、iPhone应用。 这听起来就是一个很好的集成应用平台场景。周期性的查询和监控是否某个应用的所有实例都起来了没有，跑一个预配置的脚本去发送文字信息给管理员的应用场景听起来也不错。所有需要集成在一个干净的，定义好的环境，可能都是一个ESB服务的应用场景。但通常，判断某个东西是否真的匹配成一个服务则需要相关人员的经验。当然了， Zato support 后面的团队可以帮助到你。

但是我听说SOA全部都是关于XML，SOAP和Web服务的

是的，这是某些人希望你这样相信的。
如果你与某些使用BASE64编码的CSV文件，并且用SAML2保护的SOAP信息来发送的人或者生产商一起工作，其实挺能理解为什么你会有这样的想法。
XML，SOAP和web服务有他们各自的用途，但是就像其他东西一样，他们也可能被滥用。
SOA是一个关于干净的，可管理的架构。具体的某个服务用或者不用SOAP，其实是与SOA无关的。作为一个架构方法，即使你完全没有SOAP服务在上面，SOA依然是有效的。比如一个建筑师在设计一栋漂亮的建筑，他们真的跟油漆工人采用什么颜色的油漆来处理内饰没太大关系。
所以不是这样的。 SOA不是关于XML，SOAP和web服务的，这些都能在SOA里面使用，但不是SOA的主体。
我们鼓励你友好地去指引你被误导了的同事去阅读本文，使他们理解SOA的真正含义来源：https://www.icode9.com/content-4-895251.html

赞 (0)

相关推荐