Una guida ai microservizi Java. Parte 2: distribuzione e test

Traduzione e adattamento dei microservizi Java: una guida pratica . Link alla prima parte della guida . Qualsiasi programma Java lato server, e quindi qualsiasi microservizio, è semplicemente un file con estensione .jar o .war. C'è una cosa grandiosa nell'ecosistema Java, o meglio nella JVM: devi scrivere il codice Java solo una volta e può essere eseguito su quasi tutti i sistemi operativi, a patto di non aver compilato il codice con una versione di Java più recente della tua. versione JVM di destinazione. Questo è importante da capire, soprattutto quando si tratta di argomenti come Docker, Kubernetes o (rullo di tamburi!) Il Cloud. Perché? Esaminiamo diversi scenari di distribuzione.

Esempio di distribuzione minimalista di microservizi Java

Continuiamo con l'esempio della banca. Quindi abbiamo un file monobank.jar (monolite) e il nostro riskengine.jar appena estratto (il primo microservizio di controllo del rischio). Supponiamo inoltre che entrambe le applicazioni, come ogni altra applicazione al mondo, necessitino di un file .properties. Nel nostro caso, conterrà solo l'URL e le credenziali del database. Una distribuzione minima potrebbe consistere di due directory simili a queste: Primo:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Secondo:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Ciò lascia aperta la domanda: come arriveranno i file .properties e .jar al server? Purtroppo le risposte potrebbero essere molte.

Come utilizzare strumenti di compilazione, SSH e Ansible per distribuire microservizi Java

Consigli noiosi, ma non per questo meno eccellenti su come implementare i microservizi Java... In realtà, esattamente come gli amministratori di sistema hanno implementato qualsiasi programma server Java nelle aziende negli ultimi 20 anni. Questo è il mix:

• il tuo strumento di creazione preferito (Maven, Gradle)
• buon vecchio SSH/SCP per copiare .jars sui server
• Script Bash per gestire script e server di distribuzione
• o meglio ancora: alcuni script Ansible.

Naturalmente, questo non è adatto agli innovatori che necessitano di un cloud “respirante”, server con bilanciamento automatico del carico e così via. Questa è davvero noiosa vecchia scuola. Comunque funziona!

Come utilizzare Docker per distribuire microservizi Java

Torniamo alla dolce agonia della scelta. Un paio di anni fa è entrato in scena Docker, e con esso la containerizzazione. Se non ci hai mai lavorato, ecco una breve descrizione rivolta agli utenti finali e agli sviluppatori:

• Un contenitore (semplificato) è simile alla cara vecchia macchina virtuale, ma “più leggera”. Se non ti è chiaro cosa significhi "più facile" in questo contesto, consulta questa risposta su Stackoverflow .
• Il contenitore garantisce la propria trasportabilità. Cioè, funziona ovunque. Sembra familiare, vero?

È divertente che, data la portabilità e la compatibilità con le versioni precedenti della JVM, questa funzionalità non sembri un tale vantaggio. Puoi semplicemente scaricare JVM.zip su qualsiasi Raspberry Pi (o anche telefono cellulare), estrarlo ed eseguire qualsiasi file .jar. La situazione cambia in linguaggi come PHP o Python, dove le incompatibilità di versione o le impostazioni di distribuzione sono più complesse. Oppure se la tua applicazione Java dipende da molti altri servizi installati (con i numeri di versione corretti): ad esempio, un database Postgres o un archivio di valori chiave Redis. Quindi, il vantaggio principale di Docker per i microservizi Java, o più precisamente per le applicazioni Java, è questo: la possibilità di impostare ambienti di test o integrazione omogenei utilizzando strumenti come Testcontainers . Gli sviluppi complessi sono più facili da installare. Prendi il software del forum Discourse . Puoi installarlo con una singola immagine Docker e quell'immagine contiene tutto ciò di cui hai bisogno, dal software Discourse scritto in Ruby, a un database Postgres, a Redis, al lavello della cucina. Se le tue distribuzioni sono simili o desideri eseguire un piccolo database Oracle, prova Docker. Quindi, per riassumere, invece di limitarti a guardare il file .jar, ora:

• raggruppa il tuo file jar in un'immagine Docker
• invia questa immagine a un registro Docker privato
• tira ed esegui questa immagine sulla tua piattaforma di destinazione
• oppure copia l'immagine Docker direttamente sul tuo sistema di produzione ed eseguila.

Come utilizzare Docker Swarm o Kubernetes per distribuire microservizi Java

Diciamo che decidi di provare Docker. Ogni volta che distribuisci un microservizio Java, crei un'immagine Docker che raggruppa il tuo file .jar. Supponiamo che tu abbia un paio di questi microservizi Java e desideri distribuirli su più macchine (in un cluster). La domanda sorge spontanea: come gestire questo cluster? Eseguire contenitori Docker, controllare le prestazioni, distribuire aggiornamenti, ridimensionare il sistema (brrr)? Due possibili risposte a questa domanda sono Docker Swarm e Kubernetes. Entrare nel dettaglio di entrambe le opzioni renderebbe questo tutorial già lungo troppo lungo, ma riteniamo che sia importante menzionare che entrambe le opzioni in definitiva si basano sulla scrittura di file YAML (vedi Storie di rientro Yaml ) per gestire il tuo cluster. Se vuoi sapere quali sentimenti questo suscita nella pratica, digita semplicemente una query simile nella ricerca di Twitter. Quindi il processo di distribuzione per i tuoi microservizi Java ora assomiglia a questo:

• Configurazione e gestione di Docker Swarm/Kubernetes
• Tutti i passaggi per Docker (vedi sopra)
• Scrivi ed esegui YAML finché i tuoi occhi non sanguinano finché tutto funziona.

Come testare i microservizi Java

Supponiamo che tu decida di implementare i microservizi in produzione. Come possiamo testare ora l'integrazione degli n-microservizi durante lo sviluppo? Come puoi vedere se l'intero flusso di lavoro funziona e non solo alcune parti di esso? In pratica è possibile utilizzare uno dei tre metodi:

1. Con un po' di lavoro (se utilizzi framework come Spring Boot), puoi combinare tutti i tuoi microservizi in un'unica classe di avvio e caricare tutti i microservizi utilizzando un'unica classe Wrapper.java, a seconda che tu abbia memoria sufficiente sul tuo computer per esegui tutti i tuoi microservizi.
2. Puoi copiare le impostazioni di Docker Swarm o Kubernetes localmente.
3. Basta non eseguire più test di integrazione localmente. Distribuisci invece un ambiente DEV/TEST dedicato. Questo è qualcosa che molti team effettivamente fanno quando soccombono al dolore delle configurazioni locali dei microservizi.

Inoltre, oltre ai tuoi microservizi Java, probabilmente avrai bisogno anche di un broker di messaggi in esecuzione (come ActiveMQ o RabbitMQ) o magari di un server di posta elettronica o di qualsiasi altro componente di messaggistica di cui i tuoi microservizi Java hanno bisogno per comunicare tra loro. Ciò porta a una significativa sottostima della complessità sul lato DevOps. Dai un'occhiata alle librerie di test dei microservizi, possono alleviare questo problema. In ogni caso, questa complessità ci porta ai problemi generali dei microservizi, di cui parleremo proprio adesso. Nella parte finale , tratteremo domande generali sui microservizi Java.