你只能拥有自治服务

SOA的原则之一是:"服务是自治的".我有2项服务.服务A取决于服务B.除非服务B启动并运行,否则服务A无法为客户端提供服务.我是否违反了这一宗旨？

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

或者这个原则是否意味着必须将服务设计为"fifedoms",并且具有明确定义的接口,用于获取和输出数据.然而,一些大师似乎认为你甚至需要存储你在内部收到的这些数据,以减少依赖并维持你的自主权......

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

思考？

请参阅有关SOA Tenets的这篇文章.另请参阅自主服务的分形星座.

"应该独立于依赖于它们的其他服务和/或应用程序来部署,管理和版本化服务."

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

相反,你可能有两个服务的"星座".是的,他们互相依赖.不,当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的旧数据的秘密缓存.