Web services 一个服务可以在其代码内调用另一个服务吗？

下面是一张与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服务器上调用其他服务，那么最终将耗尽它的资源。充其量，“真正的”客户机将不得不等待更长的时间，等待他们的答案，而您的web服务服务器将自行处理

另一个问题是递归循环：服务A调用B调用C调用A调用B。。。你明白了。一个服务中的一个小变化可以在没有人注意到的情况下引入这样一个循环，并且它可以在那里停留很长时间，直到它突然杀死您的服务器

这就是为什么您应该在服务器内部的层次结构中构建微服务（即，在web服务层之下-这不会向客户端公开）。这些微服务可以自上而下地相互使用（以避免循环）。然后，单元测试确保它们的行为正常

最后，这种重用非常缓慢。每个HTTP请求都需要大量资源来创建、发送、解析和处理。直接调用内部方法的速度可以提高10-10000倍

这些是单个服务器公开的服务不应该通过“公共客户端API”相互重用的主要原因

---

注意：有些web服务通过使用现有服务来构建新服务。你可以根据自己的需要采纳每一个概念。在我当前的项目中，我们有一个单独的模块负责。这是必需的，因为在现实生活中，场景可能非常复杂。因此，为了接近系统的实际管理，您需要这样一个系统

这种方法的另一个优点是保留了。还可以使业务请求与您拥有的应用程序、数据和基础架构保持一致。它通过自动化的工作流、资源调配等来定义策略和服务级别

---

编排在云服务的交付中也至关重要。因为它们是联网的，允许共享数据处理任务、集中数据存储和在线访问服务或资源

这是一个以讨论为导向的问题（很可能就此结束），但这篇摘录的来源是什么？这一主张是根据什么标准提出的？