SOA 的原则之一是：“服务是自治的”。我有 2 项服务。服务 A 依赖于服务 B。除非服务 B 启动并运行，否则服务 A 无法为客户端提供服务。我违反了这里的原则吗？
或者，如果自治必须意味着“解耦”，如果我有故障保护（比如在其他地方运行的另一个服务 B 实例，如果主实例关闭，则连接到该实例），我是否满足该原则？这可能满足我的可用性要求，但我不确定这如何减少我的依赖。是的，故障保险甚至可能是来自第三方的服务 C，在这种情况下，我确实提高了我的自主权。
或者这个原则是否仅仅意味着服务必须被设计为“fifedoms”，具有明确定义的接口来输入和输出数据。然而，一些大师似乎认为您甚至需要在内部存储您收到的这些数据，以减少依赖并保持您的自主权......
如果我将服务视为带有消息传递的组件，这是否是一个错误？:)
想法？
请参阅SOA 原则上的这篇文章。另请参阅自治服务的分形星座。
“服务的部署、管理和版本控制应独立于依赖于它们的其他服务和/或应用程序。”
自治并不意味着孤立或完全独立。
相反，您可能有两个服务的“星座”。是的，它们相互依赖。不，当 B 移动或升级时，A 不会中断。当 B 的非接口内部发生变化时，A 也不会中断。
同样——从 B 的角度来看——升级到 A 的内部结构并不会影响 B 的接口和内部结构的变化。
API 独立发展。架构、消息和实现是独立的。他们只是碰巧互相引用。
“除非服务 B 启动并运行，否则服务 A 无法为客户提供服务”——别担心。如果服务 A 宕机，它也无法为客户提供服务。服务中断是个问题。B（A所依赖的）或A无关紧要。依赖与A或B是否可靠或可用无关。
是的，服务具有定义明确且独立的接口。A的实现依赖于 B，但接口不依赖于 B。
编辑。
“一些大师似乎认为你甚至需要在内部存储你收到的这些数据，以减少依赖并保持你的自主权......”
看不出重点。如果 A 依赖于 B，并且 B 的算法发生变化，则 A 的 B 数据副本是--嗯-- 旧的。 Depends-on通常意味着一种生活的、工作的、由交易完成的关系。
问题是B可能很慢，这使得A变慢，这使得使用A的应用程序变慢。真可惜。但这并不是要求打破自治规则并让 A 为 B 保留旧数据的秘密缓存。
只有拥有后备服务才能提高您的自主权。如果服务 B 和 C 都出现故障怎么办？然后你的服务就会下降。您可以通过缓存来自外部服务的结果来进一步提高您的自主性（和您的性能）。这样，如果 B 和 C 出现故障，您仍然可以使用缓存结果为您的一些客户端提供服务。但是，只要您依赖 3rd 方服务，您就永远无法实现 100% 的自主权。