Stiamo progettando l'applicazione dei microservizi attorno all'API REST. L'applicazione ha lo scopo di cercare, creare, aggiornare e recuperare documenti da molti archivi eterogenei.
Mi chiedo se devo modellare i servizi attorno alle operazioni (ogni operazione GET, PUT, POST, PATCH, ... come servizio) o attorno ai repository (ogni repository back-end = servizio).
Microservice dovrebbe essere progettato attorno al servizio che forniscono nel sistema.
Quindi, ad esempio, potresti avere un servizio utente la cui unica responsabilità è quella di memorizzare e autenticare gli utenti. Tutti gli altri servizi nel tuo sistema utilizzano quindi questo servizio per autenticare gli utenti.
E potresti avere un servizio di archiviazione dei documenti, che non fa altro che archiviare un documento (vale a dire che non si preoccupa anche dell'autenticazione dell'utente o della conversione del documento in formati diversi per richiesta)
Non sono abbastanza sicuro di cosa intendi per "modellare i servizi attorno alle operazioni", ma se vuoi dire che hai un microservizio per GET e un microservizio per PUT , e ogni microservizio ha tutti i servizi da gestire questo compito al suo interno, quindi no, non sarebbe una buona idea e una sorta di sconfiggere il punto
Entrambi potrebbero funzionare. Dipende da come vuoi definire le tue risorse. Si potrebbe fare ottenere / Post di [Il documento] da [Il repository] e offrire per consentire al servizio di trovarlo o lasciare che l'utente specifichino un'opzione nell'URI, oppure si potrebbe ottenere / pubblicare su ciascun repository separatamente, e metterlo sul client per conoscere o cercare il repository corretto per il documento prima di chiamare per memorizzare / recuperare un documento.
In termini di testabilità e riutilizzo, le risorse più semplici sono buone, ma d'altra parte si vuole la maggior parte della logica per comporre le azioni più semplici in quelle più complesse per essere nello spazio dei servizi come è possibile presentazione separata dalla logica per ridurre l'importo da ricodificare per più modalità di presentazione. Questo tende a creare più livelli di servizi, se i requisiti di latenza lo consentono. Inoltre, con servizi di grana più fine, è possibile eseguire il bilanciamento del carico più facilmente, anche se attenzione, il database o la rete può essere il collo di bottiglia silenzioso come con tutte le applicazioni distribuite. Fondamentalmente, c'è una scelta tra la suddivisione di implementazioni comuni in altri servizi web e l'utilizzo di una libreria comune che non è esposta come servizi web.
Dovresti creare servizi intorno ai repository, non sull'operazione come nel caso delle operazioni, la tua logica di business su un'entità sarà frammentata tra vari servizi che non è un buon approccio.
Anche nei repository, innanzitutto, definisci quale esatto valore commerciale fornisce il tuo servizio, quindi scegli solo quelle entità dal repository e definisci un servizio.
Ulteriori informazioni sui microservizi --- puoi leggere da qui
Se hai ancora dubbi sulla possibilità di porre una domanda più specifica specificando le entità in un repository, sarà utile:)
Grazie ragazzi per il vostro feedback. Sì o creerò 4 servizi: uno per ottenere un'operazione, un altro per put de (crea documento), un altro per eliminare e il 4 per documento di aggiornamento (PATCH) funzionano bene. Ma posso anche creare 3 servizi ciascuno per repository specifici e in questo caso ogni repository ha una propria operazione (GET, PUT, DELETE, PATCH). D'altra parte, se seguo la best practice del design per contesto limitato alle attività commerciali, nessuna delle opzioni precedenti è il contesto aziendale. Può esserci ci sono opzioni che non riesco a vedere?
Grazie ancora per le risposte,
Abdel
Leggi altre domande sui tag design rest microservices