ciao a tutti, grazie per esservi uniti a me
um So che tutti voi avete sentito parlare di micro
servizi ma chi sta effettivamente facendo micro
servizi whew se sei qui per
ascolta le nuove e interessanti tecnologie e
nuove e interessanti infrastrutture su come fare
micro servizi sei nella stanza sbagliata
questo discorso è fondamentalmente molto pratico
parlare di come passare da Manali a
micro servizi così la prossima volta che lo farai
essere alla conferenza si può dire io sono
sto andando anche io e lo farai
vedere che se si sta facendo il diritto
modo e con molta attenzione e prudenza
non è così difficile farlo è il mio nome
avi Ron e io sono a capo dell’ingegneria
per un po ‘di settimane
quelli di voi che non hanno sentito parlare
wix.com e quello che stiamo facendo Wix è un
sito web piattaforma di costruzione abbiamo praticamente
consentire alle persone senza alcun tecnico
conoscenza per costruire bel sito web noi
basta trascinare e ROPS
ci occupiamo di tutto, dall’hosting
progettare a qualsiasi cosa di cui hanno bisogno
per gestire un po ‘il loro sito web
numeri bit attualmente abbiamo oltre 86
milioni di utenti quelli sono il sito web
costruttori in tutto il mondo che ospitiamo oltre 2
petabyte di dati che eseguiamo in tre dati
centri e le due principali nuvole noi
gestire due miliardi di richieste HTTP al giorno
e attualmente ci sono 1200 persone che
lavora su Wix ma non sei qui per ascoltare
su questo numero giusto
in effetti senti di questo numero così
Wix è la piattaforma attualmente in corso
200 o oltre 200 fanno micro servizi in
produzione
e quando senti parlare di microservizi
senti molte parole d’ordine che senti
sugli interruttori automatici e distribuiti
scoperta di transazioni e servizi e
confine del servizio e tutte quelle parole d’ordine
che in realtà sono confusi e di tipo
spaventoso per cominciare se non lo fai davvero
sapere come fare tutte quelle cose proprio così
lascia che ti accompagni per il viaggio
viaggio che le settimane stavano facendo e come noi
devo eseguire 200 micro servizi in
produzione quindi è iniziato tutto verso le sei
anni fa, sei anni fa, Wix era in esecuzione
in un monolito quindi abbiamo avuto un server che
fondamentalmente ha fatto tutto da utente
registrazione alla modifica dei siti in
pubblicare siti per la visualizzazione – fondamentalmente
tutto ciò a cui puoi pensare tranne
dal caffè e quando ne stai facendo
modello se stai incontrando problemi
alla fine quando arrivi alla scala che abbiamo
dipendenze tra caratteristiche se tu
avere bug in una zona del sistema
che avrebbe portato l’intero sistema
e quello era un problema e per
risolvere quel problema per risolvere
le dipendenze ci permettono come società
per progredire più velocemente abbiamo dovuto capire
okay, cosa faremo ed è stato
tempo di iniziare a rompere il sistema ma
non è così facile rompere il sistema
al fine di rompere il sistema a parte te
prima devi capire come è il tuo
sistema è costruito in cosa consiste di
okay, quali sono le tue preoccupazioni, così quando noi
guardato il nostro sistema cerchiamo di dividerlo
da preoccupazioni e SLA così quando guardi
a settimane abbiamo che possiamo vedere due principali
attività che stanno andando bene
l’attività sta modificando i siti web in cui tu
avere
di molte richieste di funzionalità quindi la maggior parte delle nostre
presenta la maggior parte del nostro lavoro di sviluppo
sono fatti nella parte editor dove siamo
aggiungendo più funzionalità e più capacità
a quei siti Web e, naturalmente, in termini
della parte del database ed è scritto
intensivo aggiorniamo sempre il tuo sito e
l’altro lato dell’equazione è
in realtà guardando quei siti così dentro
visualizzazione del sito quindi abbiamo diverso
riguarda che deve essere un elevato throughput
altamente scalabile in termini di database
è davvero letto intensivo invece di
scrivere intensivo e deve davvero
esegui bene quindi è così che abbiamo iniziato
quindi abbiamo il nostro monolite e da noi
identificare quelle due parti in un primo momento cosa
abbiamo deciso di fare è crearne un altro
monolito
così abbiamo preso il monolite e la treccia si è rotta
in realtà due monoliti uno era
responsabile per il lato redazione e noi
appena estratto tutto ciò che noi
il pensiero farà parte del
guardando i freaks della parte di visualizzazione e noi
ha fatto un’altra cosa suddividendola
due abbiamo anche messo un confine chiaro tra
quei due non volevamo nessun runtime no
distribuzione e nessuna dipendenza dai dati
tra questi due servizi questo in realtà
ci ha permesso di separare il prodotto
ciclo di vita disaccoppiamo l’architettura
abbiamo avuto implementazioni indipendenti e via
la parte dell’editor mantiene le cose tenute
cambiando perché quelli sono i più
richieste di funzionalità e cosa consentito
noi è di avere la parte che è spettatore
fondamentalmente la nostra parte più importante della nostra
sistema perché vogliamo che i nostri siti web per
essere sempre attivo e funzionante
essere relativamente stabile un’altra cosa
che abbiamo guadagnato solo in quei due
Bernoulli è così non è molto
micro-servizi è troppo modesto
un’altra cosa che abbiamo guadagnato noi
ottenuto separazione per livello di servizio così
ora possiamo scalare indipendentemente e noi
avere la parte spettatore che diventa massiccia
la quantità di traffico pensa a quelli 86
milioni di utenti che stanno costruendo il loro
siti Web e questo è sul lato dell’editor
e sul lato pubblico è il loro
i visitatori vanno bene così sono centinaia e
centinaia di milioni di visitatori a
quei siti
così semplicemente separandoci in due possiamo
ora scala la parte pubblica in modo diverso
che possiamo fare nel lato editoriale
abbiamo molte più istanze che ora possiamo usare
diversi data store possiamo usare MongoDB
in una settimana è il mio sequel nel
altra Cassandra puoi usare qualunque cosa tu
voglio essere lo strumento giusto per il lavoro
non siamo più accoppiati nei nostri dati
memorizzare ci ha anche permesso di ottimizzare
coppia per caso d’uso possiamo ottimizzare il
dati per leggere da un lato e ottimizzare
i dati per scrivere sull’altro lato
siamo attuali diversi data center noi
effettivamente eseguito in diversi data center
quindi per l’editor che esegue due dati
centri e pubblico corre in tre
data center da superare e uno in
Amazon e ora ci stiamo anche spostando
Google in modo che possiamo aumentare il sistema
parti del sistema come abbiamo bisogno di noi
anche ottenere la resilienza del sistema se abbiamo a
bug e il sistema va giù diciamo
la maggior parte delle funzionalità sono nell’editor
se si modifica o ha bug e Dio non voglia
il sistema non funziona, non è il tutto
sistema è solo una parte del sistema
sta andando giù
e se solo una parte del sistema sta andando
giù
hai tempi di recupero più rapidi perché
non devi portare tutto
porti solo una parte del sistema
backup
quindi dividendoci in due due e
due monoliti abbiamo imparato molto e lo faremo
ripassa le cose che impari
semplicemente dividendola in due monoliti
nessun micro-servizio ne fa due
i monoliti sono microservizi è fondamentalmente
parola stronzate va bene solo a me scusa che
Sto dicendo che è orientato al servizio
l’architettura è fatta bene e non è così
importa se si tratta di due monoliti o di un 200
microservices è semplice fatto di
disaccoppiare la tua architettura e e
farlo funzionare così morbido come in realtà così
non era pronto a lavorare bene così il primo
cosa che abbiamo fatto è fondamentalmente
capito il nostro confine di servizio che abbiamo diviso
in due aree indipendenti del sistema
e una delle migliori cose che puoi
fare per aiutarti a fare il
separazione e aiutarti a capire il
il confine del servizio è quello di separare il
database okay nessuna condivisione di due servizi
database e puoi chiedere ok, ma io sono
modificare qualcosa e voglio vederlo
sul lato opposto così che cosa ho bisogno per
fai e in realtà copi i dati così
durante un nostro caso d’uso quando un utente
clicca pubblica ciò che facciamo è prendiamo i dati
dall’editor e in realtà copio
tutto ciò di cui abbiamo bisogno non è tutto
ogni volta che abbiamo bisogno e ottimizziamo per essere
leggi sul lato pubblico
ora una volta che hai fatto ciò che devi
considera ok, ma come faccio a copiare i dati
bisogno di pensare alla serializzazione come si fa
serializzo i dati così ora vieni
per cercare bene, quindi cosa dovresti usare?
dovresti usare il binario se dovessi usare
Il testo JSON XML è su HTTP che hai
tutte quelle considerazioni e tutte quelle
le decisioni che devi rendere ciò che è
il protocollo quali sono i tuoi trade-off
ok quando scegli l’una rispetto all’altra
ciò che è più importante per te è questo
leggibilità è la prestazione come fai tu
bug, quali sono gli strumenti che hai
che sai che puoi trovare bene come
lo monitora quali sono i
dipendenze che introduci
la tua build e la tua implementazione
sistema perché scegli un formato
sull’altro e ora che tu sei
servizi di chiamata a cui devi pensare
API versione il trasporto dell’API
protocollo come esponi l’API tramite
riposa l’RPC via sapone, dio, per non farlo
preso tutte quelle opzioni che in realtà
iniziato in un formato binario usiamo il nostro
piselli e abbiamo scoperto che era davvero
difficile da debugare e per i nostri casi d’uso
mentre un formato binario è più veloce
non ha fatto davvero alcuna differenza per noi
per il nostro caso d’uso quindi abbiamo deciso di ottenere
liberare il formato binario e spostarsi verso
JSON a JSON RPC su HTTP che tu
sa Jackson è un parser molto veloce
puoi usarlo puoi usare gli strumenti è
in realtà basato sul testo puoi leggerlo tu
riesci a eseguirne il debug, puoi loggarlo molto molto
facilmente
e questo è per il nostro interno
comunicazione dall’esterno quando noi
esporre API a Internet, quindi usiamo
resto è più facile per gli sviluppatori
usa il riposo ma per noi interni in realtà
stiamo usando un JSON su RPC perché
è digitato è più facile testare ora il
la prossima cosa che stai bene così tu
avere una API quindi come si fa API
versioning
devi pensare agli schemi API
versione 1 versione 2 e ricordiamo solo noi
avere due servizi ecco che voglio
introdurre lo yakhni per quelli di voi no
sai cos’è la ghinea, non lo sei
ne avrò bisogno
all’inizio non va bene quello che usi
la retrocompatibilità non dà fastidio
te stesso con tutte quelle cose che tieni
pianificare in anticipo quando ti piace
centinaia di microservizi e centinaia
di endpoint e un client esterno quando
si inizia non si ha quello ok è
più facile mantenere la retrocompatibilità
e e tutti gli sviluppatori sono interni
e non devi mantenere è che non lo fai
avere la sopra l’overhead di
mantenimento del mantenimento del controllo delle versioni
le stesse ragazze chiamano ora in modo asincrono
che hai due diversi servizi
se dovessi presentare Kafka non dovrebbe
ridurre RabbitMQ attivo in coda qualunque
in coda ora pensaci quando l’hai fatto
uno manualmente hai avuto quelli
sistemi di messaggistica se continuate a utilizzare
qualunque cosa tu avessi ma se non lo avessi fatto
introdurre qualcos’altro e tu no
avrò bisogno di usare il filo se lo usi
discussioni prima ancora di poter utilizzare i thread
ogni volta che ne presenti un altro
middleware per il tuo sistema sei
introducendo DevOps in testa ricorda
stai correndo su un sistema di produzione
e la cosa più importante su
sistema di produzione è per mantenerlo funzionante
ogni volta che presenti un’altra cosa
sei nel tuo sistema di produzione
introducendo DevOps in testa se tu
non ho usato la messaggistica prima di non usarla
ora perché hai solo due servizi
quando avrai molto e il tuo sistema
si evolve e ne hai bisogno solo allora
introdurre nuove tecnologie non introdurre
nuova tecnologia solo perché mi hai sentito
non mi conosci o Netflix o Google
questo è un hey che abbiamo ottenuto questa fresca accodata
sistema o qualunque cosa riguardo al servizio
scoperta ora abbiamo zookeeper insegna
dalla console se vedi l’Eureka tutto
quelle cose che devi scegliere
da destra perché ora ne hai due
servizi e hai bisogno di scoprirli
non avrai bisogno di bilanciatori di carico
e la voce DNS è la soluzione perfetta
sai che otto settimane ne abbiamo 200
servizi di micro e noi ancora non abbiamo
che in questo momento, quando si corre si al 200
abbiamo iniziato a pensare al servizio
scoperta perché abbiamo 200 ma fino a quando
poi
Il DNS è perfetto, non ridurlo
più spese generali
la resilienza della resilienza è molto importante
Va bene perché ora che stai ricevendo in
mondo dei sistemi distribuiti e quando
quando vedi questo diagramma questo è un
sistema distribuito ok vedi questa freccia
cosa significa significa molto importante
cosa significa che ora hai un
punto di fallimento non stai più chiamando a
funzione sul tuo monolite se il server
è in esecuzione la funzione verrà chiamata
ok ora quando chiami qualcos’altro
potrebbe non riuscire a introdurre la rete così
ogni hub di rete che introduci
la definizione riduce la tua disponibilità e
ci sono modi per superarlo ma è così
riduce la tua disponibilità alla funzione
chiamare ciò che hai appena fatto potrebbe non esserlo
eseguito così come si fa a superare lo
diversi modelli di cui hai bisogno
capire e sapere come usare
correttamente ok, quindi hai ottenuto il tuo tentativo
politica, ma tu hai solo la cura
tentativi sulle operazioni intento di inattività si
non voglio caricare le persone due volte, ora
avere interruttori di circuito e errori del motore
ancora quelli devono essere molto ben sintonizzati
potresti causare i tuoi tempi di inattività, se tu
presto anche questa interruzione del circuito
presto causerai i tuoi tempi morti
va bene se si interrompe il circuito quando si è solo
avere un server dipende da te, quindi
quelli sono gli schemi che tu
ho bisogno di essere sperimentato con te
bisogno di capire e ti troverai
fallirà sicuramente lo farà
combattiamo fino a poco a poco e
loro si alzarono e lo sistemarono e capirono
come funziona per il nostro sistema ma il
il fatto che tu abbia questo punto di errore
può essere davvero una buona cosa
una buona cosa per il tuo cliente
esperienza perché ora se il servizio
fallisce invece di un completo down time
puoi avere un degrado del servizio
giusto così se l’editor è giù nel nostro
i case case possono ancora essere visualizzati , non è così
che tutto è giù o niente
puoi avere come lo chiamiamo un killer
funzione che è un kill switch per
caratteristiche in modo che possiamo abbattere con grazia
sottosistemi ok questo al momento no
lavoro tornare più tardi e sarai
in grado di modificare il tuo sito ma puoi ancora
vederlo ok puoi usare fallback e
meccanismo di auto-guarigione che puoi iniziare
utilizzando la coerenza finale, ad esempio
ti daremo un esempio per una riserva
per i dati così quando pubblichi un sito
sei in settimane in cui è composto il tuo URL
il tuo nome utente taglia la barra punti-com
qualunque sia il nome del tuo sito e l’utente
il nome viene prelevato dal server dell’utente
ok, qual è l’ultimo nome utente perché
puoi rinominare ora nel caso in cui il
il server utente è inattivo, abbiamo un errore
non lo facciamo non dobbiamo fallire il
transazione abbiamo effettivamente l’utente
nome già memorizzato nella tua sessione
cookie in modo da poter avere un fallback solo
prendilo da lì a cui devi pensare
tutte le borse difettose se ti interessa davvero
sulla disponibilità di cui avrai bisogno
pensa a quella scatola del guasto che puoi
che si può che si può prendere se si
vuoi caricare materiale su un altro
servizio e non funziona davvero bene
ora puoi vendere riempilo più tardi
testare è importante, facciamolo
imparalo a testare così ora lo sei
testare un sistema distribuito va bene lo è
non solo test di unità , quindi è così
il modo in cui testiamo, intendo tutti
può avere il proprio sapore di come loro
prova così è il modo in cui eseguiamo il nostro test
per prima cosa eseguiamo il test unitario su
servizio stesso la prossima cosa che facciamo
è che noi lo chiamiamo un test di integrazione
in realtà testiamo anche la serializzazione
mettiamo come server falsi o semplicemente
approvvigiona noi non prendiamo in giro il servizio che abbiamo appena
metti un falso servizio così possiamo effettivamente
prova la serializzazione prossima cosa siamo noi
fare un server end-to-end quando in realtà
eseguire l’intero servizio e tutto è
dipendenze relazioni reali il
primo strato di dipendenze e al
alla fine eseguiamo il test di automazione che è
dal browser in tutto il sistema
e questo funziona come di notte e circa
registrazione
hai un sistema distribuito proprio tu
bisogno di una registrazione distribuita non proprio
devi solo scrivere due servizi se
non avevi come lo stash di registro prima o
qualsiasi cosa distribuita più tempo prima di te
non c’è bisogno di usare proprio ora che siamo a
Spiega in ogni caso che non ci piace davvero
registrarsi è davvero difficile
sviluppatore per guardare effettivamente i log
accanto mostrami uno sviluppatore che posso
in realtà scrivere un buon registro e puoi farlo
in realtà trovare queste informazioni che non ha
basta copiare come una configurazione di registro dalla
internet e attaccalo adesso
giusto loggare quello che preferiamo è in realtà
esporre tutte le informazioni al nostro
sviluppatori quindi questo è parte del nostro micro
servizi quadro ogni micro servizio
espone tutte le metriche in una bella rete
interfaccia
gli sviluppatori non hanno bisogno di andare e
SSH la macchina può andare su una rete
interfaccia e guarda tutte le metriche che vediamo
le voci del registro recenti possono vedere
tutto ciò che ricordo è giusto …
funziona anche con le centinaia solo
dopo aver avuto un centinaio di micro
servizi solo allora abbiamo iniziato a mettere
come – sistema di registrazione realmente distribuito
bilancia perfettamente bene
ora la proprietà è un fattore chiave se tu
vuoi fare sistemi distribuiti se tu
voglio lavorare con i micro servizi e a
molti di loro la proprietà è la chiave qui va bene
non puoi scalare la tua squadra ops è il
numero di micro servizi che hai
così micro servizio è di proprietà di un team IT
non è di proprietà di una persona è
non un codice che puoi mettere e dimenticare
e se una persona lascia, non ha proprietario
il team possiede i micro servizi e se
lo costruisci allora tu sei quello che
è in esecuzione sei tu quello che
sta monitorando il tuo drone che è
responsabile se una persona lascia
la squadra due cose possono accadere se a
la persona possiede un micro servizio che può assumere
il micro servizio con lei al nuovo
squadra e mantenerla con la nuova squadra
oppure il micro servizio cambia proprietà
all’interno di una squadra così altre persone nel
il team è ora proprietario del micro servizio
una delle cose buone in cui facciamo
per garantire che ogni micro servizio
ha un proprietario è noi facciamo continuo
consegna e ogni micro servizio deve
essere distribuito alla produzione almeno una volta
un mese quindi ogni mese riceviamo un avviso
se qualcosa non è stato distribuito a
produzione con l’ultima revisione di
le strutture e tutto ciò che puoi
solo un mese indietro stantio
assicura che nulla venga lasciato indietro
e che ci porta alla più
domande interessanti su
microservizi che devo ancora trovare
rispondi e ti risponderò per te
qual è la giusta dimensione di a
il micro-servizio è una domanda stupida se
me lo chiedi perché ora ne abbiamo due
monolite quindi qual è la giusta dimensione quelli
è possibile chiamare loro micro-servizi IT
Non ha molta importanza ecco arriva
Conway
si, la legge di Conway dice ok
l’architettura è determinata dalla
struttura organizzativa quindi se hai
un sacco di gente lo capirai
lavorando sullo stesso progetto che otterrai
un monolite quindi la dimensione del micro-servizio
è la dimensione della squadra che sta costruendo
questo è uno dei motivi per cui costruiamo piccoli
squadre e costruiamo piccoli assaggi di
costruendo piccole stanze dove i nostri uffici
sono una specie di piccolo tra quattro e sette
le persone e basta se la squadra ha bisogno
per crescere hanno bisogno di andare in un altro
stanza ed è fondamentalmente una nuova squadra e
creeranno il loro micro
servizi quindi cosa hai imparato finora
con solo due monoliti impariamo a conoscere
scoperta del servizio impariamo come
monitora quelli okay abbiamo esperienza noi
scelto questa realizzazione non lo è
sincrono lo SLA del servizio come
definiamo l’API è la distribuzione
strategie
va bene la separazione dei dati di darris è lì
come testarlo per mantenere la compatibilità
la compatibilità è davvero difficile, intendo la maggior parte
del tempo in cui non si riesce voi ragazzi siete
perché qualcuno non ha fatto retromarcia
compatibilità la maggior parte delle volte vedi così
semplicemente estraendo due monoliti e
trattalo come un micro servizio
architettura imparerai molto
e fai grandi progressi se tu
non fare tutte le spese generali di tutto il
cose che non hai davvero bisogno di fare
non all’inizio non così tanto ora che noi
conosci tutte quelle cose che possiamo continuare a
estrarre sempre più micro servizi e
le cose che abbiamo fatto sono noi in realtà
mantenuto l’idea della separazione entro
SLA quindi ogni micro servizio che noi
costruito la prima domanda che chiediamo alla nostra
gli sviluppatori è a quale segmento appartiene
fa parte del segmento dell’editor
o il segmento pubblico è più letto
intensivo o di scrittura intensiva è così
il nostro sistema è ovviamente una visione parziale
può mettere come 210 anni quindi questo è il modo
Wix è un micro servizio che sembra ok così
alcuni dei micro servizi sono nel
l’editor segmenta alcuni dei micro
i servizi sono nel segmento pubblico e
questo ha aiutato gli sviluppatori a capire e
pensa a quali sono i miei requisiti per
da questo servizio va bene per lo più
giusto qual è la scalabilità e
problemi di disponibilità che ho fatto io
vuoi eseguirlo in due datacenter o a
almeno due data center okay, qual’è il mio
uptime è novantanove virgola nove o
novantanove virgola nove nove così via
definisce veramente i tuoi requisiti da
quel servizio e una cosa che se
tu pensi che io abbia davvero bisogno di entrambi
loro questa è davvero una buona indicazione
forse dovresti dividerlo in due micro
servizi e non solo costruire un monolite
o un micro servizio più grande
quindi qual è il tempo di estrarli nuovi
micro-servizi, quindi pensiamo di fare
pensa che è necessario aggiungere un nuovo
funzionalità va bene così puoi farlo come a
micro servizio o una biblioteca prendiamo un
esempio diciamo che ho bisogno di un fuso orario
lo chiameremo un servizio per ora
prende l’IP della richiesta va a max
il database delle miniere capisce che ore sono
zona e propagare tali informazioni a
il servizio di cui aveva bisogno in modo che possiamo andare
in entrambi i casi possiamo costruire una biblioteca o noi
può costruire un micro servizio che darà
noi questa informazione e c’è una serie
di domande che dobbiamo chiedere
noi stessi introducendo questa cosa, io
creare una dipendenza di distribuzione se io
modificarlo Ho un DevOps overhead
necessita di un database che lo mantenga
database che possiede questo codice lo fa in forma
le preoccupazioni di scalabilità che ho per
questo servizio può avere una squadra diversa
sviluppalo devi chiederti tutto
quelle domande e una semplice regola di
thumb is is micro service has ops
la biblioteca è per lo più computazionale, va bene così
in questo caso dove vogliamo un tempo
zona da un IP ha bisogno di andare a
database se il database è di solito
locale e non voglio dare uno stile a questo
installa questo database su tutti gli altri
servizio che ho così in questo caso
sarà un micro servizio che non voglio
creare questa dipendenza che non voglio
crea questo overhead DevOps che ora
ogni proprietario di servizi di micro necessità
questa biblioteca dovrà mantenere un annuncio
database così è
micro-servizio che è la squadra
responsabile e il suo mantenimento e
tutti gli altri solo consumare come un
servizio ora quando stiamo parlando
micro servizi una delle cose che
puoi fare è hai la libertà di
scegli molte azioni in modo da poter avere
diversi segnali che puoi avere
diversi database che si possono usare
Cassandra si può usare il mio sequel
usa Couchbase puoi usare qualsiasi Mongo
il proprietario del servizio microt può usare qualsiasi cosa
hanno bisogno o qualunque cosa vogliano che sia
peggio per i propri micro servizi
questo è vero che non lo consiglio vivamente
facendo tutto bene dovresti limitare il tuo
azione va bene
default ha fatto lo stack che conosci e
il motivo è che è di nuovo DevOps
se tutto avrà il suo
solo il middleware che la squadra saprà come
di gestirla e come operare che nel
produzione se la maggior parte delle squadre condivide
lo stesso standard o lo stesso middleware
possono condividere la conoscenza che possono loro
può arrivare a una soluzione a una risoluzione
sulla crisi produttiva e sui tempi di fermo
molto molto veloce perché possono condividere
la loro conoscenza se qualcuno sta facendo
qualcosa che nessun altro sa che è un
Squadra molto piccola che può effettivamente gestire
la crisi
ma non ti impedisce di partire
innovare dall’innovazione che puoi
innovare su un non critico
micro-servizi se hai qualcosa di nuovo
che costruisci e che è un nuovo
micro servizio e tu pensi che hey mio
stack attuale non è lo strumento giusto
per il lavoro va benissimo
innovare avviare una nuova prova di micro servizio
fuori vedi come funziona il resto del
sistema è stabile se funziona attendere
fino a quando non inizieranno uno o due altri team
usando la tua nuova tecnologia o nuovo stack
e poi renderlo uno standard
tutti possono effettivamente usarlo per condividere il
la conoscenza diffonde la conoscenza no
tenerlo contenuto all’interno di una squadra
che dire del linguaggio di programmazione che puoi
scrivere micro servizi in qualsiasi lingua
proprio in Scala e PHP in qualsiasi nodo
ma dovresti di nuovo probabilmente lo vuoi
per limitare il tuo stack anche qui va bene
perché se scrivi in più
le lingue che poi devi non puoi fare
un riutilizzo del codice
avete preoccupazioni trasversali che
devono essere affrontati da qualsiasi micro
convalide delle sessioni di sicurezza dei servizi
controllo di registrazione testare lo stesso il
stessa infrastruttura necessaria per l’esecuzione
deve essere un sistema di produzione dell’operatore
ri-implementato in tutti gli stack
se vuoi cambiare la tua crittografia
algoritmo ora devi aspettare fino a quando
ogni servizio micro scritto in a
lingua diversa dovrà
attuarlo prima di poter rotolare fuori
che rendono le cose davvero davvero
ci vuole molto tempo e vogliamo progredire
veloce quindi prova a limitare il tuo stack al
il minimo indispensabile se non sono davvero
non è lo strumento giusto per il lavoro che hai
altra scelta se non per la sua attuazione, ma in realtà
stai attento a non farlo
fuori bordo e con tutti i microservizi
essendo scritto in una lingua diversa così
ricorda di tenerlo semplice DevOps è davvero
davvero importante e quando sei cresciuto
avete un sacco di micro-servizi IT
diventa sempre più grande e più grande
in testa trascorrerai più tempo dentro
gestire la produzione più micro
servizi che hai quindi ricapitoliamo
cosa abbiamo imparato ora continuiamo a
conoscere le transazioni di disabilità e
monitoraggio del sistema e tracce distribuite
come si traccia una chiamata che va
attraverso cinque micro servizi come fai tu
sapere come va quel micro servizio
quale server ha risposto alla chiamata che ti serve
per conoscere questa cosa e capirla
scambi di nuovi micro servizi
estendere un micro servizio esistente o
creane uno nuovo per aggiungerne di nuovi
funzionalità
qual è la tua strategia di implementazione ora tu
avere una funzione che dipende da on
due o tre servizi micro da essere
implementato dovrai imparare tutto
questo come si va come si gestisce
guasti a cascata quando un server
inizia a rispondere lentamente che non vuoi
per far cadere tutta la catena di
servizi di micro che stanno chiamando voi
avrà bisogno di sapere e imparare come
per gestire queste cose è più facile
ora costruisci nuovi team e dividi nuovi team
ok perché ora ogni squadra può avere un
piccolo sottoinsieme di responsabilità ma
La grande domanda è il motivo per cui perché dovreste
mai voglia di fare questo a te stesso perché farlo
vuoi andare ai micro-servizi è
non perché sei qui e sto parlando
a riguardo e Netflix ne parla
e Google parlando di ciò che non è
la ragione per andare ai microservizi va bene
i micro-servizi vengono per risolvere un problema
va bene se non hai problemi
bastone con qualunque cosa tu abbia il primo
il problema che risolve è l’ ingegneria
scala se hai molti ingegneri
che lavorano in un popolo di monoliti
si calpesteranno l’un l’altro se tu
voglio andare veloce , è meglio averli
divisi in piccole squadre che ciascuno ha
la propria responsabilità è il suo sviluppo
velocità se hai squadre piccole loro
può progredire molto più velocemente di quello che hanno
condividere lo stesso codebase e distribuire
e aspettatevi l’un l’altro
hey ho finito con questa funzione ma
ehi, ma dobbiamo schierarci insieme così noi
c’è bisogno di aspettare fino a quando questa squadra e QA
se lo dividi in piccoli pezzi, il tuo
la velocità di sviluppo sarà molto più alta
e la terza ragione è ridimensionamento ora quando
stai andando ai micro servizi che puoi
ora ridimensiona le diverse parti in modo diverso
scalabilità come relè se non si dispone
qualcuno di questi problemi rimane con qualsiasi cosa
non sei entrato nel micro servizio ism
ora microservices è il primo post
L’architettura DevOps è la cultura
davvero molto importante
se non hai una cultura DevOps , non farlo
anche tentare di andare lì è un enorme
importante in proprietà e il diritto
stato d’animo per mantenere questo tipo di
sistema distribuito e ricorda ogni
il micro servizio è alla fine un DevOps
in testa quando aggiungi qualcosa di cui hai bisogno
qualcuno per mantenerlo non è un
codice throwaway è una produzione dal vivo
sottosistema con cui sta giocando
tutti gli altri quindi è tutto
compromessi e ricorda che pensiamo se tu
bisogno se stai aggiungendo qualcosa pensa
davvero molto attentamente se ne hai bisogno se tu
non ne hanno bisogno non usarla non usarla
perché ne hai sentito parlare da qualche parte se
hai un problema risolvilo con
la tecnologia ok non si limita a introdurre nuovi
La tecnologia al tuo al tuo stack solo
perché è bello o lo pensi
ne avrai bisogno
in fondo alla strada, aspetta fino a quando non lo fai davvero
avere un problema quindi questo è fondamentalmente
piccola serie di linee guida che abbiamo messo a disposizione
i nostri sviluppatori su come creare e
uno dei compromessi tra quando
creando il nuovo microservizio di più
cosa importante che ogni micro servizio
ha un proprio database non due micro
i servizi sono autorizzati a scrivere al
stesso database crea l’accoppiamento se tu
avere una considerazione sulle prestazioni è
ok per avere un servizio di micro sola lettura
quel database di condivisione ma poi il
il trade-off è l’accoppiamento, se necessario
cambia qualcosa nello schema ora tu
devono prendersi cura di due micro servizi
o tre al fine di gestire il tuo
spiegamento giusto okay
e ricorda se hai un problema in
I microservizi Manali non risolveranno
il tuo problema per dividerlo in molti
altri problemi e penso di aver finito
grazie
le diapositive sono lì se vuoi
scaricalo quindi abbiamo tempo per
domande
eccellente sì, grazie mille per primo
di nuovo un rapido promemoria per favore prima di te
lascia la stanza assicurati di votare
l’applicazione non abbiamo ricevuto alcuna
domande prima anche se solo tu
ho come due servizi ma tu no
avere il rilevamento dei servizi come ti
gestire il failover in una seconda istanza in
caso di guasto di uno che la logica è necessario
inserisci il tuo bilanciamento del carico così quando lo sei
in esecuzione in un cluster se un servizio
il bilanciamento del carico fallito sa davvero
fa parte della logica di un carico
bilanciatore sa quali istanze sono fallite
così che la logica è nel bilanciamento del carico così
davvero non devi preoccuparti di questo
si sta prendendo cura di un altro
domanda interessante quando si rompe
il tuo sistema in più servizi
non hanno la loro interfaccia utente o è il
UI stessa servizi come è che impostare
beh dipende da cosa ci piace fare
avere ogni sottosistema ha il suo
UI quindi è un discorso che si sia stur
di una propria serie di servizi di micro esso
in realtà dipende il vostro business
caso d’uso aziendale ma ci piace dividere
l’interfaccia utente anche sì abbiamo un numero di
domande penso che alcuni di loro siano stati
ha risposto nella tua presentazione ma
nel complesso parlando qual è stato il tuo più grande
sfida quando si implementa micro
servizi e guardando indietro ora essere
su 150 micro servizi cosa vorresti
hai fatto diversamente sapendo cosa tu
ora so che questa presentazione è basata su
la lezione che ho imparato intendo quando noi
iniziato abbiamo davvero pensato di fare
come il bilanciamento del carico lato client e
ha iniziato a implementarlo e a farlo
interruttori che abbiamo finito per non
usando perché non sapevamo come usare
così abbiamo pensato che avremmo avuto bisogno di un
molte cose, ma in realtà lo pensiamo
che abbiamo perso un sacco di tempo
costruendo quelli
cose che non abbiamo usato e anche quando
li abbiamo usati li abbiamo pensati bene
iniziato a usare quegli strumenti come dopo a
mentre dopo abbiamo avuto come 50 o 100
microservizi e la cosa che noi
pensavo che lo saremmo
risolverò per noi quando l’abbiamo iniziato
non era lo stesso problema, quindi in realtà
non ha usato la soluzione giusta per il
problema che incontriamo in realtà dopo
facendolo nella vita reale
va bene una domanda in termini più generali
come ti occupi della sicurezza?
avere cose come il single sign-on impostato
sì, quindi in realtà ne abbiamo due
meccanismi uno è per il nostro interno
sign-on e e abbiamo auth che lo fa
un single sign-on praticamente passiamo
gettoni tra i servizi sono tutti
firmato in modo da poter verificare che il
la firma è corretta
un’altra domanda come si assicura
replica del database tra servizi se
in realtà non condividono un singolo
database in modo che ogni database sia indipendente
quindi abbiamo un database per micro
servizio è stato replicato che hai
un altro database viene replicato
possiamo condividere le macchine del database solo
non condividere gli stessi schemi tra
microservizi quindi di solito ce l’abbiamo
un database con molti schemi ciascuno
microservice ha il suo schema così noi
non ridurre qualsiasi accoppiamento tra il
dati e il codice ma noi replichiamo
nuovamente i database per schema
versioning se il numero di consumatori
per un particolare servizio è in aumento
riesci ancora a farla franca con il solo fare
compatibilità all’indietro o hai un
forma di versioning in atto no noi no
avere una forma di posto di versione non
internamente comunque esternamente sì perché
è più difficile far muovere le persone che sei
non in controllo ma dentro il nostro
organizzazione facciamo ancora all’indietro
compatibilità se abbiamo bisogno di fare a
rompendo il cambiamento , introduciamo solo un
nuova API
e diciamo a tutti che ora è necessario
per passare a questa nuova API e ne hai una
a tre mesi per farlo e dopo
lo uccidiamo e chiunque non viene mosso
e lui si spezzerà
ovviamente abbiamo dato loro il periodo di ingresso
non è che faremo lo stiamo pausa, ma
li rompiamo per circa cinque minuti okay
ora hai una settimana per implementarlo
e poi potremo davvero romperti
qualsiasi domanda da parte della gente della stanza
Mi piace chiedere giù, allora penso che lo siamo
fatto così grazie mille e grazie
per favore dai loro un altro giro di
applausi
um So che tutti voi avete sentito parlare di micro
servizi ma chi sta effettivamente facendo micro
servizi whew se sei qui per
ascolta le nuove e interessanti tecnologie e
nuove e interessanti infrastrutture su come fare
micro servizi sei nella stanza sbagliata
questo discorso è fondamentalmente molto pratico
parlare di come passare da Manali a
micro servizi così la prossima volta che lo farai
essere alla conferenza si può dire io sono
sto andando anche io e lo farai
vedere che se si sta facendo il diritto
modo e con molta attenzione e prudenza
non è così difficile farlo è il mio nome
avi Ron e io sono a capo dell’ingegneria
per un po ‘di settimane
quelli di voi che non hanno sentito parlare
wix.com e quello che stiamo facendo Wix è un
sito web piattaforma di costruzione abbiamo praticamente
consentire alle persone senza alcun tecnico
conoscenza per costruire bel sito web noi
basta trascinare e ROPS
ci occupiamo di tutto, dall’hosting
progettare a qualsiasi cosa di cui hanno bisogno
per gestire un po ‘il loro sito web
numeri bit attualmente abbiamo oltre 86
milioni di utenti quelli sono il sito web
costruttori in tutto il mondo che ospitiamo oltre 2
petabyte di dati che eseguiamo in tre dati
centri e le due principali nuvole noi
gestire due miliardi di richieste HTTP al giorno
e attualmente ci sono 1200 persone che
lavora su Wix ma non sei qui per ascoltare
su questo numero giusto
in effetti senti di questo numero così
Wix è la piattaforma attualmente in corso
200 o oltre 200 fanno micro servizi in
produzione
e quando senti parlare di microservizi
senti molte parole d’ordine che senti
sugli interruttori automatici e distribuiti
scoperta di transazioni e servizi e
confine del servizio e tutte quelle parole d’ordine
che in realtà sono confusi e di tipo
spaventoso per cominciare se non lo fai davvero
sapere come fare tutte quelle cose proprio così
lascia che ti accompagni per il viaggio
viaggio che le settimane stavano facendo e come noi
devo eseguire 200 micro servizi in
produzione quindi è iniziato tutto verso le sei
anni fa, sei anni fa, Wix era in esecuzione
in un monolito quindi abbiamo avuto un server che
fondamentalmente ha fatto tutto da utente
registrazione alla modifica dei siti in
pubblicare siti per la visualizzazione – fondamentalmente
tutto ciò a cui puoi pensare tranne
dal caffè e quando ne stai facendo
modello se stai incontrando problemi
alla fine quando arrivi alla scala che abbiamo
dipendenze tra caratteristiche se tu
avere bug in una zona del sistema
che avrebbe portato l’intero sistema
e quello era un problema e per
risolvere quel problema per risolvere
le dipendenze ci permettono come società
per progredire più velocemente abbiamo dovuto capire
okay, cosa faremo ed è stato
tempo di iniziare a rompere il sistema ma
non è così facile rompere il sistema
al fine di rompere il sistema a parte te
prima devi capire come è il tuo
sistema è costruito in cosa consiste di
okay, quali sono le tue preoccupazioni, così quando noi
guardato il nostro sistema cerchiamo di dividerlo
da preoccupazioni e SLA così quando guardi
a settimane abbiamo che possiamo vedere due principali
attività che stanno andando bene
l’attività sta modificando i siti web in cui tu
avere
di molte richieste di funzionalità quindi la maggior parte delle nostre
presenta la maggior parte del nostro lavoro di sviluppo
sono fatti nella parte editor dove siamo
aggiungendo più funzionalità e più capacità
a quei siti Web e, naturalmente, in termini
della parte del database ed è scritto
intensivo aggiorniamo sempre il tuo sito e
l’altro lato dell’equazione è
in realtà guardando quei siti così dentro
visualizzazione del sito quindi abbiamo diverso
riguarda che deve essere un elevato throughput
altamente scalabile in termini di database
è davvero letto intensivo invece di
scrivere intensivo e deve davvero
esegui bene quindi è così che abbiamo iniziato
quindi abbiamo il nostro monolite e da noi
identificare quelle due parti in un primo momento cosa
abbiamo deciso di fare è crearne un altro
monolito
così abbiamo preso il monolite e la treccia si è rotta
in realtà due monoliti uno era
responsabile per il lato redazione e noi
appena estratto tutto ciò che noi
il pensiero farà parte del
guardando i freaks della parte di visualizzazione e noi
ha fatto un’altra cosa suddividendola
due abbiamo anche messo un confine chiaro tra
quei due non volevamo nessun runtime no
distribuzione e nessuna dipendenza dai dati
tra questi due servizi questo in realtà
ci ha permesso di separare il prodotto
ciclo di vita disaccoppiamo l’architettura
abbiamo avuto implementazioni indipendenti e via
la parte dell’editor mantiene le cose tenute
cambiando perché quelli sono i più
richieste di funzionalità e cosa consentito
noi è di avere la parte che è spettatore
fondamentalmente la nostra parte più importante della nostra
sistema perché vogliamo che i nostri siti web per
essere sempre attivo e funzionante
essere relativamente stabile un’altra cosa
che abbiamo guadagnato solo in quei due
Bernoulli è così non è molto
micro-servizi è troppo modesto
un’altra cosa che abbiamo guadagnato noi
ottenuto separazione per livello di servizio così
ora possiamo scalare indipendentemente e noi
avere la parte spettatore che diventa massiccia
la quantità di traffico pensa a quelli 86
milioni di utenti che stanno costruendo il loro
siti Web e questo è sul lato dell’editor
e sul lato pubblico è il loro
i visitatori vanno bene così sono centinaia e
centinaia di milioni di visitatori a
quei siti
così semplicemente separandoci in due possiamo
ora scala la parte pubblica in modo diverso
che possiamo fare nel lato editoriale
abbiamo molte più istanze che ora possiamo usare
diversi data store possiamo usare MongoDB
in una settimana è il mio sequel nel
altra Cassandra puoi usare qualunque cosa tu
voglio essere lo strumento giusto per il lavoro
non siamo più accoppiati nei nostri dati
memorizzare ci ha anche permesso di ottimizzare
coppia per caso d’uso possiamo ottimizzare il
dati per leggere da un lato e ottimizzare
i dati per scrivere sull’altro lato
siamo attuali diversi data center noi
effettivamente eseguito in diversi data center
quindi per l’editor che esegue due dati
centri e pubblico corre in tre
data center da superare e uno in
Amazon e ora ci stiamo anche spostando
Google in modo che possiamo aumentare il sistema
parti del sistema come abbiamo bisogno di noi
anche ottenere la resilienza del sistema se abbiamo a
bug e il sistema va giù diciamo
la maggior parte delle funzionalità sono nell’editor
se si modifica o ha bug e Dio non voglia
il sistema non funziona, non è il tutto
sistema è solo una parte del sistema
sta andando giù
e se solo una parte del sistema sta andando
giù
hai tempi di recupero più rapidi perché
non devi portare tutto
porti solo una parte del sistema
backup
quindi dividendoci in due due e
due monoliti abbiamo imparato molto e lo faremo
ripassa le cose che impari
semplicemente dividendola in due monoliti
nessun micro-servizio ne fa due
i monoliti sono microservizi è fondamentalmente
parola stronzate va bene solo a me scusa che
Sto dicendo che è orientato al servizio
l’architettura è fatta bene e non è così
importa se si tratta di due monoliti o di un 200
microservices è semplice fatto di
disaccoppiare la tua architettura e e
farlo funzionare così morbido come in realtà così
non era pronto a lavorare bene così il primo
cosa che abbiamo fatto è fondamentalmente
capito il nostro confine di servizio che abbiamo diviso
in due aree indipendenti del sistema
e una delle migliori cose che puoi
fare per aiutarti a fare il
separazione e aiutarti a capire il
il confine del servizio è quello di separare il
database okay nessuna condivisione di due servizi
database e puoi chiedere ok, ma io sono
modificare qualcosa e voglio vederlo
sul lato opposto così che cosa ho bisogno per
fai e in realtà copi i dati così
durante un nostro caso d’uso quando un utente
clicca pubblica ciò che facciamo è prendiamo i dati
dall’editor e in realtà copio
tutto ciò di cui abbiamo bisogno non è tutto
ogni volta che abbiamo bisogno e ottimizziamo per essere
leggi sul lato pubblico
ora una volta che hai fatto ciò che devi
considera ok, ma come faccio a copiare i dati
bisogno di pensare alla serializzazione come si fa
serializzo i dati così ora vieni
per cercare bene, quindi cosa dovresti usare?
dovresti usare il binario se dovessi usare
Il testo JSON XML è su HTTP che hai
tutte quelle considerazioni e tutte quelle
le decisioni che devi rendere ciò che è
il protocollo quali sono i tuoi trade-off
ok quando scegli l’una rispetto all’altra
ciò che è più importante per te è questo
leggibilità è la prestazione come fai tu
bug, quali sono gli strumenti che hai
che sai che puoi trovare bene come
lo monitora quali sono i
dipendenze che introduci
la tua build e la tua implementazione
sistema perché scegli un formato
sull’altro e ora che tu sei
servizi di chiamata a cui devi pensare
API versione il trasporto dell’API
protocollo come esponi l’API tramite
riposa l’RPC via sapone, dio, per non farlo
preso tutte quelle opzioni che in realtà
iniziato in un formato binario usiamo il nostro
piselli e abbiamo scoperto che era davvero
difficile da debugare e per i nostri casi d’uso
mentre un formato binario è più veloce
non ha fatto davvero alcuna differenza per noi
per il nostro caso d’uso quindi abbiamo deciso di ottenere
liberare il formato binario e spostarsi verso
JSON a JSON RPC su HTTP che tu
sa Jackson è un parser molto veloce
puoi usarlo puoi usare gli strumenti è
in realtà basato sul testo puoi leggerlo tu
riesci a eseguirne il debug, puoi loggarlo molto molto
facilmente
e questo è per il nostro interno
comunicazione dall’esterno quando noi
esporre API a Internet, quindi usiamo
resto è più facile per gli sviluppatori
usa il riposo ma per noi interni in realtà
stiamo usando un JSON su RPC perché
è digitato è più facile testare ora il
la prossima cosa che stai bene così tu
avere una API quindi come si fa API
versioning
devi pensare agli schemi API
versione 1 versione 2 e ricordiamo solo noi
avere due servizi ecco che voglio
introdurre lo yakhni per quelli di voi no
sai cos’è la ghinea, non lo sei
ne avrò bisogno
all’inizio non va bene quello che usi
la retrocompatibilità non dà fastidio
te stesso con tutte quelle cose che tieni
pianificare in anticipo quando ti piace
centinaia di microservizi e centinaia
di endpoint e un client esterno quando
si inizia non si ha quello ok è
più facile mantenere la retrocompatibilità
e e tutti gli sviluppatori sono interni
e non devi mantenere è che non lo fai
avere la sopra l’overhead di
mantenimento del mantenimento del controllo delle versioni
le stesse ragazze chiamano ora in modo asincrono
che hai due diversi servizi
se dovessi presentare Kafka non dovrebbe
ridurre RabbitMQ attivo in coda qualunque
in coda ora pensaci quando l’hai fatto
uno manualmente hai avuto quelli
sistemi di messaggistica se continuate a utilizzare
qualunque cosa tu avessi ma se non lo avessi fatto
introdurre qualcos’altro e tu no
avrò bisogno di usare il filo se lo usi
discussioni prima ancora di poter utilizzare i thread
ogni volta che ne presenti un altro
middleware per il tuo sistema sei
introducendo DevOps in testa ricorda
stai correndo su un sistema di produzione
e la cosa più importante su
sistema di produzione è per mantenerlo funzionante
ogni volta che presenti un’altra cosa
sei nel tuo sistema di produzione
introducendo DevOps in testa se tu
non ho usato la messaggistica prima di non usarla
ora perché hai solo due servizi
quando avrai molto e il tuo sistema
si evolve e ne hai bisogno solo allora
introdurre nuove tecnologie non introdurre
nuova tecnologia solo perché mi hai sentito
non mi conosci o Netflix o Google
questo è un hey che abbiamo ottenuto questa fresca accodata
sistema o qualunque cosa riguardo al servizio
scoperta ora abbiamo zookeeper insegna
dalla console se vedi l’Eureka tutto
quelle cose che devi scegliere
da destra perché ora ne hai due
servizi e hai bisogno di scoprirli
non avrai bisogno di bilanciatori di carico
e la voce DNS è la soluzione perfetta
sai che otto settimane ne abbiamo 200
servizi di micro e noi ancora non abbiamo
che in questo momento, quando si corre si al 200
abbiamo iniziato a pensare al servizio
scoperta perché abbiamo 200 ma fino a quando
poi
Il DNS è perfetto, non ridurlo
più spese generali
la resilienza della resilienza è molto importante
Va bene perché ora che stai ricevendo in
mondo dei sistemi distribuiti e quando
quando vedi questo diagramma questo è un
sistema distribuito ok vedi questa freccia
cosa significa significa molto importante
cosa significa che ora hai un
punto di fallimento non stai più chiamando a
funzione sul tuo monolite se il server
è in esecuzione la funzione verrà chiamata
ok ora quando chiami qualcos’altro
potrebbe non riuscire a introdurre la rete così
ogni hub di rete che introduci
la definizione riduce la tua disponibilità e
ci sono modi per superarlo ma è così
riduce la tua disponibilità alla funzione
chiamare ciò che hai appena fatto potrebbe non esserlo
eseguito così come si fa a superare lo
diversi modelli di cui hai bisogno
capire e sapere come usare
correttamente ok, quindi hai ottenuto il tuo tentativo
politica, ma tu hai solo la cura
tentativi sulle operazioni intento di inattività si
non voglio caricare le persone due volte, ora
avere interruttori di circuito e errori del motore
ancora quelli devono essere molto ben sintonizzati
potresti causare i tuoi tempi di inattività, se tu
presto anche questa interruzione del circuito
presto causerai i tuoi tempi morti
va bene se si interrompe il circuito quando si è solo
avere un server dipende da te, quindi
quelli sono gli schemi che tu
ho bisogno di essere sperimentato con te
bisogno di capire e ti troverai
fallirà sicuramente lo farà
combattiamo fino a poco a poco e
loro si alzarono e lo sistemarono e capirono
come funziona per il nostro sistema ma il
il fatto che tu abbia questo punto di errore
può essere davvero una buona cosa
una buona cosa per il tuo cliente
esperienza perché ora se il servizio
fallisce invece di un completo down time
puoi avere un degrado del servizio
giusto così se l’editor è giù nel nostro
i case case possono ancora essere visualizzati , non è così
che tutto è giù o niente
puoi avere come lo chiamiamo un killer
funzione che è un kill switch per
caratteristiche in modo che possiamo abbattere con grazia
sottosistemi ok questo al momento no
lavoro tornare più tardi e sarai
in grado di modificare il tuo sito ma puoi ancora
vederlo ok puoi usare fallback e
meccanismo di auto-guarigione che puoi iniziare
utilizzando la coerenza finale, ad esempio
ti daremo un esempio per una riserva
per i dati così quando pubblichi un sito
sei in settimane in cui è composto il tuo URL
il tuo nome utente taglia la barra punti-com
qualunque sia il nome del tuo sito e l’utente
il nome viene prelevato dal server dell’utente
ok, qual è l’ultimo nome utente perché
puoi rinominare ora nel caso in cui il
il server utente è inattivo, abbiamo un errore
non lo facciamo non dobbiamo fallire il
transazione abbiamo effettivamente l’utente
nome già memorizzato nella tua sessione
cookie in modo da poter avere un fallback solo
prendilo da lì a cui devi pensare
tutte le borse difettose se ti interessa davvero
sulla disponibilità di cui avrai bisogno
pensa a quella scatola del guasto che puoi
che si può che si può prendere se si
vuoi caricare materiale su un altro
servizio e non funziona davvero bene
ora puoi vendere riempilo più tardi
testare è importante, facciamolo
imparalo a testare così ora lo sei
testare un sistema distribuito va bene lo è
non solo test di unità , quindi è così
il modo in cui testiamo, intendo tutti
può avere il proprio sapore di come loro
prova così è il modo in cui eseguiamo il nostro test
per prima cosa eseguiamo il test unitario su
servizio stesso la prossima cosa che facciamo
è che noi lo chiamiamo un test di integrazione
in realtà testiamo anche la serializzazione
mettiamo come server falsi o semplicemente
approvvigiona noi non prendiamo in giro il servizio che abbiamo appena
metti un falso servizio così possiamo effettivamente
prova la serializzazione prossima cosa siamo noi
fare un server end-to-end quando in realtà
eseguire l’intero servizio e tutto è
dipendenze relazioni reali il
primo strato di dipendenze e al
alla fine eseguiamo il test di automazione che è
dal browser in tutto il sistema
e questo funziona come di notte e circa
registrazione
hai un sistema distribuito proprio tu
bisogno di una registrazione distribuita non proprio
devi solo scrivere due servizi se
non avevi come lo stash di registro prima o
qualsiasi cosa distribuita più tempo prima di te
non c’è bisogno di usare proprio ora che siamo a
Spiega in ogni caso che non ci piace davvero
registrarsi è davvero difficile
sviluppatore per guardare effettivamente i log
accanto mostrami uno sviluppatore che posso
in realtà scrivere un buon registro e puoi farlo
in realtà trovare queste informazioni che non ha
basta copiare come una configurazione di registro dalla
internet e attaccalo adesso
giusto loggare quello che preferiamo è in realtà
esporre tutte le informazioni al nostro
sviluppatori quindi questo è parte del nostro micro
servizi quadro ogni micro servizio
espone tutte le metriche in una bella rete
interfaccia
gli sviluppatori non hanno bisogno di andare e
SSH la macchina può andare su una rete
interfaccia e guarda tutte le metriche che vediamo
le voci del registro recenti possono vedere
tutto ciò che ricordo è giusto …
funziona anche con le centinaia solo
dopo aver avuto un centinaio di micro
servizi solo allora abbiamo iniziato a mettere
come – sistema di registrazione realmente distribuito
bilancia perfettamente bene
ora la proprietà è un fattore chiave se tu
vuoi fare sistemi distribuiti se tu
voglio lavorare con i micro servizi e a
molti di loro la proprietà è la chiave qui va bene
non puoi scalare la tua squadra ops è il
numero di micro servizi che hai
così micro servizio è di proprietà di un team IT
non è di proprietà di una persona è
non un codice che puoi mettere e dimenticare
e se una persona lascia, non ha proprietario
il team possiede i micro servizi e se
lo costruisci allora tu sei quello che
è in esecuzione sei tu quello che
sta monitorando il tuo drone che è
responsabile se una persona lascia
la squadra due cose possono accadere se a
la persona possiede un micro servizio che può assumere
il micro servizio con lei al nuovo
squadra e mantenerla con la nuova squadra
oppure il micro servizio cambia proprietà
all’interno di una squadra così altre persone nel
il team è ora proprietario del micro servizio
una delle cose buone in cui facciamo
per garantire che ogni micro servizio
ha un proprietario è noi facciamo continuo
consegna e ogni micro servizio deve
essere distribuito alla produzione almeno una volta
un mese quindi ogni mese riceviamo un avviso
se qualcosa non è stato distribuito a
produzione con l’ultima revisione di
le strutture e tutto ciò che puoi
solo un mese indietro stantio
assicura che nulla venga lasciato indietro
e che ci porta alla più
domande interessanti su
microservizi che devo ancora trovare
rispondi e ti risponderò per te
qual è la giusta dimensione di a
il micro-servizio è una domanda stupida se
me lo chiedi perché ora ne abbiamo due
monolite quindi qual è la giusta dimensione quelli
è possibile chiamare loro micro-servizi IT
Non ha molta importanza ecco arriva
Conway
si, la legge di Conway dice ok
l’architettura è determinata dalla
struttura organizzativa quindi se hai
un sacco di gente lo capirai
lavorando sullo stesso progetto che otterrai
un monolite quindi la dimensione del micro-servizio
è la dimensione della squadra che sta costruendo
questo è uno dei motivi per cui costruiamo piccoli
squadre e costruiamo piccoli assaggi di
costruendo piccole stanze dove i nostri uffici
sono una specie di piccolo tra quattro e sette
le persone e basta se la squadra ha bisogno
per crescere hanno bisogno di andare in un altro
stanza ed è fondamentalmente una nuova squadra e
creeranno il loro micro
servizi quindi cosa hai imparato finora
con solo due monoliti impariamo a conoscere
scoperta del servizio impariamo come
monitora quelli okay abbiamo esperienza noi
scelto questa realizzazione non lo è
sincrono lo SLA del servizio come
definiamo l’API è la distribuzione
strategie
va bene la separazione dei dati di darris è lì
come testarlo per mantenere la compatibilità
la compatibilità è davvero difficile, intendo la maggior parte
del tempo in cui non si riesce voi ragazzi siete
perché qualcuno non ha fatto retromarcia
compatibilità la maggior parte delle volte vedi così
semplicemente estraendo due monoliti e
trattalo come un micro servizio
architettura imparerai molto
e fai grandi progressi se tu
non fare tutte le spese generali di tutto il
cose che non hai davvero bisogno di fare
non all’inizio non così tanto ora che noi
conosci tutte quelle cose che possiamo continuare a
estrarre sempre più micro servizi e
le cose che abbiamo fatto sono noi in realtà
mantenuto l’idea della separazione entro
SLA quindi ogni micro servizio che noi
costruito la prima domanda che chiediamo alla nostra
gli sviluppatori è a quale segmento appartiene
fa parte del segmento dell’editor
o il segmento pubblico è più letto
intensivo o di scrittura intensiva è così
il nostro sistema è ovviamente una visione parziale
può mettere come 210 anni quindi questo è il modo
Wix è un micro servizio che sembra ok così
alcuni dei micro servizi sono nel
l’editor segmenta alcuni dei micro
i servizi sono nel segmento pubblico e
questo ha aiutato gli sviluppatori a capire e
pensa a quali sono i miei requisiti per
da questo servizio va bene per lo più
giusto qual è la scalabilità e
problemi di disponibilità che ho fatto io
vuoi eseguirlo in due datacenter o a
almeno due data center okay, qual’è il mio
uptime è novantanove virgola nove o
novantanove virgola nove nove così via
definisce veramente i tuoi requisiti da
quel servizio e una cosa che se
tu pensi che io abbia davvero bisogno di entrambi
loro questa è davvero una buona indicazione
forse dovresti dividerlo in due micro
servizi e non solo costruire un monolite
o un micro servizio più grande
quindi qual è il tempo di estrarli nuovi
micro-servizi, quindi pensiamo di fare
pensa che è necessario aggiungere un nuovo
funzionalità va bene così puoi farlo come a
micro servizio o una biblioteca prendiamo un
esempio diciamo che ho bisogno di un fuso orario
lo chiameremo un servizio per ora
prende l’IP della richiesta va a max
il database delle miniere capisce che ore sono
zona e propagare tali informazioni a
il servizio di cui aveva bisogno in modo che possiamo andare
in entrambi i casi possiamo costruire una biblioteca o noi
può costruire un micro servizio che darà
noi questa informazione e c’è una serie
di domande che dobbiamo chiedere
noi stessi introducendo questa cosa, io
creare una dipendenza di distribuzione se io
modificarlo Ho un DevOps overhead
necessita di un database che lo mantenga
database che possiede questo codice lo fa in forma
le preoccupazioni di scalabilità che ho per
questo servizio può avere una squadra diversa
sviluppalo devi chiederti tutto
quelle domande e una semplice regola di
thumb is is micro service has ops
la biblioteca è per lo più computazionale, va bene così
in questo caso dove vogliamo un tempo
zona da un IP ha bisogno di andare a
database se il database è di solito
locale e non voglio dare uno stile a questo
installa questo database su tutti gli altri
servizio che ho così in questo caso
sarà un micro servizio che non voglio
creare questa dipendenza che non voglio
crea questo overhead DevOps che ora
ogni proprietario di servizi di micro necessità
questa biblioteca dovrà mantenere un annuncio
database così è
micro-servizio che è la squadra
responsabile e il suo mantenimento e
tutti gli altri solo consumare come un
servizio ora quando stiamo parlando
micro servizi una delle cose che
puoi fare è hai la libertà di
scegli molte azioni in modo da poter avere
diversi segnali che puoi avere
diversi database che si possono usare
Cassandra si può usare il mio sequel
usa Couchbase puoi usare qualsiasi Mongo
il proprietario del servizio microt può usare qualsiasi cosa
hanno bisogno o qualunque cosa vogliano che sia
peggio per i propri micro servizi
questo è vero che non lo consiglio vivamente
facendo tutto bene dovresti limitare il tuo
azione va bene
default ha fatto lo stack che conosci e
il motivo è che è di nuovo DevOps
se tutto avrà il suo
solo il middleware che la squadra saprà come
di gestirla e come operare che nel
produzione se la maggior parte delle squadre condivide
lo stesso standard o lo stesso middleware
possono condividere la conoscenza che possono loro
può arrivare a una soluzione a una risoluzione
sulla crisi produttiva e sui tempi di fermo
molto molto veloce perché possono condividere
la loro conoscenza se qualcuno sta facendo
qualcosa che nessun altro sa che è un
Squadra molto piccola che può effettivamente gestire
la crisi
ma non ti impedisce di partire
innovare dall’innovazione che puoi
innovare su un non critico
micro-servizi se hai qualcosa di nuovo
che costruisci e che è un nuovo
micro servizio e tu pensi che hey mio
stack attuale non è lo strumento giusto
per il lavoro va benissimo
innovare avviare una nuova prova di micro servizio
fuori vedi come funziona il resto del
sistema è stabile se funziona attendere
fino a quando non inizieranno uno o due altri team
usando la tua nuova tecnologia o nuovo stack
e poi renderlo uno standard
tutti possono effettivamente usarlo per condividere il
la conoscenza diffonde la conoscenza no
tenerlo contenuto all’interno di una squadra
che dire del linguaggio di programmazione che puoi
scrivere micro servizi in qualsiasi lingua
proprio in Scala e PHP in qualsiasi nodo
ma dovresti di nuovo probabilmente lo vuoi
per limitare il tuo stack anche qui va bene
perché se scrivi in più
le lingue che poi devi non puoi fare
un riutilizzo del codice
avete preoccupazioni trasversali che
devono essere affrontati da qualsiasi micro
convalide delle sessioni di sicurezza dei servizi
controllo di registrazione testare lo stesso il
stessa infrastruttura necessaria per l’esecuzione
deve essere un sistema di produzione dell’operatore
ri-implementato in tutti gli stack
se vuoi cambiare la tua crittografia
algoritmo ora devi aspettare fino a quando
ogni servizio micro scritto in a
lingua diversa dovrà
attuarlo prima di poter rotolare fuori
che rendono le cose davvero davvero
ci vuole molto tempo e vogliamo progredire
veloce quindi prova a limitare il tuo stack al
il minimo indispensabile se non sono davvero
non è lo strumento giusto per il lavoro che hai
altra scelta se non per la sua attuazione, ma in realtà
stai attento a non farlo
fuori bordo e con tutti i microservizi
essendo scritto in una lingua diversa così
ricorda di tenerlo semplice DevOps è davvero
davvero importante e quando sei cresciuto
avete un sacco di micro-servizi IT
diventa sempre più grande e più grande
in testa trascorrerai più tempo dentro
gestire la produzione più micro
servizi che hai quindi ricapitoliamo
cosa abbiamo imparato ora continuiamo a
conoscere le transazioni di disabilità e
monitoraggio del sistema e tracce distribuite
come si traccia una chiamata che va
attraverso cinque micro servizi come fai tu
sapere come va quel micro servizio
quale server ha risposto alla chiamata che ti serve
per conoscere questa cosa e capirla
scambi di nuovi micro servizi
estendere un micro servizio esistente o
creane uno nuovo per aggiungerne di nuovi
funzionalità
qual è la tua strategia di implementazione ora tu
avere una funzione che dipende da on
due o tre servizi micro da essere
implementato dovrai imparare tutto
questo come si va come si gestisce
guasti a cascata quando un server
inizia a rispondere lentamente che non vuoi
per far cadere tutta la catena di
servizi di micro che stanno chiamando voi
avrà bisogno di sapere e imparare come
per gestire queste cose è più facile
ora costruisci nuovi team e dividi nuovi team
ok perché ora ogni squadra può avere un
piccolo sottoinsieme di responsabilità ma
La grande domanda è il motivo per cui perché dovreste
mai voglia di fare questo a te stesso perché farlo
vuoi andare ai micro-servizi è
non perché sei qui e sto parlando
a riguardo e Netflix ne parla
e Google parlando di ciò che non è
la ragione per andare ai microservizi va bene
i micro-servizi vengono per risolvere un problema
va bene se non hai problemi
bastone con qualunque cosa tu abbia il primo
il problema che risolve è l’ ingegneria
scala se hai molti ingegneri
che lavorano in un popolo di monoliti
si calpesteranno l’un l’altro se tu
voglio andare veloce , è meglio averli
divisi in piccole squadre che ciascuno ha
la propria responsabilità è il suo sviluppo
velocità se hai squadre piccole loro
può progredire molto più velocemente di quello che hanno
condividere lo stesso codebase e distribuire
e aspettatevi l’un l’altro
hey ho finito con questa funzione ma
ehi, ma dobbiamo schierarci insieme così noi
c’è bisogno di aspettare fino a quando questa squadra e QA
se lo dividi in piccoli pezzi, il tuo
la velocità di sviluppo sarà molto più alta
e la terza ragione è ridimensionamento ora quando
stai andando ai micro servizi che puoi
ora ridimensiona le diverse parti in modo diverso
scalabilità come relè se non si dispone
qualcuno di questi problemi rimane con qualsiasi cosa
non sei entrato nel micro servizio ism
ora microservices è il primo post
L’architettura DevOps è la cultura
davvero molto importante
se non hai una cultura DevOps , non farlo
anche tentare di andare lì è un enorme
importante in proprietà e il diritto
stato d’animo per mantenere questo tipo di
sistema distribuito e ricorda ogni
il micro servizio è alla fine un DevOps
in testa quando aggiungi qualcosa di cui hai bisogno
qualcuno per mantenerlo non è un
codice throwaway è una produzione dal vivo
sottosistema con cui sta giocando
tutti gli altri quindi è tutto
compromessi e ricorda che pensiamo se tu
bisogno se stai aggiungendo qualcosa pensa
davvero molto attentamente se ne hai bisogno se tu
non ne hanno bisogno non usarla non usarla
perché ne hai sentito parlare da qualche parte se
hai un problema risolvilo con
la tecnologia ok non si limita a introdurre nuovi
La tecnologia al tuo al tuo stack solo
perché è bello o lo pensi
ne avrai bisogno
in fondo alla strada, aspetta fino a quando non lo fai davvero
avere un problema quindi questo è fondamentalmente
piccola serie di linee guida che abbiamo messo a disposizione
i nostri sviluppatori su come creare e
uno dei compromessi tra quando
creando il nuovo microservizio di più
cosa importante che ogni micro servizio
ha un proprio database non due micro
i servizi sono autorizzati a scrivere al
stesso database crea l’accoppiamento se tu
avere una considerazione sulle prestazioni è
ok per avere un servizio di micro sola lettura
quel database di condivisione ma poi il
il trade-off è l’accoppiamento, se necessario
cambia qualcosa nello schema ora tu
devono prendersi cura di due micro servizi
o tre al fine di gestire il tuo
spiegamento giusto okay
e ricorda se hai un problema in
I microservizi Manali non risolveranno
il tuo problema per dividerlo in molti
altri problemi e penso di aver finito
grazie
le diapositive sono lì se vuoi
scaricalo quindi abbiamo tempo per
domande
eccellente sì, grazie mille per primo
di nuovo un rapido promemoria per favore prima di te
lascia la stanza assicurati di votare
l’applicazione non abbiamo ricevuto alcuna
domande prima anche se solo tu
ho come due servizi ma tu no
avere il rilevamento dei servizi come ti
gestire il failover in una seconda istanza in
caso di guasto di uno che la logica è necessario
inserisci il tuo bilanciamento del carico così quando lo sei
in esecuzione in un cluster se un servizio
il bilanciamento del carico fallito sa davvero
fa parte della logica di un carico
bilanciatore sa quali istanze sono fallite
così che la logica è nel bilanciamento del carico così
davvero non devi preoccuparti di questo
si sta prendendo cura di un altro
domanda interessante quando si rompe
il tuo sistema in più servizi
non hanno la loro interfaccia utente o è il
UI stessa servizi come è che impostare
beh dipende da cosa ci piace fare
avere ogni sottosistema ha il suo
UI quindi è un discorso che si sia stur
di una propria serie di servizi di micro esso
in realtà dipende il vostro business
caso d’uso aziendale ma ci piace dividere
l’interfaccia utente anche sì abbiamo un numero di
domande penso che alcuni di loro siano stati
ha risposto nella tua presentazione ma
nel complesso parlando qual è stato il tuo più grande
sfida quando si implementa micro
servizi e guardando indietro ora essere
su 150 micro servizi cosa vorresti
hai fatto diversamente sapendo cosa tu
ora so che questa presentazione è basata su
la lezione che ho imparato intendo quando noi
iniziato abbiamo davvero pensato di fare
come il bilanciamento del carico lato client e
ha iniziato a implementarlo e a farlo
interruttori che abbiamo finito per non
usando perché non sapevamo come usare
così abbiamo pensato che avremmo avuto bisogno di un
molte cose, ma in realtà lo pensiamo
che abbiamo perso un sacco di tempo
costruendo quelli
cose che non abbiamo usato e anche quando
li abbiamo usati li abbiamo pensati bene
iniziato a usare quegli strumenti come dopo a
mentre dopo abbiamo avuto come 50 o 100
microservizi e la cosa che noi
pensavo che lo saremmo
risolverò per noi quando l’abbiamo iniziato
non era lo stesso problema, quindi in realtà
non ha usato la soluzione giusta per il
problema che incontriamo in realtà dopo
facendolo nella vita reale
va bene una domanda in termini più generali
come ti occupi della sicurezza?
avere cose come il single sign-on impostato
sì, quindi in realtà ne abbiamo due
meccanismi uno è per il nostro interno
sign-on e e abbiamo auth che lo fa
un single sign-on praticamente passiamo
gettoni tra i servizi sono tutti
firmato in modo da poter verificare che il
la firma è corretta
un’altra domanda come si assicura
replica del database tra servizi se
in realtà non condividono un singolo
database in modo che ogni database sia indipendente
quindi abbiamo un database per micro
servizio è stato replicato che hai
un altro database viene replicato
possiamo condividere le macchine del database solo
non condividere gli stessi schemi tra
microservizi quindi di solito ce l’abbiamo
un database con molti schemi ciascuno
microservice ha il suo schema così noi
non ridurre qualsiasi accoppiamento tra il
dati e il codice ma noi replichiamo
nuovamente i database per schema
versioning se il numero di consumatori
per un particolare servizio è in aumento
riesci ancora a farla franca con il solo fare
compatibilità all’indietro o hai un
forma di versioning in atto no noi no
avere una forma di posto di versione non
internamente comunque esternamente sì perché
è più difficile far muovere le persone che sei
non in controllo ma dentro il nostro
organizzazione facciamo ancora all’indietro
compatibilità se abbiamo bisogno di fare a
rompendo il cambiamento , introduciamo solo un
nuova API
e diciamo a tutti che ora è necessario
per passare a questa nuova API e ne hai una
a tre mesi per farlo e dopo
lo uccidiamo e chiunque non viene mosso
e lui si spezzerà
ovviamente abbiamo dato loro il periodo di ingresso
non è che faremo lo stiamo pausa, ma
li rompiamo per circa cinque minuti okay
ora hai una settimana per implementarlo
e poi potremo davvero romperti
qualsiasi domanda da parte della gente della stanza
Mi piace chiedere giù, allora penso che lo siamo
fatto così grazie mille e grazie
per favore dai loro un altro giro di
applausi
Please follow and like us: