Architektura Mikroj膮dra 馃ゥ馃

Wi臋kszo艣膰 z nas tworzy oprogramowanie z my艣l膮, 偶e b臋dzie ono 艂atwo rozszerzalne. Ale co je偶eli musisz pozwoli膰 na rozszerzenia zewn臋trznemu zespo艂owi albo komu艣 ca艂kowicie obcemu spoza organizacji? Jak rozwi膮za膰 taki problem? Z pomoc膮 przychodzi gwiazda dzisiejszego wpisu – architektura mikroj膮dra!


Cze艣膰聽馃檪

Architektura typu mikroj膮dro to ju偶 trzeci wpis z mini-serii blog贸w o architekturach aplikacyjnych. W poprzednich wpisach mog艂e艣 przeczyta膰 o architekturze warstwowej i聽architekturze sterowanej zdarzeniami.

W dzisiejszym artykule:


Czym jest architektura mikroj膮dra?

Architektura mikroj膮dra lub inaczej architektura wtyczek stosowana jest najcz臋艣ciej kiedy oprogramowanie musi by膰 w stanie dostosowa膰 si臋 do zmieniaj膮cych si臋 wymaga艅 systemowych.

Mikroj膮dro sk艂ada si臋 z dw贸ch element贸w: j膮dra (rdze艅 systemu) oraz wtyczek (plugin贸w). Rdze艅 w najprostszych s艂owach jest jakim艣 podstawowym elementem (czasami podstawow膮 funkcjonalno艣ci膮) systemu. Zawiera on minimaln膮 ilo艣膰 kodu jaki jest potrzebny do uruchomienia systemu. Reszta le偶y na barkach wtyczek. Ka偶da wtyczka to ca艂kowicie oddzielna logika biznesowa. Z za艂o偶enia, wtyczki nie powinny wiedzie膰 o sobie nawzajem (nie zawsze si臋 tak dzieje) i by膰 ca艂kowicie niezale偶ne. Ka偶da z wtyczek dostarcza konkretn膮 funkcjonalno艣膰 biznesow膮 do systemu. Innymi s艂owy – rozszerza go.

J膮dro musi w jaki艣 spos贸b wiedzie膰 jakie wtyczki s膮 dost臋pne oraz jak si臋 do nich dosta膰. Do tego celu s艂u偶y rejestr. Zawiera on informacje o wtyczkach oraz ich kontrakt. Kontrakt to zasadniczo dane wej艣ciowe i wyj艣ciowe – pozwala on na wymian臋 danych pomi臋dzy rdzeniem i wtyczk膮. Nie zawsze b臋dzie tak, 偶e wtyczka domy艣lnie wspiera zdefiniowany kontrakt. Stosuje si臋 wtedy wzorzec projektowy adapter, kt贸ry odpowiednio zmapuje funkcjonalno艣膰.

Mikroj膮dro mo偶na traktowa膰 troch臋聽jak wzorzec metody szablonowej. M贸wi ono co ma si臋 zadzia膰 i w jakiej kolejno艣ci, natomiast jak to si臋 zadzieje jest ju偶 zale偶ne od u偶ytych wtyczek.


Przyk艂ady

Najlepszymi przyk艂adami (do wyt艂umaczenia) s膮: IDE, edytory tekstu i przegl膮darki.

IDE. Zapewnia nam podstawow膮 funkcjonalno艣膰 – widzimy struktur臋 projektu, mo偶emy pisa膰 kod i go uruchamia膰. IntelliJ wspiera r贸偶ne j臋zyki JVM’owe do kompilacji oraz uruchamiania. Jest to w艂a艣nie element wtyczki. J膮drem systemu jest kompilacja i uruchomienie, natomiast wtyczk膮 konkretny j臋zyk. Ich kontraktem wyj艣ciowym jest zapewne byte code. Rejestrem w tym przypadku b臋dzie j臋zyk jaki wybrali艣my przy tworzeniu projektu.

Przegl膮darki. J膮drem systemu w tym przypadku jest przegl膮danie witryn internetowych. A wtyczki? Istenieje du偶e prawdopodobie艅stwo, 偶e sam posiadasz zainstalowanych kilka(na艣cie) r贸偶nych wtyczek. Wszystko to rozszerza g艂贸wn膮 funkcjonalno艣膰 – przegl膮danie witryn internetowych – uzupe艂niaj膮c j膮 o dodatkow膮 logik臋.

Spring Boot. Nie jestem w 100% pewny czy jest to trafiony przyk艂ad ale powiem jak ja to widz臋 i rozumiem. Spring przy starcie aplikacji czyta wiele plik贸w konfiguracyjnych, rejestruje bean’y, wykonuje prace zarejestrowane w post processorach i innych. Je偶eli spojrzymy na to z punktu widzenia mikroj膮dra to mo偶na odebra膰 wra偶enie, 偶e j膮drem w tym przypadku jest start aplikacji. Wtyczki s膮 to bean’y, post processory i inne udogodnienia, kt贸re si臋 dziej膮 na starcie. Rejestrem mo偶e by膰 plik konfiguracyjny, XML lub adnotacja. Kontraktem jest natomiast interfejs.

Nie jestem w 100% pewny czy ostatni przyk艂ad jest dobry. Je偶eli znasz jakie艣 przyk艂ady z 偶ycia wzi臋te (czytaj framework) to podziel si臋 w komentarzu 馃檪


Wady i zalety architektury

Zalety:

  • Testowalno艣膰 – osobne, niezale偶ne wtyczki, kt贸re mo偶na przetestowa膰 w izolacji. Samo j膮dro r贸wnie偶 jest minimaln膮 cz臋艣ci膮 systemu, kt贸re nie powinno by膰 uci膮偶liwe w testowaniu (+ mo偶na wykorzysta膰 mockowanie).
  • Konfigurowalno艣膰 – mo偶na na r贸偶ne sposoby skonfigurowa膰 ten sam proces, np. kompilacja projektu przy u偶yciy Javy, Kotlina, Groovy’ego czy Scali.
  • Rozszerzalno艣膰 –聽艂atwo doda膰 now膮 wtyczk臋, kt贸ra rozszerzy funkcjonalno艣膰 systemu. Przyk艂ad: powstaje nowy j臋zyk JVM’owy – wi臋kszo艣膰 dobrych IDE (patrz IntelliJ) nie b臋dzie mia艂a problemu aby go wesprze膰.

Wady:

  • Skalowalno艣膰 – mikroj膮dro pracuje w obr臋bie jednego modu艂u. Dok艂adaj膮c kolejne wtyczki mo偶e to by膰 w膮skie gard艂o tej architektury w kontek艣cie wydajno艣ci.
  • Z艂o偶ono艣膰 – jest to skomplikowany styl architektoniczny. Mamy du偶o element贸w do ogarni臋cia – rejestr, kontrakty, konfiguracja wtyczek – to wszystko sprowadza si臋 do wysokiego progu wej艣cia.

Podsumowanie

Architektura mikroj膮dra z za艂o偶enia jest prosta. Nie jest ona natomiast 艂atwa. Przy wi臋kszych projektach (kt贸rych produkt ma 偶y膰 d艂ugo) – a zazwyczaj w艂a艣nie takie projekty powinny z niej korzysta膰聽 – jest ona ci臋偶ka do ogarni臋cia dla nowej osoby. Jej g艂贸wn膮 zalet膮 jest elastyczno艣膰 i to ten driver architektoniczny powinien przemawia膰 za wyborem tej architektury. Kluczowe jest aby przed jak膮kolwiek implementacj膮 mie膰 wizj臋 i plan – po prostu trzeba wykona膰 dok艂adn膮 analiz臋 projektu.

W przypadku aplikacji opartych na produktach (IDE, edytory tekstu, przegl膮darki, …) architektura mikroj膮dra wydaje si臋 by膰 艣wietnym kandydatem. Pozwala ona na udost臋pnianie dodatkowych funkcji u偶ytkownikowi w zale偶no艣ci od jego preferencji. Dodatkowo, dzi臋ki kontraktom nie musisz sam wytwarza膰 ka偶dej nowej wtyczki a zamiast tego u偶y膰 community zbudowanego wok贸艂 produktu :).

殴r贸d艂a:


Za tydzie艅

Kontynuujemy seri臋 o archiekturze! Kolejna b臋dzie architektura Hexagonalna.

5 2 votes
Article Rating
Subscribe
Powiadom o
guest
5 komentarzy
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
Valery Prince
8 dni temu

Architektura mikroj膮dra lub inaczej architektura wtyczek stosowana jest najcz臋艣ciej kiedy oprogramowanie musi by膰 w stanie dostosowa膰 si臋 do zmieniaj膮cych si臋 wymaga艅 systemowych.

Irek
Irek
20 dni temu

Nazwa „architektura mikroj膮dra” jest kompletnie myl膮ca, bo ten termin powszechnie odnosi si臋 do system贸w operacyjnych i znaczy zupe艂nie co innego – https://pl.wikipedia.org/wiki/Mikroj%C4%85dro 呕aden z popularnych system贸w operacyjnych nie u偶ywa mikroj膮dra, mimo 偶e ka偶dy z nich ma sterowniki (czyli pluginy). Z mikroj膮drem w systemach operacyjnych chodzi o pluginy, ale te偶 o co艣 wi臋cej: chodzi te偶 o to 偶e ka偶dy plugin jest odizolowany w oddzielnym procesie, zbudowanym tak, 偶e 偶e awaria jednego pluginu nie psuje reszty systemu. Np. w 艣wiecie Javy tak膮 architektur膮 z „mikroj膮drem” mog膮 to by膰 aplikacje Spring Bootowe pod艂膮czone do kolejek Kafki. Jedna aplikacja wrzuca co艣 do kolejki, inna czyta. Awaria… Czytaj wi臋cej 禄

Marcin Erbel
Marcin Erbel
20 dni temu

Hej, chyba przyczepi艂bym si臋 do za艂o偶enia testowalno艣ci plugin贸w. Zasadniczo pluginy nie potrafi膮 istnie膰 bez mikroj膮dra, wi臋c nie da rady ich sensownie przetestowa膰. Dodatkowo ka偶dy nowy plugin zmienia funkcjonowanie ca艂ej aplikacji, co wymusza odpowiednie pisanie test贸w dla ca艂ej aplikacji z „zamockowanymi” pluginami, co z kolei doprowadza do tego, 偶e bardzo trudne i karko艂omne b臋dzie pisanie test贸w do aplikacji z u偶ytymi pluginami. Zak艂adaj膮c sytuacj臋 kiedy istnieje wiele wersji r贸偶nych plugin贸w wpadamy w ci膮g nieko艅cz膮cego si臋 przepisywania test贸w tak, aby mie膰 pewno艣膰, 偶e nie zepsuli艣my ca艂ego flow aplikacji. Oczywi艣cie mo偶emy wyj艣膰 z za艂o偶enia, 偶e testujemy jednostkowo wszystkie komponenty, ale moim zdaniem najwi臋ksza warto艣膰… Czytaj wi臋cej 禄