以下是与 SOA 相关的演示幻灯片中提到的一点，它使我对服务编排和服务编排的概念感到困惑。要启用服务编排，Web 服务是否应该能够调用另一个 Web 服务？
SOA builds applications out of software services. Services comprise intrinsically
unassociated, loosely coupled units of functionality that have no calls to
each other embedded in them.
【问题讨论】：
标签： web-services service architecture soa
理论上，服务可以做任何它需要做的事情来完成它的工作。因此，似乎没有充分的理由禁止使用第二项服务来完成您的工作。为什么要重新发明轮子？
在实践中，问题更为复杂。如果您开始在自己的 Web 服务器上调用其他服务，那么您最终会耗尽它的资源。充其量，“真正的”客户端将不得不等待更长的时间才能得到答案，而您的 Web 服务服务器会自行运行。
另一个问题是递归循环：服务 A 调用 B 调用 C 调用 A 调用 B ...你明白了。一项服务的微小变化可能会在没有人注意到的情况下引入这样的循环，并且它可能会在那里停留很长时间，直到它突然杀死您的服务器。
这就是为什么您应该在内部服务器的层次结构中构建微服务（即在 Web 服务层之下 - 这不向客户端公开）。这些微服务可以以自上而下的方式相互使用（以避免循环）。然后单元测试确保它们正常运行。
最后，这种重用非常缓慢。每个 HTTP 请求都需要大量资源来创建、发送、解析和处理。直接调用内部方法可以快 10 到 10000 倍。
这些是单个服务器公开的服务不应通过“公共客户端 API”相互重用的主要原因。
注意：有些 Web 服务通过使用现有服务构建新服务。 IFTTT - "If This Then That" 就是这样一只野兽。
【讨论】：
您可以根据自己的需要采用每个概念。在我当前的项目中，我们有一个单独的模块负责Orchestration。这是必需的，因为在实际使用中，场景可能非常复杂。所以为了接近你系统的实际管理，你需要有这样一个。
这种方法的另一个优点是保留了 Separation_of_concerns。还将业务请求与您拥有的应用程序、数据和基础架构保持一致。它通过自动化工作流、配置等来定义策略和服务级别。
编排对于云服务的交付也至关重要。因为它们是联网的，以允许共享数据处理任务、集中数据存储以及对服务或资源的在线访问。
【讨论】：