algorithm - SOA 是否支持方法组合？

Question

有一个很好的例子here :

CRUD x Business logic interface. Suppose that you are working with Invoices. Each invoice consists of an InvoiceHeader and one or more InvoiceLine. If you use a CRUD interface for invoice you will first call CreateInvoiceHeader operation to create InvoiceHeader and then several AddInvoiceLine operations to add all InvoiceLines - that is low level CRUD approach. But if you implement business logic on the service side you will call single CreateInvoice and pass a complex object graph (header with all lines) to the service to create and add what is needed.

为什么是完全合法的方法组合

var Invoice = 
    Service.CreateInvoice(
        Service.CreateInvoiceHeader(...),
        {
            Service.CreateInvoiceLine(...),
            Service.CreateInvoiceLine(...)
        }
    )

1. 在 SOA 中使用时从性能的角度来看绝对糟糕吗？
2. 无法自动转换为单个服务调用？

为什么必须创建一个复杂的对象图并将其发送到服务方法

var InvoiceDTO = new InvoiceDTO(
    new InvoiceHeaderDTO(...),
    {
         new InvoiceLineDTO(...),
         new InvoiceLineDTO(...)
    }
)

var Invoice = Service.Create(InvoiceDTO)

并且服务必须遍历整个图并调用相同的服务方法来组装生成的发票？

有没有什么方法可以在不使用复杂对象图作为数据传输的情况下使用方法组合来创建复杂的结果？

Answer 1

答案是，对于 SOA 架构，您的性能瓶颈在于往返成本高昂。它们会增加延迟，影响您的网络和 CPU 开销。

有几种基本的缓解策略。

1. 将相互交谈的东西放在一起。在同一个过程中是最优的。在同一台机器上帮助很大。在数据中心附近仍然有帮助。这种方法的缺点是可以组合的数量受机器大小的限制。

2. 将工作分成更细粒度的 block ，以尽量减少往返次数。这种方法的缺点是剩下的交互可能会更复杂(您的“复杂对象图”就是一个例子)。

3. 使用更高效的协议(protocol)。真正聪明的人在上个世纪 mock XML 作为 RPC 协议(protocol)。聪明人十年前就意识到这是愚蠢的。许多组织仍在使用它。停止。使用 JSON、Cap'n Proto 或其他东西。唯一的缺点是让人们就应该做什么达成一致的组织挑战。

4. 并行调用。那就是不要一次发送 50 个请求。一起发过去，回来处理。不利之处在于，这会大大增加代码的复杂性，并且只会对延迟有所帮助 - 对资源消耗没有帮助。

您不必在这些选项中进行选择。拥有良好 SOA 架构的公司(例如谷歌)可以做到这 4 点。

也就是说，回到你的问题。有一个中间立场。您可以做的不是调用复杂的对象，而是调用创建对象，进行各种调用以构建数据结构，然后调用实际发送它。代码看起来与您使用低级 CRUD 接口(interface)编写的代码完全一样，除了在末尾有一个实际发送请求的 Service.Send() 调用。