Codemotion fuse presentation

1,038 views

Published on

Introductory presentation on Fuse technology

Published in: Engineering

Codemotion fuse presentation

  1. 1. Camel, Active MQ, CXF, Zookeeper e Karaf: l'integrazione nell'era del Cloud, the Apache way ! Ugo Landini
  2. 2. Agenda
  3. 3. Scope • Mostrare come sia possibile costruire un sistema di integrazione che sia: • Resiliente • Manutenibile • Flessibile • ad alte Performance
  4. 4. Glossario
  5. 5. 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
  6. 6. Cos’è un ESB?
  7. 7. 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
  8. 8. Cos’è un ESB
  9. 9. Cos’è un ESB • Routing delle richieste • Trasformazione dei dati • Versionamento dei servizi • Buffering delle richieste • Bilanciamento e Scalabilità dei servizi • Monitoring e controllo
  10. 10. Cos’è OSGI?
  11. 11. 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.
  12. 12. 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
  13. 13. Cos’è Karaf?
  14. 14. Cos’è Karaf • Lightweight container per OSGI • Servizi di hot deploy, logging, shell, configuration, provisioning • JEE component : JBoss = bundle OSGI : Karaf
  15. 15. Cos’è Active MQ?
  16. 16. 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
  17. 17. 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
  18. 18. Enterprise Integration Patterns http://camel.apache.org/eip
  19. 19. Cos’è Camel?
  20. 20. 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
  21. 21. Camel
  22. 22. Cos’è ZooKeeper
  23. 23. 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
  24. 24. Cos’è Fabric8?
  25. 25. 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)
  26. 26. Cos’è JBoss Fuse?
  27. 27. Cos’è JBoss Fuse
  28. 28. 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”
  29. 29. Architettura
  30. 30. Architettura di esempio
  31. 31. ROOT : Zookeeper
  32. 32. Provisioning remoto
  33. 33. Provisioning remoto
  34. 34. Dettaglio Nodi Camel
  35. 35. Processo di sviluppo
  36. 36. 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
  37. 37. Processo di sviluppo “Traduzione” del requisito in Enterprise Integration Patterns
  38. 38. Processo di sviluppo
  39. 39. 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)
  40. 40. Processo di sviluppo
  41. 41. Processo di sviluppo
  42. 42. Processo di sviluppo • Impacchettare la rotta in un bundle OSGI • mvn install • Fare il push sul repository • mvn deploy
  43. 43. 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)
  44. 44. 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
  45. 45. DEFCON 2 • Il processo “DEFCON 2”: • aprire la console grafica sui server di produzione • editare la rotta
  46. 46. Le console
  47. 47. 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.
  48. 48. Hawt.io: vista rotte Camel
  49. 49. 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
  50. 50. Hawt.io: debug remoto e visuale
  51. 51. Command Line Console • Fuse Command Line console • Basata su SSH • Controllo totale locale e remoto del sistema • Scriptabile
  52. 52. Command Line Console
  53. 53. Performance
  54. 54. 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.
  55. 55. 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)
  56. 56. Performance Camel
  57. 57. Affidabilità
  58. 58. High Availability • AMQ è configurabile in modalità Master - Slave • 1 Slave per 1 Master • N Slave per M Master (esempio: 2 Slave per 10 Master)
  59. 59. Nodi ActiveMQ
  60. 60. Scalabilità
  61. 61. Scalabilità ActiveMQ • AMQ offre diverse topologie per scalare orizzontalmente: • Network of Brokers • Client side partitioning
  62. 62. 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
  63. 63. Network of Brokers
  64. 64. 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
  65. 65. Client side Partitioning
  66. 66. 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
  67. 67. Success Stories
  68. 68. Customers
  69. 69. Customers
  70. 70. Customers
  71. 71. Customers
  72. 72. Customers
  73. 73. Roadmap
  74. 74. JBoss Fuse Roadmap
  75. 75. 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/
  76. 76. Conclusioni
  77. 77. Resilienza ! • Resilienza • Architettura distribuita • Failover • Master/Slave per l’alta affidabilità • Scalabilità orizzontale: Network of Brokers, Client side partitioning
  78. 78. Manutenibilità ! • Manutenibilità • OSGI based, ciclo di vita dei componenti standardizzato (con versionamento) • Console di amministrazione molto potente • Debug/Trace rotte, gestione log, editing rotte, ...
  79. 79. 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
  80. 80. Link e risorse
  81. 81. 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
  82. 82. Thank you!

×