寻找紧耦合设计与 SOA 的支持者

Posted 2023-02-16

【中文标题】寻找紧耦合设计与 SOA 的支持者

【英文标题】：Looking for proponents of tightly coupled design versus SOA

【发布时间】：2012-05-04 00:15:52

【问题描述】：

这是我对自己提出的一个奇怪的问题。我们在工作中就如何实现几乎是面向服务的架构 (SOA) 进行了一些辩论，其中有一些不值得讨论的问题。也就是说，它是一组用于构建 SaaS Web 应用程序的小型简单服务（大多数情况下，遗留包装器并不算少）。

无论如何，争论的问题之一是是否使用无共享方法并让每个服务通过该服务的 API 与其他服务进行通信，或者是否开发某种类型的共享 API 库以供各种服务导入直接相互交流。后者可能会让人们想起 CORBA。

因此，我对团队的建议是，对于每个感觉强烈的人——我们中的一些人——去研究并为我们个人希望如何实施该系统提出一个被广泛引用的案例。然后，为了希望减少确认偏差并启发每个人，请为我们个人不希望如何实施该系统提供一个被广泛引用的案例。然后我们大家再聚在一起讨论。

我的问题是，除了 CORBA 示例之外，我很难找到紧密耦合、类似 CORBA 的导入库设计的想法。是否有这样做的支持者，尤其是相对于解耦的 SOA 架构？或者只是这个时代这个想法的一般支持者？我赞成无共享架构，其中每个服务都有自己定义明确的 API，现在我需要为我不赞成的内容做一个演示，但我什至找不到任何支持证据或不是来自前 SOA 时代的信息。

【问题讨论】：

Kuali 使用 RICE 服务总线 (kuali.org/rice/modules/ksb)，它的目标是非常特定的用途，但是当我使用它时，我真的很喜欢它。运行一个 RICE 实例，然后您的其他应用程序可以在任何地方运行，只要它们可以将自己暴露于服务总线，它们之间的通信就没有问题。

我没有听说过 RICE，如何传递消息是我们可能需要考虑的事情。谢谢。

【参考方案1】：

与大多数“X vs Y”问题一样，答案是视情况而定。

脱钩不是灵丹妙药。虽然它有很多好处（可重用性、模块化、测试、更容易维护等......），但它可能导致解决方案的过度设计（因此可能需要更长的时间来创建并增加更多的进入/理解障碍）并且通常有一些对性能的影响。避免仅仅为了它而去耦/抽象也是很好的（除非它很容易或“低垂的果实”）。否则，请确保您有一些体面的用例来支持它。

这在很大程度上取决于您的项目类型、时间表和绩效目标。与其在考虑你的项目之前问哪个 x 更好，不如问每个 x 可以如何以具体和有意义的方式应用于你的项目，并判断基于此。

【讨论】：

很好的答案...如果我从这个角度出发，我想我可以将重点放在完全解耦的设计上。谢谢。