[Musica]
grazie, benvenuto nel mio discorso
questo colloquio è profondo fino al ginocchio nei microservizi
uno spinosad sarà sul micro
servizi cloud nativi e demoni infernali
dal destino
Sono un ingegnere senior e consulente presso
Contenitore di consulenza basato Amsterdam
soluzioni e sono un grande fan del
classico videogioco FPS Doom e mentre
giocando a Doom ho fatto alcune realizzazioni
quanto è simile alla gestione di micro
servizi in produzione o costruendoli
così doom è un gioco di scienziati su
Marte apre un portale per l’inferno per canalizzare
energia pulita dalla salute alla terra
beh, come puoi aspettarti, non ha funzionato
fuori troppo bene e demoni oltre corse il
struttura con solo il verde corazzato
marino in piedi tra loro e
i micro servizi dell’umanità sono molto
stile architettonico popolare oggi
perché le grandi aziende come Netflix e
Google fondamentalmente doveva architettare i loro
applicazioni in questo modo a causa della loro
scala e persone in aziende più piccole
stanno guardando a questo questo
stile architettonico e meraviglia
se dovremmo anche usarlo o andare
entra e non preoccuparsi per il
rischi o realizzarli, quindi non tutti
sta distribuendo un gran numero di
componenti per comprare un gran numero di
squadre e avendo milioni e milioni
o miliardi di richieste al secondo
i loro server ma lo è davvero anche loro
grande rischio o i benefici superano
i rischi oggi quali sono i benefici di
micro servizi e quali sono i demoni
potresti scatenarti su te stesso se tu
partire
in questo modo prima di tutto i micro-servizi
verrà siamo una grande architettura
utilizza risorse cloud elastiche per te
sarà in grado di scalare la tua applicazione
in modo più efficiente se ne hai diversi
team che forniscono il tuo software o persino
a volte può funzionare con una squadra tua
la velocità di sviluppo può aumentare
perché stai consegnando componenti
indipendentemente quindi dopo una iniziale
aumentare o diminuire la velocità che puoi
puoi più tardi quando le tue applicazioni
la complessità aumenta, puoi farlo
distribuire più veloce resilienza del
aumenta l’ applicazione ai guasti
perché è possibile eseguirlo su diversi
posizioni geografiche diversi dati
centri e cloud pubblico di oggi
i fornitori lo rendono facile per te, ma tu
ha bisogno di un’architettura che lo farà
supportare finalmente l’ottimizzazione dei costi
se hai componenti che hanno molto
prestazioni diverse e utilizzo delle risorse
caratteristiche con un micro servizio
architettura che sarai in grado di scalare
loro indipendentemente e quindi utilizzano
le risorse cloud migliorano così quando sono
parlando voglio chiarire un po ‘quello che ho
significa dai micro servizi è molto vago
termine usato in molti modi diversi
gli anni come cosa intendo con loro e
durante questo discorso è un codice separato
repository per moduli separati o
componenti separati della vostra applicazione
che sono confezionati come indipendenti
artefatti che poi vengono distribuiti in a
modo in cui questi artefatti non sono per
esempio raggruppato in un singolo
macchina virtuale ma sono sotto ma lo sono
gestito dalla piattaforma di produzione come
componenti indipendenti tutto questo questo
lo schema potrebbe essere modificato in molti
modi diversi per motivi pratici così
si potrebbe desiderare di avere un repo mono per
il tuo codice ma in qualche modo costruisci diversi
artefatti o cosa
del tempo accade con o molte volte
succede con le applicazioni monolitiche il
il codice potrebbe anche essere separato ma lo è
raggruppati in un unico grande artefatto o
tutto è separato ma poi lo è
installato su una VM ed eseguire tutto è
correre insieme quindi sono tutti validi
opzioni è non c’è un modo giusto per
faccio i micro servizi che non sto provando a
sottintende che specialmente con l’eredità
applicazioni ragioni evolutive come
le cose si evolvono con un’applicazione quelle
sono tutti approcci validi ma ora sono io
voglio mostrare i benefici di un puro
architettura di micro-servizi specialmente in
relazione con le tecnologie cloud native
Ma quali sono i demoni che si sarà
scatenando quando vanno i micro servizi oh
sì come una diapositiva sull’essere preparati così
anche se questi scienziati hanno fallito
in modo orribile avevano effettivamente uno status
messaggio che dice invasione demoniaca in
progresso
è molto bello quindi il tuo primo passo
essere preparati è seduto su questo discorso
quindi prima di tutto dovrai averne bisogno
impacchetta la tua applicazione di cui hai bisogno a
tecnologia che in realtà ti permette di
pacchetto di applicazioni in modo uniforme in
un modo che può essere consegnato a
produzione invariata, così non lo fai
produrre qualcosa che poi è confezionato
dalla squadra ops in qualcos’altro e
quindi viene distribuito in modo diverso su
un sistema di produzione ti serve anche a
tecnologia che ti consente di implementare
ogni artefatto che hai in un modo uniforme
perché altrimenti la complessità lo farà
trasforma il tuo ambiente di produzione in un
ambiente molto eterogeneo dove tutto
sono diversi tipi di artefatti
schierato in modo diverso così alla fine lì
sarà un pushback dalle operazioni
squadra per mantenerlo semplice e facciamolo
per esempio, crea tutto in Java
lo sviluppo locale sarà un problema con
micro servizi quando ne esegui uno tuo
ID e tutto è
fatto per eseguire un’applicazione forse – tu
crea le tue configurazioni e tutto
se ne hai 10 15 20 allora allora
diventa molto più difficile gestire il tuo
applicazione sul tuo sviluppo locale
ambiente e che le persone a volte
non si rendono nemmeno conto, ma rallenta il
tutta la velocità della squadra di molto perché tu
dispone di un disco funzioni di test di tempo o
i tuoi cambiamenti nell’osservazione dell’isolamento
anche come lo sviluppo locale era
sempre qualcosa da risolvere ma con micro
servizi diventa più difficile monitoraggio
diventa anche molto più cruciale e
diverso e più importante di
con l’ architettura monolitica
l’auto-guarigione è qualcosa di cui avrai bisogno
fino ad un certo grado perché se
stai facendo centinaia di piccoli
servizi in produzione che non puoi avere
il sysadmin ragazzo va e ricomincia
qualcosa quando e fallisce e infine
probabilmente il tuo problema più grande sarà
silos organizzativi almeno per lotti
di società in realtà stranamente per alcuni
le aziende non è un problema perché
semplicemente non hanno un team operativo per
esempio e bene ne hanno altri
problemi allora ma almeno il
lotte intestine tra le operazioni e
i team di sviluppo non si verificano
quindi fondamentalmente le operazioni richiedono stabilità
quelli non vogliono che le cose cambino
perché è così che riescono a mantenere
le cose che gli sviluppatori in esecuzione vogliono spingere
le nuove funzionalità improvvisamente decidono gli sviluppatori
che invece di tre artefatti sono
andando a rompere l’applicazione in
20 o 50 e tutte quelle cose che hanno
precedentemente contenuta all’interno
l’applicazione diventa improvvisamente visibile per
operazioni e inizia a comunicare
la rete diventa così via
più complesso per loro per questo è necessario
buone collaborazioni tra le operazioni
e i team di sviluppo per gestirlo
complessità neonata ma va bene per tutti
questi demoni spaventosi hai cloud nativo
armi per combatterli
le tecnologie native del cloud hanno
diventare piuttosto popolare negli ultimi due
anni portano a modi completamente nuovi
gestire queste sfide di micro
servizi mostrerò come non risolvono
tutti i problemi quindi non ci sto provando
implicare qui che usi
tecnologie cognitive e micro
i servizi diventano super semplici e
tutti dovrebbero farlo non aiutano
con il tuo sovraccarico di sviluppo
componenti indipendenti così allora il codice
lato non c’è così tanto che ha
successo negli ultimi anni a
Almeno non l’ho visto, ma a destra
lato e al centro i manufatti noi
ora abbiamo un buon formato di imballaggio e noi
avere un nuovo modo di implementare la finestra mobile roba
è la tecnologia che ti consente di pacchettizzare
le tue applicazioni suddividono il tuo virtuale
macchine e consegnare alla produzione a
gamma di diverse tecnologie in a
modo uniforme che il team operativo può
capire in grado di gestire può correre e il
team di sviluppo può effettivamente anche
utilizzare nel loro processo di sviluppo
docker compose può aiutare con il locale
sviluppo perché contenitori docker
l’intera tecnologia attorno alla finestra mobile è a
nuovo modo migliore di virtualizzare
o almeno un modo più leggero di
virtualizzare le cose che puoi realmente
avere quella virtualizzazione sul tuo sul tuo
laptop che utilizza la finestra mobile comporre o
altri strumenti come mini cubo o
minimizer che effettivamente esegue anche a
cluster più realistico sulla tua macchina
e quindi hai un modo carino e facile
effettivamente eseguire più componenti insieme
sul tuo portatile fino a quando eri il
le risorse sul tuo laptop lo consentono
è anche bello e poi i grandi cannoni
questo è ciò che vedi lì è il
BFG il grosso fucking gun from doom è
il più potente come il
gli orchestratori sono i più potenti
strumenti che dobbiamo gestire la tua produzione
ambiente
gli orchestratori di contenitori prendono un set di
macchine virtuali e li utilizzano per l’esecuzione
i tuoi contenitori sopra di loro non lo fanno
tutto ciò che è rivoluzionario è un it’s it’s
una cosa carina perché una volta che si impacchetta
contenitori che vorrai eseguirli
da qualche parte e questo orchestratore prende
cura di questo
ma perché questo ha abilitato molto
modo diverso di gestire il tuo
le applicazioni è perché l’orchestratore
sta guardando la tua applicazione a molto
più alto livello di astrazione di
strumenti precedenti così quando eri
installando macchine virtuali usando puppet your your
il livello di astrazione è più o meno
file nel sistema operativo e
servizi e cose e e non
applicazioni con contenitori di questo livello
di astrazione si muove più in alto e io
contenitore Orchestrator in realtà
capisce che i tuoi tre front end
contenitori che vedi che sono
distribuito su due nodi diversi
appartengono allo stesso componente dell’applicazione
e quindi pro può fornire il bilanciamento del carico
su di loro o ridimensionandoli su e giù
la nostra scoperta di servizi con anche dns
server che puoi semplicemente affrontare in anticipo
fine e il tuo traffico viene indirizzato al
al contenitore giusto così con questi
le cose diventano molto diverse che possono
essere visto come soluzioni di monitoraggio così
le soluzioni di monitoraggio sono un buon esempio
di come le cose si sono evolute in questi giorni
c’è una breve lista di alcuni dei
soluzioni di monitoraggio nativo cloud che
ora può monitorare i contenitori
produzione in esecuzione su a
il sistema di orchestrazione di container è molto
interessante vedere che zero alla fine
le soluzioni di monitoraggio erano davvero molte
cercando di raggiungere il monitoraggio
contenitori perché i contenitori hanno a
durata molto più breve rispetto a VMS e
inoltre non puoi semplicemente installare agenti e
roba nel contenitore perché
contenitore è progettato per
basta eseguire una singola procedura di applicazione
così il modo in cui queste soluzioni di monitoraggio
stavano lavorando prima non era sostenibile
il mondo dei container ma quello che era
fortunato per queste soluzioni di monitoraggio
e perché in realtà sono riusciti a pareggiare
migliorare rispetto allo stato precedente
era che il contenitore Orchestrator il
maestro ha in realtà una visione globale di
tutto ciò che sta accadendo nel
cluster ha in realtà tutto il
gli orchestratori di contenitori hanno un’API che
puoi interrogare e ottenere questo stato globale
e come ho detto è chiuso a
astrazione a livello di applicazione in modo che
significa nel mio esempio qui ho il
strumento di monitoraggio dei costi che mi mostra CPU
tempo dei miei servizi e di quei servizi
lassù so che questo è un laser, va bene così
questi servizi quassù nei tempi antichi
Avrei dovuto configurare cosa a
il servizio significa che dovrei dirlo a qualcuno
come la soluzione di monitoraggio ora io no
più deve fare questo il monitoraggio
la soluzione potrebbe semplicemente chiedere ai kubernetes
api afferra tutti i servizi chiedi che cosa
i contenitori sono dietro quei servizi
monitorare quei contenitori e aggregare
i risultati in questo grafico qui o
può monitorare quanti contenitori
in realtà compongono il servizio in modo che tu possa
vedere qui è un picco nell’utilizzo della CPU e
puoi vedere un picco nel numero di
contenitori così effettivamente il servizio è
scalando purtroppo qui le etichette
sono un po ‘incasinato quindi questo è questo
mostra molto bene come in the
cloud mondo nativo il concetto di micro
i servizi stanno diventando più facili da gestire in
la produzione successiva è continua
integrazione è qualcosa che continua
tutti questi strumenti hanno raggiunto
con i contenitori in un modo che possono
possono costruire contenitori di cui possono parlare
agli orchestratori di solito non in un molto
bel modo c’è ancora lavoro da fare dentro
Questo
ma puoi usare i tuoi strumenti che conosci
e mi piace costruire e distribuire contenitori
Allora, qual è il tuo passaggio?
dovrà prendere quando si decide per a
micro servizi cloud native di adozione
dovrà implementare indipendente
consegna di componenti per sfruttare il tuo
l’architettura di micro servizi di cui avrai bisogno
essere in grado di gestire questi cloud nativi
ambienti che dovrai avere un po ‘
catena di CD CI aggiornata nel caso in cui tu già
ne hai avuto uno relativamente buono
essere in grado di gestire la produzione
i carichi di lavoro si occupano in modo efficiente di
la tua gente in queste tecnologie e
devi fare un buon controllo devops
sì, devi fare buoni DevOps e fare
il monitoraggio nativo della nuvola così lo farò
usa questo esempio da uno dei nostri
clienti con cui lavoriamo insieme
loro per mettere la loro applicazione in
produzione su un cluster kubernetes in
il motore del contenitore Google è a
applicazione relativamente semplice non è un
esempio di un migliaio di micro servizi ma
illustra il mio punto sul perché non lo è
solo la tecnologia cloud nativa sta aiutando
Micro signore ti aiuta a eseguire micro
servizi in produzione ma anche il
l’architettura dei micro servizi non lo è
certo è assolutamente necessario ma a
almeno è molto adatto a cosa
puoi farlo nel cloud usando il contenitore
orchestratori quindi quello che è successo qui era
la sua azienda ha deciso di migrare lontano da
la loro applicazione legacy che era a
applicazione web dotnet classica con
database dietro di esso
a un intero nuovo stack in realtà nella fonte
da una società di outsourcing e
costruiscilo costruisci tutto sopra
nodejs e ricerca elastica e
quello che hanno fatto è stato costruire un esportatore da
il vecchio database per spingere i dati
era ancora aggiornato a RabbitMQ e importato
attraverso la nuova applicazione nella
nuovo database è stato necessario perché
la migrazione è avvenuta passo dopo passo quindi
la nuova applicazione stava lentamente prendendo piede
con funzionalità alla vecchia applicazione
e fino a che in realtà non era finito
hanno dovuto costruire un proxy che in realtà
richiesta di proxy per funzionalità che sono
non ancora finito al nuovo
applicazione e lo costruiscono
creando un componente di amministrazione un front-end
componente e ammassando tre back-end
componenti insieme in una sorta di a
monolite quindi il problema che abbiamo incontrato
quando stavamo lavorando insieme a loro
e mettendo questa applicazione in
la produzione era ad esempio l’importatore
componente necessario per essere ridimensionato
con il back-end quindi cosa è successo quando
load hit ha fatto l’ applicazione che il
importatore scalato e ha iniziato l’importazione
messaggi dal vecchio database o dal
dati dal vecchio database in realtà
più veloce mentre l’ applicazione stava ottenendo
carico extra dal front-end che era a
situazione molto brutta lì il proxy
componente mentre in realtà quello che si potrebbe
essere ridimensionato con il back-end e persino esso
un po ‘ ha senso perché lo sono
sotto carico allo stesso tempo non potrebbe essere
monitorato separatamente dal back-end
così quando abbiamo avuto un elevato utilizzo della CPU o
memoria traboccante non c’era modo di farlo
dire se c’è l’importatore il
proxy o il back-end che è in errore
e con questa nuvola nativa come ho visto il
soluzioni di monitoraggio e con il
gli orchestratori in realtà è proprio quello che ottieni
una visione molto profonda del tuo sistema, se tu
in realtà diviso in separato
contenitori che eseguono processi separati così
il tuo prossimo passo sarà indipendente
consegna dei componenti, se lo si desidera
davvero sfruttare che hai un micro
l’architettura di servizio non li distribuisce
tutti insieme potrebbero essere
buon livello intermedio ma prova a muoverti
verso una fonte separata chiamata rapport
artefatti separati e non condividere il codice
tra di essi tra loro il comune
libreria che contiene l’ 80% del codice
un modello molto cattivo perché poi tu solo
non è possibile distribuire le cose indipendentemente anche
anche se potrebbe sembrare così fino a te
in realtà cambiare qualcosa nel comune
libreria che spezzerà qualcosa in a
servizio completamente diverso e proprio
i componenti dell’applicazione dovrebbero possedere i loro
possedere nuovamente il database per essere in grado di essere
distribuito indipendentemente come lo abbiamo fatto
in con questa applicazione noi
confezionato in kubernetes ogni servizio come
una distribuzione kubernetes che può essere
ridimensionato indipendentemente sono raggruppati
insieme in un servizio e scala automatica
utilizzando un podoscale automatico pod orizzontale così
questo è un diagramma super semplice
tutto è molto uniforme tutto è
un contenitore è tutto un dispiegamento
tutto è un servizio che carica
equilibri tra questi contenitori e
tutto ha un HPA e un pod orizzontale
il programma di scalabilità automatica è chiamato in kubernetes è
un componente o un pezzo di configurazione
che effettivamente ridimensiona l’applicazione
su e giù e il loro database è a
database gestito a elastico così è
anche uno strumento molto importante che puoi usare
un’architettura cloud lascia solo qualcuno
altrimenti gestisci un database la coda o il tuo
cluster Kubernetes soprattutto per
le aziende più piccole sono molto buone
idea di gestire gli ambienti
devono avere ambienti economici
usa e getta e versione per avere un molto
consegna prevedibile stabile in
kubernetes Continuo a usarlo come un
esempio hai dei bei spazi per questo in
spazi dei nomi puoi isolare il tuo
i contenitori distribuiscono la stessa applicazione
più volte mentre è in ogni
namespace è come se fosse il
unica cosa sul cluster e tu puoi
creare questi spazi dei nomi nella nostra pratica
praticamente non costano nulla
la creazione di un nuovo ambiente ha preso
noi fino a quando il contenitore più lento a
avvio che significa quasi secondi
carichi di lavoro di produzione che devi fare
scaling automatico Ho menzionato l’orizzontale
scalari potahto prima di altri contenitori
i sistemi di orchestrazione hanno differenti
modi per farlo
si dovrà essere risorsa messa a punto
limiti e prenotazioni sul tuo cluster
Penso che questo sia il più almeno per me
quando si lavora con kubernetes
cluster questo è stato il più sorprendente
cosa che doveva essere difficile da fare
in realtà stava decidendo quanta CPU
dovrebbe avere un servizio prenotato e come
molto può usare al massimo con un sacco di
diversi ambienti in esecuzione sul
stesso cluster e condividendo risorse voi
bisogna stare molto attenti a questo se
date troppo a un contenitore troppo in alto
prenotazione e sarete in esecuzione un sacco
di macchine virtuali per accogliere tutti
quei contenitori con tutti quelli che sono
affamato di CPU e forse non lo fa
qualsiasi cosa, perché quando si prenota una CPU
a un contenitore è riservato e il
contenitore potrebbe non fare nulla
e occuperà ancora la CPU
naturalmente il ridimensionamento automatico lo attenua
ma è uno sforzo per ottenere questo
giusto e se lo dai anche a pochi
poca riserva rispetto ad altri contenitori
può conservarlo in consegna continua
è questa parte non differisce molto
tranne dal da come eri tu
potrebbe averlo fatto prima semplicemente
diventa ancora più importante di cui hai bisogno
assicurati che qualunque strumento di fatturazione tu sia
utilizzando la finestra mobile supporta la maggior parte del bene
quelli lo supportano ora come spingere
artefatti per ambienti che sono
qualcosa che dovrai capire
le persone hanno un nuovo contenitore
orchestrare o sei un nuovo modo di
la distribuzione sta parlando all’API del
contenitore Orchestrator così avrai
a
avere un modo per farlo in realtà questi
giorni gli strumenti Cice si lascia per lo più solo
lo script piuttosto che non è molto
difficile da fare sarebbe più bello se lì
sarebbe più profonde integrazioni con il
video orchestratori e un importante
punto su DevOps che il team ops crea
la lavorazione per la consegna continua
non prendono i manufatti dal
team di sviluppo e inserirli
produzione perché se questo sta accadendo
quindi non c’è scalabilità in
numero di servizi perché c’è solo
nessun modo il team operativo capirà
ogni nuovo servizio che deve essere
schierato il tuo team operativo avrà
per capire gli orchestratori di contenitori
esegui il debug li leghi insieme a
monitoraggio e registrazione delle soluzioni di regressione
mentre il tuo team di sviluppo deve farlo
fidati anche degli utenti della piattaforma
è molto importante l’abbiamo scoperto quando
gli sviluppatori hanno solo un non avere un
sufficiente conoscenza approfondita di come le cose
lavoro e loro non hanno bisogno di capire
come funzionano gli interni di Kubernetes, ma loro
bisogno di capire i concetti e come
per essere un utente esperto di loro poi loro
se ciò non accade non gli piace
per toccarlo e l’intero DevOps
l’esperienza soffre perché lo saranno
spingendo sempre di più il team ops
e il monitoraggio di nuovo ho già
mostrato ma ora da un DevOps
prospettiva ancora il team ops offre
gli strumenti di cui potresti aver bisogno
debug inter-servizio così tu o te
avrà bisogno di un debug inter-servizio così a
la soluzione di aggregazione dei log sarà assolutamente
essere necessario inserire alcuni ID di correlazione
così puoi effettivamente trovare – quello che è successo
a una richiesta su diversi servizi
che siamo tutti coinvolti in realtà dentro
manutenzione che probabilmente sarà lavoro
vediamo di solito che le aziende non hanno
quel buon monitoraggio e sopravvivere con esso
abbastanza bene con il monolitico
l’architettura la mia ipotesi è dovuta a
impilare tracce soprattutto perché trasportano a
molte informazioni per scoprire dove come
una richiesta è passata all’interno dell’applicazione
ma lo perdi quando tu
avere servizi che comunicano su a
rete quindi dovrai effettivamente
aggregarli registrandoli da diversi
servizi e quindi assicurarsi che non lo fanno
guarda troppo perché poi è di nuovo
difficile scoprire qual è l’importante
cose
e infine DevOps DevOps sarà un
necessità assoluta e tu lo farai
potrebbe aver bisogno di un team operativo per sviluppare il
strumenti o si va in alcuni completamente
soluzioni gestite che sono là fuori
come abbiamo fatto con questo nostro cliente –
sono andati al motore del contenitore di Google
che è un kubernetes gestito usa il
soluzioni di monitoraggio gestite in Google
chiamare lo stack driver usa la gestione
database e ancora hanno finito con
un tizio deve fare le cose così
assicurati e se hai già un ops
squadra sul posto assicurarsi che non lo sono
distribuire applicazioni ma lo sono
sviluppando gli strumenti che il
gli sviluppatori quindi usano per distribuire il
le applicazioni e gli ambienti dovrebbero
anche la responsabilità dello sviluppatore
il team operativo non dovrebbe essere come
mantenendo l’ambiente di test su e
correndo in qualche modo sì, la vista ideale
di questo sistema sarebbe tutto questo
componenti separati e in esecuzione in
l’orchestratore quindi fanno il marinaio
viaggiato all’inferno per sconfiggere i demoni
lì ed è riuscito solo a vedere il
i demoni stanno ancora arrivando sulla terra dove lui
dovevano andare e sconfiggerli di nuovo a
infine salvare l’umanità sta andando essere un
giro brusco ma non dimenticare la tua nuvola
armi native e non aver paura di
i demoni ti ringraziano
tu
grazie, benvenuto nel mio discorso
questo colloquio è profondo fino al ginocchio nei microservizi
uno spinosad sarà sul micro
servizi cloud nativi e demoni infernali
dal destino
Sono un ingegnere senior e consulente presso
Contenitore di consulenza basato Amsterdam
soluzioni e sono un grande fan del
classico videogioco FPS Doom e mentre
giocando a Doom ho fatto alcune realizzazioni
quanto è simile alla gestione di micro
servizi in produzione o costruendoli
così doom è un gioco di scienziati su
Marte apre un portale per l’inferno per canalizzare
energia pulita dalla salute alla terra
beh, come puoi aspettarti, non ha funzionato
fuori troppo bene e demoni oltre corse il
struttura con solo il verde corazzato
marino in piedi tra loro e
i micro servizi dell’umanità sono molto
stile architettonico popolare oggi
perché le grandi aziende come Netflix e
Google fondamentalmente doveva architettare i loro
applicazioni in questo modo a causa della loro
scala e persone in aziende più piccole
stanno guardando a questo questo
stile architettonico e meraviglia
se dovremmo anche usarlo o andare
entra e non preoccuparsi per il
rischi o realizzarli, quindi non tutti
sta distribuendo un gran numero di
componenti per comprare un gran numero di
squadre e avendo milioni e milioni
o miliardi di richieste al secondo
i loro server ma lo è davvero anche loro
grande rischio o i benefici superano
i rischi oggi quali sono i benefici di
micro servizi e quali sono i demoni
potresti scatenarti su te stesso se tu
partire
in questo modo prima di tutto i micro-servizi
verrà siamo una grande architettura
utilizza risorse cloud elastiche per te
sarà in grado di scalare la tua applicazione
in modo più efficiente se ne hai diversi
team che forniscono il tuo software o persino
a volte può funzionare con una squadra tua
la velocità di sviluppo può aumentare
perché stai consegnando componenti
indipendentemente quindi dopo una iniziale
aumentare o diminuire la velocità che puoi
puoi più tardi quando le tue applicazioni
la complessità aumenta, puoi farlo
distribuire più veloce resilienza del
aumenta l’ applicazione ai guasti
perché è possibile eseguirlo su diversi
posizioni geografiche diversi dati
centri e cloud pubblico di oggi
i fornitori lo rendono facile per te, ma tu
ha bisogno di un’architettura che lo farà
supportare finalmente l’ottimizzazione dei costi
se hai componenti che hanno molto
prestazioni diverse e utilizzo delle risorse
caratteristiche con un micro servizio
architettura che sarai in grado di scalare
loro indipendentemente e quindi utilizzano
le risorse cloud migliorano così quando sono
parlando voglio chiarire un po ‘quello che ho
significa dai micro servizi è molto vago
termine usato in molti modi diversi
gli anni come cosa intendo con loro e
durante questo discorso è un codice separato
repository per moduli separati o
componenti separati della vostra applicazione
che sono confezionati come indipendenti
artefatti che poi vengono distribuiti in a
modo in cui questi artefatti non sono per
esempio raggruppato in un singolo
macchina virtuale ma sono sotto ma lo sono
gestito dalla piattaforma di produzione come
componenti indipendenti tutto questo questo
lo schema potrebbe essere modificato in molti
modi diversi per motivi pratici così
si potrebbe desiderare di avere un repo mono per
il tuo codice ma in qualche modo costruisci diversi
artefatti o cosa
del tempo accade con o molte volte
succede con le applicazioni monolitiche il
il codice potrebbe anche essere separato ma lo è
raggruppati in un unico grande artefatto o
tutto è separato ma poi lo è
installato su una VM ed eseguire tutto è
correre insieme quindi sono tutti validi
opzioni è non c’è un modo giusto per
faccio i micro servizi che non sto provando a
sottintende che specialmente con l’eredità
applicazioni ragioni evolutive come
le cose si evolvono con un’applicazione quelle
sono tutti approcci validi ma ora sono io
voglio mostrare i benefici di un puro
architettura di micro-servizi specialmente in
relazione con le tecnologie cloud native
Ma quali sono i demoni che si sarà
scatenando quando vanno i micro servizi oh
sì come una diapositiva sull’essere preparati così
anche se questi scienziati hanno fallito
in modo orribile avevano effettivamente uno status
messaggio che dice invasione demoniaca in
progresso
è molto bello quindi il tuo primo passo
essere preparati è seduto su questo discorso
quindi prima di tutto dovrai averne bisogno
impacchetta la tua applicazione di cui hai bisogno a
tecnologia che in realtà ti permette di
pacchetto di applicazioni in modo uniforme in
un modo che può essere consegnato a
produzione invariata, così non lo fai
produrre qualcosa che poi è confezionato
dalla squadra ops in qualcos’altro e
quindi viene distribuito in modo diverso su
un sistema di produzione ti serve anche a
tecnologia che ti consente di implementare
ogni artefatto che hai in un modo uniforme
perché altrimenti la complessità lo farà
trasforma il tuo ambiente di produzione in un
ambiente molto eterogeneo dove tutto
sono diversi tipi di artefatti
schierato in modo diverso così alla fine lì
sarà un pushback dalle operazioni
squadra per mantenerlo semplice e facciamolo
per esempio, crea tutto in Java
lo sviluppo locale sarà un problema con
micro servizi quando ne esegui uno tuo
ID e tutto è
fatto per eseguire un’applicazione forse – tu
crea le tue configurazioni e tutto
se ne hai 10 15 20 allora allora
diventa molto più difficile gestire il tuo
applicazione sul tuo sviluppo locale
ambiente e che le persone a volte
non si rendono nemmeno conto, ma rallenta il
tutta la velocità della squadra di molto perché tu
dispone di un disco funzioni di test di tempo o
i tuoi cambiamenti nell’osservazione dell’isolamento
anche come lo sviluppo locale era
sempre qualcosa da risolvere ma con micro
servizi diventa più difficile monitoraggio
diventa anche molto più cruciale e
diverso e più importante di
con l’ architettura monolitica
l’auto-guarigione è qualcosa di cui avrai bisogno
fino ad un certo grado perché se
stai facendo centinaia di piccoli
servizi in produzione che non puoi avere
il sysadmin ragazzo va e ricomincia
qualcosa quando e fallisce e infine
probabilmente il tuo problema più grande sarà
silos organizzativi almeno per lotti
di società in realtà stranamente per alcuni
le aziende non è un problema perché
semplicemente non hanno un team operativo per
esempio e bene ne hanno altri
problemi allora ma almeno il
lotte intestine tra le operazioni e
i team di sviluppo non si verificano
quindi fondamentalmente le operazioni richiedono stabilità
quelli non vogliono che le cose cambino
perché è così che riescono a mantenere
le cose che gli sviluppatori in esecuzione vogliono spingere
le nuove funzionalità improvvisamente decidono gli sviluppatori
che invece di tre artefatti sono
andando a rompere l’applicazione in
20 o 50 e tutte quelle cose che hanno
precedentemente contenuta all’interno
l’applicazione diventa improvvisamente visibile per
operazioni e inizia a comunicare
la rete diventa così via
più complesso per loro per questo è necessario
buone collaborazioni tra le operazioni
e i team di sviluppo per gestirlo
complessità neonata ma va bene per tutti
questi demoni spaventosi hai cloud nativo
armi per combatterli
le tecnologie native del cloud hanno
diventare piuttosto popolare negli ultimi due
anni portano a modi completamente nuovi
gestire queste sfide di micro
servizi mostrerò come non risolvono
tutti i problemi quindi non ci sto provando
implicare qui che usi
tecnologie cognitive e micro
i servizi diventano super semplici e
tutti dovrebbero farlo non aiutano
con il tuo sovraccarico di sviluppo
componenti indipendenti così allora il codice
lato non c’è così tanto che ha
successo negli ultimi anni a
Almeno non l’ho visto, ma a destra
lato e al centro i manufatti noi
ora abbiamo un buon formato di imballaggio e noi
avere un nuovo modo di implementare la finestra mobile roba
è la tecnologia che ti consente di pacchettizzare
le tue applicazioni suddividono il tuo virtuale
macchine e consegnare alla produzione a
gamma di diverse tecnologie in a
modo uniforme che il team operativo può
capire in grado di gestire può correre e il
team di sviluppo può effettivamente anche
utilizzare nel loro processo di sviluppo
docker compose può aiutare con il locale
sviluppo perché contenitori docker
l’intera tecnologia attorno alla finestra mobile è a
nuovo modo migliore di virtualizzare
o almeno un modo più leggero di
virtualizzare le cose che puoi realmente
avere quella virtualizzazione sul tuo sul tuo
laptop che utilizza la finestra mobile comporre o
altri strumenti come mini cubo o
minimizer che effettivamente esegue anche a
cluster più realistico sulla tua macchina
e quindi hai un modo carino e facile
effettivamente eseguire più componenti insieme
sul tuo portatile fino a quando eri il
le risorse sul tuo laptop lo consentono
è anche bello e poi i grandi cannoni
questo è ciò che vedi lì è il
BFG il grosso fucking gun from doom è
il più potente come il
gli orchestratori sono i più potenti
strumenti che dobbiamo gestire la tua produzione
ambiente
gli orchestratori di contenitori prendono un set di
macchine virtuali e li utilizzano per l’esecuzione
i tuoi contenitori sopra di loro non lo fanno
tutto ciò che è rivoluzionario è un it’s it’s
una cosa carina perché una volta che si impacchetta
contenitori che vorrai eseguirli
da qualche parte e questo orchestratore prende
cura di questo
ma perché questo ha abilitato molto
modo diverso di gestire il tuo
le applicazioni è perché l’orchestratore
sta guardando la tua applicazione a molto
più alto livello di astrazione di
strumenti precedenti così quando eri
installando macchine virtuali usando puppet your your
il livello di astrazione è più o meno
file nel sistema operativo e
servizi e cose e e non
applicazioni con contenitori di questo livello
di astrazione si muove più in alto e io
contenitore Orchestrator in realtà
capisce che i tuoi tre front end
contenitori che vedi che sono
distribuito su due nodi diversi
appartengono allo stesso componente dell’applicazione
e quindi pro può fornire il bilanciamento del carico
su di loro o ridimensionandoli su e giù
la nostra scoperta di servizi con anche dns
server che puoi semplicemente affrontare in anticipo
fine e il tuo traffico viene indirizzato al
al contenitore giusto così con questi
le cose diventano molto diverse che possono
essere visto come soluzioni di monitoraggio così
le soluzioni di monitoraggio sono un buon esempio
di come le cose si sono evolute in questi giorni
c’è una breve lista di alcuni dei
soluzioni di monitoraggio nativo cloud che
ora può monitorare i contenitori
produzione in esecuzione su a
il sistema di orchestrazione di container è molto
interessante vedere che zero alla fine
le soluzioni di monitoraggio erano davvero molte
cercando di raggiungere il monitoraggio
contenitori perché i contenitori hanno a
durata molto più breve rispetto a VMS e
inoltre non puoi semplicemente installare agenti e
roba nel contenitore perché
contenitore è progettato per
basta eseguire una singola procedura di applicazione
così il modo in cui queste soluzioni di monitoraggio
stavano lavorando prima non era sostenibile
il mondo dei container ma quello che era
fortunato per queste soluzioni di monitoraggio
e perché in realtà sono riusciti a pareggiare
migliorare rispetto allo stato precedente
era che il contenitore Orchestrator il
maestro ha in realtà una visione globale di
tutto ciò che sta accadendo nel
cluster ha in realtà tutto il
gli orchestratori di contenitori hanno un’API che
puoi interrogare e ottenere questo stato globale
e come ho detto è chiuso a
astrazione a livello di applicazione in modo che
significa nel mio esempio qui ho il
strumento di monitoraggio dei costi che mi mostra CPU
tempo dei miei servizi e di quei servizi
lassù so che questo è un laser, va bene così
questi servizi quassù nei tempi antichi
Avrei dovuto configurare cosa a
il servizio significa che dovrei dirlo a qualcuno
come la soluzione di monitoraggio ora io no
più deve fare questo il monitoraggio
la soluzione potrebbe semplicemente chiedere ai kubernetes
api afferra tutti i servizi chiedi che cosa
i contenitori sono dietro quei servizi
monitorare quei contenitori e aggregare
i risultati in questo grafico qui o
può monitorare quanti contenitori
in realtà compongono il servizio in modo che tu possa
vedere qui è un picco nell’utilizzo della CPU e
puoi vedere un picco nel numero di
contenitori così effettivamente il servizio è
scalando purtroppo qui le etichette
sono un po ‘incasinato quindi questo è questo
mostra molto bene come in the
cloud mondo nativo il concetto di micro
i servizi stanno diventando più facili da gestire in
la produzione successiva è continua
integrazione è qualcosa che continua
tutti questi strumenti hanno raggiunto
con i contenitori in un modo che possono
possono costruire contenitori di cui possono parlare
agli orchestratori di solito non in un molto
bel modo c’è ancora lavoro da fare dentro
Questo
ma puoi usare i tuoi strumenti che conosci
e mi piace costruire e distribuire contenitori
Allora, qual è il tuo passaggio?
dovrà prendere quando si decide per a
micro servizi cloud native di adozione
dovrà implementare indipendente
consegna di componenti per sfruttare il tuo
l’architettura di micro servizi di cui avrai bisogno
essere in grado di gestire questi cloud nativi
ambienti che dovrai avere un po ‘
catena di CD CI aggiornata nel caso in cui tu già
ne hai avuto uno relativamente buono
essere in grado di gestire la produzione
i carichi di lavoro si occupano in modo efficiente di
la tua gente in queste tecnologie e
devi fare un buon controllo devops
sì, devi fare buoni DevOps e fare
il monitoraggio nativo della nuvola così lo farò
usa questo esempio da uno dei nostri
clienti con cui lavoriamo insieme
loro per mettere la loro applicazione in
produzione su un cluster kubernetes in
il motore del contenitore Google è a
applicazione relativamente semplice non è un
esempio di un migliaio di micro servizi ma
illustra il mio punto sul perché non lo è
solo la tecnologia cloud nativa sta aiutando
Micro signore ti aiuta a eseguire micro
servizi in produzione ma anche il
l’architettura dei micro servizi non lo è
certo è assolutamente necessario ma a
almeno è molto adatto a cosa
puoi farlo nel cloud usando il contenitore
orchestratori quindi quello che è successo qui era
la sua azienda ha deciso di migrare lontano da
la loro applicazione legacy che era a
applicazione web dotnet classica con
database dietro di esso
a un intero nuovo stack in realtà nella fonte
da una società di outsourcing e
costruiscilo costruisci tutto sopra
nodejs e ricerca elastica e
quello che hanno fatto è stato costruire un esportatore da
il vecchio database per spingere i dati
era ancora aggiornato a RabbitMQ e importato
attraverso la nuova applicazione nella
nuovo database è stato necessario perché
la migrazione è avvenuta passo dopo passo quindi
la nuova applicazione stava lentamente prendendo piede
con funzionalità alla vecchia applicazione
e fino a che in realtà non era finito
hanno dovuto costruire un proxy che in realtà
richiesta di proxy per funzionalità che sono
non ancora finito al nuovo
applicazione e lo costruiscono
creando un componente di amministrazione un front-end
componente e ammassando tre back-end
componenti insieme in una sorta di a
monolite quindi il problema che abbiamo incontrato
quando stavamo lavorando insieme a loro
e mettendo questa applicazione in
la produzione era ad esempio l’importatore
componente necessario per essere ridimensionato
con il back-end quindi cosa è successo quando
load hit ha fatto l’ applicazione che il
importatore scalato e ha iniziato l’importazione
messaggi dal vecchio database o dal
dati dal vecchio database in realtà
più veloce mentre l’ applicazione stava ottenendo
carico extra dal front-end che era a
situazione molto brutta lì il proxy
componente mentre in realtà quello che si potrebbe
essere ridimensionato con il back-end e persino esso
un po ‘ ha senso perché lo sono
sotto carico allo stesso tempo non potrebbe essere
monitorato separatamente dal back-end
così quando abbiamo avuto un elevato utilizzo della CPU o
memoria traboccante non c’era modo di farlo
dire se c’è l’importatore il
proxy o il back-end che è in errore
e con questa nuvola nativa come ho visto il
soluzioni di monitoraggio e con il
gli orchestratori in realtà è proprio quello che ottieni
una visione molto profonda del tuo sistema, se tu
in realtà diviso in separato
contenitori che eseguono processi separati così
il tuo prossimo passo sarà indipendente
consegna dei componenti, se lo si desidera
davvero sfruttare che hai un micro
l’architettura di servizio non li distribuisce
tutti insieme potrebbero essere
buon livello intermedio ma prova a muoverti
verso una fonte separata chiamata rapport
artefatti separati e non condividere il codice
tra di essi tra loro il comune
libreria che contiene l’ 80% del codice
un modello molto cattivo perché poi tu solo
non è possibile distribuire le cose indipendentemente anche
anche se potrebbe sembrare così fino a te
in realtà cambiare qualcosa nel comune
libreria che spezzerà qualcosa in a
servizio completamente diverso e proprio
i componenti dell’applicazione dovrebbero possedere i loro
possedere nuovamente il database per essere in grado di essere
distribuito indipendentemente come lo abbiamo fatto
in con questa applicazione noi
confezionato in kubernetes ogni servizio come
una distribuzione kubernetes che può essere
ridimensionato indipendentemente sono raggruppati
insieme in un servizio e scala automatica
utilizzando un podoscale automatico pod orizzontale così
questo è un diagramma super semplice
tutto è molto uniforme tutto è
un contenitore è tutto un dispiegamento
tutto è un servizio che carica
equilibri tra questi contenitori e
tutto ha un HPA e un pod orizzontale
il programma di scalabilità automatica è chiamato in kubernetes è
un componente o un pezzo di configurazione
che effettivamente ridimensiona l’applicazione
su e giù e il loro database è a
database gestito a elastico così è
anche uno strumento molto importante che puoi usare
un’architettura cloud lascia solo qualcuno
altrimenti gestisci un database la coda o il tuo
cluster Kubernetes soprattutto per
le aziende più piccole sono molto buone
idea di gestire gli ambienti
devono avere ambienti economici
usa e getta e versione per avere un molto
consegna prevedibile stabile in
kubernetes Continuo a usarlo come un
esempio hai dei bei spazi per questo in
spazi dei nomi puoi isolare il tuo
i contenitori distribuiscono la stessa applicazione
più volte mentre è in ogni
namespace è come se fosse il
unica cosa sul cluster e tu puoi
creare questi spazi dei nomi nella nostra pratica
praticamente non costano nulla
la creazione di un nuovo ambiente ha preso
noi fino a quando il contenitore più lento a
avvio che significa quasi secondi
carichi di lavoro di produzione che devi fare
scaling automatico Ho menzionato l’orizzontale
scalari potahto prima di altri contenitori
i sistemi di orchestrazione hanno differenti
modi per farlo
si dovrà essere risorsa messa a punto
limiti e prenotazioni sul tuo cluster
Penso che questo sia il più almeno per me
quando si lavora con kubernetes
cluster questo è stato il più sorprendente
cosa che doveva essere difficile da fare
in realtà stava decidendo quanta CPU
dovrebbe avere un servizio prenotato e come
molto può usare al massimo con un sacco di
diversi ambienti in esecuzione sul
stesso cluster e condividendo risorse voi
bisogna stare molto attenti a questo se
date troppo a un contenitore troppo in alto
prenotazione e sarete in esecuzione un sacco
di macchine virtuali per accogliere tutti
quei contenitori con tutti quelli che sono
affamato di CPU e forse non lo fa
qualsiasi cosa, perché quando si prenota una CPU
a un contenitore è riservato e il
contenitore potrebbe non fare nulla
e occuperà ancora la CPU
naturalmente il ridimensionamento automatico lo attenua
ma è uno sforzo per ottenere questo
giusto e se lo dai anche a pochi
poca riserva rispetto ad altri contenitori
può conservarlo in consegna continua
è questa parte non differisce molto
tranne dal da come eri tu
potrebbe averlo fatto prima semplicemente
diventa ancora più importante di cui hai bisogno
assicurati che qualunque strumento di fatturazione tu sia
utilizzando la finestra mobile supporta la maggior parte del bene
quelli lo supportano ora come spingere
artefatti per ambienti che sono
qualcosa che dovrai capire
le persone hanno un nuovo contenitore
orchestrare o sei un nuovo modo di
la distribuzione sta parlando all’API del
contenitore Orchestrator così avrai
a
avere un modo per farlo in realtà questi
giorni gli strumenti Cice si lascia per lo più solo
lo script piuttosto che non è molto
difficile da fare sarebbe più bello se lì
sarebbe più profonde integrazioni con il
video orchestratori e un importante
punto su DevOps che il team ops crea
la lavorazione per la consegna continua
non prendono i manufatti dal
team di sviluppo e inserirli
produzione perché se questo sta accadendo
quindi non c’è scalabilità in
numero di servizi perché c’è solo
nessun modo il team operativo capirà
ogni nuovo servizio che deve essere
schierato il tuo team operativo avrà
per capire gli orchestratori di contenitori
esegui il debug li leghi insieme a
monitoraggio e registrazione delle soluzioni di regressione
mentre il tuo team di sviluppo deve farlo
fidati anche degli utenti della piattaforma
è molto importante l’abbiamo scoperto quando
gli sviluppatori hanno solo un non avere un
sufficiente conoscenza approfondita di come le cose
lavoro e loro non hanno bisogno di capire
come funzionano gli interni di Kubernetes, ma loro
bisogno di capire i concetti e come
per essere un utente esperto di loro poi loro
se ciò non accade non gli piace
per toccarlo e l’intero DevOps
l’esperienza soffre perché lo saranno
spingendo sempre di più il team ops
e il monitoraggio di nuovo ho già
mostrato ma ora da un DevOps
prospettiva ancora il team ops offre
gli strumenti di cui potresti aver bisogno
debug inter-servizio così tu o te
avrà bisogno di un debug inter-servizio così a
la soluzione di aggregazione dei log sarà assolutamente
essere necessario inserire alcuni ID di correlazione
così puoi effettivamente trovare – quello che è successo
a una richiesta su diversi servizi
che siamo tutti coinvolti in realtà dentro
manutenzione che probabilmente sarà lavoro
vediamo di solito che le aziende non hanno
quel buon monitoraggio e sopravvivere con esso
abbastanza bene con il monolitico
l’architettura la mia ipotesi è dovuta a
impilare tracce soprattutto perché trasportano a
molte informazioni per scoprire dove come
una richiesta è passata all’interno dell’applicazione
ma lo perdi quando tu
avere servizi che comunicano su a
rete quindi dovrai effettivamente
aggregarli registrandoli da diversi
servizi e quindi assicurarsi che non lo fanno
guarda troppo perché poi è di nuovo
difficile scoprire qual è l’importante
cose
e infine DevOps DevOps sarà un
necessità assoluta e tu lo farai
potrebbe aver bisogno di un team operativo per sviluppare il
strumenti o si va in alcuni completamente
soluzioni gestite che sono là fuori
come abbiamo fatto con questo nostro cliente –
sono andati al motore del contenitore di Google
che è un kubernetes gestito usa il
soluzioni di monitoraggio gestite in Google
chiamare lo stack driver usa la gestione
database e ancora hanno finito con
un tizio deve fare le cose così
assicurati e se hai già un ops
squadra sul posto assicurarsi che non lo sono
distribuire applicazioni ma lo sono
sviluppando gli strumenti che il
gli sviluppatori quindi usano per distribuire il
le applicazioni e gli ambienti dovrebbero
anche la responsabilità dello sviluppatore
il team operativo non dovrebbe essere come
mantenendo l’ambiente di test su e
correndo in qualche modo sì, la vista ideale
di questo sistema sarebbe tutto questo
componenti separati e in esecuzione in
l’orchestratore quindi fanno il marinaio
viaggiato all’inferno per sconfiggere i demoni
lì ed è riuscito solo a vedere il
i demoni stanno ancora arrivando sulla terra dove lui
dovevano andare e sconfiggerli di nuovo a
infine salvare l’umanità sta andando essere un
giro brusco ma non dimenticare la tua nuvola
armi native e non aver paura di
i demoni ti ringraziano
tu
Please follow and like us: