你应该只有自主服务

Question

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

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

或者，原则仅仅意味着服务必须被设计为具有定义良好的接口的“fifedom”，用于数据的传入和传出。然而，一些大师似乎认为，您甚至需要在内部存储这些数据，以减少依赖性并维护您的自主性……

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

有什么想法？

Answer 1

请参阅SOA Tenets上的这篇文章。另请参阅The Fractal Constellation of Autonomous Services。

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

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

相反，您可能有两个服务的“星座”。是的，它们相互依赖。不，当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的旧数据的秘密缓存。

Answer 2

只有通过备份服务才能提高您的自主性。如果服务B和服务C都出现故障怎么办？然后你的服务就会停机。您可以通过缓存来自外部服务的结果来进一步提高您的自主性(和性能)。这样，即使B和C出现故障，您仍然可以使用缓存的结果为一些客户端提供服务。但是，只要你依赖第三方服务，你就永远不会实现100%的自主性。