Jaké typy architektur existují?

Existuje mnoho typů softwarových architektur s vlastními klady a zápory. Dále si povíme o funkcích nejoblíbenějších z nich a řekneme vám o našem přechodu na mikroslužby.

/libreshot/PD

Typy softwarových architektur

Vrstvená architektura

Toto je jedna z nejběžnějších architektur. Na jeho základě je postaveno mnoho velkých frameworků – Java EE, Drupal, Express. Snad nejznámějším příkladem této architektury je síťový model OSI.

Systém je rozdělen do úrovní, z nichž každá interaguje pouze se dvěma sousedními. Proto požadavky do databáze, která se obvykle nachází na samém konci interakčního řetězce, procházejí postupně každou „vrstvou“.

Z architektury nevyplývá žádný povinný počet úrovní – mohou být tři, čtyři, pět nebo více. Nejčastěji se používají třívrstvé systémy: s prezentační úrovní (klient), logickou úrovní a datovou úrovní.

O vrstvené architektuře bylo napsáno nespočet knih a článků. A názory na jeho výhody a nevýhody byly různé.

Každá vrstva této architektury vykonává přísně omezenou sadu funkcí (které se neopakují z vrstvy na vrstvu) a neví, jak jsou strukturovány ostatní vrstvy. Proto lze „obsah“ vrstev měnit bez rizika globálních konfliktů mezi vrstvami.

Obecně jsou vícevrstvé aplikace tak běžné, že se pro jejich vývoj vytvářejí speciální generátory šablon. Například LASG for Visual Studio nabízí několik metod generování kódu, které automatizují rutinní úlohy a pomáhají vytvářet aplikační vrstvy.

V programování se říká, že jakýkoli problém lze vyřešit přidáním další úrovně abstrakce. Tento přístup však může v konečném důsledku vést ke špatné organizaci kódu a zmatku pro vývojáře.

To vede k dalšímu problému – nízké rychlosti. Mnoho informací začne zbytečně přecházet z vrstvy na vrstvu bez použití obchodní logiky. Někdy se tomuto problému říká sinkhole anti-pattern – návrhový vzor, kdy počet zbytečných operací začíná převažovat nad užitečnými.

Hledání chyb ve víceúrovňových systémech může být také obtížné. Před vstupem do databáze informace prochází všemi úrovněmi (protože databáze je konečnou součástí). Pokud jsou z nějakého důvodu tyto informace poškozeny (nebo ztraceny po cestě), musí být každá úroveň analyzována samostatně, aby se našla chyba.

Když jsme v 1cloud začali pracovat na interních systémech našeho poskytovatele virtuální infrastruktury, použili jsme přesně tento typ architektury. Na začátku jsme nebyli postaveni před úkol vytvořit službu IaaS schopnou zpracovat provoz desítek či stovek tisíc uživatelů. Rozhodli jsme se rychle uvést produkt na trh a začít rozvíjet zákaznickou základnu a řešit problémy se škálováním, jakmile nastanou (a nyní převádíme všechny systémy na architekturu mikroslužeb, o které bude řeč později).

Event-Driven Architecture

V tomto případě vývojář předepisuje chování (reakce) programu, když nastanou nějaké události. Událost v systému je považována za významnou změnu jeho stavu.

Lze nakreslit analogii s nákupem auta v autorizovaném servisu. Když auto najde nového majitele, jeho stav se změní z na prodej na prodáno. Tato akce zahajuje proces předprodejní přípravy – instalace přídavných zařízení, kontrola technického stavu, mytí atd.

Přečtěte si více

Jak ošetřit keře angreštu?

Systém řízený událostmi obvykle obsahuje dvě složky: zdroje událostí (agenti) a spotřebitele událostí (sinks). Obvykle také existují dva typy událostí: inicializační událost a událost, na kterou spotřebitelé reagují.

Příkladem implementace takové architektury je knihovna Java Swing. Pokud třída potřebuje upozornění na událost, vývojář implementuje tzv. posluchač – ActionListener (“zachytí” odpovídající událost) a připojí ji k objektu, který tato událost dokáže vygenerovat.

Wiki poskytuje následující kód pro implementaci tohoto mechanismu:

public class FooPanel extends JPanel implements ActionListener < public FooPanel() < super(); JButton btn = new JButton("Click Me!"); btn.addActionListener(this); this.add(btn); >@Override public void actionPerformed(ActionEvent ae) < System.out.println("Button has been clicked!"); >>

Výhody architektury:

Protože se aplikace skládají z velkého počtu asynchronních modulů (které nemají žádné znalosti o svých implementacích), lze je snadno škálovat. Takové systémy jsou sestaveny jako konstruktor – není třeba specifikovat závislosti, stačí implementovat nový modul. Asynchronní model navíc umožňuje vysoký výkon aplikací.

Asynchronní povaha takových aplikací ztěžuje ladění. Jedna událost může spustit několik řetězců akcí najednou. Pokud existuje mnoho takových řetězců, pak může být obtížné pochopit, co přesně způsobilo selhání. Chcete-li problém vyřešit, musíte vypracovat složité podmínky pro zpracování chyb. To také vede k problému s logováním – logy se obtížně strukturují.

Tvorba asynchronních systémů. To je zřejmé, protože samotná architektura se skládá z velkého počtu asynchronních modulů.
Lze použít k vytvoření uživatelského rozhraní. Webová stránka funguje jako kontejner, ve kterém je každá její součást izolovaná a reaguje na určité akce uživatele.
Organizovat výměnu zpráv mezi různými informačními systémy.

Architektura mikrokernelu

Tento typ architektury se skládá ze dvou komponent: jádra systému a zásuvných modulů. Pluginy jsou zodpovědné za obchodní logiku a jádro řídí jejich načítání a vykládání.

O’Reillyho kniha cituje Eclipse IDE jako příklad architektury mikrojádra. Jedná se o jednoduchý editor, který otevírá soubory, umožňuje je upravovat a spouští procesy na pozadí. Ale s přidáním pluginů (například kompilátor Java) se jeho funkčnost rozšiřuje.

Architekturu mikrokernelu kdysi používal operační systém Symbian pro mobilní zařízení (vývoj zastaven v roce 2012). Jeho mikrojádro obsahovalo plánovač úloh, systémy správy paměti a ovladače a souborový systém a komponenty odpovědné za telefonní komunikaci fungovaly jako zásuvné moduly.

Výhody architektury:

Je snadné přenést aplikaci z jednoho prostředí do druhého, protože je třeba upravit pouze mikrokernel. Oddělení politik na vysoké úrovni od mechanismů na nízké úrovni usnadňuje údržbu a rozšiřitelnost systému.

Výkon aplikace se sníží, pokud připojíte příliš mnoho modulů. Může však být obtížné najít rovnováhu mezi počtem pluginů a počtem úloh mikrokernelu (obvykle obsahuje pouze často používaný kód).

Také je obtížné předem (ještě před vývojem aplikace) určit optimální míru fragmentace kódu mikrokernelu. A později změnit přístup je téměř nemožné.

Vytváření rozšiřitelných aplikací, které používá velké množství lidí. Například iPhone OS má kořeny „mikrokernelu“ – jeho vývojáři se inspirovali u Macha (toto je jeden z úplně prvních příkladů mikrojádra).
Vytvářejte aplikace s jasným oddělením základních metod a pravidel na vysoké úrovni.
Vývoj systémů s dynamicky se měnícím souborem pravidel, která musí být často aktualizována.

Přečtěte si více

Jak utřít stůl bez šmouh?

Mikroslužby

Podobné jako událostmi řízená architektura a mikrokernel. Používají se ale tehdy, když lze jednotlivé aplikační úlohy jednoduše rozdělit do malých funkcí – nezávislých služeb. Tyto služby mohou být napsány v různých programovacích jazycích, protože spolu komunikují pomocí REST API (například pomocí JSON nebo Thrift).

Je na vývojáři, aby rozhodl, kolik kódu bude sdílet, ale Sam Newman, autor knihy Building Microservices, doporučuje věnovat mikroslužbě tolik řádků kódu, kolik je tým schopen reprodukovat za dva týdny. Podle něj se tak předejde zbytečnému „nafouknutí“ architektury.

Nejčastěji jsou mikroslužby spouštěny v tzv. kontejnerech. Tyto kontejnery jsou dostupné přes síť dalším mikroslužbám a aplikacím a všechny jsou spravovány orchestračním systémem: příklady zahrnují Kubernetes, Docker Swarm atd.

Architektura mikroslužeb usnadňuje škálování aplikací. Pro implementaci nové funkce stačí napsat novou službu. Pokud již funkce není potřeba, lze mikroslužbu deaktivovat. Každá mikroslužba je samostatný projekt, takže práci na nich lze snadno rozdělit mezi vývojové týmy.

Více o mechanismech pro škálování mikroservisních systémů si můžete přečíst v knize „The Art of Scalability“ od Martina L. Abbotta.

Je těžké najít chyby. Na rozdíl od monolitických systémů (kde jsou všechny funkce v jednom jádru) může být obtížné určit, proč požadavek selhal. Pro podrobnosti musíte jít do protokolů procesu „viníka“ (pokud jich je několik, problém se zhorší).

To představuje další režii pro přenos zpráv mezi mikroslužbami. Podle našich odhadů by nárůst síťových nákladů mohl dosáhnout 25 %.

Další nevýhodou je nutnost smířit se s konceptem případné konzistence. Mikroslužby mají svá vlastní úložiště dat, ke kterým mají přístup jiné mikroslužby. Informace o změnách v těchto datech se nešíří systémem okamžitě. Proto nastávají situace, kdy některé mikroslužby (i na extrémně krátkou dobu) mají zastaralá data.

Ve velkých projektech s vysokou zátěží. Mikroslužby využívají například streamovací platformy. Systémy doručování obsahu a další pomocné služby lze škálovat nezávisle na sobě a přizpůsobovat se změnám zatížení.
V systémech využívajících „různorodé“ zdroje. Pokud jedna část aplikace potřebuje více procesorového času a druhá část potřebuje více paměti, pak má smysl je rozdělit na mikroslužby. Poté mohou být hostovány na různých strojích – s výkonným CPU nebo velkým množstvím paměti.
Když potřebujete bezpečnost. Protože jsou mikroslužby izolované a komunikují přes API, můžete zaručit, že budou přenášeny pouze informace, které konkrétní služba potřebuje. To je důležité při práci s hesly nebo údaji o platebních kartách.

Proč u 1cloud přecházíme na mikroslužby?

Jak jsme již řekli, služby, které poskytujeme (privátní cloud, virtuální servery, objektové cloudové úložiště atd.), jsou založeny na vícevrstvé architektuře. Ukázal svou hodnotu, ale nyní jeho škálovací schopnosti začaly vysychat.

Máme stále více partnerů, kteří poskytují svá řešení založená na naší franšízové platformě. Objevují se vzdálené lokality a služby, které je stále obtížnější spravovat z jednoho místa (zejména naše zařízení se nachází v několika datových centrech v Rusku, Kazachstánu a Bělorusku).

Přečtěte si více

K čemu se fluoroplast používá?

Abychom usnadnili škálování stávajících funkcí a zavádění nových funkcí, převádíme v 1cloud celou naši infrastrukturu na mikroslužby.

Chceme je rozdělit do samostatných modulů a místo jedné komplexní databáze pořídit N jednoduchých. V nové architektuře tak bude mít každý prvek samostatnou databázi. To je mnohem pohodlnější a efektivnější při podpoře a vývoji.

Budeme moci rozdělit práci na službách mezi více vývojářů (zvýraznit specializace ve firmě) a efektivně horizontálně škálovat – v případě potřeby jednoduše propojíme nové mikroslužby.

Naši klienti získají také řadu výhod. Vzhledem k tomu, že mikroslužby nejsou vzájemně propojeny, pokud určitá služba selže, budou nedostupné pouze všechny ostatní; Navíc, i když dojde k celosvětovému poklesu našich služeb, ovládací panel bude nadále fungovat.

Zákazníci z Kazachstánu a Běloruska (a dalších zemí, kde otevřeme kanceláře) zaznamenají výrazné zvýšení rychlosti a odezvy rozhraní, protože ovládací panely budou hostovány lokálně.

Co se již udělalo

Zatím jsme implementovali pouze první pilotní projekt: „Monitorovací služba“. Zbývající služby převedeme na nové koleje koncem roku 2018 – začátkem roku 2019.

Nová architektura zároveň pokládá technologický základ pro další fázi – migraci na kontejnery. Nyní používáme infrastrukturu Windows a abychom se mohli přesunout do kontejnerů, musíme přepsat veškerý nashromážděný kód do .NetCore a přenést jej pod kontrolu Linuxu.

Nový přechod plánujeme zahájit na začátku roku 2019 a dokončit jej na konci příštího roku.

Jednoduše řečeno, co stojí za to pamatovat na architektuře

Vrstvená architektura — aplikace je rozdělena do úrovní, z nichž každá plní přesně definovanou sadu funkcí. Každou úroveň lze individuálně upravit. Nevýhodou je nízká rychlost kódu a obtížnost hledání chyb.