Quali sono le considerazioni importanti quando si passa dall'architettura monolitica a quella dei microservizi in .NET? [chiuso]

Ho lavorato su numerosi progetti di microservizi. Inevitabilmente le aziende hanno imboccato la strada perché il loro grande approccio ai DB non può più scalare. Ecco le mie esperienze / recomenations.

Organizzazione. Una soluzione per microservizio. pacchetti nuget per librerie condivise

Sviluppo. team più grandi 5-6 sviluppa un'area di funzionalità alla volta. Refactor in un servizio interfacciato. Sostituisci il servizio in memoria con un client per il microservice.

Test. test di integrazione che utilizzano dati di input / output reali. Si desidera essere in grado di attivarli contro qualsiasi istanza in esecuzione per verificare che siano attivi e corretti, istanze locali, ambienti test / utente e in istanze di memoria per il test dell'unità. Assicurati di poter testare la versione dell'istanza tramite un'interfaccia healthcheck o simile

Ridimensionamento. La coda è la migliore così come è in grado di gestire i processi distribuiti multistadio. Coniglio MQ, Zero MQ, MSMQ ecc. Ma i servizi di REST bilanciati vanno bene per le chiamate in stile rpc e possono essere un facile punto di partenza.

Distribuzione. Octopus. progetti db, autore di no-sql.dbs come Mongo. Anche se penso che stai andando nella direzione sbagliata se hai più dbs. Piuttosto, hai messaggi pesanti che contengono i dati necessari per il processo e alcuni dbs più grandi per l'archiviazione dei dati nascosta dietro le proprie apis.

Nessun DBA! Se hai un DBA wrt in DBA stai sbagliando.

Infrastruttura. Nessun problema. Leggi da una coda. Processo. Scrivi su una coda. Puoi fare a meno di più di un'istanza per scatola anche su istanze di cloud micro per servizi denominati di piccole dimensioni o poco frequenti

Monitoraggio. Interfacce di verifica dello stato di salute per tutti i servizi denominati in linea con il monitoraggio del software e fino alla scheda madre.

Il failover e il recupero automatici sono importanti, le istanze dovrebbero avviarsi quando necessario e essere apolidi, quindi un crash non mantiene il servizio fuori linea.

Il problema principale non sono i tanti servizi che scendono perché la natura stessa dei micro servizi li rende robusti a questo riguardo. È come gestisci i messaggi che non possono essere elaborati.

Usa logstash o simili per tenere traccia del flusso dei messaggi e capire dove e quali sono i problemi. Assicurati di poter eseguire nuovamente i messaggi non riusciti in modo che un processo fisso possa continuare da dove era stato interrotto.

Nota finale. versione di tutto, dlls, nugets, dati, interfacce. Con più istanze di più servizi e messaggi storici che lo circondano può essere una delle principali cause di problemi.

Negli ultimi 2 anni stiamo dividendo un monolite in microservizi, quindi ecco alcune delle cose che stiamo facendo

Organizzazione : ogni servizio sarà una soluzione da solo, nessun progetto comune con nessun altro servizio. E abbiamo concluso che i contratti erano di per sé una soluzione separata, in cui ogni versione è un pacchetto .nuget.

Sviluppo : ogni team lavorava su una parte dell'applicazione, per ogni nuovo servizio iniziato con la creazione del contratto e poi separando il servizio, ma continuando a tenerlo parte dell'app / soluzione principale ( quindi nessuna chiamata HTTP ancora). E in un prossimo passo terremo questo servizio totalmente a parte.

Routing : tutti i nostri servizi sono dietro un bilanciamento del carico e ogni servizio viene implementato su pochi vms. Stiamo condividendo lo stesso vm per più servizi. Andare con un vm per servizio mi sembrava uno spreco di risorse, perché i servizi sono piccoli mentre un vm di Windows ha bisogno di circa 2G per funzionare correttamente. Alcuni servizi che non sono correlati all'interazione dell'utente (come l'invio di e-mail / notifiche) funzionano con le code.

Test : inizialmente pensavamo che l'unità testasse il servizio e testasse la compatibilità dei contratti tra diverse versioni dei client e del servizio con Pact.Net sarebbe sufficiente. Ma abbiamo avuto problemi quando non è stata distribuita una nuova versione di un servizio e abbiamo lavorato con quello precedente. Tutti i test sono passati, ma l'intera piattaforma non funzionava correttamente. Quindi abbiamo aggiunto alcuni test di alto livello (integrazione) sui flussi principali.

Distribuzione : tutta la piattaforma è installata su un paio di vms, stiamo usando una combinazione di TFS per la compilazione, AWS S3 per gli artefatti, Ansible per la creazione, la distribuzione e la configurazione di VM. Ansible gioca un ruolo importante qui, è senza agente e utilizza il servizio remoto di PowerShell per la connessione a Windows. Abbiamo smesso di utilizzare la trasformazione xml di web.config e spostato nei modelli Ansible, così possiamo avere tutta la configurazione nei file Ansible. E la parte buona è gratuita e open source, rispetto al polpo. VMS completamente nuovi sono utilizzati per le nuove versioni, noi aggiorniamo i servizi solo quando dobbiamo implementare le correzioni.

Ridimensionamento : in una distribuzione di questo tipo è possibile ridimensionare solo i vms e non il servizio stesso. Quindi controlla le tue prestazioni (CPU, RAM), il numero di richieste che ricevi, o anche il tempo basato (come nel fine settimana c'è meno traffico) che inizi e fermi nuovi vms

Monitoraggio : siamo su AWS e abbiamo CloudWatch per gli avvisi di serie temporali, ma stiamo progettando di andare a Grafana e Prometheus (un passo avanti per andare alla finestra mobile, ora con Server 2016). Sulla registrazione stiamo usando Graylog (che sta usando ElastiSearch dietro). È stato facile adottarlo, perché prima usavamo Log4Net con gli appendici di file e c'è un appender in particolare per Graylog. Puoi creare molti avvisi basati su di esso, ci siamo resi conto che è in realtà un processo continuo.