当我们意识到召开下一次会议很无聊时，我们决定将其变成更具动感的东西。 即，在决斗中，在两种集成方法（ESB和分布式）之间的决斗中，其荣誉受到重量级专家的捍卫。 在这篇文章中，我们将告诉您战斗如何进行并找出获胜者。
关于格式的几句话
我们的公司架构师
Alexander Trekhlebov代表中央总线发言。 对于权力下放-Promsvyazbank创新与有前途技术中心的负责人Andrey Trushkin。 他们轮流发表有关其技术的报告，并回答了各种挑衅性的问题，但不是很好。 就是这样。
为什么ESB很酷？
首先，您应该将其放在知识中并告诉一切一切是如何开始的。 许多人可能还记得，在每个阶段的最初阶段，所有事件都是在没有任何集成的情况下发生的，这是因为每个系统都与其他系统进行通信并进行集成测试。
因此，如果一个人辞职或其他事情发生在他身上，那么没人会知道这一切将如何运作。 每台计算机都与某个服务器交互。 什么协议，什么样的交互作用？ 只有在系统中工作的人才知道这一切。
然后是集成总线。 看起来不仅如此，还因为它收集了主要的交互协议和交互方法，因此可能不会强迫系统描述任何特定的事物。 她可以使用内部算法与他们进行交流。
此外，事实证明，它们最经常通过队列或REST与总线进行通信。
但是，随着时间的流逝，在许多情况下不再需要总线和REST。 但这看起来像是回滚，重要的问题又挂了：
- 如果没有轮胎，如何协调。 这将在哪里发生？
- 如何处理数据和协议格式？
此外，集中式系统中的性能要比分布式系统中的性能好得多。 您可以指望速度，数量和可用性。 所有这一切都是因为这是一个特定团队为之服务的系统。
这个系统有多脆弱？ 如果一台计算机被黑客入侵会怎样？总会有冗余和集中化。 万一发生故障，系统将正常工作。
谁负责轮胎？ 您的团队或第三方开发人员？在内部团队中，我们提供运营服务，提供可靠性和监控。 如果某事不起作用，我们知道在哪里找。 有一个问题：“在这种情况下，是否可以信任供应商和第三方团队？” 这里需要良好的监控。 因为无论如何，质量是内部团队的责任。
随着总线的增长，服务不会建立连接。 您会使用发行版更改服务还是什么？ 与敏捷怎么办？在这里，我们谈到了基本问题。
集成不是应用程序。 它曾经是一部分，但现在不是。 集成开发不是应用程序开发。 它是集成交互的开发，或者是单独项目（但不是专门针对一个应用程序）的框架内的开发。
您的敏捷问题是可以理解的。 当我们制作一个单独的系统连接到侧面某处的总线时，将使用此模型。 当我在另一家银行工作时，就有这样的系统：一个月的测试，一个月的开发。 结果，所有集成交互都在总线上快速实现。 因为开发系统非常复杂和简单，所以其速度甚至比分析师描述的还要快。 在最终系统的开发中使用了敏捷。
团队需要多长时间寻找所需的服务，以及在哪里寻找？每个人都梦想着有一张世界地图，所有主要商业区域都分布在这些地图上。 而且它甚至是部分实现的。 分析师去了那里，并开始在大陆上徘徊，过了一段时间，他发现了需要的互动。 此外，如果一切都非常合适，他会简单地使用它。 如果没有，请在传统知识中说明他需要什么补充。 拥有这样的选择将是很棒的选择，但是到目前为止，不那么方便的系统是很重要的，它需要更多的时间和精力来使用它们。
也许Service Mesh更凉爽？
首先，在3-4年中确实发生了很多变化。 但是到底发生了什么？ 所有讲话者都经常重复这种平庸的平庸，我们也不能通过这种平庸：世界正在变化。
对变化速度的要求越来越高。 同时，可靠性要求，安全要求不会在任何地方消失，而负载要求只会增加。 正如我们所看到的，每个人都在试图占领市场份额，这不可避免地导致企业系统负担增加，并因此增加了集成负担。
的确，ESB曾经非常酷，在应用程序分散化，不同应用程序之间的逻辑分配，用于将应用程序相互集成的统一设备方面，曾作为技术实施的模板。 我们只说有条件地统一。
现在，让我们假设公司中没有20个系统-毕竟，它正在寻求迁移到被称为流行语“微服务”的架构。 什么是微服务？ 有很多定义，其中的一种由Martin Fowler定期使用：中级开发人员可以在一次冲刺中开发这项服务。 想象一下，在一家大公司中将有多少种这样的服务。 例如，Netflix估计其微服务的数量为800-900。 原则上，在一家寻求建立合作伙伴外部生态系统的公司中，这些服务可以超过一千。 但是从长远来看，这些服务中的每一个都承受着巨大的负担，应该独立开发。
公共汽车呢？ 如果总线仍然是它们之间的共同点，那么事实证明它将成为瓶颈并延迟服务的开发。 不仅因为她正在等待这些服务，还因为她正在由拥有相同技术和技能的人组成一个独立的团队。
现在，让我们想象：数十个产品团队正在与我们合作并与其合作。 他们每个人都有几项服务。 公交车由两支车队驱动。 当然，这些具有很高概率的团队将无法以必要的速度和质量水平发展这种高度集成。
随之而来的问题是：“我们如何在不失去可访问性，安全性等的情况下确保相同的速度？” 答案很简单：“让这些服务直接交互，而无需明确的中介。”
然后提出下一个重要问题：“服务如何相互了解？” 答案也很简单：您可以想出一个系统，服务可以使用该系统报告自己。 也就是说，在开发服务时，它将在某个注册表中独立发布有关自身的信息。 基于这些信息，所有服务都将能够开始与他进行交互。
因此，形成了服务“网格”的概念-最初被称为
“服务网格” 。 作为服务之间的一种中间集成级别，它提供了这种集成，就好像是一个云解决方案。
大型公司现在正在尝试并行解决开发速度问题-为此找到一种通用的，分布式的且通常是嵌入式的解决方案。 在这种情况下，每个服务都使用一组特定的现成库，以便在部署时自动将信息发布到注册表。
通常，仍然会出现一个问题：“但是，与规范数据模型有什么关系呢？规范数据模型通常是ESB的来源，ESB在其中投入了大量的金钱和精力来实施和维护它？” 毕竟，她是标准的模特。 这是一个反问题：“这给我们带来了什么好处？ 难道正是这一点延迟了我们的发展吗？” 确实，在开发服务时，该模型会不断扩展。 永远会有新的挑战。
坦率地说，
添加新设备，组织交互等的成本通常比维护最新的ESB数据模型的成本低得多 。
同样，分散式集成在很大程度上确保了相同的高可用性。 每个微服务都独立于其他微服务，包括其他微服务，但严格取决于其上的外部负载。 与集成并行部署的技术也可以独立实现。
有时在现代条件下使用相当沉重的ESB毫无意义，甚至反之亦然，这会降低解决方案的质量。 无服务器技术的应用，即不适应所创建解决方案的临时需求的基础架构，已经处于边缘，但是以正确的形式提供了特定服务。 现在看起来好像很遥远，但是世界已经在变化，就像已经说过的那样，很快。
许多软件供应商在集成解决方案方面都采用这种方式。 已经有实质上实现服务网格概念的框架（相同的Linkerd或Istio）。 作为托管大量网络代理和服务网格集成服务的一部分，已经发生了同样的事情。 与服务网格和容器编排系统（如Kubernetes）有很多共同点。
是否可以基于ESB构建Distributed？ 也就是说，是否可以从一个系统中制作另一个？ 如果是这样，这些争议的意义何在？黑格尔和他的“否定否定”在这里浮现在脑海。 当一个想法在更高的历史水平上重演时。 在我看来，彼此之间是可能的。 另一个问题是我们将如何处理。 实际上，从本质上讲，微服务的概念及其实现在许多方面都与最初的集成概念相似：微服务之间，每个微服务之间的交互。
如果我们从ESB出发，是否可以根据网格原理进行集成？ 实际上，现在是IBM的Red Hat已经遵循了相同的原则。 只需看看他们对集成堆栈和灵活集成（Agile Integration）概念的理解即可。 它们提供了大量的集成代理，而这些代理不会因逻辑而过载。 最重要的是透明度和所有新进入者都需要的服务知识。
您的银行是否了解，如果ESB继续在其中投入大量预算，它的生存期就会过去？坦白说，预算问题是一个商业秘密。 至于使用的方法，目前我们正在开发两种方法的并行。 在Promsvyazbank中，确实有许多与总线相关的系统。 它们仍通过总线集成。 但是，就我们而言，我们理解ESB是一种没有希望的方法，并且无需使用总线就可以投资于分布式集成，效率更高。 这是我们现在的战略重点。
分布式系统中用于业务监视的位置在哪里？在分散式集成中，大量服务的存在并不排除业务监控的存在。 所有这些都可以在相应框架的层次上进行阐述。 因此，该监视可以将信息合并到负责数据的某个存储中。 在此对这些数据进行分析，并准备一份汇总报告。
您如何看待向分散式集成过渡的计划？向分散集成的过渡在向新架构原则过渡的背景下考虑是有意义的。 这是一个复杂的过渡，无法一次完成。 是的，您可以尝试以“大爆炸”的形式保存它，但是此方案选项会带来严重的风险。 更具逻辑性的选择是创建与现有电路并行的新电路，并在创建时（以迭代模式）在其中建立新产品。 随着新架构的发展，可以将经受了时间考验的当前IT领域的那些产品转移到那里。 这种路径相当长-估计长达4-5年-但由于迭代，有可能按顺序在工业操作模式下获得结果。
谁赢了
经过三轮互动的演讲，提问和答案后，听众对预期最终结果的公布感到隐瞒。 您可能意识到PSB战役的胜利者是Andrey Trushkin和分布式系统。
最后，我们提供了一个视频，有助于您感受战斗的气氛：