ESB和SOA是什么？

2019独角兽企业重金招聘Python工程师标准>>>

ESB和SOA是什么？

ESB Enterprise Service Bus(企业服务总线)
SOA Service Oriented Architecture(面向服务架构)

真相

想像在你登录到你的银行账户页面时可以看到什么：

1. 显示你的名字
2. 账号余额
3. 你的信用卡和借记卡列表
4. 基金列表
5. 你可能感兴趣的优惠贷款

这些信息来自不同的系统和应用，每一条信息可能通过不同的接口取得，这些接口或数据可能是 (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV, 但这并不重要)：

1. 来自一个运行在Linux和Oracle上的CRM系统
2. 来自一个在z/OS上的COBOL系统
3. 有可能只是给你个CSV文件，数据从哪来的你完全不知
4. 来自一个部署在windows上的由PHP和Ruby混合实现的应用
5. 来自一个部署在 Linux和Solaris上的由PostgreSQL, Python和Java 实现的应用

现在的问题是：你怎么来做个前端程序支持这5种途径的数据？
参见下图，各应用间的数据交互及调用关系可以有多种形式（不同的连线）

更可怕的是上图还没有描述各调用间的依赖关系，如(App1调用App2，App3，App5前需要使用调用App6时成功后返回的数据，之后App4采集App2的数据需要得到App1的许可，等等，有点晕吧？)

每个应用运行在10台服务器上，那么至少有60个组件之间要交互.
怎样拆分接口？你怎样按计划上线？每个应用由不同的厂商，部门或团队管理时怎样协调更新或维护，而且是在最初的开发人员已经走了一半的情况下

即使你能处理好6个应用，那么30个应用呢？如下图：

增加到400个，2000个呢？每个应用可能需要运行在10台服务器或其它设备组成的系统环境中，这样就有20K台服务器，加上应用可以是跨行业的，可能使用了各种不同的技术实现，所有部件不停的交换消息，而且永远没有停止的时候。
这种场景有个好的名字，称为混乱(mess)

你怎样清理这种混乱局面

先得承认这种情况已经失去了控制，不必感到内疚，已经这样了，这里有个方法可能可以清理这种局面。

由IT部门着手处理这种局面，明确一点，不论是银行，录音，定位设备或其它业务，系统和应用只是围绕着数据来转。

你可能围绕着这些服务开始思考构建或重构你们的系统，一些服务在受关注的 ，可重用，原子性方面做得比较好，其它应用可以很好的使用，但是没有提供点对点的方式，这是最短的有意义的定义。

如果一个系统的功能满足这3点要求：

• I nteresting（受关注的）
• R eusable（可重用）
• A tomic（原子的）

那么作为给其它系统使用的一项服务已经做得非常好了，虽然不直接。

我们通过几个示例来讨论IRA:

Variable	Notes
环境	一个电力公司的CRM
功能	返回2012年第三季度自助服务门户 系统中活跃的客户列表
受关注吗？	非常有用，可能用来生成各种有用的报表和统计数据
可复用吗？	不行，虽然你可以设计成获取整年的数据，但到2018年你是不会需要查看这项数据了吧
原子的吗？	极有可能啊，如果还有其它季度类似的服务，总部需要这些数据来统计全年的情况
怎样设计成IRA?	*用起止时间代替某一季度. *允许接收一个参数表达某种应用，而不是把自助服务门户硬编码到系统中

Variable	Notes
环境	电子商务网站
功能	返回之前收集到的给定用户的所有信息
受关注吗？	有用，你总能从完整信息中挑出你真正需要的那部分
可复用吗？	可能吧，如果你想得到用户的所有信息，但多数情况下你只是想取其中的部分信息
原子的吗？	不是的，这个巨大的函数必然由几十个较小函数组成
怎样设计成IRA?	* 拆分得小一点，想一下怎么描述一个客户，每个客户有地址，联系方式，依赖的服务等等 *完整信息 放在ESB中实现

Variable	Notes
环境	任意CRM系统
功能	在建立一个账号时更新C_NAZ_AJ表的CUST_AR_ZN列
受关注吗？	这是CRM的内部函数，没有谁想要处理如此低级别的函数
可复用吗？	看上去是可以重用的，账号能够通过多种渠道建立
原子的吗？	似乎是的，只是简单的更新一个表里的一列
怎样设计成IRA?	不要试图将这个函数放到服务里，业务上不关心这个接口，没人想要知道系统内表和列的相关细节。所以即使满足 reusable 及atomic，你也不可以将其加入对外的服务中，该功能由CRM 内部负责，别想着有谁可以分担这个责任。

Variable	Notes
环境	一个移动电话公司
功能	在计费系统中给预付费卡充值
受关注吗？	很有用啊，每个人都会去使用，通过短信，语音服务中心，官方网站等等。
可复用吗？	该功能可以集成到各种高级别的流程中
原子的吗？	是的，从调用应用的角度看，由计费系统通过一系列不相关的步骤来实现。从业务角度看，是计费系统提供的一项服务
怎样设计成IRA?	已经是IRA了

如果你50年左右的编程经验，现在你能清晰精确的知道应该暴露给其它系统什么样的API.仅有的区别在于你不用处理单个系统的模块，你会站在多种不同的系统的高度来考虑问题。

在SOA,ESB上构建可用的服务

你明白了系统间不能直接交换信息以及每个服务是做什么的，那么你可以开始使用ESB构建了。

现在ESB的任务是展示以及调用服务，大多数情况下，在系统和ESB间只需要定义一个访问方法，一个接口。
如上图所示，你有8个系统，16个接口（方向不同）负责建立，维护，管理
如果不使用ESB你就需要（7*8）56个接口来处理（每个系统都要和其它系统交互）

更少的接口可以省时省钱。这个事实应该足够让你考虑引入ESB了吧。

如果一个系统经历过重写，更换开发团队，部门或厂商，引入ESB可以处理好这些变化。没有其它系统会注意到这些变化 ，因为其它系统只和ESB打交道。

当你在日常工作中就是基于IRA的，你可以开始思考整合

还记得上文提到的“给我你能给的这个客户的所有信息”吗？
这样做不好但你有时会有这种需求，引入ESB后的做法是在ESB中整合这些数据返回给客户。

随着时间的推移，整个公司开始明白没必要了解数据库中的表、文件、批处理、函数、路由或记录。只需要知道这是由ESB架构集中提供的符合IRA的服务。

不再有人思考应用或系统发送一些东西从一个到另一个。他们只要知道ESB作为统一访问网关提供了他们感兴趣的接口，他们不再困扰接口由谁提供，他们只需要和ESB打交道。

所有这一切需要时间，耐心和协调能力，最重要的是的确可行。

注意事项

一个最大的错误是以为引入SOA,ESB后所以问题会自己消失。想法很好，但只是简单的安装ESB并不会解决问题。

举个最好的例子，把脏东西扫到地毯下面，像下面的图这样，将什么问题也解决不了。

管理部门刚开始还能容忍ESB,因为这是个新事物，但慢慢的这会成为一个笑柄“这是新的银弹？哈哈哈”
如果ESB不做为项目计划中的一部分，这样的后果就不可避免。

ESB只适用于银行类行业吗？

不是的。只要是需要使用多数据源以及多个访问方法一起获取感兴趣的结果情况下ESB都是不错的选择。

例如，获取热传感器上最新的数据并通过几种不同的方式发布，如E-mail告警，通知IPhone app，就像一个聚合平台那样。

定期采集和监视关键应用的所有实例是否可用，如果当机了，除了发送短信给管理员还执行一个预先定义好的脚本。

所有东西都需要整合在清晰，定义良好的环境中，这对实现ESB很有用，这做起来很多时候是靠经验，但在Zato后的团队可以帮助你。

我听说的SOA都是些XML,SOAP和web services

是的，这是某些人给你的感觉。
如果你的工作是将CSV文件用BSAE64编码的然后通过安全的SAML2 SOAP消息取回来，这很容易理解，你可能之前就做过

XML,SOAP和web service有他们的用途，但也和其它东西一样，可能被滥用 。

SOA是一个干净的和可管理的架构。 一个服务使不使用SOAP都无关紧要。作为一个架构的方法，即使没有SOAP，SOA仍然有用。

如果一个设计师设计一座漂亮的建筑，在室内粉刷颜色选择上不会作出要求。

所以，你可以在SOA中使用XML,SOAP和web services这些技术，但这不是SOA的全部

建议你引导你的同事阅读这篇文档，让他们明白真实的SOA。

更多的内容

这一章涉及的内容是最基本的，仅在让你更清楚的明白ESB和SOA是什么。

下面列出没有覆盖的其它主题，包涵但不限于：

• 管理ESB时怎样获取相关支持
• 怎样培养SOA架构师及分析团队
• 在组织中引入典型的数据模型（CDM）
• 关键绩效指标（KPI），现在你有一套统一的提供跨系统服务的方法，你应该开始监视和评价真正交付给你的是什么
• 业务流程管理(BPM)，怎样及何时选择一个BPM平台去编排这些流程（回答-不用太早，等你先熟悉怎样去构建漂亮可敬的流程后再说）
• 当系统没有提供API时怎么做？例如，由ESB直接访问他们的数据库（回答-视情况而定，这里没有都适用的方法）

那么，Zato到底是什么？
Zato是一个由Python实现的ESB和应用服务器，能够用来构建中间件和后端系统。他是一款开源的商业软件，提供商业支持。Python是一种著名的编程语言，很容易使用并且很高效。

使用Python和Zato意味着你能更高效以及在麻烦的事情上花费更少的时间。

Zato由实用主用者开发，不是由其它系统打补丁而成，也不是由某厂商炒作ESB/SOA概念所作

事实上，Zato诞生于解决一些系统中紧急问题的实际经验，真的，在这之前Zato作者花费了大量时间处理恶劣环境中的问题，而现在可以对这些问题免疫了。

这样的环境造就了Zato以及其与其它类似解决方案不同的无与伦比的高效率和易用性。

转载于:https://my.oschina.net/u/618083/blog/196523