Tu n'auras que des services autonomes

Question

L’un des principes de la SOA est le suivant: "Les services sont autonomes". J'ai 2 services. Le service A dépend du service B. Le service A ne peut servir les clients que si le service B est opérationnel. Dois-je violer le principe ici?

Ou si autonome doit signifier "découplé", est-ce que je respecte le principe si j'ai une sécurité (par exemple, une autre instance du service B s'exécutant ailleurs qui est connectée à si l'instance principale est en panne)? Cela peut répondre à mes exigences de disponibilité, mais je ne sais pas comment cela peut réduire ma dépendance. Oui, la sécurité intrinsèque pourrait même provenir du service C d'un tiers et dans ce cas, j'augmenterais mon autonomie.

Ou le principe signifie-t-il simplement que les services doivent être conçus comme "" fifedoms"? avec des interfaces bien définies pour obtenir les données dans & amp; en dehors. Cependant, certains gourous semblent penser que vous devez même stocker les données que vous recevez en interne pour réduire la dépendance et conserver votre autonomie ...

Est-ce une erreur de traiter les services comme des composants de la messagerie? :)

Pensées?

Answer 1

Voir ce message sur SOA Tenets . Voir également la La constellation fractale de services autonomes .

"Les services doivent être déployés, gérés et mis en version indépendamment des autres services et / ou applications qui en dépendent. "

L’autonomie ne signifie pas isolé ou totalement autonome.

Au lieu de cela, vous pouvez avoir une " constellation " de deux services. Oui, ils dépendent les uns des autres. Non, A ne casse pas lorsque B est déplacé ou mis à niveau. De même, A ne s'interrompt pas lorsque les internes de B sont modifiés.

De même, du point de vue de B, la mise à niveau vers les composants internes de A ne se répercute pas sur les modifications apportées à l'interface et aux composants internes de B.

Les API évoluent indépendamment. Le schéma, les messages et les implémentations sont indépendants. Ils se réfèrent simplement les uns aux autres.

"Le service A ne peut servir les clients que si le service B est opérationnel" - ne t'inquiète pas. Le service A ne peut pas servir les clients s'il est en panne non plus. Le service est un problème. Peu importe que ce soit B (sur lequel dépend A) ou A. La dépendance n'a rien à voir avec le fait que A ou B soit fiable ou disponible.

Oui, les services ont des interfaces bien définies et indépendantes. La mise en œuvre de A dépend de B, mais pas de l'interface.

Modifier.

"Certains gourous semblent penser que vous devez même stocker les données que vous recevez en interne pour réduire la dépendance et conserver votre autonomie ..."

Vous ne pouvez pas voir le point. Si A dépend de B et que l'algorithme de B change, la copie des données de B par A est - bien - ancienne. Dépend-en signifie généralement une relation dynamique, opérationnelle et à la transaction.

Le problème est que B peut être lent, ce qui ralentit A, ce qui ralentit l'application utilisant A lent. C'est une déception. Mais ce n’est pas un appel à briser les règles d’autonomie et à garder A un cache secret de vieilles données de B.

Answer 2

Votre autonomie est seulement améliorée grâce à un service de sauvegarde. Et si les deux services B et C baissaient? Ensuite, votre service diminue. Vous pouvez encore améliorer votre autonomie (et vos performances) en mettant en cache les résultats des services externes. Ainsi, si B et C ne fonctionnent pas, vous pouvez toujours servir certains de vos clients avec les résultats mis en cache. Tant que vous aurez recours à des services tiers, vous ne pourrez jamais atteindre une autonomie de 100%.