- I always see that microservices are supposed to communicate with one another. Currently 2 separate microservices might call the same backend service. Is this correct design, or should I make one microservice A that calls a backend service, and 2 other microservices, B and C, that call A?
Risposta 1: Decidere di suddividere o unire i microservizi o alterare la loro struttura di comunicazione dipende in realtà da ciò che si desidera ottenere in termini di prestazioni, sicurezza, sovraccarico di rete e codice e limiti operativi .
Puoi rispondere alla tua domanda "dovrei creare un microservizio A che chiama un servizio di back-end e altri 2 microservizi, B e C, che chiamano A?" rispondendo ad alcune domande come:
- In che modo le prestazioni hanno un impatto su tutti i servizi quando prendi una decisione?
- In che modo la sicurezza ha impatto per tutti i servizi quando prendi una decisione?
- Quale decisione è più facile per gli sviluppatori ragionare o semplifica la struttura del codice?
- Esistono restrizioni che limiterebbero entrambe le decisioni (costi superati con nuovi server / contenitori, limiti di autorizzazione API esterni da servizi di terze parti, ecc.)?
Una volta che rispondi alle domande che contano, puoi trovare i motivi per cui potresti o non dividerei un servizio specifico.
Nota a margine: sei molto chiaro che la tua organizzazione designa la differenza tra un servizio di microservizio e un servizio di backend. A volte le organizzazioni usano il linguaggio specifico del dominio sbagliato e raggruppano le cose in un modo che è incompatibile con la flessibilità mentale di cui hai bisogno come sviluppatore per svolgere il tuo lavoro. Per essere chiari: tutto è un microservizio. Non dovresti aver paura di aprire un'interfaccia REST su un servizio "back-end" se la matrice di prestazioni, sicurezza, sovraccarico e limitazioni sono a favore di questa decisione ... perché "è solo un altro servizio".
SE la tua definizione di servizi di back-end sono database condivisi o servizi in coda, quindi non stai facendo microservizi nel modo giusto. Suddividi tutti questi tavoli in istanze di database collegate ai rispettivi servizi. I servizi non dovrebbero condividere lo stesso schema di database, ma dovrebbero condividere i dati con le loro interfacce definite (REST / websocket / network). La risposta in questo scenario sarebbe "crea un microservizio A che chiama un servizio di backend e altri 2 microservizi, B e C, che chiamano A".
- We want to push some formatting from the UI to the microservice. For instance, we always want to format a phone number from backend service A to have dashes. 5552223333 to 555-222-3333. Should I have a formatting microservice I pass through, or is it best to do it on each microservice that calls backend service A?
Risposta 2 La formattazione condivisa (o algoritmi) deve essere inserita in un modulo condiviso e installata nel codice più vicino alla trasformazione. Suggerirei che il codice necessario per l'analisi, la formattazione e la convalida dei numeri di telefono sia spostato su un modulo condiviso che può essere installato su ciascun microservizio che deve gestire i numeri di telefono.
Nota a margine: se non si è d'accordo con l'idea del modulo condiviso e si è optato per un "servizio di formattazione del numero di telefono", esploriamo in che modo si adatta. Cosa succede quando hai bisogno di un "servizio di formattazione degli indirizzi"? Si tratta di un servizio separato con tutto il codice, la rete e il sovraccarico di manutenzione? Apriamo nuovi endpoint REST sul "servizio di formattazione dei numeri di telefono" e confondiamo le linee di singola responsabilità? La soluzione più semplice sarebbe quella di creare un nuovo modulo condiviso (che ha un basso codice, rete e spese generali di manutenzione), isolare tutta la logica di indirizzo in quel modulo, quindi includerlo in qualsiasi servizio che deve gestire quella logica.
- Each web app only communicates with it's specific microservice. Should web apps communicate to multiple services rather than just the one? This would get rid of the duplication I see throughout the microservices.
Risposta 3: Questa è una domanda complicata. In un mondo assoluto e ideale; utilizzare un microservizio come facciata per ogni app Web è la decisione giusta. In questo modo si attenuano il comportamento erratico degli utenti e i problemi di prestazioni dei servizi principali. Garantisce inoltre una separazione netta della logica specifica del cliente dalla logica principale.
Tuttavia, la risposta del mondo reale è più organica. Inizia a sviluppare l'app Web ed effettua le richieste direttamente ai servizi. Se la capacità dell'app Web cresce oltre quella gestibile con la comunicazione point-to-point per ciascun servizio, allora crea una facciata.
Molto probabilmente le prime persone a parlare saranno gli sviluppatori mobili che chiedono un singolo endpoint / servizio aggregato che possono chiamare al posto di molti endpoint / servizi.
Nota a margine: dovresti eliminare la duplicazione del codice nei tuoi servizi indipendentemente dalla risposta che scegli qui. Se è presente la duplicazione del codice tra i servizi, spostarlo in un modulo condiviso con un'interfaccia semplificata, quindi includere tale modulo nei servizi e rimuovere il codice duplicato. Avrai ancora la duplicazione del codice, ma sarà il codice che utilizza l'interfaccia pubblica che hai progettato (stabile), invece della specifica logica aziendale su come gestire un problema (meno stabile).