[Musica]
quindi una grande organizzazione per esempio
prendiamo Netflix immagino di non averlo
un numero esatto ma almeno hanno
più di 1000 ingegneri del software in
confronto abbiamo 12 quindi c’è un grande
differenza tra grandi organizzazioni
e start-up e purtroppo lì
non esiste una regola d’oro che puoi
facilmente applicare maledetto così invece si deve
affrontare un sacco di compromessi lungo il tuo
modo
Grazie scivolo per favore e prima di andare
prima di entrare nell’ordine nel nostro
dettagli del viaggio fammi darti un
piccola breve panoramica di ciò che siamo
così facendo mi chiamo Ivana Kaiba
Sono il CTO del solo software che siamo
iniziare applicato ad Amburgo e solo
software che abbiamo sviluppato solo socialmente
soluzione b2b che fornisce app per
collaborazione e comunicazione a
team di supporto che lavorano di più
in modo efficiente e puoi fare una diapositiva successiva
per favore e prima che io spieghi perché noi
introdotto come start-up era molto alto
con meno risorse che abbiamo introdotto
micro servizi ti porterò su un
viaggio verso il nostro inizio in modo per lo
All’inizio tutto era un’unica unità
e ogni aspetto quindi eravamo una squadra
lavorando su un prodotto di collaborazione
implementato come una base di codice basata su
una pila di tecnologia successiva diapositiva per favore
e dopo un po ‘tutto si è evoluto
che è abbastanza buono ma prova va bene
perché abbiamo aggiunto sempre più funzionalità
al nostro prodotto e al nostro numero di utenti
aumentato e il numero di voi e
la squadra stava crescendo, quindi è supposto
essere fantastico ma invece raggiunto a
punto circa un anno e mezzo
fa dove tutto sembrava un po ‘goffo
tutto era un po ‘legato insieme così
dal punto di vista organizzativo che
ci sono voluti abbastanza tempo per fare le cose così
discussioni riunioni o decisioni e noi
non aveva davvero assegnato chiaramente
responsabilità quindi ci è voluto un po ‘
qualcuno si sentiva responsabile per uno specifico
azione per esempio quando un patto si presenta così
chi prende prende il responsabile di
analizzare e sistemarlo in modo che i nostri processi fossero
tipo di lavoro siamo un po ‘ lenti e nostri
produttività subita e dal
prospettiva dei prodotti che eravamo
aggiungendo continuamente più funzionalità in alto
di esso e così l’esperienza utente e
usabilità utente sofferta dal
emendamenti continuativi perché
invece di risolvere un utente fedele
problemi in un modo molto semplice eravamo
costantemente o incorrere sempre più
confondendoli così e dal software
attractor architecture perspective it
non è stato molto facile aggiungere nuove funzionalità
senza influenzare l’intero sistema e
anche per non rilasciare quelle modifiche che
abbiamo fatto senza ridistribuire senza
ricostruire e ridistribuire l’intero
sistema quindi c’era una sorta di bisogno
per dividere e spostare la prossima diapositiva
per favore così prodotto saggio che era uno e
un anno e mezzo fa pensavamo a noi
ha stabilito la visione per dividere il nostro
prodotto o una grande palla di fango in
singoli annunci e ognuno di loro prende
prendersi cura di un caso d’uso specifico e
risolvere un problema e questo molto
bene così abbiamo diviso il nostro unico prodotto in
diverse app di collaborazione
prendersi cura della condivisione dei documenti o attività
gestione o epinet per tempo reale
collaborazione e anche per lo scambio o
condividere notizie e informazioni aziendali
con un social network aziendale successivo
leggermente
saggio organizzativo abbiamo diviso il nostro 1
squadra in più squadre più piccole e
con l’obiettivo di stabilirsi autonomo
i team interfunzionali erano ben definiti
responsabilità quindi vogliamo i nostri team
lavorare su diverse parti di sistemi
mobili indipendenti tra loro a
una velocità diversa e con il minimo
impatto impatto tra i team
assegnato a ciascuno di questi gruppi specifici
schede di collaborazione in modo che il contatto
può prendersene cura con questi di questi
app di collaborazione e sviluppo e
distribuirli alla loro velocità, così noi
voglio rilasciare le modifiche indipendentemente come
bene, veloce e senza intaccare il
intero sistema per ottenere l’autonomia che abbiamo
sbarazzarsi delle dipendenze e di
raggiungere questo abbiamo anche due kabobs
all’interno della nostra architettura software così dentro
la lunga corsa che volevamo presentare
micro servizi e dopo che abbiamo
petizione il nostro prodotto in un’unica app
e dividi la nostra unica grande squadra in più piccola
quelli che eravamo così ben definiti
responsabilità ci lasciamo la logica
il passo successivo è stato introdurre micro
servizi per ottenere anche autonomia e
flessibilità nella nostra architettura software
così anche questo sembra molto facile all’inizio
colpo d’occhio ma è bello è molto più facile
dire quindi fare perché i micro servizi
fare un po ‘ venire con un sacco di
complessità che potrebbe non essere ovvia a
prima vista così in un sistema distribuito
o i tuoi micro servizi stanno comunicando
su una rete lenta e inaffidabile e
questo significa che questi servizi possono fallire
e in qualsiasi momento e devi
stabilire un meccanismo per rendere il vostro
sistema resiliente e quindi è stato necessario aggiungere
complessità per gestire l’errore parziale in
il tuo sistema e poiché i microservizi sono
trattare con dati partizionati che sei
perdere consistenza e una distribuzione
sistema devi anche prendertene cura
gestire la coerenza finale nel tuo
sistema e dal momento che sei ora dal tuo
aumenta la complessità operativa
perché devi affrontare di più
parti in movimento devi aggiungere un complesso
82 anni di monitoraggio e implementazione come
bene e visto che i tuoi micro servizi sono
comunicando tramite un’API si – lo hai
considerare e fare riferimento ad esso nel tuo
fase di test con il consumatore
appaltatori guidati per esempio e con
tutte quelle complessità è quella tua
il set di abilità è completamente diverso da quando
implementando un micro servizio e questo è
un po ‘come costoso sull’altro
da un lato perché o devi
impara il nuovo set di abilità o assumi
qualcuno e assumere alcuni consulenti per
esempio e un’altra cosa che avete
riflettere è come gestire
autorizzazione di autenticazione e un’altra
l’aspetto è l’ambiente di sviluppo
perché non vuoi i tuoi sviluppatori
istituire tutti i tuoi servizi e ha detto
vuoi avere un accesso facile in questo modo
possono sviluppare i loro servizi senza intoppi
è probabile
così districare il monolite è un duro lavoro
e richiede molto tempo così
il processo di sviluppo sta inizialmente rallentando
in fondo sta peggiorando prima che sia
migliorare e la trasformazione
il processo stesso richiede molto più tempo di te
originariamente anticipato così all’inizio quando
li abbiamo presentati abbiamo perso un traguardo
e questo è il motivo per cui si deve
prenditi cura di quelle complessità e prendi
il tuo tempo per ottenere le tue capacità fino a questo
puoi eseguire un micro servizio nel
ecosistema e se hai se lo sei
trattare con funzionalità di base con a
molte dipendenze è molto difficile
districa tutte queste dipendenze e tu
non puoi lasciare una parte che tu ancora
avere il sistema in esecuzione che hai ancora
per mantenere
e prenditi cura di così dopo, se guardi
tutte queste complessità e sfide di
microservizi che potresti chiederti
bene devo introdurre Microsoft
architettura o semplicemente stare in una delle
l’architettura bene e dipende da
dipende da ciò che si vuole raggiungere e da ciò
dipende da in che situazione
sono e per noi è stata la mia procedura
I micro-servizi Neetu non erano solo
tecnico guidato ma lo era
organizzativo e prodotto scritto così noi
prima diviso il nostro prodotto in singolo
app di collaborazione e poi anche la nostra
squadra in più piccola squadra era ok
con l’obiettivo di stabilirsi autonomo
team così e vogliamo assegnare a ciascuno
delle squadre ben definite
responsabilità in modo che tutti possano
lavorare in modo efficiente da soli
servizi responsabili e inoltre noi
voglio sviluppare e distribuire in modo indipendente
quindi ogni squadra dovrebbe avere la capacità
per implementarlo e distribuirlo a
la loro velocità e velocità senza
interessando l’intero sistema e anche
senza influenzare le altre squadre e a
rilasciare rapidamente le modifiche, così è stato il nostro
motivazione perché abbiamo introdotto micro
servizi e dopo aver deciso bene
prossima diapositiva per favore
iniziamo con il servizio micro su come
come possiamo iniziare con i micro servizi
quindi abbiamo la tua grande palla di martin tu
cercare di decomporsi come servizio
di esso e quindi ciò che abbiamo poi derivato era a
tipo di processo di trasformazione
esistente composto da diverse parti
il primo è identificare i candidati
quali sono buoni candidati per il mio per
servizi il secondo è il de coma
decompone il processo di decomposizione stesso
e il terzo è la stabilire la
ecosistema di micro servizi che non lo farò
devono andare sequenziali che possono anche essere
in parallelo pure
quindi iniziamo con l’identificazione
candidati e prima di farlo
quello dopo è chiaramente necessario prendere in considerazione
i concetti chiave della buona modellizzazione
micro-servizi per raggiungere il principale
benefici dei micro servizi e questi
sono l’accoppiamento lento tra il
servizi e alta coesione in a
servizio quindi non mi dispiace
quindi quando i servizi sono liberamente accoppiati a
il cambiamento di un servizio non deve influire
gli altri servizi e si apportano modifiche
facilmente posso apportare modifiche prima a uno
servizio e distribuito senza modifiche
l’intero sistema è ad alta coesione
riflessi correlati correlati a tale tasso
comportamento si siederà insieme così quando
quando cambi questo comportamento che vuoi
per cambiare questo comportamento in un singolo
punto se hai due cambiamenti a
diverse parti del tuo sistema che hai
per ridistribuire tutti questi servizi che sono
in relazione a questo comportamento e poi al tuo
il processo di implementazione è nuovamente accoppiato
insieme e questo è qualcosa che noi
non voglio ottenere questo è tutto
questi sono i concetti chiave che hai
da tenere a mente per per identificare
candidati per i micro servizi quindi dopo
leggermente questo comportamento correlato è
di solito riflesso dal contesto limitato
abbiamo sentito parlare prima che sia un modello
del design guidato dal dominio ed è
riflettendo il responsabile
responsabilità per affari ben definiti
funzione di un business ben definito
capacità va bene
è un mezzo automatizzato
miracolo così nel nostro caso abbiamo usato il nostro
collaborazione abs funzionante come cofano
contesto come il servizio di grano coercitivo
confini e da quel punto possiamo andare
dentro e per trovare grandi servizi tanto a lungo
successivamente così e ora la prossima parte di
il processo di trasformazione inizia il
scomposizione del servizio micro
candidati il primo approccio che noi
fatto è che abbiamo stabilito una coesistenza
servizio da zero e abbiamo usato il nostro
guida l’amplificatore di collaborazione facendo attenzione
di condivisione dei documenti e sto rovinando tutto
non era una buona idea, ma in generale il
parlando non c’è niente di sbagliato in
creare un servizio coesistente da zero
ma dimenticherò di essere al
svantaggi nella prossima diapositiva ma che cosa
abbiamo fatto e questo è al coesistere
servizio lo stavamo creando da zero
e ha stabilito una condivisione dei documenti
servizio stesso che ha i dati
autorità sui documenti e quindi solo gioia
stesso possiede i dati o il merito
questo significa e ogni documento ha un
autore assegnato e autore stesso
è ancora derivante dal profilo
gestione che è ancora conservata nel
monolite stessa quindi la prossima domanda
sorgere così ogni volta che mostriamo un documento
dobbiamo quindi richiedere l’autore
informazioni direttamente direttamente dal
modelli o dobbiamo quindi tenerlo
ridondante nella nostra e nostra app di guida così
questo è quello che abbiamo fatto abbiamo copiato abbiamo tenuto un
dati ridondanti del profilo
informazioni nel nostro nel nostro nuovo servizio
e per tenerlo in zinco abbiamo stabilito
un broker di messaggi che il monolite
stesso è quindi la modifica di pubblicazione
eventi fino a quando un dato profilo ha
stato aggiornato in modo che i segni del
nuovo può consumare e aggiornarlo
e una tecnologia di conseguenza bene per essere onesti
è stato molto pesante intraprendere perché
abbiamo fatto tutto in una volta, come ho detto
prima non era un equivalente esatto di
il servizio esistente invece abbiamo aggiunto
più funzioni nella stessa fase del processo
e abbiamo introdotto dati completamente nuovi
struttura perché anche noi avevamo voluto
coprire anche alcuni requisiti specifici
e anche una nuova interfaccia utente per
migliorare l’ esperienza dell’utente stesso e
nel frattempo dobbiamo ancora
mantenere ed eseguire il sistema attuale così
questo ha richiesto molto tempo ed è stato un po ‘di
frustrante perché non li abbiamo ottenuti
risultati molto rapidamente e non abbiamo potuto
guadagna davvero esperienza attraverso il
processo prendendo questo primo documento come
un servizio e distruttività del
servizio e aggiungendo nuove funzionalità in cima
anche così invece dovremmo avere
incentrato su pezzi più piccoli e quindi cosa noi
è stato invece il prossimo servizio
noi la prossima app di collaborazione che noi
usato come candidato per i micro servizi
è che l’abbiamo diviso in pezzi più piccoli
e andando dall’alto verso il basso così abbiamo
identificato il prossimo candidato per micro
servizi e quello che abbiamo fatto per primo è quello
abbiamo estratto l’ interfaccia utente prima come
un’app separata che estrae il client web
e la stessa logica di business è a questo
passo ancora residente e poi il
monolite e il client Web stesso
il monolite ne sta introducendo un numero
API che può essere indirizzata dal nuovo
client web Web estratto, quindi questo dà
noi il vantaggio che possiamo sviluppare e
distribuire l’app Web in modo indipendente e
che possiamo iterare sul
sull’interfaccia utente molto molto rapidamente
quindi questo è il primo passo che abbiamo fatto
il secondo passo è quindi estrarre il
logica aziendale e questo è più lavoro
di estrarre il client web perché
si hanno anche per prendersi cura del
dipendenza che aveva prima nel
monolite così per ogni dipendenza quella
hai avuto e l’ammonal è che sei tu
devi specificare o fornire una API
sui nuovi server, ad esempio, se
i monitor stanno ancora accedendo al nostro nuovo
servizio che abbiamo fornito ad esempio un RESTO
Anche la console API potrebbe essere un’altra
e a quel punto siamo ancora
accesso alla stessa memoria di dati e
questo è quello che stiamo districando
il prossimo perché diventare uno standalone
servizio disaccoppiato abbiamo finalmente bisogno di
dividere l’ archiviazione dei dati in modo che
il nostro nuovo servizio sta diventando i dati
Autorità o sta ottenendo i dati
autorità delle proprie funzioni aziendali
e nel caso che tu avessi tenuto
dati ridondanti che abbiamo fatto per esempio
con la nostra app di guida come quella che abbiamo mantenuto
dati dell’autore ridondanti non appena tu
fallo devi tenerli
in qualche modo e zinco e tu per esempio e
l’abbiamo fatto stabilendo un messaggio
broker così ogni volta che i dati ridondanti
è stato aggiornato e i monoliti e
l’evento è stato presentato e il
il consumatore lo ha aggiornato
di conseguenza così quando hai a che fare con
diversi candidati per i micro servizi
ti chiedi, ok, quale dovrei?
fai prima quello che mostrerò il primo
indirizzo e facile
il principio è estrarre quelli che sono
molto facile da estrarre perché hanno
meno o pochissime dipendenze e
perché quando inizi con quelli
sono facili da estrarre stai guadagnando a
molta esperienza in un breve periodo di
tempo e quindi anche tu stai ricevendo
esperienze potrebbe
servizi ma anche con l’estrazione
processo in particolare e quindi è possibile
concentrati anche su quello che ti dà
il massimo vantaggio quando estrai un vero
micro-servizi per esempio se ne hai
alcuni servizi o alcuni candidati
cambia spesso, allora è un bene
candidato a usarlo come prossimo e così
poi dopo aver creato tutto ciò che hai
ti sei convertito nel mio servizio per te
può quindi distribuire le modifiche più velocemente di
prima
in altre parole un’altra opzione è quella
stai estraendo quelli che stanno usando
requisiti di risorse differenti per
esempio se usi qualcuno con un livello elevato
il consumo di memoria è possibile distribuire su
server con alto che alto equipaggiato
memoria in modo da poter scalare il tuo micro
mondo dei servizi facilmente e altra cosa è
che dovresti smettere di dar da mangiare
monolite perché quando ti stai ritagliando
i tuoi servizi da una parte e
stai aggiungendo nuove funzionalità o nuove
funzioni sui monitor quindi sul tuo
i monitor non si restringono invece
è lo stesso o nel peggiore dei casi
è anche in crescita e rallenta il tuo
processo di trasformazione quindi la prossima cosa
è che vorrei parlare è
stabilire un ecosistema Microsoft e questo
potrebbe essere un po ‘ particolare per noi
perché stiamo gestendo i nostri servizi
prodotto non solo nel cloud ma anche
in loco quindi e abbiamo grande
i clienti che richiedono di eseguire il nostro
servizi sulle loro macchine così noi
hanno anche stabilito un ecosistema e così
il primo è quello dopo che abbiamo
districati i nostri micro servizi come facciamo noi
indirizzare loro come li accediamo da
Internet da internet pubblico
dal client dall’interfaccia utente
e una cosa è che potresti direttamente
accedervi tramite un’interfaccia utente ma
questo si imbatte nel problema che tu sei
esponendo alcune parti della tua API interna
che sono in genere correlati al servizio utente
comunicazione ed in caso di
i servizi sono in esecuzione
su diversi domini, specialmente con il
Permessi JavaScript abilitati
condivisione di risorse incrociate e anche
il tuo cliente potrebbe fare invece in termini di
in caso di recupero di informazioni da
diversi micro servizi che devi fare
più viaggi di andata e anche tu potresti
avere clienti diversi un client mobile
e un client desktop e potrebbero avere
esigenze diverse quindi quello che puoi
Stabilire quindi è un gateway API per funzionare
come adattatore come singolo punto di ingresso
per te micro mondo dei servizi e questo
si eliminano i requisiti del corso
e perché ora stiamo correndo su uno
dominio singolo su un dominio e mantiene
all’interno delle tue parti interne della tua API
di tutti i tuoi micro servizi interni
mondo e potrebbe essere un gateway come pure
anche gestito come la traduzione di protocollo
e fornisce anche il meccanismo di caching
i nostri stessi monitor erano principalmente
implementato in Java e utilizzato per il nostro
ecosistema usiamo principalmente Netflix open
software sorgente e con la molla
fornisce le librerie cloud e Netflix OSS
un sacco di librerie di quadri per costruire
la tua architettura di micro- servizi e
infrastruttura in modo tale che il cloud di primavera offra
un’interazione molto semplice con noi
la maggior parte delle reti che l’OSS stava aggiungendo
dipendenze dal pass di classe e
annotare qualcosa che ho davvero sollevato
alcuni esempi più avanti quindi l’API
gateway è il primo cittadino del nostro
ecosistema di micro servizi ora il prossimo
uno è come il servizio di autorizzazione o
c’è una gestione delle prenotazioni e
proteggere un monolite è facile perché tu
di solito hanno un componente di sicurezza comune
che si prende cura dell’autorizzazione in
la tua catena di gestione delle richieste e poi
si propaga all’utente
formazione al tuo metodo successivo
chiama e loro possono fidarsi di questo
informazioni per garantire il microservizio
invece è molto è molto difficile
perché si deve capire come
i servizi possono fidarsi l’uno dell’altro e tu
anche evitare la manipolazione
autorizzazione in ogni micro-servizio
e questo qualcosa è qualcosa che può
essere gestito introducendo e globale
server di autorizzazione che si occupa di
questa preoccupazione trasversale di
autorizzazione quindi abbiamo stabilito un tutto
l’intero server deve essere eseguito come proprietario
servizio e il nostro gateway API così tutto
la valutazione dei server è come fornire
token di accesso che può essere l’interfaccia utente
utilizzare le risorse specifiche del Texas per affrontare
risorse dai micro servizi
loro stessi e il nostro gateway API in questo
in questo contesto è stato usato come sistema operativo
relè token che significa che dopo il
l’interfaccia utente ha ottenuto questo
token di accesso è probabilmente lo è
pubblicare il token di accesso insieme a
la richiesta originale al micro
servizi in sé uno svantaggio è con
questo si avvicina al micro servizio
deve ancora controllare nabela G il
bene validità del token e
inoltre devono anche ritirare l’ utente
informazioni in modo che la pelle causi il noleggio
carico maggiore sul servizio di autorizzazione
così che potrebbe essere anche un altro approccio
che hai introdotto nel token Web JSON
invece di diminuire il carico del
servizio di autorizzazione mm-hmm devi
eliminare la convalida del token e anche
il rituale delle informazioni dell’utente e
potremmo invece trasportare l’utente
informazioni come reclamo di identità su a
Token Web JSON in aggiunta a questo Web JSON
token viene automaticamente firmato da
servizio di autorizzazione in modo che il Micra
i servizi stessi possono fidarsi di questo
informazioni l’API abilitata gateway
funziona come un
Constanza lations così è stato quando
l’utente l’ interfaccia utente il tuo cliente
richiede un token di accesso e ottenuto
dopo aver ottenuto questo token di accesso
invia questo token insieme al suo
richiesta al gateway API e all’API
gateway fa la traduzione così
estrae il token di accesso e lo usa
uno ai sensi dell’autorizzazione
il server riceve un token Web JSON e
prevenire pubblica poi inoltra quelli
Token Web JSON insieme alla richiesta di
i sottostanti micro-servizi in modo tale
loro che i servizi di Micra stessi
basta prendere solo devono elaborare
questo questo token web che è abbastanza facile
implementare il prossimo cittadino del nostro
l’ ecosistema di micro- servizio è il servizio
scoperta e architettura dei miei microsomi
può contenere un gran numero di micro
servizi e interagire tra loro
Così come si può facilmente identificare servizi elia
tutte le istanze in esecuzione che vorrebbero
interagire con una configurazione manuale
è totalmente poco pratico ed è molto
fragile e quindi una scoperta di servizio
fornisce invece un singolo servizio di ricerca
per ogni registro di istanze di servizio
registrandosi automaticamente a
l’avvio e altri servizi possono scoprire
quelli recuperano quelli già miserabili
servizi e scoprili e poi
in seguito connettendoci così alcuni
le soluzioni sono ad esempio Netflix voi
concordare Eureka console in città o su
PIPA e abbiamo usato nel nostro caso noi
usato Eureka perché è insieme
Sprint cloud perché è davvero facile
integrazione è molto molto facile a
integrare un bowler perché è solo
lì devi solo fornirti solo
devono fornire il rispettivo
dipendenze dal pass di classe e
annotare da un lato il tuo servizio
e dall’altra parte il tuo servizio è tuo
i clienti che quindi registrano automaticamente
all’avvio i micro servizi che vogliono
utilizzare il nostro servizio stesso può anche essere
può creare dalla loro parte per esempio a
modello di riposo bilanciato e vengo
a questo più tardi e utilizzare l’ID di servizio
e al relativo modello di modello di riposo
connettersi al tuo servizio in modo e cosa
accade in background è che il
i modelli di resto del bilanciamento del carico contengono
nastro del connettore che è il lato client
bilanciamento del carico dinamico da scoprire e a
connetti i tuoi servizi automaticamente così
questo è il prossimo cittadino del nostro ecosistema
che ha introdotto un carico lato client
equilibratore esso tradizionalmente piccoli fasci
sono i nostri componenti lato server e il
il servizio di bilanciamento del carico lato client è parte
del troverà applicazione e così via
si rende consapevole di quali servizi sono
disponibile e rende la propria scelta come
quale servizio chiamare in un dato momento
così anche noi nella scoperta del servizio
slide Stavo parlando del carico
modello di resto di equilibrio e quello è
automatico si connette a nastro e bene
che nastro stesso è un lato client
load balancer e anche da Netflix
La famiglia OSS e cosa fa è
automatico in taghrida il servizio
scoperta per ottenere l’elenco dei server e
la gioventù Eureka quando è presente sulla sua
ultimo percorso e bilanciamento del carico
automaticamente se più servizi di
i nostri Microsoft sono disponibili così là
è nessuna implementazione chiamata è tutto
sito del cliente e non hai bisogno del tuo
configurazione ID di servizio durante la lavorazione
fuori servizio
devi in un sistema distribuito te
dover affrontare il fatto che devi
sfida dove il volto del
sfide che stiamo interagendo over
una rete lenta e affidabile, in modo che abbiamo
per renderlo più resistente dobbiamo
definire per fallimento quel significato che noi
Devo introdurre i timeout handlings e
devono fornire quattro gambe e anche
modello interruttore e qual è il
compito dell’interruttore che abbiamo implementato come
con la storia è un’altra famiglia del
un altro membro della famiglia della collana
OSS monitora tutte le chiamate remote
hai definito un comando isterico e
tiene traccia di ogni richiesta e crea e
conta il numero di successo e
richieste non riuscite che hai fatto e con a
soglia specifica dell’interruttore
esso stesso si apre e ritorna e fallisce
immediatamente potrebbe essere per esempio a
fallimento in fallback che hai
precedentemente precedentemente definito o un
eccezione pure, quindi è un fuoco veloce
strategia devo fare un po ‘
più veloce così vado così questo succede a
lato client, quindi non è necessario a
server è necessario solo specifico
annotazioni ad esso in modo da definire a
comando di cronologia e definizione come pubblico a
messaggio se vuoi e tu sei allora
automaticamente una storia storia è quindi
monitoraggio della chiamata remota e di cosa si tratta
anche molto importante è che non lo fai
dimentica di impostare anche i tuoi timeout
perché questo è qualcosa che la storia
non importa che sia stato preso
cura di
invece devi impostare anche il tempo libero
e per quale storia emette
ogni evento acuto e dei suoi Stati membri attuali
un flusso di attività che può essere
visualizzato come
attraverso la dashboard della storia è una specie di
un’interfaccia web di monitoraggio che consente
per monitorare i tuoi servizi su on
livelli di servizio così di solito lo abbiamo ancora
monitoraggio degli animali a livello di sondaggio e
Hystrix
il cruscotto bene insieme era la turbina
questo è un altro strumento di Netflix OSS
ti consente di visualizzare i servizi
lo stato di ciascun servizio e Kampala
data la vista stessa così la corrente
ecosistema quello che abbiamo coperto finora è
un server di autorizzazione della guida API
scoperta e monitoraggio dei servizi
cruscotto e si potrebbe pensare bene noi
sono fatti ma non è così perché
ce ne sono molti altri da coprire
esempio la configurazione centrale
gestione che è possibile stabilire o
la registrazione di analisi per il debug per
esempio che è possibile registrare attraverso across
confini del servizio e cosa è cosa
anche molto molto importante è la build
processo e questo continua l’integrazione
pipeline di consegna continua che tu
hai già nel tuo nel tuo monolito
ma ora devi applicarlo per micro
servizio e dal fatto che tu sei
occuparsi di API ora e più di
prima di dover estendere il test
con test contrattuali guidati dai consumatori
devi assicurarti di avere un
ambiente completamente accessibile per il tuo
sviluppo che non devi prendere
cura come sviluppatore per la creazione di tutti
questi stessi servizi quindi le lezioni
quello che abbiamo imparato è quello durante il nostro
viaggio e non siamo ancora lì così noi
non sono ancora alla fine, quindi è così
l’inizio era in decomposizione e grandi pezzi
frustra perché ci vuole molto tempo
e prima di ottenere qualcosa fatto e
si ritorna si riceve un risultato e sì
stabilire il tuo ecosistema richiede molto
di volte e un sacco di tempo e richiede
un sacco di nuove competenze e strumenti e quindi noi
iniziato proprio all’inizio con no
esplicito esplicito
team di infrastruttura e stava rallentando
giù il processo perché ogni squadra era
tipo di trovare la propria soluzione e
quindi stava rallentando tutto e
anche ciò che aiuta e che non avevamo
proprio all’inizio come olistica
immagine dell’architettura di destinazione
perché ti tiene concentrato su ciò che è
fare il prossimo e bene alla fine ci è voluto un
molte prende ha preso e prende avrà
molto più a lungo di quanto originariamente
anticipato perché stai andando ora
in questo mondo completamente nuovo così come a
il riassunto è ciò che possiamo ottenere
le nostre lezioni apprese sono che è meglio
basta iniziare in piccolo e dividere in gestibile
passi così servizio per servizio invece cosa
abbiamo fatto all’inizio era una specie di
sbaglio che anche il nostro pezzo era troppo
squadre grandi e affermate che per
micro servizi che abbiamo già fatto
le nostre app di collaborazione ma anche prima
infrastruttura perché questo è il
l’ecosistema deve correre e tu come a
sviluppatore Non voglio prendere cura di
l’ecosistema tutto il tempo invece tu
Devo avere questa è la nostra esperienza
abbiamo creato anche un team di infrastruttura
e anche definire un’architettura di destinazione a
tenere a rimanere concentrati su ciò che si vuole
raggiungere il prossimo e bene sì è da pari
anche se è ancora una lunga strada da percorrere
posso dire che è possibile trasferire tutto
i modelli in micro servizi anche con
risorse limitate e quindi aver detto
questo non solo sul suo prodotto ma anche
la nostra architettura software è stata creata con
ama tanto il sudore e le lacrime e anche adesso
con i micro servizi grazie
tu
quindi una grande organizzazione per esempio
prendiamo Netflix immagino di non averlo
un numero esatto ma almeno hanno
più di 1000 ingegneri del software in
confronto abbiamo 12 quindi c’è un grande
differenza tra grandi organizzazioni
e start-up e purtroppo lì
non esiste una regola d’oro che puoi
facilmente applicare maledetto così invece si deve
affrontare un sacco di compromessi lungo il tuo
modo
Grazie scivolo per favore e prima di andare
prima di entrare nell’ordine nel nostro
dettagli del viaggio fammi darti un
piccola breve panoramica di ciò che siamo
così facendo mi chiamo Ivana Kaiba
Sono il CTO del solo software che siamo
iniziare applicato ad Amburgo e solo
software che abbiamo sviluppato solo socialmente
soluzione b2b che fornisce app per
collaborazione e comunicazione a
team di supporto che lavorano di più
in modo efficiente e puoi fare una diapositiva successiva
per favore e prima che io spieghi perché noi
introdotto come start-up era molto alto
con meno risorse che abbiamo introdotto
micro servizi ti porterò su un
viaggio verso il nostro inizio in modo per lo
All’inizio tutto era un’unica unità
e ogni aspetto quindi eravamo una squadra
lavorando su un prodotto di collaborazione
implementato come una base di codice basata su
una pila di tecnologia successiva diapositiva per favore
e dopo un po ‘tutto si è evoluto
che è abbastanza buono ma prova va bene
perché abbiamo aggiunto sempre più funzionalità
al nostro prodotto e al nostro numero di utenti
aumentato e il numero di voi e
la squadra stava crescendo, quindi è supposto
essere fantastico ma invece raggiunto a
punto circa un anno e mezzo
fa dove tutto sembrava un po ‘goffo
tutto era un po ‘legato insieme così
dal punto di vista organizzativo che
ci sono voluti abbastanza tempo per fare le cose così
discussioni riunioni o decisioni e noi
non aveva davvero assegnato chiaramente
responsabilità quindi ci è voluto un po ‘
qualcuno si sentiva responsabile per uno specifico
azione per esempio quando un patto si presenta così
chi prende prende il responsabile di
analizzare e sistemarlo in modo che i nostri processi fossero
tipo di lavoro siamo un po ‘ lenti e nostri
produttività subita e dal
prospettiva dei prodotti che eravamo
aggiungendo continuamente più funzionalità in alto
di esso e così l’esperienza utente e
usabilità utente sofferta dal
emendamenti continuativi perché
invece di risolvere un utente fedele
problemi in un modo molto semplice eravamo
costantemente o incorrere sempre più
confondendoli così e dal software
attractor architecture perspective it
non è stato molto facile aggiungere nuove funzionalità
senza influenzare l’intero sistema e
anche per non rilasciare quelle modifiche che
abbiamo fatto senza ridistribuire senza
ricostruire e ridistribuire l’intero
sistema quindi c’era una sorta di bisogno
per dividere e spostare la prossima diapositiva
per favore così prodotto saggio che era uno e
un anno e mezzo fa pensavamo a noi
ha stabilito la visione per dividere il nostro
prodotto o una grande palla di fango in
singoli annunci e ognuno di loro prende
prendersi cura di un caso d’uso specifico e
risolvere un problema e questo molto
bene così abbiamo diviso il nostro unico prodotto in
diverse app di collaborazione
prendersi cura della condivisione dei documenti o attività
gestione o epinet per tempo reale
collaborazione e anche per lo scambio o
condividere notizie e informazioni aziendali
con un social network aziendale successivo
leggermente
saggio organizzativo abbiamo diviso il nostro 1
squadra in più squadre più piccole e
con l’obiettivo di stabilirsi autonomo
i team interfunzionali erano ben definiti
responsabilità quindi vogliamo i nostri team
lavorare su diverse parti di sistemi
mobili indipendenti tra loro a
una velocità diversa e con il minimo
impatto impatto tra i team
assegnato a ciascuno di questi gruppi specifici
schede di collaborazione in modo che il contatto
può prendersene cura con questi di questi
app di collaborazione e sviluppo e
distribuirli alla loro velocità, così noi
voglio rilasciare le modifiche indipendentemente come
bene, veloce e senza intaccare il
intero sistema per ottenere l’autonomia che abbiamo
sbarazzarsi delle dipendenze e di
raggiungere questo abbiamo anche due kabobs
all’interno della nostra architettura software così dentro
la lunga corsa che volevamo presentare
micro servizi e dopo che abbiamo
petizione il nostro prodotto in un’unica app
e dividi la nostra unica grande squadra in più piccola
quelli che eravamo così ben definiti
responsabilità ci lasciamo la logica
il passo successivo è stato introdurre micro
servizi per ottenere anche autonomia e
flessibilità nella nostra architettura software
così anche questo sembra molto facile all’inizio
colpo d’occhio ma è bello è molto più facile
dire quindi fare perché i micro servizi
fare un po ‘ venire con un sacco di
complessità che potrebbe non essere ovvia a
prima vista così in un sistema distribuito
o i tuoi micro servizi stanno comunicando
su una rete lenta e inaffidabile e
questo significa che questi servizi possono fallire
e in qualsiasi momento e devi
stabilire un meccanismo per rendere il vostro
sistema resiliente e quindi è stato necessario aggiungere
complessità per gestire l’errore parziale in
il tuo sistema e poiché i microservizi sono
trattare con dati partizionati che sei
perdere consistenza e una distribuzione
sistema devi anche prendertene cura
gestire la coerenza finale nel tuo
sistema e dal momento che sei ora dal tuo
aumenta la complessità operativa
perché devi affrontare di più
parti in movimento devi aggiungere un complesso
82 anni di monitoraggio e implementazione come
bene e visto che i tuoi micro servizi sono
comunicando tramite un’API si – lo hai
considerare e fare riferimento ad esso nel tuo
fase di test con il consumatore
appaltatori guidati per esempio e con
tutte quelle complessità è quella tua
il set di abilità è completamente diverso da quando
implementando un micro servizio e questo è
un po ‘come costoso sull’altro
da un lato perché o devi
impara il nuovo set di abilità o assumi
qualcuno e assumere alcuni consulenti per
esempio e un’altra cosa che avete
riflettere è come gestire
autorizzazione di autenticazione e un’altra
l’aspetto è l’ambiente di sviluppo
perché non vuoi i tuoi sviluppatori
istituire tutti i tuoi servizi e ha detto
vuoi avere un accesso facile in questo modo
possono sviluppare i loro servizi senza intoppi
è probabile
così districare il monolite è un duro lavoro
e richiede molto tempo così
il processo di sviluppo sta inizialmente rallentando
in fondo sta peggiorando prima che sia
migliorare e la trasformazione
il processo stesso richiede molto più tempo di te
originariamente anticipato così all’inizio quando
li abbiamo presentati abbiamo perso un traguardo
e questo è il motivo per cui si deve
prenditi cura di quelle complessità e prendi
il tuo tempo per ottenere le tue capacità fino a questo
puoi eseguire un micro servizio nel
ecosistema e se hai se lo sei
trattare con funzionalità di base con a
molte dipendenze è molto difficile
districa tutte queste dipendenze e tu
non puoi lasciare una parte che tu ancora
avere il sistema in esecuzione che hai ancora
per mantenere
e prenditi cura di così dopo, se guardi
tutte queste complessità e sfide di
microservizi che potresti chiederti
bene devo introdurre Microsoft
architettura o semplicemente stare in una delle
l’architettura bene e dipende da
dipende da ciò che si vuole raggiungere e da ciò
dipende da in che situazione
sono e per noi è stata la mia procedura
I micro-servizi Neetu non erano solo
tecnico guidato ma lo era
organizzativo e prodotto scritto così noi
prima diviso il nostro prodotto in singolo
app di collaborazione e poi anche la nostra
squadra in più piccola squadra era ok
con l’obiettivo di stabilirsi autonomo
team così e vogliamo assegnare a ciascuno
delle squadre ben definite
responsabilità in modo che tutti possano
lavorare in modo efficiente da soli
servizi responsabili e inoltre noi
voglio sviluppare e distribuire in modo indipendente
quindi ogni squadra dovrebbe avere la capacità
per implementarlo e distribuirlo a
la loro velocità e velocità senza
interessando l’intero sistema e anche
senza influenzare le altre squadre e a
rilasciare rapidamente le modifiche, così è stato il nostro
motivazione perché abbiamo introdotto micro
servizi e dopo aver deciso bene
prossima diapositiva per favore
iniziamo con il servizio micro su come
come possiamo iniziare con i micro servizi
quindi abbiamo la tua grande palla di martin tu
cercare di decomporsi come servizio
di esso e quindi ciò che abbiamo poi derivato era a
tipo di processo di trasformazione
esistente composto da diverse parti
il primo è identificare i candidati
quali sono buoni candidati per il mio per
servizi il secondo è il de coma
decompone il processo di decomposizione stesso
e il terzo è la stabilire la
ecosistema di micro servizi che non lo farò
devono andare sequenziali che possono anche essere
in parallelo pure
quindi iniziamo con l’identificazione
candidati e prima di farlo
quello dopo è chiaramente necessario prendere in considerazione
i concetti chiave della buona modellizzazione
micro-servizi per raggiungere il principale
benefici dei micro servizi e questi
sono l’accoppiamento lento tra il
servizi e alta coesione in a
servizio quindi non mi dispiace
quindi quando i servizi sono liberamente accoppiati a
il cambiamento di un servizio non deve influire
gli altri servizi e si apportano modifiche
facilmente posso apportare modifiche prima a uno
servizio e distribuito senza modifiche
l’intero sistema è ad alta coesione
riflessi correlati correlati a tale tasso
comportamento si siederà insieme così quando
quando cambi questo comportamento che vuoi
per cambiare questo comportamento in un singolo
punto se hai due cambiamenti a
diverse parti del tuo sistema che hai
per ridistribuire tutti questi servizi che sono
in relazione a questo comportamento e poi al tuo
il processo di implementazione è nuovamente accoppiato
insieme e questo è qualcosa che noi
non voglio ottenere questo è tutto
questi sono i concetti chiave che hai
da tenere a mente per per identificare
candidati per i micro servizi quindi dopo
leggermente questo comportamento correlato è
di solito riflesso dal contesto limitato
abbiamo sentito parlare prima che sia un modello
del design guidato dal dominio ed è
riflettendo il responsabile
responsabilità per affari ben definiti
funzione di un business ben definito
capacità va bene
è un mezzo automatizzato
miracolo così nel nostro caso abbiamo usato il nostro
collaborazione abs funzionante come cofano
contesto come il servizio di grano coercitivo
confini e da quel punto possiamo andare
dentro e per trovare grandi servizi tanto a lungo
successivamente così e ora la prossima parte di
il processo di trasformazione inizia il
scomposizione del servizio micro
candidati il primo approccio che noi
fatto è che abbiamo stabilito una coesistenza
servizio da zero e abbiamo usato il nostro
guida l’amplificatore di collaborazione facendo attenzione
di condivisione dei documenti e sto rovinando tutto
non era una buona idea, ma in generale il
parlando non c’è niente di sbagliato in
creare un servizio coesistente da zero
ma dimenticherò di essere al
svantaggi nella prossima diapositiva ma che cosa
abbiamo fatto e questo è al coesistere
servizio lo stavamo creando da zero
e ha stabilito una condivisione dei documenti
servizio stesso che ha i dati
autorità sui documenti e quindi solo gioia
stesso possiede i dati o il merito
questo significa e ogni documento ha un
autore assegnato e autore stesso
è ancora derivante dal profilo
gestione che è ancora conservata nel
monolite stessa quindi la prossima domanda
sorgere così ogni volta che mostriamo un documento
dobbiamo quindi richiedere l’autore
informazioni direttamente direttamente dal
modelli o dobbiamo quindi tenerlo
ridondante nella nostra e nostra app di guida così
questo è quello che abbiamo fatto abbiamo copiato abbiamo tenuto un
dati ridondanti del profilo
informazioni nel nostro nel nostro nuovo servizio
e per tenerlo in zinco abbiamo stabilito
un broker di messaggi che il monolite
stesso è quindi la modifica di pubblicazione
eventi fino a quando un dato profilo ha
stato aggiornato in modo che i segni del
nuovo può consumare e aggiornarlo
e una tecnologia di conseguenza bene per essere onesti
è stato molto pesante intraprendere perché
abbiamo fatto tutto in una volta, come ho detto
prima non era un equivalente esatto di
il servizio esistente invece abbiamo aggiunto
più funzioni nella stessa fase del processo
e abbiamo introdotto dati completamente nuovi
struttura perché anche noi avevamo voluto
coprire anche alcuni requisiti specifici
e anche una nuova interfaccia utente per
migliorare l’ esperienza dell’utente stesso e
nel frattempo dobbiamo ancora
mantenere ed eseguire il sistema attuale così
questo ha richiesto molto tempo ed è stato un po ‘di
frustrante perché non li abbiamo ottenuti
risultati molto rapidamente e non abbiamo potuto
guadagna davvero esperienza attraverso il
processo prendendo questo primo documento come
un servizio e distruttività del
servizio e aggiungendo nuove funzionalità in cima
anche così invece dovremmo avere
incentrato su pezzi più piccoli e quindi cosa noi
è stato invece il prossimo servizio
noi la prossima app di collaborazione che noi
usato come candidato per i micro servizi
è che l’abbiamo diviso in pezzi più piccoli
e andando dall’alto verso il basso così abbiamo
identificato il prossimo candidato per micro
servizi e quello che abbiamo fatto per primo è quello
abbiamo estratto l’ interfaccia utente prima come
un’app separata che estrae il client web
e la stessa logica di business è a questo
passo ancora residente e poi il
monolite e il client Web stesso
il monolite ne sta introducendo un numero
API che può essere indirizzata dal nuovo
client web Web estratto, quindi questo dà
noi il vantaggio che possiamo sviluppare e
distribuire l’app Web in modo indipendente e
che possiamo iterare sul
sull’interfaccia utente molto molto rapidamente
quindi questo è il primo passo che abbiamo fatto
il secondo passo è quindi estrarre il
logica aziendale e questo è più lavoro
di estrarre il client web perché
si hanno anche per prendersi cura del
dipendenza che aveva prima nel
monolite così per ogni dipendenza quella
hai avuto e l’ammonal è che sei tu
devi specificare o fornire una API
sui nuovi server, ad esempio, se
i monitor stanno ancora accedendo al nostro nuovo
servizio che abbiamo fornito ad esempio un RESTO
Anche la console API potrebbe essere un’altra
e a quel punto siamo ancora
accesso alla stessa memoria di dati e
questo è quello che stiamo districando
il prossimo perché diventare uno standalone
servizio disaccoppiato abbiamo finalmente bisogno di
dividere l’ archiviazione dei dati in modo che
il nostro nuovo servizio sta diventando i dati
Autorità o sta ottenendo i dati
autorità delle proprie funzioni aziendali
e nel caso che tu avessi tenuto
dati ridondanti che abbiamo fatto per esempio
con la nostra app di guida come quella che abbiamo mantenuto
dati dell’autore ridondanti non appena tu
fallo devi tenerli
in qualche modo e zinco e tu per esempio e
l’abbiamo fatto stabilendo un messaggio
broker così ogni volta che i dati ridondanti
è stato aggiornato e i monoliti e
l’evento è stato presentato e il
il consumatore lo ha aggiornato
di conseguenza così quando hai a che fare con
diversi candidati per i micro servizi
ti chiedi, ok, quale dovrei?
fai prima quello che mostrerò il primo
indirizzo e facile
il principio è estrarre quelli che sono
molto facile da estrarre perché hanno
meno o pochissime dipendenze e
perché quando inizi con quelli
sono facili da estrarre stai guadagnando a
molta esperienza in un breve periodo di
tempo e quindi anche tu stai ricevendo
esperienze potrebbe
servizi ma anche con l’estrazione
processo in particolare e quindi è possibile
concentrati anche su quello che ti dà
il massimo vantaggio quando estrai un vero
micro-servizi per esempio se ne hai
alcuni servizi o alcuni candidati
cambia spesso, allora è un bene
candidato a usarlo come prossimo e così
poi dopo aver creato tutto ciò che hai
ti sei convertito nel mio servizio per te
può quindi distribuire le modifiche più velocemente di
prima
in altre parole un’altra opzione è quella
stai estraendo quelli che stanno usando
requisiti di risorse differenti per
esempio se usi qualcuno con un livello elevato
il consumo di memoria è possibile distribuire su
server con alto che alto equipaggiato
memoria in modo da poter scalare il tuo micro
mondo dei servizi facilmente e altra cosa è
che dovresti smettere di dar da mangiare
monolite perché quando ti stai ritagliando
i tuoi servizi da una parte e
stai aggiungendo nuove funzionalità o nuove
funzioni sui monitor quindi sul tuo
i monitor non si restringono invece
è lo stesso o nel peggiore dei casi
è anche in crescita e rallenta il tuo
processo di trasformazione quindi la prossima cosa
è che vorrei parlare è
stabilire un ecosistema Microsoft e questo
potrebbe essere un po ‘ particolare per noi
perché stiamo gestendo i nostri servizi
prodotto non solo nel cloud ma anche
in loco quindi e abbiamo grande
i clienti che richiedono di eseguire il nostro
servizi sulle loro macchine così noi
hanno anche stabilito un ecosistema e così
il primo è quello dopo che abbiamo
districati i nostri micro servizi come facciamo noi
indirizzare loro come li accediamo da
Internet da internet pubblico
dal client dall’interfaccia utente
e una cosa è che potresti direttamente
accedervi tramite un’interfaccia utente ma
questo si imbatte nel problema che tu sei
esponendo alcune parti della tua API interna
che sono in genere correlati al servizio utente
comunicazione ed in caso di
i servizi sono in esecuzione
su diversi domini, specialmente con il
Permessi JavaScript abilitati
condivisione di risorse incrociate e anche
il tuo cliente potrebbe fare invece in termini di
in caso di recupero di informazioni da
diversi micro servizi che devi fare
più viaggi di andata e anche tu potresti
avere clienti diversi un client mobile
e un client desktop e potrebbero avere
esigenze diverse quindi quello che puoi
Stabilire quindi è un gateway API per funzionare
come adattatore come singolo punto di ingresso
per te micro mondo dei servizi e questo
si eliminano i requisiti del corso
e perché ora stiamo correndo su uno
dominio singolo su un dominio e mantiene
all’interno delle tue parti interne della tua API
di tutti i tuoi micro servizi interni
mondo e potrebbe essere un gateway come pure
anche gestito come la traduzione di protocollo
e fornisce anche il meccanismo di caching
i nostri stessi monitor erano principalmente
implementato in Java e utilizzato per il nostro
ecosistema usiamo principalmente Netflix open
software sorgente e con la molla
fornisce le librerie cloud e Netflix OSS
un sacco di librerie di quadri per costruire
la tua architettura di micro- servizi e
infrastruttura in modo tale che il cloud di primavera offra
un’interazione molto semplice con noi
la maggior parte delle reti che l’OSS stava aggiungendo
dipendenze dal pass di classe e
annotare qualcosa che ho davvero sollevato
alcuni esempi più avanti quindi l’API
gateway è il primo cittadino del nostro
ecosistema di micro servizi ora il prossimo
uno è come il servizio di autorizzazione o
c’è una gestione delle prenotazioni e
proteggere un monolite è facile perché tu
di solito hanno un componente di sicurezza comune
che si prende cura dell’autorizzazione in
la tua catena di gestione delle richieste e poi
si propaga all’utente
formazione al tuo metodo successivo
chiama e loro possono fidarsi di questo
informazioni per garantire il microservizio
invece è molto è molto difficile
perché si deve capire come
i servizi possono fidarsi l’uno dell’altro e tu
anche evitare la manipolazione
autorizzazione in ogni micro-servizio
e questo qualcosa è qualcosa che può
essere gestito introducendo e globale
server di autorizzazione che si occupa di
questa preoccupazione trasversale di
autorizzazione quindi abbiamo stabilito un tutto
l’intero server deve essere eseguito come proprietario
servizio e il nostro gateway API così tutto
la valutazione dei server è come fornire
token di accesso che può essere l’interfaccia utente
utilizzare le risorse specifiche del Texas per affrontare
risorse dai micro servizi
loro stessi e il nostro gateway API in questo
in questo contesto è stato usato come sistema operativo
relè token che significa che dopo il
l’interfaccia utente ha ottenuto questo
token di accesso è probabilmente lo è
pubblicare il token di accesso insieme a
la richiesta originale al micro
servizi in sé uno svantaggio è con
questo si avvicina al micro servizio
deve ancora controllare nabela G il
bene validità del token e
inoltre devono anche ritirare l’ utente
informazioni in modo che la pelle causi il noleggio
carico maggiore sul servizio di autorizzazione
così che potrebbe essere anche un altro approccio
che hai introdotto nel token Web JSON
invece di diminuire il carico del
servizio di autorizzazione mm-hmm devi
eliminare la convalida del token e anche
il rituale delle informazioni dell’utente e
potremmo invece trasportare l’utente
informazioni come reclamo di identità su a
Token Web JSON in aggiunta a questo Web JSON
token viene automaticamente firmato da
servizio di autorizzazione in modo che il Micra
i servizi stessi possono fidarsi di questo
informazioni l’API abilitata gateway
funziona come un
Constanza lations così è stato quando
l’utente l’ interfaccia utente il tuo cliente
richiede un token di accesso e ottenuto
dopo aver ottenuto questo token di accesso
invia questo token insieme al suo
richiesta al gateway API e all’API
gateway fa la traduzione così
estrae il token di accesso e lo usa
uno ai sensi dell’autorizzazione
il server riceve un token Web JSON e
prevenire pubblica poi inoltra quelli
Token Web JSON insieme alla richiesta di
i sottostanti micro-servizi in modo tale
loro che i servizi di Micra stessi
basta prendere solo devono elaborare
questo questo token web che è abbastanza facile
implementare il prossimo cittadino del nostro
l’ ecosistema di micro- servizio è il servizio
scoperta e architettura dei miei microsomi
può contenere un gran numero di micro
servizi e interagire tra loro
Così come si può facilmente identificare servizi elia
tutte le istanze in esecuzione che vorrebbero
interagire con una configurazione manuale
è totalmente poco pratico ed è molto
fragile e quindi una scoperta di servizio
fornisce invece un singolo servizio di ricerca
per ogni registro di istanze di servizio
registrandosi automaticamente a
l’avvio e altri servizi possono scoprire
quelli recuperano quelli già miserabili
servizi e scoprili e poi
in seguito connettendoci così alcuni
le soluzioni sono ad esempio Netflix voi
concordare Eureka console in città o su
PIPA e abbiamo usato nel nostro caso noi
usato Eureka perché è insieme
Sprint cloud perché è davvero facile
integrazione è molto molto facile a
integrare un bowler perché è solo
lì devi solo fornirti solo
devono fornire il rispettivo
dipendenze dal pass di classe e
annotare da un lato il tuo servizio
e dall’altra parte il tuo servizio è tuo
i clienti che quindi registrano automaticamente
all’avvio i micro servizi che vogliono
utilizzare il nostro servizio stesso può anche essere
può creare dalla loro parte per esempio a
modello di riposo bilanciato e vengo
a questo più tardi e utilizzare l’ID di servizio
e al relativo modello di modello di riposo
connettersi al tuo servizio in modo e cosa
accade in background è che il
i modelli di resto del bilanciamento del carico contengono
nastro del connettore che è il lato client
bilanciamento del carico dinamico da scoprire e a
connetti i tuoi servizi automaticamente così
questo è il prossimo cittadino del nostro ecosistema
che ha introdotto un carico lato client
equilibratore esso tradizionalmente piccoli fasci
sono i nostri componenti lato server e il
il servizio di bilanciamento del carico lato client è parte
del troverà applicazione e così via
si rende consapevole di quali servizi sono
disponibile e rende la propria scelta come
quale servizio chiamare in un dato momento
così anche noi nella scoperta del servizio
slide Stavo parlando del carico
modello di resto di equilibrio e quello è
automatico si connette a nastro e bene
che nastro stesso è un lato client
load balancer e anche da Netflix
La famiglia OSS e cosa fa è
automatico in taghrida il servizio
scoperta per ottenere l’elenco dei server e
la gioventù Eureka quando è presente sulla sua
ultimo percorso e bilanciamento del carico
automaticamente se più servizi di
i nostri Microsoft sono disponibili così là
è nessuna implementazione chiamata è tutto
sito del cliente e non hai bisogno del tuo
configurazione ID di servizio durante la lavorazione
fuori servizio
devi in un sistema distribuito te
dover affrontare il fatto che devi
sfida dove il volto del
sfide che stiamo interagendo over
una rete lenta e affidabile, in modo che abbiamo
per renderlo più resistente dobbiamo
definire per fallimento quel significato che noi
Devo introdurre i timeout handlings e
devono fornire quattro gambe e anche
modello interruttore e qual è il
compito dell’interruttore che abbiamo implementato come
con la storia è un’altra famiglia del
un altro membro della famiglia della collana
OSS monitora tutte le chiamate remote
hai definito un comando isterico e
tiene traccia di ogni richiesta e crea e
conta il numero di successo e
richieste non riuscite che hai fatto e con a
soglia specifica dell’interruttore
esso stesso si apre e ritorna e fallisce
immediatamente potrebbe essere per esempio a
fallimento in fallback che hai
precedentemente precedentemente definito o un
eccezione pure, quindi è un fuoco veloce
strategia devo fare un po ‘
più veloce così vado così questo succede a
lato client, quindi non è necessario a
server è necessario solo specifico
annotazioni ad esso in modo da definire a
comando di cronologia e definizione come pubblico a
messaggio se vuoi e tu sei allora
automaticamente una storia storia è quindi
monitoraggio della chiamata remota e di cosa si tratta
anche molto importante è che non lo fai
dimentica di impostare anche i tuoi timeout
perché questo è qualcosa che la storia
non importa che sia stato preso
cura di
invece devi impostare anche il tempo libero
e per quale storia emette
ogni evento acuto e dei suoi Stati membri attuali
un flusso di attività che può essere
visualizzato come
attraverso la dashboard della storia è una specie di
un’interfaccia web di monitoraggio che consente
per monitorare i tuoi servizi su on
livelli di servizio così di solito lo abbiamo ancora
monitoraggio degli animali a livello di sondaggio e
Hystrix
il cruscotto bene insieme era la turbina
questo è un altro strumento di Netflix OSS
ti consente di visualizzare i servizi
lo stato di ciascun servizio e Kampala
data la vista stessa così la corrente
ecosistema quello che abbiamo coperto finora è
un server di autorizzazione della guida API
scoperta e monitoraggio dei servizi
cruscotto e si potrebbe pensare bene noi
sono fatti ma non è così perché
ce ne sono molti altri da coprire
esempio la configurazione centrale
gestione che è possibile stabilire o
la registrazione di analisi per il debug per
esempio che è possibile registrare attraverso across
confini del servizio e cosa è cosa
anche molto molto importante è la build
processo e questo continua l’integrazione
pipeline di consegna continua che tu
hai già nel tuo nel tuo monolito
ma ora devi applicarlo per micro
servizio e dal fatto che tu sei
occuparsi di API ora e più di
prima di dover estendere il test
con test contrattuali guidati dai consumatori
devi assicurarti di avere un
ambiente completamente accessibile per il tuo
sviluppo che non devi prendere
cura come sviluppatore per la creazione di tutti
questi stessi servizi quindi le lezioni
quello che abbiamo imparato è quello durante il nostro
viaggio e non siamo ancora lì così noi
non sono ancora alla fine, quindi è così
l’inizio era in decomposizione e grandi pezzi
frustra perché ci vuole molto tempo
e prima di ottenere qualcosa fatto e
si ritorna si riceve un risultato e sì
stabilire il tuo ecosistema richiede molto
di volte e un sacco di tempo e richiede
un sacco di nuove competenze e strumenti e quindi noi
iniziato proprio all’inizio con no
esplicito esplicito
team di infrastruttura e stava rallentando
giù il processo perché ogni squadra era
tipo di trovare la propria soluzione e
quindi stava rallentando tutto e
anche ciò che aiuta e che non avevamo
proprio all’inizio come olistica
immagine dell’architettura di destinazione
perché ti tiene concentrato su ciò che è
fare il prossimo e bene alla fine ci è voluto un
molte prende ha preso e prende avrà
molto più a lungo di quanto originariamente
anticipato perché stai andando ora
in questo mondo completamente nuovo così come a
il riassunto è ciò che possiamo ottenere
le nostre lezioni apprese sono che è meglio
basta iniziare in piccolo e dividere in gestibile
passi così servizio per servizio invece cosa
abbiamo fatto all’inizio era una specie di
sbaglio che anche il nostro pezzo era troppo
squadre grandi e affermate che per
micro servizi che abbiamo già fatto
le nostre app di collaborazione ma anche prima
infrastruttura perché questo è il
l’ecosistema deve correre e tu come a
sviluppatore Non voglio prendere cura di
l’ecosistema tutto il tempo invece tu
Devo avere questa è la nostra esperienza
abbiamo creato anche un team di infrastruttura
e anche definire un’architettura di destinazione a
tenere a rimanere concentrati su ciò che si vuole
raggiungere il prossimo e bene sì è da pari
anche se è ancora una lunga strada da percorrere
posso dire che è possibile trasferire tutto
i modelli in micro servizi anche con
risorse limitate e quindi aver detto
questo non solo sul suo prodotto ma anche
la nostra architettura software è stata creata con
ama tanto il sudore e le lacrime e anche adesso
con i micro servizi grazie
tu
Please follow and like us: