29. září 2013

Architektura integračního řešení

V dnešním článku se opět vracím k mému poslednímu projektu, na kterém jsme realizovali nového virtuálního operátora, viz článek Zkušenosti s Apache Camel. Já konkrétně jsem měl na starosti integrační část celého řešení.

Integrační část je centrálním bodem celého řešení, a proto musí být vždy dostupná. Kromě jiného musí splňovat ještě tyto požadavky:

  • spolehlivost
  • škálovatelnost
  • výkonnost
Pro úplnost uvedu přehled externích systémů, se kterými integrační platforma komunikuje:
Při návrhu aplikací a vlastně i při jejich realizaci se snažím držet mého přesvědčení, že nemá cenu dělat nic zbytečně dopředu, dokud není jasné, že je to opravdu potřeba. Pamatuji si na dobu, kdy jsem se snažil vše řešit co nejobecněji a naivně jsem si myslel, že až se ukáže v budoucnu, že to bude potřeba, tak to na to už bude připravené. Bohužel k tomu nikdy nedocházelo - buď se změnily požadavky nebo k tomu ani nedošlo, aby se něco dodělávalo. Jsem přesvědčený o tom, že pokud jsou věci jednoduché (tedy jednoduchá a jasná architektura), pak je to i srozumitelné a lépe udržovatelné. 

S tímto přístupem jsme navrhovali i toto integrační řešení:
  • operační systém CentOS 6.4 64bit
  • Apache Tomcat 7 - krásný příklad, jak v jednoduchosti je síla. Nevidím žádný (technický) důvod, proč používat něco složitějšího.
  • PostgreSQL 9 - databázi používáme pro persistenci vstupních zpráv, se kterými dále pracujeme a zaručujeme se o jejich zpracování. Mě osobně by se zde více líbilo JMS (např. Apache ActiveMQ nebo RabbitMQ), ale výběr databáze byl již dán, takže jsem s tím musel pracovat jak to bylo dáno. Obával jsem se zde úzkého výkonnostního hrdla, zejména v momentě, kdy se více ESB instancí bude "prát" o nové zprávy ke zpracování, ale zatím se ukazuje, že moje obavy byly zbytečné.
  • Load balancing je prováděn komponentou apache http serveru mod_proxy_balancer pomocí round robbin algoritmu. Balancing zajišťuje rozkládání zátěže na jednotlivé nody a primárně je  použit z důvodu vysoké dostupnosti ESB nodu, jelikož v případě výpadku jednoho z ESB nodů automaticky na daný chybný node přestane směrovat requesty.
  • Samotný apache http server je zároveň provozován také na dvou nodech, mezi kterými je pak pohyblivá IP adresa, která je pak aktivní pouze na jednom ze serverů a přes tento server je pak primárně směřován provoz. Apache na druhém serveru je tak pouze ve stavu standby a přes něj by byl směrován provoz až v případě migrace této „pohyblivé“ IP adresy na tento server, ze kterého je pak prováděn balancing stejným způsobem na oba dva aktivní aplikační servery čímž je zajištěna vysoká dostupnost systému.
  • Na HTTP proxy je zakončena zabezpečená SSL komunikace, dále směrem k aplikačnímu serveru je již komunikace realizována pouze pomocí HTTP protokolu.
Co se týče výběru aplikačního stacku, tak základ je tvořený knihovnou Apache Camel, která zajišťuje samotné routování zpráv. Zbylé věci jsou řešeny Spring knihovnami:
  • Spring Framework tvoří základní stavební kámen pro konfiguraci aplikace
  • Spring Security pro zabezpečení webové admin části a pro zabezpečení komunikace s externími systémy
  • Spring Web Services jako hlavní Camel komponenta pro komunikaci pomocí webových služeb

1 komentář:

oknoplast řekl(a)...

Jsem opravdu takhle projektu zejména tyto okna. Podobné jsem viděl http://oknoplastokna.cz/cz/okna.html a myslím, že budu muset jít domů