从SOA中的编排层调用服务？

Question

面向服务的体系结构原则site指出，服务组合是面向服务的体系结构中的一件重要事情。但是服务松散耦合也很重要。

这是否意味着“编排层”应该是唯一允许调用系统中的服务的层？

根据我对SOA的理解，“编排层”将所有服务“粘合”到一个软件应用程序中。我试图在图A和图B中描述这一点。

两者之间的区别在于，在图A中，应用程序由服务组成，所有逻辑都在“编排层”中完成(对服务的所有调用仅从“编排层”完成)。在图B中，应用程序由服务组成，但一个服务调用另一个服务。

图B中的架构是否违反了SOA的“服务松散耦合”原则？一个服务可以调用SOA中的另一个服务吗？更广泛地说，在服务松散耦合、抽象、可重用性、自主性等方面，图A上的架构是否优于图B上的架构？

我的猜测是，A架构更加通用，但它可以在“编排层”和所有被调用的服务之间添加一些不必要的数据传输。

​

​

Answer 1

假设服务1和服务2下面的所有内容都封装在它们的契约后面，那么它们是松散耦合的。然而，B没有利用编排层的能力来释放服务1。A与B之间没有明显的对错，但存在权衡。图A需要更多的开发工作，因为B返回给A的细节需要提取到编排层-如果涉及到数据列表，那么B需要允许参数集合作为标准传入。然而，这使得svc 1对svc 2一无所知。因此，如果服务由两个不同的团队拥有和管理，那么A将允许这些团队自主工作。例如，如果svc 1是客户信息服务( CIS )，svc 2是支付服务，则编排层可以将CIS数据与Svc 2缝合在一起，以返回客户姓名及其最近支付数据的列表。在图A中，在编排层中使用内存中的连接来进行拼接。然后客户端调用编排层。使用B，客户端可以直接调用服务1，但如果您开始允许服务相互调用，您可能会得到一个令人讨厌的依赖图，其中包括可重入调用的可能性。如果您的团队规模较小，并且同时拥有svc 1和svc 2，那么他们可以跟踪这些依赖关系。然而，当您有不同的团队时，您可能会发现依赖关系在B中并不容易了解或很好地管理。