In che modo i microservizi rendono più semplice evitare l'accoppiamento troppo stretto tra i componenti?

Question

In che modo i microservizi rendono più semplice evitare l'accoppiamento troppo stretto tra i componenti?

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

0

Ho letto in questo articolo sull'architettura dei microservizi di M. Fowler:

Another consequence of using services as components is a more explicit component interface. Most languages do not have a good mechanism for defining an explicit Published Interface. Often it's only documentation and discipline that prevents clients breaking a component's encapsulation, leading to overly-tight coupling between components. Services make it easier to avoid this by using explicit remote call mechanisms.

Non sono nemmeno sicuro di come chiedere. In che modo i microservizi sono migliori delle librerie nel far rispettare un contratto di interfaccia? In che modo un endpoint REST è migliore di una funzione Java? Qualcuno può elaborare, magari dare un esempio?

architecture rest microservices libraries enterprise-architecture

posta garci560 16.05.2017 - 15:48

fonte

3 risposte

Leggi altre domande sui tag architecture rest microservices libraries enterprise-architecture

Scopri le implementazioni dell'interfaccia Annullamento di "correzioni"

score 2 · Answer 1

In che modo i microservizi migliorano l'applicazione di un contratto di interfaccia?

Non puoi chiamare nel loro interno. Puoi chiamarli solo tramite l'interfaccia che espongono pubblicamente.

Con una biblioteca, un membro o una classe non contrassegnata come privata può essere chiamata anche se non era destinata. O anche se è stato documentato che gli utenti non dovrebbero farlo. Quando un utente chiama qualcosa che deve essere "dentro" la tua libreria, allora quel codice client diventa strettamente associato all'implementazione interna della libreria. Anche quando una biblioteca ha membri privati o interni, molte lingue offrono funzionalità reflection che ti consentono di (incautamente) accedi o invocale.

Con i (micro) servizi, l'isolamento delle parti interne è totale. L'unico modo per chiamarli è attraverso l'interfaccia pubblica.

score 2 · Answer 2

Non credo che le architetture dei microservizi siano migliori delle librerie in "imporre un contratto di interfaccia", ma sono migliori nei definire i contratti . Fowler sta dicendo che le librerie di codici in genere hanno molti membri pubblici, ma solo alcune di queste sono destinate a formare l'interfaccia pubblicata - il contratto concordato tra due o più componenti.

Presumibilmente, questo è perché pensa che i membri pubblici siano molto economici da creare, quindi la disciplina spesso ci impedisce di limitarli.

Gli endpoint del servizio (REST, messaggistica, ecc.) sono molto più espliciti e più costosi da creare. Prendono maggiormente in considerazione problemi di compatibilità, sicurezza e prestazioni. Per questo motivo, è probabile che sul tuo servizio siano presenti meno interfacce, meglio definite, rendendo più facile il disaccoppiamento e la riorganizzazione dei servizi in futuro.

score 1 · Answer 3

How are microservices better than libraries in enforcing an interface contract?

Non lo sono. In effetti, probabilmente sono peggio .

Entrambi i microservizi e le librerie dispongono di API. Con le librerie normalmente puoi avere garanzie di compilazione / unit test dei tuoi contratti di interfaccia.

I microservizi hanno (o dovrebbero avere ...) lo stesso contratto di interfaccia. Tuttavia, la capacità di convalidarlo viene spostata su un test di integrazione o peggio, sulla verifica dell'ambiente di produzione.

Questo problema si traduce in:

test di integrazione ingombrante
mancanza di test e speriamo che le cose funzionino negli ambienti di produzione

Si noti che questo problema è uno che il test del contratto è progettato per risolvere. Ti invito a leggere Pact.io in quanto sono più o meno in grado di risolvere il problema principale qui.