wcf - 你将只有自治服务

Question

SOA 的原则之一是:“服务是自治的”。
我有 2 项服务。服务 A 依赖于服务 B。除非服务 B 启动并运行，否则服务 A 无法为客户端提供服务。我违反了这里的原则吗？

或者，如果自治必须意味着“解耦”，如果我有故障保护(比如在其他地方运行的另一个服务 B 实例，如果主实例关闭，那么我是否满足该原则。)？这可能满足我的可用性要求，但我不确定这如何减少我的依赖。是的，故障保险甚至可能是来自第三方的服务 C，在这种情况下，我确实提高了我的自主权。

或者这个原则是否仅仅意味着服务必须被设计为“fifedoms”，具有明确定义的接口(interface)来获取数据。然而，一些大师似乎认为你甚至需要在内部存储你收到的这些数据，以减少依赖并保持你的自主权......

如果我将服务视为带有消息传递的组件，这是否是一个错误？ :)

想法？

Answer 1

在 SOA Tenets 上查看此帖子.另见 The Fractal Constellation of Autonomous Services .

“服务的部署、管理和版本控制应独立于依赖于它们的其他服务和/或应用程序。”

自治并不意味着孤立或完全独立。

相反，您可能有两个服务的“星座”。是的，它们相互依赖。不，当 B 移动或升级时，A 不会中断。当 B 的非接口(interface)内部发生变化时，A 也不会中断。

同样——从 B 的角度来看——升级到 A 的内部结构并不会影响 B 的接口(interface)和内部结构的变化。

API 独立发展。架构、消息和实现是独立的。他们只是碰巧互相引用。

“除非服务 B 启动并运行，否则服务 A 无法为客户提供服务”——别担心。如果服务 A 宕机，它也无法为客户提供服务。服务中断是个问题。 B(A所依赖的)或A无关紧要。依赖与A或B是否可靠或可用无关。

是的，服务具有定义明确且独立的接口(interface)。 A 的实现依赖于 B，但接口(interface)不依赖于 B。

编辑。

“一些大师似乎认为你甚至需要在内部存储你收到的这些数据，以减少依赖并保持你的自主权......”

看不出重点。如果 A 依赖于 B，并且 B 的算法发生变化，则 A 的 B 数据副本是--嗯-- 旧的。 Depends-on 通常意味着一种生活的、工作的、由交易完成的关系。

问题是B可能很慢，这使得A变慢，这使得使用A的应用程序变慢。真可惜。但这并不是要求打破自治规则并让 A 为 B 保留旧数据的 secret 缓存。