Przejd┼║ do tre┼Ťci

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
3 lat 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
3 lat 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
3 lat 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 ┬╗

5
0
Would love your thoughts, please comment.x