La complessità nei moderni sistemi software - 2ª parte Marzo 2019 - Server users.dimi.uniud.it
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
La complessità nei
moderni sistemi software
2ª parte
Marzo 2019
Stargate Un semplice servizio di Authentication, Authorization & Accounting scritto in Kotlin (https://kotlinlang.org) a scopo didattico. Esempio di codifica di un dominio relativamente piccolo. Esempio di evoluzione della codifica all'aggiungersi di requisiti.
Step 1: requisiti di base Una primissima versione di un software di AAA deve permettere la registrazione di un utente e la sua autenticazione. • Utente è identificato per email • Email verificata • Prima password scelta tramite token • L'utente può autenticarsi con email e password
Credenziali
Account
Token di attivazione
Servizio di gestione utenze
Servizio di gestione utenze (fixed)
Servizio di autenticazione
Step 2: validazione password • La password deve essere validata secondo alcuni criteri (ad es.) o Minimo 8 caratteri o Contiene lettere minuscole o Contiene lettere maiuscole o Contiene cifre o Non contiene spazi • La password scade dopo un certo intervallo di tempo • La password può essere resettata • La password può essere cambiata
Validazione implicita
Scadenza password
Cambiare la password
Testing
Step 2: password history & brute-forcing protection • L'utente non può cambiare la password con una che ha già utilizzato • Il numero di tentativi di login per utente dev'essere limitato
Password history validation
Brute forcing protection
Giacomo Alzetta giacomo.alzetta@cybaze.it (Trieste)
Mauro Rocchi mauro.rocchi@cybaze.it (Udine)
https://cybaze.it
Milano, Roma, Torino, Napoli, Trieste, Udine, Cesena, Benevento, BrusselBig ball of mud • Scadenze stringenti • Debito tecnico • Modello inesistente • Scelte architetturali • Logica sparpagliata e incoerenti duplicata • Architettura in secondo • Responsabilità indefinite piano • Codice contorto e • Cliente insoddisfatto incomprensibile • Tempo/denaro • Documentazione insufficiente mancante o incoerente • Compromessi continui
Monolithic architecture • Un singolo artefatto • Sistema centralizzato • Semplice e gestibile, quando è piccolo • La complessità evolve rapidamente
Microservice architecture • Costituita da diversi servizi che collaborano tra loro • Servizi più semplici da comprendere ed evolvere • Sistema distribuito • Integrazione tra i servizi più complessa
Distribuited monolith • Tutti gli svantaggi del monolite • con la complessità dei sistemi distribuiti • Servizi fortemente accoppiati • Cambiamenti a cascata • Ridurre le responsabilità • Prevedere i cambiamenti
Decompose by DDD subdomains • Singolo modello difficile da mantenere coerente • Conviene dividere il sistema in diversi «bounded contexts» • Ogni contesto è dotato di un modello coerente e può essere promosso a servizio • Ogni servizio ha un nucleo costituito da un insieme di «aggregati»
Aggregate rules • Esternamente, interagire solo con aggregate root • Referenziare aggregati tramite chiave primaria • Una singola transazione agisce su un singolo aggregato
Repositories • Materializza aggregate roots • Aggregati persistibili come documenti (es. https://github.com/emaze/emaze-pongo) • Concorrenza protetta da tecniche di locking
Decouple with domain events • Un evento rappresenta un cambiamento rilevante accaduto nel sistema • Immutabile • Può essere arricchito • Propagato attraverso messaggi • Consumato dai servizi interessati in modalità publish/subscribe
Communication mechanisms • Comunicazione sincrona (diretta) o Via HTTP (es. REST o gRPC) o Circuit breaker o Service discovery • Comunicazione asincrona (scambio di messaggi) o Message broker o Increase availability o Messaggi duplicati, out-of-order, race conditions…
Transactional messaging
• Commit/Publish sono operazioni indipendenti
• Errori lasciano il sistema in stato inconsistente
• Outbox pattern
Service
Commit data Broker
and messages
Read
messages Publish
Database PublisherMaintaining data consistency
• Un'operazione può coinvolgere diversi servizi
• Saga pattern
o Una sequenza di transazioni locali
o Coordinata in modo implicito o esplicito
Check
Create Booking consumer Consumer
booking Service Service
Confirm Authorize
booking Account payment
ServiceCompensating transactions
• Rollback gestito tramite azioni di compensazione
Check
Create Booking consumer Consumer
booking Service Service
Reject Authorize
booking Account Payment
Service (fail)https://12factor.net/ • Evitare ogni dipendenza dal sistema ospite (librerie, comandi di sistema) • Dichiarazione e isolamento delle dipendenze (build riproducibile e deterministico) • Configurazione granulare e portabile attraverso variabili d’ambiente • Nessun assunzione sui servizi dipendenti, su memoria e filesystem (servizi stateless e shared-nothing) • Applicazioni «self-contained» (embedded server) • Servizi realizzati attraverso processi di sistema, leggeri e robusti (fast startup, graceful shutdown, crash-only architecture) • Logging via stdout
Giacomo Alzetta giacomo.alzetta@cybaze.it (Trieste)
Mauro Rocchi mauro.rocchi@cybaze.it (Udine)
https://cybaze.it
Milano, Roma, Torino, Napoli, Trieste, Udine, Cesena, Benevento, BrusselCYBAZE S.p.A.
Via Giovanni Battista Martini, 6
00198 Roma
Tel. 06 85352121
www.cybaze.it info@cybaze.it
Milano, Roma, Torino, Napoli, Trieste, Udine, Cesena, Benevento, BrusselPuoi anche leggere
