Sommerville, Iane. Softwarové inženýrství - soubor n1.doc. Distribuované koncepty architektury, které jsem se naučil při budování velkého platebního systému

AggreGate je jedna z mála platforem IoT na světě, která skutečně podporuje distribuovanou architekturu. To poskytuje neomezenou škálovatelnost pro vyvážení a oddělení všech operací AggreGate serveru na různých úrovních. Taková architektura může být základem jak pro řešení současných problémů, tak pro uspokojení potřeb budoucnosti.

Na rozdíl od clusteru s podporou převzetí služeb při selhání jsou servery AggreGate v distribuované architektuře zcela nezávislé. Každý server má svou vlastní databázi, účty místní uživatelé a jejich související oprávnění.

Distribuovaná architektura AggreGate je extrémně flexibilní. Technicky je založen na vytváření vztahů peer-to-peer mezi servery a připojení částí jednoho datového modelu některých serverů („dodavatelů“) k jiným („spotřebitelům“).

Cíle distribuovaných operací

Hlavní cíle distribuované architektury jsou:

• Škálovatelnost. Servery nižší úrovně mohou být silně zatíženy sběrem dat a správou velkého počtu zařízení téměř v reálném čase. V praxi je však počet zařízení, která může obsluhovat jeden server, omezen na několik tisíc. Při škálování systému pro správu velký počet zařízení, je rozumné instalovat několik serverů a kombinovat je jako součást distribuované instalace.
• Vyvažování zátěže. Každý server v distribuované instalaci řeší svůj vlastní problém. Servery pro správu sítě kontrolují dostupnost a výkon síťové infrastruktury, servery pro řízení přístupu zpracovávají požadavky z ovladačů dveří a turniketů. Řídicí operace, jako je generování zpráv a zasílání pošty, lze provádět na centrálním serveru.
• Ochrana proti vniknutí. Sekundární sondové servery mohou být instalovány na vzdálených místech a připojeny k centrálnímu serveru. Systémoví operátoři se připojují pouze k centrálnímu serveru a není třeba konfigurovat VPN a přesměrování portů na tyto servery.
• Centralizace. Sekundární servery mohou pracovat v plně automatickém režimu, přičemž jejich konfigurace a sledování probíhá prostřednictvím hlavního serveru instalovaného v centrálním dispečinku.

Rozdělení rolí serveru

V tomto jednoduchém scénáři jsou dva servery spojeny do distribuované infrastruktury. Operátoři systému jsou neustále připojeni k monitorovacímu serveru a plní své každodenní povinnosti. Vedení společnosti se připojuje k reportovacímu a analytickému serveru, když potřebuje získat část dat. Bez ohledu na množství dat a zatížení serveru, tuto operaci nebude mít vliv na práci operátorů.

Rozsáhlá cloudová platforma IoT

Poskytovatelé telekomunikačních a cloudových služeb nabízejí služby IoT v modelech IaaS/PaaS/SaaS. V těchto případech se bavíme o milionech zařízení, která vlastní tisíce uživatelů. Údržba tak obrovské infrastruktury vyžaduje stovky serverů AggreGate, z nichž většinu lze seskupit do dvou skupin:

• Servery, které ukládají registr uživatelů a jejich zařízení, přesměrovávají připojení operátorů a zařízení na servery nižší úrovně, jakož i agregovaná data pro následnou analýzu informací za účasti serverů nižší úrovně
• Servery, které monitorují a spravují zařízení a také přijímají, ukládají a zpracovávají data

Servery pro správu uživatelů a zařízení jsou také zodpovědné za interakci se systémem správy cloudu, který nasazuje a monitoruje nové úložné a analytické servery.

Servery pro ukládání a zpracování dat využívají zdroje (alarmy, modely, pracovní postupy, řídicí panely atd.) přijaté ze serverů šablon, které zase ukládají hlavní kopie těchto zdrojů.

Vrstvená IoT infrastruktura

Díky distribuované infrastruktuře AggreGate může každé řešení zahrnovat mnoho serverů různých úrovní. Některé z nich mohou pracovat na IoT branách, sbírat data, jiné mohou ukládat a zpracovávat informace a zbytek může provádět agregaci na vysoké úrovni a distribuované výpočty.

Polní zařízení, jako jsou senzory a akční členy, lze k serverům připojit přímo, prostřednictvím agentů, přes brány nebo kombinací obou.

chytrá správa města

Toto je příklad vrstvené architektury založené na AggreGate pro end-to-end automatizaci velké skupiny budov:

• Úroveň 1: fyzický hardware ( síťové routery, ovladače, průmyslová zařízení atd.)
• Úroveň 2: servery pro správu (servery pro monitorování sítě, servery pro řízení přístupu, servery pro automatizaci budov a další)
• Úroveň 3: budování center správy serverů (jeden server na budovu, který shromažďuje informace ze všech serverů druhé úrovně)
• Úroveň 4: servery městské oblasti (konečný cíl pro eskalaci výstrah nižší úrovně, monitorování v reálném čase, integrace se systémy Service Desk)
• Úroveň 5: servery ústředí (ovládání okresních serverů, sběr a sestavování reportů, upozornění)

Kterýkoli z výše uvedených serverů může být cluster s podporou převzetí služeb při selhání s více uzly.

Správa vícesegmentové sítě

AggreGate Network Manager je postaven na platformě AggreGate a je typickým případem použití pro distribuovanou architekturu. Velké segmentované sítě korporací a telekomunikačních operátorů nelze ovládat jediné centrum kvůli omezením směrování, bezpečnostní politice nebo omezením šířku pásma komunikační kanály se vzdálenými segmenty sítě.

Distribuovaný monitorovací systém se tedy obvykle skládá z následujících komponent:

• Hlavní nebo centrální server, který shromažďuje informace ze všech segmentů sítě
• Sekundární servery popř sondovací serveryže dotazovací zařízení v izolovaných segmentech
• Specializované servery, jako jsou servery pro analýzu provozu zpracovávající miliardy NetFlow událostí denně

Sekundární a specializované servery jsou poskytovateli informací pro hlavní server a poskytují část svého datového modelu řídicímu centru. To může být:

• Veškerý obsah kontextového stromu sondy serveru, který umožňuje plnou kontrolu nad konfigurací z centrálního serveru. V tomto případě je sondový server jednoduše použit jako proxy k překonání problému segmentace sítě.
• Výstrahy generované serverem sondy. V tomto případě může být 99 % pracovišť vzdálených a operátor centrálního serveru bude okamžitě dostávat upozornění ze sekundárních serverů.
• Vlastní datové sady ze zkušebních serverů, jako jsou živé informace o stavu kritických zařízení nebo agregované zprávy. Veškerá související práce bude provedena na sekundárním serveru, což umožní distribuci zátěže.

Vysoce výkonný management událostí

Některé případy použití platformy AggreGate, jako je centralizovaná správa incidentů, vyžadují přijetí, zpracování a trvalé uložení velkého počtu událostí ve strukturovaném formátu. Někdy mohou streamy dosahovat objemů milionů událostí za sekundu, navíc přijatých z různých zdrojů.

V takových případech jeden AggreGate server nebude schopen zvládnout celý tok událostí. Distribuovaná architektura pomůže organizovat zpracování událostí:

• Na objektech, které generují události, je nainstalováno několik místních serverů, které tyto události zpracovávají. K jednomu zpracovatelskému serveru se může připojit několik zdrojů (sond).
• Dedikovaný úložný server nebo multiserverový cluster úložiště velkých dat je svázán s každým místním serverem pro zpracování. Počet uzlů clusteru se může lišit v závislosti na rychlosti generování událostí.
• Všechny servery lokálního úložiště provádějí předběžné filtrování, deduplikaci, korelaci (s použitím pravidel platných pro lokálně připojené sondy), obohacení a ukládání událostí.
• Servery místního úložiště se připojují k centrálnímu agregačnímu serveru. Agregační server je zodpovědný za korelaci důležitých událostí v celém systému.
• Operátoři centrálního serveru mohou prohlížet celou databázi událostí, přičemž úkol vyhledání aktuálních dat je rozdělen mezi úložné servery. Je tak možné vytvářet centralizované hlášení a výstrahy založené na databázi všech událostí.

Digitální podnik

AggreGate může fungovat jako koordinační platforma pro digitální podnik. Každý z AggreGate serverů může fungovat různé funkce, od monitorování a správy vzdálených objektů až po služby na vysoké úrovni, jako je business intelligence nebo například správa incidentů.

Všechny servery digitálního podniku jsou vzájemně propojeny prostřednictvím distribuované infrastruktury. Servery nižší úrovně poskytují přístup k části kontextů jednoho datového modelu k serverům vyšší úrovně, což vám umožňuje vytvořit situační centrum pro celý podnik.

Zásady tvorby celopodnikového systému zpracování informací

Historie vývoje výpočetní techniky (a tedy i softwaru) začala samostatnými, autonomními systémy. Vědci a inženýři byli zaměstnáni tvorbou prvních počítačů a v podstatě si lámali hlavu nad tím, jak přimět tyto davy fungovat. elektronické elektronky. Tento stav však netrval dlouho – myšlenka na spojení výpočetního výkonu byla zcela zřejmá a vznášela se ve vzduchu, prosycená hučením kovových skříní prvních ENIAKů a Marků. Koneckonců, myšlenka spojit úsilí dvou nebo více počítačů k řešení složitých, zdrcujících úkolů pro každý z nich samostatně leží na povrchu.

Rýže. 1. Schéma distribuovaného počítání

Praktickou realizaci myšlenky propojování počítačů do clusterů a sítí však brzdil nedostatek technických řešení a především potřeba vytvářet standardy a protokoly pro interakci. Jak víte, první počítače se objevily na konci čtyřicátých let dvacátého století a první počítačová síť ARPANet, která propojovala několik počítačů ve Spojených státech, se objevila až v roce 1966, téměř o dvacet let později. Taková kombinace výpočetních schopností samozřejmě připomínala moderní distribuovanou architekturu velmi vágně, ale přesto to byl první krok správným směrem.

Vzhled lokální sítěčasem vedlo k rozvoji nová oblast vývoj softwaru - tvorba distribuovaných aplikací. Musel jsem to udělat, jak se říká, od nuly, ale naštěstí velké společnosti okamžitě projevily zájem o takové aplikace, jejichž obchodní struktura taková řešení vyžadovala. Právě ve fázi vytváření podnikových distribuovaných aplikací se formovaly základní požadavky a byly vyvinuty hlavní architektury takových systémů, které se používají dodnes.

Postupně se sálové počítače a terminály vyvíjely směrem k architektuře klient-server, která byla v podstatě první verzí distribuované architektury, tedy dvouvrstvé distribuovaný systém. Ostatně právě v aplikacích klient-server byla část výpočetních operací a obchodní logiky přenesena na stranu klienta, což se ve skutečnosti stalo vrcholem, charakteristickým znakem tohoto přístupu.

Během tohoto období se ukázalo, že hlavní výhody distribuovaných aplikací jsou:

dobrá škálovatelnost – v případě potřeby lze snadno zvýšit výpočetní výkon distribuované aplikace bez změny její struktury;

· schopnost řídit zátěž - střední úrovně distribuované aplikace umožňují řídit tok uživatelských požadavků a přesměrovávat je ke zpracování na méně zatížené servery;

· globálnost – distribuovaná struktura umožňuje sledovat prostorové rozložení obchodních procesů a vytvářet zakázky pro klienty na nejvhodnějších místech.

Čas plynul a malé ostrovy univerzit, vlády a firemní sítě rozšířeny, sloučeny do regionálních a národních systémů. A nyní se na scéně objevil hlavní hráč – internet.

Chvalozpěvy na World Wide Web se již dlouho staly běžným místem pro publikace o počítačových tématech. Internet skutečně sehrál rozhodující roli ve vývoji distribuovaného počítání a učinil z této poněkud specifické oblasti vývoje softwaru předmět armády profesionálních programátorů. Dnes výrazně rozšiřuje možnosti využití distribuovaných aplikací umožňujících připojení vzdálení uživatelé a zpřístupnění funkcí aplikace všude.

To je historie problému. Nyní se podívejme, co jsou distribuované aplikace.

Distribuované výpočetní paradigma

Představte si poměrně velkou výrobní, obchodní nebo servisní společnost. Všechny jejich divize už mají vlastní základny data a konkrétní software. Centrální kancelář nějakým způsobem shromažďuje informace o aktuální činnosti těchto útvarů a poskytuje vedoucím pracovníkům informace, na základě kterých činí manažerská rozhodnutí.

Pojďme dále a předpokládejme, že organizace, o které uvažujeme, se úspěšně rozvíjí, otevírá pobočky, vyvíjí nové typy produktů nebo služeb. Progresivní lídři se navíc na posledním setkání rozhodli zorganizovat síť vzdálených pracovišť, ze kterých by zákazníci mohli dostávat nějaké informace o realizaci svých zakázek.

V popsané situaci lze pouze litovat vedoucího IT oddělení, pokud se předem nepostaral o vybudování společného systému řízení podnikových toků, protože bez něj bude velmi obtížné zajistit efektivní rozvoj organizace. Navíc se zde neobejdete bez celopodnikového systému zpracování informací navrženého tak, aby zohlednil rostoucí zátěž a také odpovídal hlavním obchodním tokům, protože všechna oddělení musí plnit nejen své úkoly, ale v případě potřeby také zpracovávat požadavky. z jiných oddělení a dokonce (noční můra pro projektového manažera!) zákazníků.

Jsme tedy připraveni formulovat základní požadavky pro moderní aplikace rozsah podniku, diktovaný samotnou organizací výrobního procesu.

Prostorové oddělení. Divize organizace jsou prostorově oddělené a často mají špatně sjednocený software.

Konstrukční soulad. Software musí adekvátně odrážet informační strukturu podniku – odpovídat hlavním datovým tokům.

Orientace na vnější informace. Moderní podniky jsou nuceny věnovat zvýšenou pozornost práci se zákazníky. Podnikový software proto musí umět pracovat s novým typem uživatelů a jejich požadavky. Takoví uživatelé mají samozřejmě omezená práva a mají přístup k přesně definovanému typu dat.

Distribuované systémy splňují všechny uvedené požadavky na software podnikového měřítka - schéma výpočetní distribuce je znázorněno na Obr. 1.

Distribuované aplikace samozřejmě nejsou bez chyb. Za prvé jsou drahé na provoz a za druhé je tvorba takových aplikací pracný a složitý proces a náklady na chybu ve fázi návrhu jsou velmi vysoké. Vývoj distribuovaných aplikací se však úspěšně rozvíjí - koneckonců, hra stojí za svíčku, protože takový software pomáhá zvyšovat efektivitu organizace.

Paradigma distribuovaného počítání tedy předpokládá přítomnost několika center (serverů) pro ukládání a zpracování informací, které implementují různé funkce a jsou odděleny v prostoru. Tato centra musí kromě požadavků klientů systému plnit i požadavky navzájem, protože v některých případech může být k vyřešení prvního úkolu zapotřebí společné úsilí několika serverů. Pro řízení složitých požadavků a fungování systému jako celku je zapotřebí specializovaný řídicí software. A nakonec musí být celý systém „ponořen“ do určitého transportního média, které zajišťuje interakci jeho částí.

Distribuované výpočetní systémy mají takové obecné vlastnosti, jako jsou:

ovladatelnost – znamená schopnost systému efektivně řídit jeho součásti. Toho je dosaženo použitím řídicího softwaru;

· produktivita - je poskytována díky možnosti přerozdělení zátěže na servery systému pomocí řídicího softwaru;

· škálovatelnost – pokud je nutné zvýšit fyzický výkon, distribuovaný systém může snadno integrovat nové výpočetní zdroje do svého transportního prostředí;

· rozšiřitelnost - distribuované aplikace lze přidat k novým komponentám (serverovému softwaru) s novými funkcemi.

Přístup k datům v distribuovaných aplikacích je možný z klientského softwaru a další distribuované systémy mohou být organizovány na různých úrovních – od klientského softwaru a transportních protokolů až po ochranu databázových serverů.

Rýže. 2. Hlavní úrovně architektury distribuovaných aplikací

Uvedené vlastnosti distribuovaných systémů jsou dostatečným důvodem, proč se smířit s náročností jejich vývoje a vysokými náklady na údržbu.

Distribuovaná aplikační architektura

Zvažte architekturu distribuované aplikace, která jí umožňuje provádět složité a různorodé funkce. Různé zdroje poskytují různé možnosti pro vytváření distribuovaných aplikací. A všechny mají právo na existenci, protože takové aplikace řeší nejširší spektrum problémů v mnoha tematických oblastech a nezadržitelný vývoj vývojových nástrojů a technologií tlačí k neustálému zlepšování.

Existuje však většina obecná architektura distribuovaná aplikace, podle které se dělí do více logických vrstev, úrovní zpracování dat. Aplikace, jak víte, jsou navrženy tak, aby zpracovávaly informace, a zde můžeme zdůraznit tři z jejich hlavních funkcí:

reprezentace dat (uživatelská úroveň). Zde si uživatelé aplikace mohou prohlédnout potřebná data, odeslat žádost o provedení, zadat nová data do systému nebo je upravit;

Zpracování dat (střední úroveň, middleware). Na této úrovni se koncentruje obchodní logika aplikace, řídí se datové toky a organizuje se interakce částí aplikace. Právě koncentrace všech funkcí zpracování a řízení dat na jedné úrovni je považována za hlavní výhodu distribuovaných aplikací;

datové úložiště (datová vrstva). Toto je úroveň databázových serverů. Jsou zde umístěny samotné servery, databáze, nástroje pro přístup k datům a různé pomocné nástroje.

Často se taková architektura nazývá třívrstvá nebo třívrstvá architektura. A velmi často na základě těchto „tří velryb“ vzniká struktura vyvíjené aplikace. Vždy je třeba poznamenat, že každou úroveň lze dále rozdělit na několik podúrovní. Uživatelskou úroveň lze například rozdělit na skutečné uživatelské rozhraní a pravidla pro ověřování a zpracování vstupu.

Samozřejmě, pokud vezmeme v úvahu možnost rozdělení do podúrovní, pak lze do tříúrovňové architektury zadat jakoukoli distribuovanou aplikaci. Zde však nelze pominout ještě jednu věc. výrazná vlastnost Nedílnou součástí distribuovaných aplikací je správa dat. Důležitost této funkce je zřejmá, protože je velmi obtížné vytvořit skutečně fungující distribuovanou aplikaci (se všemi klientskými stanicemi, middleware, databázovými servery atd.), která by nezvládala své požadavky a odpovědi. Distribuovaná aplikace tedy musí mít ještě jednu logickou vrstvu – vrstvu správy dat.

Rýže. 3. Distribuce obchodní logiky napříč úrovněmi distribuované aplikace

Proto je vhodné rozdělit meziúroveň na dvě nezávislé úrovně: úroveň zpracování dat (jelikož je nutné vzít v úvahu důležitou výhodu, kterou přináší – koncentraci obchodních pravidel zpracování dat) a úroveň správy dat. Ten zajišťuje kontrolu nad prováděním požadavků, udržuje práci s datovými toky a organizuje interakci částí systému.

Lze tedy rozlišit čtyři hlavní úrovně distribuované architektury (viz obr. 2):

Prezentace dat (uživatelská úroveň);

pravidla obchodní logiky (vrstva zpracování dat);

správa dat (úroveň správy dat);

datové úložiště (vrstva ukládání dat).

Tři ze čtyř úrovní, s výjimkou první, se přímo podílejí na zpracování dat a úroveň prezentace dat umožňuje jejich vizualizaci a úpravu. Pomocí této vrstvy uživatelé přijímají data z vrstvy zpracování dat, která zase získává informace z úložišť a provádí veškeré potřebné transformace dat. Po zadání nových informací nebo úpravě stávajících informací proudí data opačným směrem: z uživatelského rozhraní přes vrstvu obchodních pravidel v obchodě.

Další vrstva - správa dat - stojí stranou hlavního toku dat, ale zajišťuje hladké fungování celého systému správou požadavků a odpovědí a interakcí částí aplikace.

Samostatně je nutné zvážit možnost prohlížení dat v režimu pouze pro čtení. V tomto případě se vrstva zpracování dat nepoužívá v celkovém schématu přenosu dat, protože není třeba provádět žádné změny. A samotný tok informací je jednosměrný – od úložiště až po úroveň prezentace dat.

Fyzická struktura distribuovaných aplikací

Nyní se pojďme věnovat fyzickým vrstvám distribuovaných aplikací. Topologie distribuovaného systému předpokládá rozdělení na několik databázových serverů, serverů pro zpracování dat a kombinaci lokálních a vzdálených klientů. Všechny mohou být umístěny kdekoli: v jedné budově nebo na jiném kontinentu. V každém případě musí být části distribuovaného systému propojeny spolehlivými a bezpečnými komunikačními linkami. Co se týče rychlosti přenosu dat, ta do značné míry závisí na důležitosti propojení obou částí systému z hlediska zpracování a přenosu dat a v menší míře na jejich odlehlosti.

Distribuce obchodní logiky napříč vrstvami distribuované aplikace

Je čas jít dál Detailní popisúrovně distribuovaného systému, ale nejprve si řekněme pár slov o rozdělení funkčnosti aplikace podle úrovní. Obchodní logiku lze implementovat na kterékoli z úrovní třívrstvé architektury.

Databázové servery mohou nejen ukládat data do databází, ale také obsahovat část obchodní logiky aplikace v uložených procedurách, triggerech atd.

Klientské aplikace mohou také implementovat pravidla pro zpracování dat. Pokud je soubor pravidel minimální a scvrkává se hlavně na postupy ověřování zadávání dat, máme co do činění s „tenkým“ klientem. „Tlustý“ klient naopak obsahuje velký podíl funkčnosti aplikace.

Úroveň zpracování dat je vlastně navržena tak, aby implementovala obchodní logiku aplikace a jsou zde soustředěna všechna základní pravidla zpracování dat.

V obecném případě je tedy funkčnost aplikace „rozmazaná“ v celé aplikaci. Veškerou rozmanitost distribuce obchodní logiky napříč aplikačními úrovněmi lze znázornit jako hladkou křivku ukazující podíl pravidel zpracování dat soustředěných na určitém místě. Křivky na Obr. 3 jsou kvalitativní, ale přesto nám umožňují vidět, jak mohou změny ve struktuře aplikace ovlivnit distribuci pravidel.

A praxe tento závěr potvrzuje. Vždy je totiž potřeba implementovat pár pravidel přesně do uložených procedur databázového serveru a velmi často je vhodné některé počáteční datové operace přenést na stranu klienta – alespoň proto, aby se zabránilo zpracování nesprávných dotazů.

Prezentační vrstva

Prezentační vrstva je jediná dostupná koncový uživatel. Tato vrstva modeluje distribuované aplikační klientské pracovní stanice a související software. Možnosti klientské pracovní stanice jsou primárně určeny možnostmi operačního systému. V závislosti na typu uživatelského rozhraní je klientský software rozdělen do dvou skupin: klienti, kteří používají funkce grafického uživatelského rozhraní (například Windows) a weboví klienti. V každém případě však musí klientská aplikace poskytovat následující funkce:

přijímání dat;

prezentace dat pro prohlížení uživatelem;

editace dat;

Kontrola správnosti zadaných údajů;

uložení provedených změn;

· Zpracování výjimek a zobrazování informací o chybách uživateli.

Je žádoucí soustředit všechna obchodní pravidla na úroveň zpracování dat, ale v praxi to není vždy možné. Poté hovoří o dvou typech klientského softwaru. Tenký klient obsahuje minimální sada obchodní pravidla, zatímco „tlustý“ implementuje významnou část logiky aplikace. V prvním případě se distribuovaná aplikace mnohem snadněji ladí, upgraduje a rozšiřuje, v druhém případě je možné minimalizovat náklady na vytvoření a údržbu úrovně správy dat, protože některé operace lze provádět na straně klienta, a pouze přenos dat spadá do podílu middlewaru.

Vrstva zpracování dat

Vrstva zpracování dat kombinuje části, které implementují obchodní logiku aplikace a je prostředníkem mezi vrstvou prezentace dat a vrstvou ukládání dat. Veškerá data jím procházejí a procházejí v něm změnami, vzhledem k řešenému problému (viz obr. 2). Funkce této úrovně zahrnují následující:

Zpracování datových toků v souladu s obchodními pravidly;

interakce s prezentační vrstvou dat za účelem přijímání požadavků a vracení odpovědí;

interakce s vrstvou úložiště dat pro odesílání požadavků a přijímání odpovědí.

Nejčastěji je vrstva zpracování dat identifikována s middlewarem distribuované aplikace. Tato situace platí plně pro "ideální" systém a pouze částečně - pro skutečné aplikace(Viz obr. 3). Pokud jde o posledně jmenované, middleware pro ně obsahuje velký podíl pravidel pro zpracování dat, ale některá z nich jsou implementována na serverech SQL ve formě uložených procedur nebo triggerů a některá jsou součástí klientského softwaru.

Takové „rozostření“ obchodní logiky je oprávněné, neboť umožňuje zjednodušit část postupů zpracování dat. Vezměme si klasický příklad pokladny. Může obsahovat názvy pouze těch produktů, které jsou skladem. Při přidávání určité položky do objednávky a určování jejího množství je tedy nutné odečíst odpovídající číslo ze zůstatku této položky na skladě. Je zřejmé, že nejlepší je implementovat tuto logiku pomocí nástrojů databázového serveru – uložené procedury nebo triggeru.

Vrstva správy dat

Aby byla aplikace konzistentní, odolná a spolehlivá, upgradovatelná a škálovatelná, je zapotřebí vrstva správy dat. Zajišťuje provádění systémových úloh, bez něj nebudou moci části aplikace (databázové servery, aplikační servery, middleware, klienti) vzájemně interagovat a spojení přerušená při zvýšení zátěže nelze obnovit.

Kromě toho lze ve vrstvě správy dat implementovat různé služby aplikačního systému. Vždy jsou totiž pro celou aplikaci společné funkce, které jsou nezbytné pro chod všech úrovní aplikace, nelze je tedy umístit na žádnou z dalších úrovní.

Například služba univerzálního času poskytuje všem částem aplikace systémová časová razítka, která synchronizují jejich práci. Představte si, že distribuovaná aplikace má server, který rozesílá úkoly klientům s konkrétním datem splatnosti. Pokud je termín zmeškán, musí být úloha zaregistrována s výpočtem doby zpoždění. Pokud jsou klientské pracovní stanice umístěny ve stejné budově jako server nebo na vedlejší ulici, žádný problém, algoritmus účtování je jednoduchý. Co když se ale klienti nacházejí v jiných časových pásmech – v jiných zemích nebo dokonce za oceánem? V tomto případě musí být server schopen vypočítat rozdíl s ohledem na časová pásma při odesílání úloh a přijímání odpovědí a klienti budou muset do zpráv přidat servisní informace o místním čase a časovém pásmu. Pokud distribuovaná aplikace obsahuje jednorázovou službu, pak tento problém jednoduše neexistuje.

Kromě jednorázové služby může vrstva správy dat obsahovat služby pro ukládání obecných informací (informace o aplikaci jako celku), generování obecných zpráv atd.

Mezi funkce vrstvy správy dat tedy patří:

Správa částí distribuované aplikace;

správa spojení a komunikačních kanálů mezi částmi aplikace;

Správa datových toků mezi klienty a servery a mezi servery;

řízení zátěže;

implementace služeb aplikačního systému.

Je třeba poznamenat, že úroveň správy dat je často vytvářena na základě hotových řešení dodávaných na softwarový trh různými výrobci. Pokud si vývojáři pro svou aplikaci zvolili architekturu CORBA, pak zahrnuje zprostředkovatele objektových požadavků (Object Request Broker, ORB), v případě platformy Windows mají k dispozici celou řadu nástrojů: COM + technologie (vývoj Microsoft Transaction Server, technologie MTS), technologie zpracování front zpráv MSMQ, technologie Microsoft BizTalk atd.

Úložná vrstva

Vrstva úložiště dat kombinuje SQL servery a databáze používané aplikací. Poskytuje následující úkoly:

Ukládání dat do databáze a jejich udržování v provozuschopném stavu;

Zpracování požadavků vrstvy zpracování dat a vrácení výsledků;

implementace části obchodní logiky distribuované aplikace;

· správa distribuovaných databází pomocí administrativních nástrojů databázových serverů.

Kromě samozřejmých funkcí – ukládání dat a zpracování dotazů, může úroveň obsahovat část obchodní logiky aplikace v uložených procedurách, triggerech, omezeních atd. A samotná struktura databáze aplikace (tabulky a jejich pole, indexy, zahraniční klíče atd.) ) dochází k implementaci datové struktury, se kterou distribuovaná aplikace pracuje, a implementaci některých pravidel obchodní logiky. Například použití cizího klíče v databázové tabulce vyžaduje vytvoření vhodného omezení manipulace s daty, protože záznamy hlavní tabulky nelze odstranit, pokud existují odpovídající záznamy propojené cizím klíčem tabulky.

Většina databázových serverů podporuje různé administrativní procedury, včetně správy distribuovaných databází. Patří mezi ně replikace dat, vzdálená archivace, přístup ke vzdáleným databázím atd. Možnost využití těchto nástrojů je třeba zvážit při vývoji struktury vlastní distribuované aplikace.

Připojování k databázím SQL servery prováděny především pomocí serverového klientského softwaru. Navíc lze dodatečně využít různé technologie pro přístup k datům, jako je ADO (ActiveX Data Objects) nebo ADO.NET. Ale při návrhu systému je třeba vzít v úvahu, že funkčně zprostředkující technologie přístupu k datům nepatří do vrstvy ukládání dat.

Rozšíření základní úrovně

Výše uvedené úrovně architektury distribuované aplikace jsou základní. Tvoří strukturu aplikace se vytváří obecně, ale zároveň samozřejmě nedokážou zajistit implementaci jakékoli aplikace - předmětové oblasti a úkoly jsou příliš rozsáhlé a různorodé. Pro takové případy lze architekturu distribuované aplikace rozšířit o další vrstvy, které jsou navrženy tak, aby odrážely vlastnosti vytvářené aplikace.

Mimo jiné existují dvě nejčastěji používaná rozšíření základních úrovní.

Vrstva obchodního rozhraní se nachází mezi vrstvou uživatelského rozhraní a vrstvou zpracování dat. Skrývá před klientskými aplikacemi detaily struktury a implementace obchodních pravidel vrstvy zpracování dat a poskytuje abstrakci kódu klientské aplikace od implementačních detailů aplikační logiky.

Výsledkem je, že vývojáři klientských aplikací používají určitou sadu nezbytných funkcí - analog aplikačního programovacího rozhraní (API). To umožňuje, aby klientský software byl nezávislý na implementaci vrstvy zpracování dat.

Při provádění velkých změn v systému je samozřejmě globální přepracování nezbytné, ale úroveň obchodního rozhraní vám to umožňuje, pokud to není nezbytně nutné.

Vrstva pro přístup k datům se nachází mezi vrstvou ukládání dat a vrstvou zpracování dat. Umožňuje vytvořit strukturu aplikace nezávislou na konkrétní technologii ukládání dat. V takových případech softwarové entity vrstvy zpracování dat odesílají požadavky a přijímají odpovědi pomocí prostředků zvolené technologie přístupu k datům.

Při implementaci aplikací na platformě Windows je nejčastěji využívána technologie přístupu k datům ADO, která poskytuje univerzální způsob přístupu k široké škále datových zdrojů – od SQL serverů až po tabulky. Pro aplikace na platformě .NET se používá technologie ADO.NET.

n1.doc

11. Architektura distribuovaných systémů

Cíle
Účelem této kapitoly je studovat architekturu distribuovaných softwarové systémy. Po přečtení této kapitoly byste měli:

• 
  znát hlavní výhody a nevýhody distribuovaných systémů;
• 
  rozumět různým přístupům používaným při vývoji architektur klient/server;
• 
  porozumět rozdílům mezi architekturou klient/server a architekturou distribuovaných objektů;
• 
  znát koncept zprostředkovatele objektových požadavků a principy implementované ve standardech CORBA.

V současné době jsou distribuovány téměř všechny velké softwarové systémy. Distribuovaný systém je takový systém, ve kterém není zpracování informací soustředěno na jednom počítači, ale je distribuováno mezi více počítačů. Při navrhování distribuovaných systémů, které mají mnoho společného s návrhem jakéhokoli jiného softwaru, je stále třeba brát v úvahu řadu specifických vlastností. Některé z nich již byly zmíněny v úvodu ke kapitole 10 při diskuzi o architektuře klient/server a podrobněji se o nich pojednává zde.

Vzhledem k tomu, že distribuované systémy jsou v dnešní době tak rozšířené, musí vývojáři softwaru znát jejich konstrukční funkce. Donedávna byly všechny velké systémy většinou centralizované, které běžely na jednom hlavním počítači (mainframe) s připojenými terminály. Terminály prakticky nezpracovávaly informace - všechny výpočty byly prováděny na hlavním stroji. Vývojáři takových systémů nemuseli myslet na problémy distribuovaného počítání.

Všechny moderní softwarové systémy lze rozdělit do tří velkých tříd.
1. Systémy aplikačního softwaru navržené pro provoz pouze na jednom osobním počítači nebo pracovní stanici. Patří mezi ně textové procesory, tabulkové procesory, grafické systémy a podobně.

2. Vestavěné systémy navržené pro provoz na jediném procesoru nebo na integrované skupině procesorů. Patří sem řídicí systémy pro domácí spotřebiče, různé spotřebiče atd.

3. Distribuované systémy, ve kterých software běží na volně integrované skupině paralelních procesorů propojených sítí. Patří sem ATM systémy vlastněné bankou, publikační systémy, softwarové systémy pro kolektivní použití atd.
V současnosti jsou mezi uvedenými třídami softwarových systémů jasné hranice, které se budou v budoucnu stále více stírat. Postupem času, když vysokorychlostní bezdrátová síť budou široce dostupné, bude možné dynamicky integrovat zařízení s vestavěnými softwarovými systémy, jako jsou elektronické organizéry s obecnějšími systémy.

Kniha zdůrazňuje šest klíčových charakteristik distribuovaných systémů.
1. Sdílení zdrojů. Distribuované systémy umožňují sdílení hardwarové a softwarové prostředky, jako např pevné disky, tiskárny, soubory, kompilátory atd. připojené přes síť. Sdílení zdrojů je samozřejmě možné i ve víceuživatelských systémech, ale v tomto případě by za poskytování zdrojů a jejich správu měl odpovídat centrální počítač.

2. Otevřenost. Jedná se o možnost rozšířit systém přidáním nových zdrojů. Distribuované systémy jsou otevřené systémy, ke kterému je připojen hardware a software od různých výrobců.

3. Rovnoběžnost. V distribuovaných systémech může současně běžet více procesů různé počítače online. Tyto procesy se mohou (ale nemusí) vzájemně ovlivňovat, když jsou spuštěny.

4. Škálovatelnost. V zásadě jsou všechny distribuované systémy škálovatelné: aby systém vyhovoval novým požadavkům, lze jej škálovat přidáním nových výpočetních zdrojů. Ale v praxi může být růst omezen na síť, která spojuje jednotlivé počítače v systému. Pokud připojíte mnoho nových počítačů, šířka pásma sítě nemusí být dostatečná.

5. Odolnost proti chybám. Přítomnost více počítačů a možnost duplikace informací znamená, že distribuované systémy jsou odolné vůči určitému hardwaru a softwarové chyby(viz kapitola 18). Většina distribuovaných systémů obvykle dokáže zachovat alespoň částečnou funkčnost v případě chyby. K úplnému selhání systému dochází pouze v případě síťových chyb.

6. Průhlednost. Tato vlastnost znamená, že uživatelé mají plnou hodnotu transparentní přístup ke zdrojům a zároveň jsou před nimi skryty informace o rozložení zdrojů v systému. V mnoha případech však specifické znalosti o organizaci systému pomáhají uživateli lépe využívat zdroje.
Distribuované systémy mají samozřejmě řadu nevýhod.

Složitost. Distribuované systémy jsou složitější než centralizované. Mnohem obtížnější je obecně porozumět a vyhodnotit vlastnosti distribuovaných systémů a také tyto systémy otestovat. Například zde výkon systému nezávisí na rychlosti jednoho procesoru, ale na šířce pásma sítě a rychlosti různých procesorů. Přesunutím zdrojů z jedné části systému do druhé může být výkon systému drasticky ovlivněn.

Bezpečnost. Obvykle lze k systému přistupovat z několika různých strojů, zprávy v síti lze prohlížet nebo zachytit. Proto je mnohem obtížnější udržet bezpečnost v distribuovaném systému.

ovladatelnost. Systém se může skládat z různých typů počítačů, na kterých různé verze operační systémy. Chyby na jednom počítači se mohou rozšířit na další počítače s nepředvídatelnými následky. Proto je potřeba mnohem více úsilí pro správu a udržování systému v provozuschopném stavu.

Nepředvídatelnost. Jak všichni uživatelé webu vědí, odezva distribuovaných systémů na určité události je nepředvídatelná a závisí na plné zátěži systému, jeho organizaci a zatížení sítě. Vzhledem k tomu, že se všechny tyto parametry mohou neustále měnit, může se čas potřebný k dokončení uživatelského požadavku v té či oné době výrazně lišit.
Při diskuzi o výhodách a nevýhodách distribuovaných systémů kniha identifikuje řadu kritických problémů návrhu takových systémů (tabulka 11.1). Tato kapitola se zaměřuje na architekturu distribuovaného softwaru, protože se domnívám, že je to nejdůležitější bod ve vývoji softwarových produktů. Pokud vás zajímají jiná témata, podívejte se do specializovaných knih o distribuovaných systémech.
Tabulka 11.1. Problémy navrhování distribuovaných systémů

Úkolem vývojářů distribuovaných systémů je navrhnout software nebo hardware tak, aby poskytoval všechny potřebné vlastnosti distribuovaného systému. A to vyžaduje znát výhody a nevýhody různých architektur distribuovaných systémů. Existují dva příbuzné typy architektur distribuovaných systémů.
1. Architektura klient/server. V tomto modelu lze systém chápat jako soubor služeb poskytovaných servery klientům. V takových systémech se servery a klienti navzájem výrazně liší.

2. Architektura distribuovaných objektů. V tomto případě neexistují žádné rozdíly mezi servery a klienty a systém lze považovat za sadu vzájemně se ovlivňujících objektů, na jejichž umístění ve skutečnosti nezáleží. Mezi poskytovatelem služeb a jejich uživateli není žádný rozdíl.
V distribuovaném systému mohou být implementovány různé systémové komponenty různé jazyky programování a běh na různých typech procesorů. Datové modely, reprezentace informací a interakční protokoly – to vše nemusí být nutně stejného typu v distribuovaném systému. Distribuované systémy proto vyžadují software, který dokáže spravovat tyto heterogenní části a zaručit interakci a výměnu dat mezi nimi. Middleware patří do této třídy softwaru. Je jakoby uprostřed mezi různými částmi distribuovaných součástí systému.

Tento článek popisuje různé typy middlewaru, které mohou podporovat distribuované výpočty. Takový software je zpravidla sestaven z hotových komponent a nevyžaduje speciální úpravy od vývojářů. Mezi příklady middlewaru patří programy pro správu databází, transakční manažery, převodníky dat, komunikační inspektoři atd. Dále v této kapitole bude struktura distribuovaných systémů popsána jako třída middlewaru.

Distribuované systémy jsou obvykle vyvíjeny pomocí objektově orientovaného přístupu. Tyto systémy jsou vytvořeny z volně integrovaných částí, z nichž každá může přímo interagovat jak s uživatelem, tak s ostatními částmi systému. Tyto části by měly reagovat na nezávislé události, kdykoli je to možné. Softwarové objekty postavené na těchto principech jsou přirozenou součástí distribuovaných systémů. Pokud ještě nejste obeznámeni s pojmem objekty, doporučuji si nejprve přečíst kapitolu 12 a poté se k této kapitole znovu vrátit.

11.1. Víceprocesorová architektura

Nejjednodušším distribuovaným systémem je víceprocesorový systém. Skládá se z mnoha různých procesů, které mohou (ale nemusí) běžet na různých procesorech. Tento model se často používá ve velkých systémech pracujících v reálném čase. Jak se dozvíte v kapitole 13, tyto systémy shromažďují informace, rozhodují se na jejich základě a posílají signály agentovi, který mění systémové prostředí. V zásadě lze všechny procesy související se sběrem informací, rozhodováním a řízením výkonného mechanismu provádět na jediném procesoru pod kontrolou plánovače úloh. Použití více procesorů zlepšuje výkon a odolnost systému. Rozdělení procesů mezi procesory může být potlačeno (je vlastní kritickým systémům) nebo může být řízeno správcem procesů.

Na Obr. 11.1 ukazuje příklad tohoto typu systému. Jedná se o zjednodušený model systému řízení dopravy. Skupina distribuovaných senzorů shromažďuje informace o množství průtoku. Shromážděné údaje jsou zpracovávány na místě před odesláním do dispečinku. Na základě obdržených informací se operátoři rozhodují a řídí semafory. V tomto příkladu existují samostatné logické procesy pro správu senzorů, řídicí místnosti a semaforů. Může se jednat jak o jednotlivé procesy, tak o skupinu procesů. V našem příkladu běží na různých procesorech.

Rýže. 11.1. Multiprocesorový systém řízení dopravy
Softwarové systémy, na kterých běží více procesů současně, nemusí být nutně distribuovány. Pokud je v systému více než jeden procesor, není složité implementovat distribuci procesů. Při tvorbě víceprocesorových softwarových systémů však není nutné vycházet pouze z distribuovaných systémů. Návrh těchto typů systémů se v podstatě řídí stejným přístupem jako návrh systémů pracujících v reálném čase popsaný v kapitole 13.

11.2. Architektura klient/server

Kapitola 10 se již zabývala konceptem klient/server. V architektuře klient/server je softwarová aplikace modelována jako sada služeb poskytovaných servery a sada klientů využívajících tyto služby. Klienti si musí být vědomi dostupných (existujících) serverů, i když si nemusí být vědomi existence jiných klientů. Jak je patrné z Obr. Na obrázku 11.2, což je schéma distribuované architektury klient/server, klienti a servery představují různé procesy.


Rýže. 11.2. Systém klient/server
Systém nemusí mít vztah jedna ku jedné mezi procesy a procesory. Na Obr. Obrázek 11.3 ukazuje fyzickou architekturu systému, který se skládá ze šesti klientských strojů a dvou serverů. Spouštějí klientské a serverové procesy znázorněné na obr. 11.2. Obecně, když mluvím o klientech a serverech, mluvím spíše o logických procesech než o fyzických strojích, které tyto procesy provozují.

Architektura systému klient/server by měla odrážet logickou strukturu vyvíjené softwarové aplikace. Na Obr. 11.4 nabízí další pohled na softwarovou aplikaci strukturovanou do tří úrovní. Prezentační vrstva poskytuje uživatelům informace a interakci s nimi. Runtime aplikace implementuje logiku aplikace. Vrstva správy dat provádí všechny databázové operace. V centralizovaných systémech neexistuje jasné oddělení mezi těmito úrovněmi. Při návrhu distribuovaných systémů je však nutné tyto vrstvy oddělit, aby bylo možné každou vrstvu umístit na různé počítače.

Nejjednodušší architektura klient/server je dvouvrstvá, ve které se aplikace skládá ze serveru (nebo mnoha identických serverů) a skupiny klientů. Existují dva druhy takové architektury (obr. 11.5).
1. model tenkého klienta. V tomto modelu se veškerá práce s aplikací a správa dat provádí na serveru. Na klientském počítači běží pouze software prezentační vrstvy.

2. model tlustého klienta. V tomto modelu server pouze spravuje data. Na klientském stroji je realizován provoz aplikace a interakce s uživatelem systému.


Rýže. 11.3. Počítače v síti klient/server

Rýže. 11.4. Softwarové aplikační vrstvy
Tenký klient s dvouvrstvou architekturou je nejjednodušší způsob migrace stávajících centralizovaných systémů (viz Kapitola 26) na architekturu klient/server. Uživatelské rozhraní se v těchto systémech „přesune“ na osobní počítač a samotná softwarová aplikace plní funkce serveru, tzn. spouští všechny aplikační procesy a spravuje data. Model tenkého klienta lze také implementovat tam, kde jsou klienty běžná síťová zařízení spíše než osobní počítače nebo pracovní stanice. Síťová zařízení provozují internetový prohlížeč a uživatelské rozhraní implementované v systému.


Rýže. 11.5. Modely tenkých a tlustých klientů
Hlavní nevýhodou modelu tenkého klienta je vysoká zátěž serveru a sítě. Všechny výpočty se provádějí na serveru, což může vést ke značnému síťovému provozu mezi klientem a serverem. Moderní počítače mají dostatek výpočetního výkonu, ten se ale v modelu tenkého klienta banky prakticky nepoužívá.

Naproti tomu model tlustého klienta využívá výpočetní výkon místních strojů: na klientském počítači je umístěna vrstva pro provádění aplikací i vrstva prezentace. Server je zde v podstatě transakční server, který spravuje všechny databázové transakce. Příkladem tohoto typu architektury mohou být systémy bankomatů, kde je bankomatem klient a server je centrální počítač, který spravuje databázi zákaznických účtů.

Na Obr. zobrazeno 11.6 síťový systém bankomaty. Všimněte si, že bankomaty nejsou připojeny k zúčtovací databázi přímo, ale prostřednictvím teleprocessingového monitoru. Tento monitor je prostředníkem, který komunikuje se vzdálenými klienty a organizuje požadavky klientů do sekvence transakcí pro práci s databází. Použití sekvenčních transakcí, když dojde k selhání, umožňuje systému obnovit se bez ztráty dat.


Rýže. 11.6. Systém klient/server pro síť ATM
Vzhledem k tomu, že provádění softwarové aplikace je organizováno efektivněji v modelu tlustého klienta než v modelu tenkého klienta, je obtížnější takový systém spravovat. Zde jsou funkce aplikace distribuovány na mnoha různých strojích. Nutnost výměny aplikace vede k její reinstalaci na všech klientských počítačích, což je drahé, pokud jsou v systému stovky klientů.

Příchod jazyka Java a apletů ke stažení umožnil vývoj modelů klient/server, které jsou někde mezi modely tenkých a tlustých klientů. Část programů, které tvoří aplikaci, lze stáhnout na klientský počítač jako Java applety a tím snižovat zatížení serveru. Uživatelské rozhraní je vytvořeno pomocí webového prohlížeče, který spouští Java applety. Nicméně, webové prohlížeče od různých dodavatelů a dokonce různé verze Webové prohlížeče od stejného výrobce nefungují vždy stejně. Starší prohlížeče na starších počítačích nemusí vždy spustit Java applety. Proto by se tento přístup měl používat pouze tehdy, když jste si jisti, že všichni uživatelé systému mají nainstalované prohlížeče kompatibilní s Java.

Ve dvouvrstvém modelu klient/server je významným problémem umístění tří logických vrstev na dvou počítačových systémech – prezentace, spouštění aplikací a správa dat. Proto má tento model často buď problémy se škálovatelností a výkonem, pokud je zvolen model tenkého klienta, nebo problémy se správou systému, pokud je použit model tlustého klienta. Aby se předešlo těmto problémům, je třeba zvolit alternativní přístup – třívrstvý model architektury klient/server (obrázek 11.7). V této architektuře odpovídají samostatné procesy vrstvám prezentace, spouštění aplikací a správy dat.


Rýže. 11.7. Třívrstvá architektura klient/server
Softwarová architektura, postavená na třívrstvém modelu klient/server, nevyžaduje tři počítačové systémy. Na stejném počítači serveru můžete spustit spouštění aplikací i správu dat jako samostatné logické servery. Pokud zároveň vzrostou systémové požadavky, bude relativně snadné oddělit spouštění aplikací a správu dat a provozovat je na různých procesorech.

Bankovní systém využívající internetové služby lze implementovat pomocí třívrstvé architektury klient/server. Účtovací databáze (obvykle umístěná na hostitelském počítači) poskytuje služby správy dat, webový server podporuje aplikační služby, jako jsou zařízení pro převod peněz, generování zpráv, placení faktur atd. Klientem je počítač uživatele s internetovým prohlížečem. Jak je znázorněno na Obr. 11.8 je tento systém škálovatelný, protože je relativně snadné přidávat nové webové servery s rostoucím počtem klientů.

Použití třívrstvé architektury v tomto příkladu optimalizovalo přenos dat mezi webovým serverem a databázovým serverem. Interakce mezi těmito systémy nemusí být založena na internetových standardech, ale lze použít rychlejší nízkoúrovňové komunikační protokoly. Informace z databáze jsou obvykle zpracovávány účinným middlewarem, který podporuje dotazy na databázi ve strukturovaném dotazovacím jazyce SQL.

V některých případech lze třívrstvý model klient/server převést na vícevrstvý přidáním dalších serverů do systému. Vrstvené systémy lze také použít tam, kde aplikace potřebují mít přístup k informacím umístěným v různých databázích. V tomto případě je federovaný server umístěn mezi serverem, na kterém je spuštěna aplikace, a databázovými servery. Federovaný server shromažďuje distribuovaná data a předkládá je aplikaci, jako by byla ve stejné databázi.


Rýže. 11.8. Distribuovaná architektura bankovní systém použitímInternet-služby
Návrháři architektur klient/server musí při výběru té nejvhodnější zvážit řadu faktorů. V tabulce. 11.2 uvádí různá použití architektury klient/server.
Tabulka 11.2. aplikace odlišné typy architektury klient/server

11.3. Architektura distribuovaných objektů

V modelu klient/server distribuovaného systému existují rozdíly mezi klienty a servery. Klient požaduje služby pouze od serveru, hq ne od jiných klientů; servery mohou fungovat jako klienti a požadovat služby od jiných serverů, ale ne od klientů; klienti si musí být vědomi služeb poskytovaných určitými servery a toho, jak tyto servery interagují. Tento model je skvělý pro mnoho typů aplikací, ale zároveň omezuje vývojáře systémů, kteří se musí rozhodovat, kde budou poskytovat služby. Musí také poskytovat podporu pro škálovatelnost a vyvíjet prostředky pro zahrnutí klientů na distribuované servery.

Obecnějším přístupem používaným v návrhu distribuovaného systému je rozmazání rozdílu mezi klientem a serverem a návrh architektury systému jako architektury distribuovaného objektu. V této architektuře (obrázek 11.9) jsou hlavními součástmi systému objekty, které prostřednictvím svých rozhraní poskytují sadu služeb. Jiné objekty vyvolávají tyto služby bez rozlišení mezi klientem (uživatelem služby) a serverem (poskytovatelem služby).


Rýže. 11.9. Architektura distribuovaných objektů
Objekty mohou být umístěny na různých počítačích v síti a interagovat prostřednictvím middlewaru. Analogicky se systémovou sběrnicí, která umožňuje připojení různá zařízení a podporují komunikaci mezi hardwarem, middleware lze považovat za softwarovou sběrnici. Poskytuje sadu služeb, které umožňují objektům vzájemně interagovat, přidávat je nebo odebírat ze systému. Middleware se nazývá broker objektových požadavků. Jeho úkolem je poskytovat rozhraní mezi objekty. Zprostředkovatelé požadavků na objekty jsou popsáni v části 11.4.

Hlavní výhody modelu distribuované objektové architektury jsou uvedeny níže.
Vývojáři systému mohou být pomalí při rozhodování o tom, kde a jak budou služby poskytovány. Objekty poskytující služby mohou běžet kdekoli (uzel) v síti. Proto se rozdíl mezi modely tlustého a tenkého klienta stává irelevantním, protože pro spuštění aplikace není nutné předem plánovat umístění objektů.

Architektura systému je zcela otevřená, což umožňuje v případě potřeby přidávat do systému nové zdroje. Další část poznamenává, že standardy softwarových sběrnic se neustále vyvíjejí, aby umožnily objektům napsaným v různých programovacích jazycích vzájemně se ovlivňovat a poskytovat si služby.

Flexibilita a škálovatelnost systému. Pro zvládnutí zatížení systému můžete vytvořit instance systému se stejnými službami, které budou poskytovat různé objekty nebo různé instance (kopie) objektů. Když se zatížení zvýší, mohou být do systému přidány nové objekty, aniž by byla přerušena práce ostatních objektů v systému.

Systém je možné dynamicky rekonfigurovat pomocí objektů migrujících v síti na vyžádání. Objekty poskytující služby mohou migrovat na stejný procesor jako objekty požadující služby, čímž se zlepšuje výkon systému.
Architekturu distribuovaných objektů lze v procesu návrhu systému použít dvěma způsoby.
1. Ve formě logického modelu, který umožňuje vývojářům strukturovat a plánovat systém. V tomto případě je funkčnost aplikace popsána pouze termíny a kombinacemi služeb. Poté jsou vyvíjeny způsoby poskytování služeb pomocí více distribuovaných objektů. Na této úrovni se zpravidla navrhují velkomodulové objekty, které poskytují služby odrážející specifika konkrétní aplikační oblasti. Například v programu maloobchodního účetnictví můžete zahrnout objekty, které by sledovaly stav zásob, sledovaly interakce zákazníků, klasifikovaly zboží atd.

2. Jako flexibilní přístup k implementaci systémů klient/server. V tomto případě je logickým modelem systému model klient/server, ve kterém jsou klienti a servery implementováni jako distribuované objekty, které interagují prostřednictvím softwarové sběrnice. S tímto přístupem je snadné nahradit systém např. dvouúrovňovým víceúrovňovým. V tomto případě nelze server ani klienta implementovat do jednoho objektu, ale mohou se skládat z mnoha malých objektů, z nichž každý poskytuje určitou službu.
Příkladem systému, který je vhodný pro distribuovanou objektovou architekturu, je systém pro zpracování dat uložených v různých databázích (obr. 11.10). V tomto příkladu lze libovolnou databázi považovat za objekt s rozhraním, které poskytuje přístup k datům pouze pro čtení. Každý z objektů integrátoru se zabývá určitými typy závislostí dat shromažďováním informací z databází, aby se pokusil tyto závislosti sledovat.

Objekty vizualizéru interagují s objekty integrátoru a prezentují data v grafické podobě nebo generují zprávy o analyzovaných datech. Způsoby, jak prezentovat grafické informace, jsou popsány v kapitole 15.


Rýže. 11.10. Architektura systému distribuovaného zpracování dat
Pro tento typ aplikace je architektura distribuovaných objektů vhodnější než architektura klient/server ze tří důvodů.
1. V těchto systémech (na rozdíl např. od systému ATM) neexistuje jediný poskytovatel služeb, na který by byly soustředěny všechny služby správy dat.

2. Můžete zvýšit počet dostupných databází bez přerušení systému, protože každá databáze je pouze objekt. Tyto objekty podporují zjednodušené rozhraní, které řídí přístup k datům. Dostupné databáze lze umístit na různé stroje.

3. Přidáním nových objektů integrátoru můžete sledovat nové typy závislostí mezi daty.
Hlavní nevýhodou distribuovaných objektových architektur je, že je obtížnější je navrhnout než systémy klient/server. Ukazuje se, že systémy klient/server poskytují přirozenější přístup k budování distribuovaných systémů. Odráží vztah mezi lidmi, ve kterém někteří lidé využívají služeb jiných lidí, kteří se specializují na poskytování konkrétních služeb. Je mnohem obtížnější vyvinout systém v souladu s architekturou distribuovaných objektů, protože softwarový průmysl dosud nenashromáždil dostatečné zkušenosti s návrhem a vývojem objektů velkého rozsahu.

11.4. CORBA

Jak bylo uvedeno v předchozí části, implementace architektury distribuovaných objektů vyžaduje middleware (zprostředkovatele požadavků na objekty), který organizuje interakci mezi distribuovanými objekty. Zde mohou nastat určité problémy, protože objekty v systému mohou být implementovány v různých programovacích jazycích, mohou být spouštěny různé platformy a jejich jména by neměla znát všechny ostatní objekty v systému. Takže middleware musí stačit dobrá práce aby byla zachována neustálá interakce objektů.

V současné době existují dva hlavní standardy middlewaru pro podporu distribuovaných objektů.
1. CORBA (Common Object Request Broker Architecture - architektura poptávkových brokerů pro společné objekty). Jedná se o sadu middlewarových standardů vyvinutých OMG (Object Management Group). OMG je konsorcium výrobců softwaru a hardwaru, včetně společností jako Sun, Hewlett-Packard a IBM. Standardy CORBA definují běžný na stroji nezávislý přístup k výpočtu distribuovaných objektů. od různých výrobců bylo vyvinuto mnoho implementací tohoto standardu. Standardy CORBA jsou podporovány operačním systémem Unix a operační systémy od společnosti Microsoft.

2. DCOM (Distributed Component Object Model - objektový model distribuované komponenty). DCOM je standard vyvinutý a implementovaný společností Microsoft a integrovaný do jejích operačních systémů. Tento model distribuovaného počítání je méně univerzální než CORBA a nabízí omezenější možnosti pro síťové interakce. DCOM je v současnosti omezen na operační systémy Microsoft.
Zde jsem se rozhodl věnovat pozornost technologii CORBA, protože je univerzálnější. Navíc se domnívám, že pravděpodobně CORBA, DCOM a další technologie, jako je RMI (Remote Method Invocation - call vzdálená metoda, technologie pro budování distribuovaných aplikací v jazyce Java) se budou postupně vzájemně sbližovat a tato konvergence bude vycházet ze standardů CORBA. Proto není potřeba další standard. Rozdílné standardy budou pouze brzdou dalšího rozvoje.

Standardy CORBA definuje skupina OMG, která sdružuje více než 500 společností podporujících objektově orientovaný vývoj. Úlohou OMG je vytvářet standardy pro objektově orientovaný vývoj, nikoli poskytovat konkrétní implementace těchto standardů. Tyto normy jsou volně dostupné na webových stránkách OMG. Skupina se nezabývá pouze standardy CORBA, ale definuje také širokou škálu dalších standardů, včetně modelovacího jazyka UML.

Zastoupení distribuovaných aplikací v rámci CORBA je znázorněno na Obr. 11.11. Toto je zjednodušený diagram architektury správy objektů převzatý z článku. Očekává se, že distribuovaná aplikace se bude skládat z následujících komponent.
1. Aplikační objekty, které jsou vytvořeny a vyvinuty pro tento softwarový produkt.

2. Standardní objekty, které jsou definovány OMG pro konkrétní úkoly. V době psaní této knihy se mnoho lidí zabývalo vývojem objektových standardů pro finance, pojišťovnictví, elektronický obchod, zdravotnictví a další.

3. Základní služby CORBA, které podporují základní služby distribuované výpočty, jako jsou adresáře, správa zabezpečení atd.

4. Horizontální nástroje CORBA, jako jsou uživatelská rozhraní, nástroje pro správu systému atd. Horizontálními prostředky, které jsou společné pro mnoho aplikací.


Rýže. 11.11. Struktura aplikace založené na distribuovaných standardechCORBA
Standardy CORBA popisují čtyři hlavní prvky.
1. Objektový model, ve kterém objekt CORBA zapouzdřuje stavy prostřednictvím jasného popisu v jazyce IDL (Interface Definition Language).

2. Object Request Broker (ORB), který spravuje požadavky na objektové služby. ORB přiděluje objekty, které poskytují služby, připravuje je na příjem požadavků, předává požadavek službě a vrací výsledky objektu, který požadavek podal.

3. Kolekce objektových služeb, které jsou základními službami a jsou potřebné v mnoha distribuovaných aplikacích. Příkladem jsou adresářové služby, transakční služby a dočasné služby údržby objektů.

4. Agregát společné komponenty postavený nad základními službami. Mohou být jak vertikální, odrážející specifika konkrétní oblasti, tak horizontální univerzální komponenty používané v mnoha softwarových aplikací. Tyto komponenty jsou popsány v kapitole 14.
V modelu CORBA objekt zapouzdřuje atributy a služby jako běžný objekt. Objekty CORBA však musí obsahovat také definici různých rozhraní, která popisují globální atributy a operace objektu. Objektová rozhraní CORBA jsou definována ve standardu univerzální jazyk popisy rozhraní IDL. Pokud jeden objekt požaduje služby poskytované jinými objekty, přistupuje k těmto službám prostřednictvím rozhraní IDL. Objekty CORBA mají jedinečný identifikátor nazývaný Interoperable Object Reference (IOR). Když jedna entita odešle požadavky na službu poskytovanou jinou entitou, použije se identifikátor IOR.

Zprostředkovatel požadavků na objekty zná objekty, které požadují služby, a jejich rozhraní. Organizuje interakci mezi objekty. O umístění jiných objektů, stejně jako o jejich realizaci, nemusí spolupracující objekty nic vědět. Protože rozhraní IDL odděluje objekty od zprostředkovatele, implementaci objektů lze změnit, aniž by to ovlivnilo ostatní součásti systému.

Na Obr. Obrázek 11-12 ukazuje, jak objekty ol a o2 komunikují prostřednictvím zprostředkovatele požadavku na objekt. Volající (ol) je spojen s IDL stub, který definuje rozhraní objektu, který poskytuje službu. Konstruktor objektu ol při požadavku na službu vloží volání do útržku jeho implementace objektu. IDL je rozšíření C++, takže pokud programujete v C++, C nebo Java, přístup k útržku je snadný. Překlad popisu rozhraní objektu do IDL je také možný pro jiné jazyky, jako je Ada nebo COBOL. Ale v těchto případech je nutná vhodná instrumentální podpora.

Rýže. 11.12. Objektová komunikace prostřednictvím Object Request Broker
Objekt, který poskytuje službu, je spojen s kostrou IDL, která váže rozhraní k implementaci služby. Jinými slovy, když je služba volána přes rozhraní, rámec IDL překládá volání do služby bez ohledu na to, jaký jazyk byl použit při implementaci. Po dokončení metody nebo postupu kostra převede výsledky do IDL, aby byly k dispozici volajícímu. Pokud objekt současně poskytuje služby jiným objektům nebo využívá služby, které jsou poskytovány jinde, potřebuje jak IDL kostru, tak IDL stub. Ten je nezbytný pro všechny používané objekty.

Zprostředkovatel požadavků na objekt se obvykle neimplementuje jako samostatné procesy, ale jako rámec (viz kapitola 14), který je spojen s implementací objektu. Proto v distribuovaném systému musí mít každý počítač, na kterém jsou spuštěny objekty, svého vlastního zprostředkovatele požadavků na objekt, který zpracovává všechna volání místních objektů. Pokud je však podán požadavek na službu, která je poskytována vzdálenou entitou, je vyžadována interakce mezi zprostředkovateli.

Tato situace je znázorněna na Obr. 11.13. V tomto příkladu, pokud objekt ol nebo o2 odesílá požadavky na služby poskytované objekty o3 nebo o4, je nutná interakce zprostředkovatelů spojených s těmito objekty. Standardy CORBA podporují komunikaci broker-to-broker, což umožňuje makléřům přístup k popisům rozhraní IDL, a nabízejí standard OMG Generic Inter-ORB Protocol (GIOP) pro komunikaci s makléři. Tento protokol definuje standardní zprávy, které si makléři mohou vyměňovat při volání vzdálených objektů a předávání informací. V kombinaci s nízkoúrovňovým internetovým protokolem TCP/IP umožňuje tento protokol makléřům komunikovat přes internet.

První varianty CORBA byly vyvinuty již v 80. letech 20. století. Rané verze CORBA byly pouze o podpoře distribuovaných objektů. Postupem času se však standardy vyvíjely, staly se pokročilejšími. Podobně jako mechanismy pro komunikaci distribuovaných objektů nyní standardy CORBA některé definují standardní služby, který lze použít k podpoře objektově orientovaných aplikací.


Rýže. 11.13. Interakce mezi brokery žádosti o objekt
Služby CORBA jsou nástroje, které jsou potřebné v mnoha distribuovaných systémech. Tyto standardy definují přibližně 15 běžných služeb (služeb). Tady jsou některé z nich.
1. Pojmenovací služba, která umožňuje objektům najít jiné objekty v síti a odkazovat na ně. Jmenná služba je adresářová služba, která přiřazuje názvy objektům. Objekty mohou tuto službu použít k vyhledání IOR jiných objektů podle potřeby.

2. Registrační služba, která umožňuje objektům registrovat jiné objekty poté, co nastanou určité události. Pomocí této služby lze objekty registrovat svou účastí na určité události, a když tato událost již nastala, služba ji automaticky zaregistruje.

3. Transakční služba, která podporuje elementární transakce a vrácení zpět v případě chyb nebo selhání. Tato služba je zařízení odolné proti chybám (viz kapitola 18), které poskytuje obnovu v případě chyb během operace aktualizace. Pokud akce k aktualizaci objektu vedou k chybám nebo zhroucení systému, lze objekt vždy vrátit do stavu, ve kterém byl před zahájením aktualizace.
Předpokládá se, že standardy CORBA by měly obsahovat definice rozhraní pro širokou škálu komponent, které lze použít při vytváření distribuovaných aplikací. Tyto komponenty mohou být vertikální nebo horizontální. Vertikální komponenty jsou navrženy speciálně pro specifické aplikace. Jak již bylo uvedeno, na vývoji definic těchto složek se podílelo mnoho odborníků z různých oblastí činnosti. Horizontální komponenty jsou obecné, jako jsou komponenty uživatelského rozhraní.

V době psaní této knihy již byly specifikace součástí vyvinuty, ale ještě nebyly dohodnuty. Z mého pohledu je to pravděpodobně místo, kde jsou standardy CORBA nejslabší, a může trvat několik let, než se dostanete do bodu, kdy jsou k dispozici specifikace i implementace komponent.
KLÍČOVÉ KONCEPTY
Všechny velké systémy Do jisté míry jsou distribuované, ve kterých jsou softwarové komponenty spouštěny na skupině procesorů integrovaných do sítě.

Distribuované systémy mají následující vlastnosti: využití zdrojů, otevřenost, souběžnost, škálovatelnost, tolerance chyb a průhlednost.

Systémy klient/server jsou distribuovány. Takové systémy jsou modelovány jako sada služeb poskytovaných serverem klientským procesům.

V systému klient/server je uživatelské rozhraní na straně klienta a správa dat je vždy udržována na sdíleném serveru. Aplikační funkce mohou být implementovány na klientském počítači nebo na serveru.

V architektuře distribuovaných objektů neexistuje žádný rozdíl mezi klienty a servery. Objekty poskytují základní služby, které mohou volat jiné objekty. Stejný přístup lze použít při implementaci systémů klient/server.

Distribuované objektové systémy musí mít middleware navržený tak, aby zpracovával interakce mezi objekty a přidával nebo odebíral objekty ze systému. Koncepčně lze middleware chápat jako softwarovou sběrnici, ke které jsou připojeny objekty.

Standardy CORBA jsou souborem standardů pro middleware, který podporuje architekturu distribuovaných objektů. Patří mezi ně objektový model, zprostředkovatel požadavků na objekt a definice sdílených služeb. V současné době existuje několik implementací standardů CORBA.
Cvičení
11.1. Vysvětlete, proč jsou distribuované systémy vždy škálovatelnější než centralizované. Jaký je pravděpodobný limit škálovatelnosti softwarového systému?

11.2. Jaký je hlavní rozdíl mezi modely tlustého a tenkého klienta při vývoji klient/server? Vysvětlete, proč použití Javy jako implementačního jazyka vyhlazuje rozdíly mezi těmito modely?

11.3. Na základě aplikačního modelu znázorněného na obr. Na obrázku 11.4 zvažte potenciální problémy, které mohou nastat při převodu sálového systému zdravotní péče z 80. let na systém klient/server.

11.4. Distribuované systémy založené na modelu klient/server se vyvíjejí od 80. let 20. století, ale teprve nedávno byly implementovány systémy založené na distribuovaných objektech. Uveďte tři důvody, proč se tak stalo.

11.5. Vysvětlete, proč používání distribuovaných objektů ve spojení s zprostředkovatelem požadavků na objekty usnadňuje implementaci škálovatelných systémů klient/server. Svou odpověď ilustrujte příkladem.

11.6. Jak se IDL používá k podpoře komunikace mezi objekty implementovanými v různých programovacích jazycích? Vysvětlete, proč tento přístup může způsobit problémy s výkonem, pokud existují drastické rozdíly mezi jazyky použitými k implementaci objektů.

11.7. Jaké základní vybavení by měl zprostředkovatel žádosti o objekt poskytovat?

11.8. Lze prokázat, že vývoj norem CORBA pro horizontální a vertikální komponenty omezuje konkurenci. Pokud jsou již vytvořeny a přizpůsobeny, brání to menším společnostem ve vývoji lepších komponent. Diskutujte o roli standardizace při udržování nebo omezování konkurence na softwarovém trhu.

• Překlad

Do Uberu jsem nastoupil před dvěma lety jako mobilní vývojář s určitými zkušenostmi z back-endového vývoje. Zde jsem vyvíjel platební funkcionalitu v aplikaci – a po cestě přepisoval samotnou aplikaci. Poté jsem přešel do vedení vývoje a vedl tým samotný. Díky tomu jsem mohl mnohem blíže poznat backend, protože můj tým je zodpovědný za mnoho našich backendových systémů, které umožňují platby.

Před mým působením v Uberu jsem neměl žádné zkušenosti s distribuovanými systémy. Získal jsem tradiční vzdělání v oboru výpočetní techniky, po kterém jsem pracoval tucet let ve fullstackovém vývoji. Proto, i když jsem mohl kreslit různé diagramy a mluvit o kompromisech ( kompromisy) v systémech jsem do té doby dostatečně nechápal a nevnímal pojmy distribuce - jako je například konzistence ( konzistence), dostupnost ( dostupnost) nebo idempotence ( idempotence).

V tomto příspěvku se budu věnovat několika konceptům, které jsem se potřeboval naučit a uvést do praxe při budování rozsáhlého, vysoce dostupného systému distribuovaných plateb, který dnes Uber provozuje. Jedná se o systém se zátěží až několik tisíc požadavků za sekundu, ve kterém musí správně fungovat kritická platební funkce i v případech, kdy některé části systému přestanou fungovat.

Je toto úplný seznam? S největší pravděpodobností ne. Kdybych se však o těchto pojmech dozvěděl dříve, velmi by mi to usnadnilo život.

Začněme tedy s naším ponorem do SLA, konzistence, trvanlivosti dat, perzistence zpráv, idempotence a některých dalších věcí, které jsem se potřeboval naučit ve své nové práci.

SLA

• Dostupnost: procento času, kdy je služba aktivní. I když existuje pokušení dosáhnout 100% dostupnosti, dosažení tohoto výsledku může být opravdu obtížné a velmi nákladné. Dokonce i velké a kritické systémy, jako je síť karet VISA, Gmail nebo poskytovatelé internetových služeb, nemají 100% dostupnost – v průběhu let nashromáždí sekundy, minuty nebo hodiny strávené v prostojích. U mnoha systémů se za vysokou dostupnost považuje dostupnost čtyř devítek (99,99 %, neboli asi 50 minut výpadku za rok). Abyste se dostali na tuto úroveň, musíte se pořádně zapotit.
• Přesnost: Je přijatelná ztráta dat nebo nepřesnost? Pokud ano, jaké procento je přijatelné? U platebního systému, na kterém jsem pracoval, muselo být toto číslo 100 %, protože neexistoval způsob, jak ztratit data.
• Šířka pásma/výkon (kapacita): jakou zátěž by měl systém vydržet? Tato metrika se obvykle vyjadřuje v počtu požadavků za sekundu.
• Latence: jak dlouho by měl systém reagovat? Jak dlouho by mělo být vyřízeno 95 % a 99 % žádostí? V takových systémech je obvykle mnoho požadavků „šum“, takže zpoždění p95 a p99 je větší praktické využití ve skutečném světě.

Horizontální a vertikální škálování

Horizontální škálování je o přidání více strojů (nebo uzlů) do systému pro zvýšení propustnosti ( kapacita). Horizontální škálování je nejoblíbenější způsob škálování distribuovaných systémů.

Vertikální škálování je v podstatě „kupte si větší/silnější stroj“ – (virtuální) stroj s více jádry, lepší výpočetní výkon a více paměti. V případě distribuovaných systémů je škálování obvykle méně populární, protože může být dražší než horizontální škálování. Některé známé velké weby, jako Stack Overflow, však úspěšně vertikálně škálovaly, aby odpovídaly zatížení.

Proč má škálovací strategie smysl, když budujete velký platební systém? Brzy jsme se rozhodli, že vybudujeme systém, který se bude horizontálně škálovat. Ačkoli je vertikální škálování v některých případech přijatelné, náš platební systém již v té době dosáhl svého předpokládaného zatížení a byli jsme pesimističtí ohledně předpokladu, že jediný super drahý sálový počítač by toto zatížení zvládl dnes, natož v budoucnu. Kromě toho bylo v našem týmu několik lidí, kteří pracovali pro velké poskytovatele platebních služeb a měli špatné zkušenosti se snahou vertikálně škálovat i na těch nejvýkonnějších strojích, které si v těch letech za peníze mohly koupit.

Konzistence

Konzistence je klíčovou otázkou ve vysoce dostupných systémech. Systém je konzistentní, pokud všechny uzly vidí a vracejí stejná data ve stejnou dobu. Na rozdíl od našeho předchozího modelu, kdy jsme přidali více uzlů, abychom dosáhli větší dostupnosti, není zdaleka triviální zajistit, aby systém zůstal konzistentní. Aby bylo zajištěno, že každý uzel obsahuje stejné informace, musí si navzájem posílat zprávy, aby byly neustále synchronizovány. Zprávy, které si vzájemně posílají, však nemusí být doručeny – mohou se ztratit a některé z uzlů mohou být nedosažitelné.

Konzistence je koncept, který mi zabralo nejvíce času, než jsem ho pochopil, než jsem ho pochopil a ocenil. Existuje několik typů konzistence, nejrozšířenější v distribuovaných systémech je silná konzistence ( silná konzistence), slabá konzistence ( slabá konzistence) a konečná konzistence ( případná konzistence). Užitečný praktický rozbor výhod a nevýhod každého z modelů si můžete přečíst v tomto článku. Obecně platí, že čím slabší je požadovaná úroveň konzistence, tím rychleji může systém běžet – ale tím je pravděpodobnější, že nevrátí nejnovější sadu dat.

Proč by se měla při budování velkého platebního systému brát v úvahu důslednost? Data v systému musí být konzistentní. Ale jak konzistentní? Pro některé části systému budou stačit pouze vysoce konzistentní data. Potřebujeme například vysoce konzistentním způsobem uchovávat informace o tom, že byla zahájena platba. U ostatních částí systému, které nejsou tak důležité, lze konzistenci nakonec považovat za rozumný kompromis.

Výstup seznamu nedávných transakcí to dobře ilustruje: lze je implementovat pomocí konzistence ( případná konzistence) - to znamená, že poslední transakce se může objevit v některých částech systému až o nějaký čas později, ale díky tomu dotaz na seznam vrátí výsledek s menším zpožděním nebo vyžaduje méně prostředků na provedení.

Trvanlivost dat

Různé distribuované databáze mají různé úrovně trvanlivosti dat. Někteří z nich podporují trvanlivost dat na úrovni počítače/uzlu, jiné to dělají na úrovni clusteru a některé tuto funkci neposkytují vůbec. Ke zvýšení trvanlivosti se obvykle používá určitá forma replikace – pokud jsou data uložena ve více uzlech a jeden z uzlů selže, data budou stále dostupná. , vysvětlující, proč může být dosažení trvanlivosti v distribuovaných systémech vážnou výzvou.

Proč při budování platebního systému záleží na trvanlivosti dat? Pokud jsou data kritická (například platby), nemůžeme si dovolit o ně přijít v mnoha částech našeho systému. Distribuovaná datová úložiště, která jsme vytvořili, musela podporovat trvanlivost dat na úrovni clusteru – takže i když instance selhaly, dokončené transakce přetrvávaly. V současnosti většina distribuovaných služeb úložiště – jako Cassandra, MongoDB, HDFS nebo Dynamodb – všechny podporuje trvanlivost na různých úrovních a všechny lze nakonfigurovat tak, aby poskytovaly odolnost na úrovni clusteru.

Stálost a trvanlivost zpráv

V případě distribuovaných systémů, zasílání zpráv ( zasílání zpráv) se obvykle provádí pomocí nějaké distribuované služby zasílání zpráv - RabbitMQ, Kafka nebo jiné. Tito zprostředkovatelé zpráv mohou podporovat (nebo jsou nakonfigurováni pro podporu) různé úrovně spolehlivost doručení zpráv.

Přetrvávání zprávy znamená, že když uzel zpracovávající zprávu selže, zpráva bude po vyřešení problému stále k dispozici pro zpracování. Trvanlivost zpráv se běžně používá na úrovni fronty zpráv. S trvalou frontou zpráv platí, že pokud fronta (nebo uzel) přejde při odeslání zprávy do režimu offline, zprávu přesto obdrží, když se vrátí do režimu online. Dobrý podrobný článek Tento problém k dispozici prostřednictvím odkazu.


Proč je při budování velkých platebních systémů důležitá bezpečnost a trvanlivost zpráv? Měli jsme zprávy, které jsme si nemohli dovolit ztratit – například zprávu, že člověk inicioval platbu za zájezd. To znamenalo, že systém zasílání zpráv, který jsme měli používat, musel být bezztrátový: každá zpráva musela být doručena jednou. Nicméně vytvoření systému, který doručí každou zprávu hladký jednou než alespoň jednou - to jsou úkoly, které se výrazně liší svou obtížností. Rozhodli jsme se implementovat systém zasílání zpráv, který doručuje alespoň jednou, a zvolili jsme sběrnici zpráv ( sběrnice zpráv), na jehož vrcholu jsme se rozhodli jej postavit (zvolili jsme Kafku, čímž jsme vytvořili bezztrátový cluster, což bylo v našem případě vyžadováno).

Idempotence

Návrh idempotentních distribuovaných systémů vyžaduje určitou strategii distribuovaného zamykání. Zde vstupují do hry koncepty, o kterých jsme hovořili dříve. Řekněme, že máme v úmyslu implementovat idempotenci pomocí optimistického zamykání, abychom se vyhnuli souběžným aktualizacím. Abychom se mohli uchýlit k optimistickému zamykání, musí být systém silně konzistentní – abychom za běhu mohli zkontrolovat, zda nezačala jiná operace pomocí nějaké formy verzování.

Existuje mnoho způsobů, jak dosáhnout idempotence, a jakákoli konkrétní volba bude záviset na omezeních systému a typu prováděné operace. Navrhování idempotentních přístupů je pro vývojáře důstojnou výzvou – stačí se podívat na příspěvky Bena Nadela, kde hovoří o různých strategiích, které použil, které zahrnují jak distribuované zámky, tak omezení ( omezení) Databáze. Když navrhujete distribuovaný systém, idempotence může být snadno jednou z částí, které jste přehlédli. V naší praxi jsme se setkali s případy, kdy můj tým „vyhořel“, že nebyl přesvědčen o správné idempotenci u některých klíčových operací.

Proč při budování velkého platebního systému záleží na idempotenci? A co je nejdůležitější: vyhnout se dvojímu účtování a dvojímu vrácení peněz. Vzhledem k tomu, že náš systém zasílání zpráv má doručení „alespoň jednou, bez ztráty“, musíme předpokládat, že všechny zprávy mohou být doručeny vícekrát a systémy musí zaručit idempotenci. Rozhodli jsme se to řešit pomocí verzování a optimistického zamykání, kdy naše systémy implementují idempotentní chování pomocí silně konzistentního úložiště jako zdroje dat.

Sharding a kvorum

Mnoho distribuovaných systémů má data nebo výpočty, které jsou replikovány napříč více uzly. Aby bylo zajištěno, že operace jsou prováděny konzistentním způsobem, je definován přístup hlasování, ve kterém, aby byla operace považována za úspěšnou, je nutné, aby určitý počet uzlů obdržel stejný výsledek. Tento proces se nazývá kvorum.

Proč má při budování velkého platebního systému v Uberu smysl kvorum a sharding? Oba tyto koncepty jsou jednoduché a používají se téměř všude. Setkal jsem se s nimi, když jsme nastavili replikaci v Cassandře. Cassandra (a další distribuované systémy) používají kvorum a místní kvorum ( místní kvorum), aby byla zajištěna konzistence mezi shluky.

Herec Model

Herecký model je založen na hercích, kteří si posílají zprávy a odpovídají na ně. Každý herec může dělat omezený soubor věcí – vytvářet další herce, posílat zprávy ostatním nebo se rozhodnout, co udělá s další zprávou. S pomocí několika jednoduchá pravidla, můžeme docela dobře popsat složité distribuované systémy, které se dokážou samy obnovit poté, co aktér „spadne“. Pokud tento přístup neznáte, pak vám článek doporučuji

Často je při definování distribuovaného systému v popředí rozdělení jeho funkcí mezi více počítačů. S tímto přístupem jakékoli výpočetní systém kde je zpracování dat sdíleno mezi dvěma nebo více počítači. Poněkud úžeji distribuovaný systém lze na základě definice E. Tanenbauma definovat jako soubor nezávislých počítačů propojených komunikačními kanály, které z pohledu uživatele nějakého softwaru vypadají jako jeden celek.

Tento přístup k definování distribuovaného systému má své nevýhody. Například vše, co se v takovém distribuovaném systému používá software by mohl fungovat na jednom počítači, nicméně z pohledu výše uvedené definice již takový systém distribuován nebude. Koncepce distribuovaného systému by proto měla být pravděpodobně založena na analýze softwaru, který takový systém tvoří.

Jako základ pro popis interakce dvou entit uvažujme obecný model interakce klient-server, ve kterém jedna ze stran (klient) iniciuje výměnu dat odesláním požadavku na druhou stranu (server). Server požadavek zpracuje a v případě potřeby odešle klientovi odpověď (obrázek 1.1).

Rýže. 1.1.

Interakce v rámci modelu klient-server může být buď synchronní, kdy klient čeká, až server dokončí zpracování svého požadavku, nebo asynchronní, kdy klient odešle požadavek na server a pokračuje v jeho provádění, aniž by čekal na odpověď serveru. Model klienta a serveru lze použít jako základ pro popis různých interakcí. Pro tento kurz je důležitá interakce komponent softwaru, který tvoří distribuovaný systém.

Zvažte některé typická aplikace, které lze v souladu s moderními představami rozdělit do následujících logických úrovní (obr. 1.2): uživatelské rozhraní(IP), aplikační logika (LP) a datový přístup (DD) pracující s databází (DB). Uživatel systému s ním komunikuje prostřednictvím uživatelského rozhraní, databáze ukládá data popisující předmět aplikace a aplikační logická vrstva implementuje všechny algoritmy související s aplikací. předmětová oblast.

Vzhledem k tomu, že v praxi mají různí uživatelé systému obvykle zájem o přístup ke stejným datům, nejjednodušším oddělením funkcí takového systému mezi několik počítačů bude oddělení logických úrovní aplikace mezi jednu serverovou část odpovědné aplikace. pro přístup k datům a klientským částem umístěným na několika počítačích, implementující uživatelské rozhraní. Aplikační logiku lze přiřadit serveru, klientům nebo mezi ně rozdělit (obr. 1.3).

Architektura aplikací postavených na tomto principu se nazývá klient-server nebo dvouvrstvá. V praxi takové systémy často nejsou klasifikovány jako distribuované systémy, ale formálně je lze považovat za nejjednodušší zástupce distribuovaných systémů.

Vývoj architektury klient-server je třívrstvá architektura, ve které jsou uživatelské rozhraní, aplikační logika a přístup k datům rozděleny do nezávislých komponent systému, které mohou běžet na nezávislých počítačích (obr. 1.4).

Požadavek uživatele v takových systémech postupně zpracovává klientská část systému, server aplikační logiky a databázový server. Distribuovaným systémem se však obvykle rozumí systémy se složitější architekturou než je třívrstvá.