SOA的一个原则是：“服务是自治的”。 我有2项服务。服务A取决于服务B.除非服务B启动并运行，否则服务A无法为客户端提供服务。我是否违反了这一宗旨？
或者，如果自治必须意味着“解耦”，那么如果我有故障保护，我是否满足了这个原则（比如服务B的另一个实例在其他地方运行，如果主实例已关闭则连接到其他实例）？这可能满足我的可用性要求，但我不确定这如何可以减少我的依赖性。是的，故障保险甚至可以是来自第三方的服务C，在这种情况下，我确实提高了我的自主权。
或者这个原则是否意味着必须将服务设计为“fifedoms”，并且具有明确定义的接口，以便将数据输入到＆amp;出。然而，一些大师似乎认为你甚至需要存储你在内部收到的这些数据，以减少依赖并维持你的自主权......
如果我将服务视为具有消息传递的组件，这是一个错误吗？ ：）
思想？
答案 0 :(得分：7)
在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，但接口不依赖。
编辑。
“一些大师似乎认为你甚至需要存储你在内部收到的这些数据，以减少依赖并维持你的自主权......”
看不出重点。如果A依赖于B，并且B的算法发生变化，那么A的B数据副本就已经过时了。 取决于通常意味着实时，有效，最新的交易关系。
问题是B可能很慢，这使A变慢，这使得使用A的应用程序变慢。那真是太糟糕了。但这并不是要求打破自治规则并让A保留来自B的旧数据的秘密缓存。
答案 1 :(得分：1)
通过备份服务，您的自主权只能改进。如果服务B和C都下降了怎么办？然后你的服务就会失败。通过缓存外部服务的结果，您可以进一步提高自主性（和性能）。这样，如果B和C关闭，您仍然可以使用缓存结果为客户部分提供服务。但是，只要您依赖第三方服务，您就永远无法实现100％的自主权。