Lefordítottalak :D
A skálázhatóság és a rendelkezésre állás növelése
a "vezérlés megfordítása" mintávalKonklúzió:
Ha meg akarjuk érteni egy komplex rendszer működését, legjobb ha felbontjuk kis részekre: ha az összes kis rész érthetővé válik, a kép világosabb lesz. Persze a Sparky-t nem lehet összehasonlítani a Spring-gel vagy a teljesen kifejlett Java EE stack-kel, nagy előnye viszont, hogy a kódmérete még kezelhető a tanulók számára.Kitűnő gyakorlat lehet hallgatóknak egy új üzenetküldő protokollt implementálni vagy a meglévő implementáció szűk keresztmetszeteit vizsgálni.
Azt hiszem, hogy a Sparky pehelykönnyű, ennek ellenére számtalan hatékony funkcióval bír. Nem a legjobb megvalósítás és rengeteg dolog van, amit fejleszteni lehetne:* konténer megszakítás támogatása
* egy példány konkurrens másolatainak felső határa a klaszterben
* round-robin ütemező helyett, adaptívabb kiválogatása a konténereknek, mondjuk statisztika alapján
* feladatok migrációjának támogatása csomópontok(node) közöttMintahogy a téma áttekintésben megemlítettem, számtalan más gráftípust ki lehetne próbálni az üzenetküldés alapjának. A prototípus Kautz-gráfra lett készítve, de még a JMS-alapú üzenetküldésnél is lassabb volt, köszönhetően az üzenettovábbítás magas költségének. Nagyon magas komplexitás/haszon mutatója miatt az ötlet el lett dobva.
Transparently enhancing scalability and availability
using inversion of control techniquesConclusion
When someone tries to understand how complex systems work, it’s best to start at the small
parts: if once all the small parts are understood, the picture will become clearer. Of course
Sparky cannot be compared to Spring or a full-blown Java EE stack, but there is a clear
advantage: it’s code size is manageable for students.
Creating a new messaging implementation, or trying to evaluate the current code’s
bottlenecks can be good exercises in the classroom.
I believe Sparky is very lightweight, yet it supports many powerful features. The
implementation of these features aren’t the best, and there are many things which could be
improved:
- container disconnection support
- upper bound of a single instance’s number of concurrent copies inside a cluster
- instead of round-robin, use a more adaptive way to select the container to use, like
statistics
- job migration support between nodes
As it’s mentioned in the topic overview right after the front page, there are several other
graph-types that can be tried to form a logical network to base the a messaging
implementation on. A test implementation was made for the Kautz-graph, but it was even
slower than JMS-based messaging, due to the high cost of message distribution. It had a
very high complexity/benefit ratio, so it was abandoned.