假设你通过银行前端应用登录银行会发生什么？

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接口。
不同之处在于，是在处理单个系统的子模块，而是在处理整个分布式系统的某个层次。

当您理解系统不直接交换信息和服务时，您现在可以开始使用它ESB了。

ESB工作是提供和调用集成系统服务。ESB，在大多数情况下，每个系统和ESB在此之间，只需定义一个访问方法和一个接口。如果你有8个系统，就会有16个接口维护、管理和个)需要创建、维护、管理和关注。
如果没有ESB，你需要56个接口来思考和处理。（假设每个系统都需要与其他系统交谈）少40个接口意味着少花时间和金钱。这就是为什么你在周末不必那么紧张。
基于这个事实，你应该迫切考虑需要介绍ESB。
如果一个系统需要重写，改变所有者、制造商或部门的分离，这是ESB处理这个变化的工作。其他系统甚至不需要知道，因为它们与ESB接口不变。
当你开始每天使用它时IRA您可以考虑组合服务。
还记得上面的给我所有的客户信息服务吗？你最好不要创建这样的服务。虽然有时你必须处理客户端应用程序需要集成和总结这些信息。
这将是ESB选择原子服务组合成混合服务，为某些客户端系统提供特定的数据组合。
随着时间的推移，我们开始明白数据库表、文件、批处理、功能、程序或记录不再存在。该系统架设在有趣、可重用、原子性的基础上ESB在提供供的服务应用架构。人们不再考虑应用程序和系统之间的直接传输。他们只考虑ESB提供有趣的服务作为统一的接入网关。他们甚至忽略了谁能提供什么，他们的系统只关注ESB，处理与ESB相关事项。
耐心和合作需要时间，但这是可行的。

毁掉SOA概念的最佳方法是引入它ESB，期待一切顺利。ESB这是一个伟大的想法，但不幸的是，这只是一个简单的安装ESB不要解决太多的问题。最好的办法是打扫你的毯子（整理你的结构）。
如下图所示，如果不清洗，即使使用ESB也得不到任何好处。

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

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

这篇文章主要覆盖非常基础的知识，但是能够让你明白ESB和SOA应该是怎么样的，以及如果要获得成功需要做什么。
这篇文章还不包含（不限于）以下的内容：
怎么为ESB获得管理层的支持
怎么组织SOA架构师和分析团队
在组织中引入规范数据模型
关键业绩指标-你现在系统中有统一和通用的方法来提供服务，你应该监控和评估你的系统你收到了什么
业务流程管理–什么时候以及怎么样引入业务流程管理平台去协调各个服务（别太快，先熟悉怎么搭建优秀的，优雅的服务）
如果没有API的系统，应该怎么做？比如ESB应该直接访问他们的数据库吗？（看情况，没有黄金法则）
所以，Zato确切来说是什么东西？
Zato 是ESB，并且服务都是用Python写的。Zato它可以用来构建中间件和后端系统。它是开源软件，有商业公司和社区支持。并且 Zato使用了Python，这个因为他的易用性和生产效率高而闻名的编程语言。使用Python和Zato意味着你有更高的生产效率，少花一些时间在麻烦事上。
Zato 是实用主义者写给实用主义者的软件。 他并不是那些在炒作ESB/SOA的生产商快速胡拼乱凑出来的系统。事实上，Zato来自于对上述一团糟的系统的救火经验。Zato的作者花了太多的时间去处理这些灾难性的的环境，才使他们不至于陷入困境。
因此，Zato就是这样被设计出来的，它是应时而生的解决方案。这也是为什么跟Zato类似的解决方案能提供高效的生产力和无与伦比的易用性的原因。

参考链接：https://zato.io/docs/intro/esb-soa-cn.html
说了这么多其实是为了推销自家的ESB产品Zato😂。