Codemotion fuse presentation

Preview:

DESCRIPTION

Introductory presentation on Fuse technology

Citation preview

Camel, Active MQ, CXF, Zookeeper e Karaf: l'integrazione nell'era del

Cloud, the Apache way

!

Ugo Landini

Agenda

Scope

• Mostrare come sia possibile costruire un sistema di integrazione che sia:

• Resiliente

• Manutenibile

• Flessibile

• ad alte Performance

Glossario

Glossario• Fabric

• Container

• OSGI

• Rotta (Camel)

• Provisioning

• Versionamento

• Maven/Nexus

• GIT

• Coda

• REST/WS

• Zookeeper

• ESB

• Profiles

• Bundle

• OSGI

• EIP, Enterprise Integration Patterns

• Aggregator

• Splitter

• CBR

• Enrichment

• Multicast

• Wiretap

Cos’è un ESB?

Cos’è un ESB

• ESB = Enterprise Service Bus

• Termine coniato nei primi anni 2000

• E’ un modello architetturale che permette l’integrazione fra applicazioni (EAI)

• Si basa sull’astrazione di un BUS, in maniera similare all’analogo concetto per le architetture hardware

Cos’è un ESB

Cos’è un ESB

• Routing delle richieste

• Trasformazione dei dati

• Versionamento dei servizi

• Buffering delle richieste

• Bilanciamento e Scalabilità dei servizi

• Monitoring e controllo

Cos’è OSGI?

Cos’è OSGI?

• Uno standard per un Java “Modulare”

• permette di “impacchettare” il codice in un bundle (jar)

• gestisce le dipendenze dei bundle

• i bundle OSGI possono essere installati, lanciati, fermati, aggiornati (Lifecycle Management) ed offrire servizi

• OSGI = SOA in una JVM

• la prima versione risale al 2000 e nasce negli ambienti telco.

Maven / Nexus

• Maven è lo standard “de facto” del dependency management nel mondo Java

• Nexus è un repository Maven centralizzato che facilita l’approccio “Devops”

• permette di gestire le dipendenze in maniera controllata

• un server che contiene tutti gli “artifatti” del processo di sviluppo

• Coadiuva la gestione dipendenze a runtime di OSGi

Cos’è Karaf?

Cos’è Karaf

• Lightweight container per OSGI

• Servizi di hot deploy, logging, shell, configuration, provisioning

• JEE component : JBoss = bundle OSGI : Karaf

Cos’è Active MQ?

Cos’è ActiveMQ

• Il Messaging Broker Open Source più diffuso al mondo

• JMS, AMQP, MQTT, OpenWire, STOMP, REST

• Java, C, C++, C#, Ruby, Perl, Python, PHP

• Pluggable Transport

• in-VM, TCP, SSL, NIO, UDP, JGroups

Enterprise Integration Patterns

• Lavoro di Hohpe / Woolf

• Divenuto uno standard de facto

• parlare un linguaggio comune

• riutilizzo di know how e soluzioni

• Eliminazione codice custom dalle implementazioni

• performance, bugs, quantità di codice

Enterprise Integration Patterns

http://camel.apache.org/eip

Cos’è Camel?

Cos’è Camel

• Framework Open source che implementa i pattern EIP (>100 componenti)

• mapping 1:1 fra pattern e componenti

• le rotte camel sono gestite tramite OSGI

• per Container si intende il “contenitore” di componenti OSGI

• OSGI : Container = EJB : J2EE Server

Camel

Cos’è ZooKeeper

Cos’è ZooKeeper

• E’ un componente dell’ecosistema di Hadoop

• Serve a costruire logiche di coordinamento

• Sharding, Failover, Discovery, Master election, ecc.

• Usato da HBase, Kafka, Solr, Yahoo, Fuse Fabric8

Cos’è Fabric8?

Cos’è Fabric8

• Fabric8 sfrutta le caratteristiche di OSGI e Zookeeper per fornire ulteriori servizi:

• Provisioning (configurazioni, codice, container, fabric stesso!)

• Registry centralizzato (configurazioni, load balancing, discovery, fail-over)

• Versionamento (git)

Cos’è JBoss Fuse?

Cos’è JBoss Fuse

Cos’è JBoss Fuse

• Middleware composto da:

• JBoss AMQ (ActiveMQ) per la messaggistica

• Camel per le mediazioni (rotte)

• CXF per i Web Services

• Fabric8 per la governance (registry, provisioning) con Zookeeper, git, hawt.io

• decine di sottocomponenti “minori”

Architettura

Architettura di esempio

ROOT : Zookeeper

Provisioning remoto

Provisioning remoto

Dettaglio Nodi Camel

Processo di sviluppo

Processo di sviluppo

• Raccolta del requisito di integrazione

• Se il tag A contenuto nel messaggio M ha nel record corrispondente della tabella B il campo X

• Trasformazione del messaggio M (rimozione tag t1, aggiunta tag X)

• Successiva trasformazione del messaggio M aggiungendo un tag t3

Processo di sviluppo

“Traduzione” del requisito in Enterprise Integration Patterns

Processo di sviluppo

Processo di sviluppo

• Riportare gli EIP sotto forma di codice

• usando un DSL Java

• usando un DSL XML

• con un editor grafico (plugin per Eclipse)

Processo di sviluppo

Processo di sviluppo

Processo di sviluppo

• Impacchettare la rotta in un bundle OSGI

• mvn install

• Fare il push sul repository

• mvn deploy

Processo di sviluppo

• Tramite CLI console o Web Console, e secondo le strategie di Roll-out aziendale, prelevare il bundle dal repository

• I container selezionati faranno partire automaticamente la rotta se il deploy è andato a buon fine (in caso di autostart, il default)

Processo canonico

• Il processo “canonico” dunque è:

• creare una nuova rotta che implementi le nuove regole di business

• creare una nuova versione su Fabric, per esempio 1.1

• effettuare un check facendo un upgrade di un container alla 1.1

• roll-out su tutti i container o roll-back del subset

DEFCON 2

• Il processo “DEFCON 2”:

• aprire la console grafica sui server di produzione

• editare la rotta

Le console

Hawt.io

• Web console

• Progetto open source: Hawt.io

• Accesso completo e remoto:

• container, log, dashboard con strumenti di controllo

• rotte camel, nodi AMQ, API Management, cluster.

Hawt.io: vista rotte Camel

Hawt.io

• versioni, profili, bundle OSGI, ...

• permette il DEBUG grafico delle rotte camel, con breakpoint

• permette di editare rotte camel, anche su server di PRODUZIONE

• permette di effettuare dei TRACE delle rotte

• può mostrare i SORGENTI di codice Java che ha sollevato un’eccezione

Hawt.io: debug remoto e visuale

Command Line Console

• Fuse Command Line console

• Basata su SSH

• Controllo totale locale e remoto del sistema

• Scriptabile

Command Line Console

Performance

Performance ActiveMQ

• Persistenza AMQ basata su File system

• Utilizza LevelDB, un nosql di Google

• il Btree di indicizzazione di LevelDB garantisce tempi O(1) per il caricamento dei messaggi

• in altre parole, 3 o 30.000.000 di messaggi persistenti vengono “presi in carico” “istantaneamente” da un broker.

Performance ActiveMQ

• LevelDB permette anche eccellenti tempi di scrittura sul file system

• La velocità del disco è il singolo fattore più importante nel tuning.

• Circa 10k msg/secondo da 5kb sostenuti per ore su un laptop moderno con SSD

• Circa 4.5k msg/secondo sostenuti sul server di Amazon (9k msg/secondo con due dischi)

Performance Camel

Affidabilità

High Availability

• AMQ è configurabile in modalità Master - Slave

• 1 Slave per 1 Master

• N Slave per M Master (esempio: 2 Slave per 10 Master)

Nodi ActiveMQ

Scalabilità

Scalabilità ActiveMQ

• AMQ offre diverse topologie per scalare orizzontalmente:

• Network of Brokers

• Client side partitioning

Network of Brokers

• I messaggi vengono “inoltrati” fra i brokers

• Store and Forward

• Mono o bi-direzionale

• Questa topologia implica un certo grado di comunicazione fra i broker (chattiness)

• Uno o più hop per raggiungere il server su cui il messaggio è presente

Network of Brokers

Client side Partitioning

• E’ la topologia che permette di scalare orizzontalmente in maniera illimitata

• I diversi Broker NON sono a conoscenza l’uno dell’altro

• I client “partizionano” i messaggi secondo un criterio qualsiasi

• In questa topologia è possibile avere una singola coda deployata su centinaia di broker

Client side Partitioning

Client side Partitioning

• E’ la topologia consigliata per ambienti ad altissime performance, insieme al Master/Slave per l’HA

• La natura dei messaggi deve prevedere criteri di partizionamento

• E’ anche possibile avere diversi broker divisi per area geografica per architetture Follow The Sun

Success Stories

Customers

Customers

Customers

Customers

Customers

Roadmap

JBoss Fuse Roadmap

JBoss Fuse Roadmap

!

• JBoss FUSE 6.0

• Aprile 2013

• JBoss FUSE 6.1

• GA da Lunedì 14 Aprile :)

• build 379

• https://repository.jboss.org/nexus/content/repositories/ea/org/jboss/fuse/jboss-fuse-full/

Conclusioni

Resilienza

!

• Resilienza

• Architettura distribuita

• Failover

• Master/Slave per l’alta affidabilità

• Scalabilità orizzontale: Network of Brokers, Client side partitioning

Manutenibilità

!

• Manutenibilità

• OSGI based, ciclo di vita dei componenti standardizzato (con versionamento)

• Console di amministrazione molto potente

• Debug/Trace rotte, gestione log, editing rotte, ...

Alte performance

• Alte performance

• da 4.5k a 10k messaggi al secondo per coda (messaggi persistenti “reali” da diversi Kb)

• Possibile dedicare un broker ed un disco per ogni coda (o anche distribuire la stessa coda su più macchine ottenendo facilmente > 100k msg/secondo)

• Tempi O(1) per presa in carico da parte del broker

Link e risorse

Link e risorse

• Active MQ

• http://activemq.apache.org

• Camel

• https://camel.apache.org

• CXF

• http://cxf.apache.org

• ZooKeeper

• http://zookeeper.apache.org

• Karaf

• http://karaf.apache.org

• Fabric8

• http://fabric8.io

• JBoss FUSE 6.1 EA builds

• https://repository.jboss.org/nexus/content/repositories/ea/org/jboss/fuse/jboss-fuse-full/

• Red Hat Supported!

• https://www.jboss.org/products/fuse.html

Thank you!