• Prenos

Do spoločnosti Uber som nastúpil pred dvoma rokmi ako mobilný vývojár s určitými skúsenosťami s backendom. Tu som vyvíjal platobnú funkcionalitu v aplikácii - a popri tom som prepísal samotnú aplikáciu. Potom som prešiel k vývojovému manažmentu a viedol som samotný tím. Vďaka tomu som sa mohol oveľa viac zoznámiť s backendom, pretože môj tím je zodpovedný za veľa našich backendových systémov, ktoré umožňujú platby.

Pred nástupom do Uberu som nemal žiadne skúsenosti s distribuovanými systémami. Dostal som tradičné vzdelanie v odbore informatiky, po ktorom som tucet rokov vyvíjal vývoj v celom zásobníku. Preto by som síce mohol nakresliť rôzne diagramy a hovoriť o kompromisoch ( kompromisy) v systémoch som do tej doby dostatočne nepochopil a nevnímal pojmy distribúcia - napríklad ako konzistencia ( dôslednosť), dostupnosť ( dostupnosť) alebo idempotencia ( idempotencia).

V tomto príspevku budem hovoriť o niekoľkých konceptoch, ktoré som sa musel naučiť a uplatniť v praxi pri budovaní rozsiahleho a vysoko dostupného distribuovaného platobného systému, ktorý v súčasnosti beží na Uberi. Jedná sa o systém so záťažou až niekoľko tisíc požiadaviek za sekundu, v ktorom musí kritická funkčnosť platieb fungovať správne aj v prípadoch, keď určité časti systému prestanú fungovať.

Je to úplný zoznam? Pravdepodobne nie. Keby som sa však osobne o týchto konceptoch dozvedel už skôr, uľahčilo by mi to život.

Poďme teda na náš ponor do SLA, konzistencie, trvanlivosti dát, integrity správ, idempotencie a niekoľkých ďalších vecí, ktoré som sa musel pri svojej novej práci naučiť.

SLA

Vo veľkých systémoch, ktoré spracúvajú milióny udalostí za deň, sa niektoré veci musia definitívne pokaziť. Preto je najdôležitejším krokom pred ponorom do plánovania systému rozhodnutie, čo pre nás znamená „zdravý“ systém. Miera „zdravia“ by mala byť niečím vlastne dá sa zmerať. Všeobecne akceptovaným spôsobom merania „zdravia“ systému je SLA ( dohody o úrovni služieb). Tu uvádzam niektoré z najbežnejších typov SLA, s ktorými som sa v praxi stretol:

• Dostupnosť: Percento času, počas ktorého je služba aktívna. Aj keď môže byť lákavé dosiahnuť 100% dostupnosť, dosiahnutie tohto výsledku môže byť skutočne náročné a nákladné. Ani veľké a kritické systémy ako sieť kariet VISA, poskytovatelia Gmailu alebo internetu nie sú stopercentne k dispozícii - v priebehu rokov budú hromadiť sekundy, minúty alebo hodiny strávené v prestojoch. U mnohých systémov sa dostupnosť štyroch deviatich zariadení (99,99%, tj. Zhruba 50 minút výpadku ročne) považuje za vysokú dostupnosť. Aby ste sa dostali na túto úroveň, musíte sa poriadne zapotiť.
• Presnosť: je strata údajov prijateľná alebo nepresná? Ak áno, aké percento je prijateľné? Pre platobný systém, na ktorom som pracoval, mal byť tento údaj 100%, pretože neexistoval spôsob, ako prísť o dáta.
• Kapacita / kapacita: Aká záťaž by mal systém vydržať? Táto metrika je zvyčajne vyjadrená v požiadavkách za sekundu.
• Latencia: ako dlho má systém reagovať? Ako dlho by malo byť vybavených 95% a 99% požiadaviek? V takýchto systémoch je veľa otázok zvyčajne „šumových“, takže latencie p95 a p99 sú v reálnom svete praktickejšie.

Prečo sú pri vytváraní veľkého platobného systému potrebné zmluvy SLA? Vytvárame nový systém, ktorý nahradí ten súčasný. Aby sme zaistili, že robíme všetko dobre a že náš nový systém bude „lepší“ ako jeho predchodca, na definovanie našich očakávaní sme použili SLA. Prístupnosť bola jednou z najdôležitejších požiadaviek. Keď sme už mali cieľ, potrebovali sme sa vyrovnať s architektonickými kompromismi, aby sme dosiahli tieto metriky.

Horizontálne a vertikálne škálovanie

S rastom podnikania pomocou nášho novo vytvoreného systému sa jeho zaťaženie iba zvýši. Existujúca inštalácia v určitom okamihu nebude schopná vydržať ďalšie zvyšovanie zaťaženia a budeme musieť zvýšiť prípustné zaťaženie. Dve bežné stratégie škálovania sú vertikálne alebo horizontálne škálovanie.

Pri škálovaní ide o pridanie ďalších strojov (alebo uzlov) do systému s cieľom zvýšiť priepustnosť ( kapacita). Škálovanie je najpopulárnejším spôsobom škálovania distribuovaných systémov.

Škálovanie je v podstate „kúpte si väčší / silnejší stroj“ - (virtuálny) stroj s väčším počtom jadier, lepšou výpočtovou silou a väčšou pamäťou. V prípade distribuovaných systémov je vertikálne škálovanie zvyčajne menej populárne, pretože môže byť nákladnejšie ako horizontálne škálovanie. Niektoré známe veľké weby ako Stack Overflow sa však úspešne zmenšili vertikálne, aby sa prispôsobili pracovnému zaťaženiu.

Prečo má stratégia škálovania zmysel, keď budujete veľký platobný systém? Skoro sme sa rozhodli, že postavíme systém, ktorý bude mať horizontálne mierky. Napriek tomu, že v niektorých prípadoch je možné použiť vertikálne škálovanie, náš platobný systém už v tom čase dosiahol plánované zaťaženie a my sme boli pesimistickí, pokiaľ ide o predpoklad, že jediný superdrahý mainframe dokáže toto zaťaženie vydržať dnes, nehovoriac o budúcnosti ... Okrem toho bolo v našom tíme niekoľko ľudí, ktorí pracovali pre veľkých poskytovateľov platobných služieb a mali negatívne skúsenosti so snahou vertikálne škálovať aj na najvýkonnejších strojoch, ktoré si za tie roky mohli kúpiť.

Dôslednosť

Dostupnosť ktoréhokoľvek zo systémov je dôležitá. Distribuované systémy sa často vyrábajú zo strojov, ktorých individuálna dostupnosť je nižšia ako dostupnosť celého systému. Našim cieľom je vybudovať systém s 99,999% dostupnosťou (doba výpadku je približne 5 minút ročne). Používame stroje / uzly, ktoré majú priemernú dostupnosť 99,9% (sú to výpadky približne 8 hodín / rok). Priamym spôsobom, ako dosiahnuť požadovaný indikátor dostupnosti, je pridať do klastra niekoľko ďalších takýchto strojov / uzlov. Aj keď sú niektoré z uzlov mimo prevádzky, iné budú naďalej funkčné a celková dostupnosť systému bude vyššia ako dostupnosť jeho jednotlivých komponentov.

Konzistentnosť je kľúčovým problémom vysoko dostupných systémov. Systém je konzistentný, ak všetky uzly vidia a vracajú rovnaké údaje súčasne. Na rozdiel od nášho predchádzajúceho modelu, kde sme pridali viac uzlov, aby sme dosiahli vyššiu dostupnosť, zaistenie konzistentnosti systému nie je ani zďaleka triviálne. Aby sa zabezpečilo, že každý uzol obsahuje rovnaké informácie, musia si navzájom posielať správy, aby boli neustále synchronizované. Správy, ktoré si navzájom posielajú, sa však nemusia doručiť - môžu sa stratiť a niektoré uzly môžu byť nedostupné.

Konzistentnosť je koncept, ktorý mi trval najviac času, kým som ho pochopil a ocenil. Existuje niekoľko druhov konzistencie, v distribuovaných systémoch sa najčastejšie používa silná konzistencia ( silná konzistencia), slabá konzistencia ( slabá konzistencia) a nakoniec konzistencia ( prípadná konzistencia). Užitočné praktické rozdelenie výhod a nevýhod jednotlivých modelov si môžete prečítať v tomto článku. Spravidla platí, že čím slabšia požadovaná úroveň konzistencie, tým rýchlejší systém môže bežať - ale je pravdepodobnejšie, že nevráti najnovšiu množinu údajov.

Prečo by sa pri budovaní veľkého platobného systému mala brať do úvahy dôslednosť? Údaje v systéme musia byť konzistentné. Ale ako dôsledne? V niektorých častiach systému budú fungovať iba vysoko konzistentné údaje. Potrebujeme napríklad uchovať vo veľmi konzistentnej forme informácie o tom, že platba bola iniciovaná. V prípade ostatných častí systému, ktoré nie sú také dôležité, možno konzistenciu v konečnom dôsledku považovať za rozumný kompromis.

Dobre to ilustruje zoznam posledných transakcií: môžu sa implementovať v konečnom dôsledku konzistentnosťou ( prípadná konzistencia) - to znamená, že posledná transakcia sa môže v niektorých častiach systému objaviť až o nejaký čas neskôr, ale kvôli tomu vráti zoznamový dopyt výsledok s menším oneskorením alebo vyžaduje menej zdrojov na vykonanie.

Trvanlivosť údajov

Dlhovekosť znamená, že keď sa dáta úspešne pridajú do dátového skladu, budú nám k dispozícii v budúcnosti. Bude to platiť aj v prípade, že uzly systému prejdú do režimu offline, zlyhajú alebo dôjde k poškodeniu údajov uzlov.

Rôzne distribuované databázy majú rôznu úroveň trvanlivosti údajov. Niektoré z nich podporujú trvanlivosť údajov na úrovni stroja / uzla, iné to robia na úrovni klastra a niektoré túto funkciu po vybalení z krabice vôbec neposkytujú. Na predĺženie životnosti sa zvyčajne používa určitá forma replikácie - ak sú údaje uložené na viacerých uzloch a jeden z uzlov prestane fungovať, budú stále k dispozícii. vysvetlenie, prečo môže byť dosiahnutie dlhovekosti v distribuovaných systémoch veľkou výzvou.

Prečo pri budovaní platobného systému záleží na trvanlivosti údajov? Ak sú údaje kritické (napríklad sú to platby), nemôžeme si dovoliť ich stratiť v mnohých častiach nášho systému. Distribuované dátové úložiská, ktoré sme vytvorili, museli udržiavať životnosť dát na úrovni klastra - takže aj keby došlo k zlyhaniu inštancií, dokončené transakcie budú pretrvávať. V dnešnej dobe väčšina distribuovaných úložných služieb - ako Cassandra, MongoDB, HDFS alebo Dynamodb - podporuje odolnosť na rôznych úrovniach a všetky je možné nakonfigurovať tak, aby poskytovala odolnosť na úrovni klastra.

Vytrvalosť a trvanlivosť správy

Uzly v distribuovaných systémoch vykonávajú výpočty, ukladajú údaje a navzájom si posielajú správy. Kľúčovou charakteristikou odosielania správ je to, ako spoľahlivo tieto správy prichádzajú. Pre systémy kritické pre misiu často existuje požiadavka, aby sa nestratila žiadna zo správ.

V prípade distribuovaných systémov zasielanie správ ( zasielanie správ) sa zvyčajne vykonáva pomocou nejakej služby distribuovaných správ - RabbitMQ, Kafka alebo iných. Títo sprostredkovatelia správ môžu podporovať (alebo môžu byť nakonfigurovaní tak, aby podporovali) rôzne úrovne spoľahlivosti doručovania správ.

Trvalosť správy znamená, že keď dôjde k zlyhaniu v uzle, ktorý spracováva správu, správa bude po vyriešení problému stále k dispozícii na spracovanie. Trvanlivosť správy sa bežne používa na úrovni frontu správ. V prípade frontu správ s dlhou životnosťou, ak sa front (alebo uzol) po odoslaní správy prepne do režimu offline, bude ju stále prijímať, keď sa vráti späť do režimu online. Dobrý podrobný článok o tejto téme je k dispozícii tu.


Prečo pri budovaní veľkých platobných systémov záleží na bezpečnosti a trvanlivosti správ? Mali sme správy, ktoré sme si nemohli dovoliť stratiť - napríklad správu, že človek inicioval platbu za zaplatenie cesty. To znamenalo, že systém správ, ktorý sme mali používať, musel fungovať bez strát: každá správa musela byť doručená raz. Vytváranie systému, ktorý však doručuje každú správu hladký skôr raz ako najmenej raz - to sú úlohy, ktoré sa výrazne líšia svojou náročnosťou. Rozhodli sme sa implementovať systém správ, ktorý dodáva aspoň raz, a vybrali sme zbernicu správ ( zbernica správ), navyše sme sa rozhodli ju postaviť (rozhodli sme sa pre Kafku a vytvorili sme bezstratový klaster, ktorý bol v našom prípade potrebný).

Idempotencia

V prípade distribuovaných systémov sa môže pokaziť čokoľvek - spojenie môže upadnúť uprostred alebo môže časový limit vypršať. Zákazníci budú tieto požiadavky často opakovať. Idempotentný systém zaisťuje, že bez ohľadu na to, čo sa stane, a bez ohľadu na to, koľkokrát sa konkrétna požiadavka vykoná, dôjde k skutočnému vykonaniu tejto žiadosti iba raz. Dobrým príkladom je uskutočnenie platby. Ak klient požiada o platbu, žiadosť je úspešná, ale ak klientovi vypršal časový limit, môže opakovať rovnakú žiadosť. V prípade idempotentného systému nebude osobe, ktorá uskutočňuje platbu, účtované poplatky dvakrát; ale pre neidemponetový systém je to celkom možný jav.

Návrh idempotentných distribuovaných systémov vyžaduje istý druh stratégie distribuovaného uzamykania. Tu vstupujú do hry koncepty, o ktorých sme hovorili skôr. Povedzme, že máme v úmysle implementovať idempotenciu pomocou optimistického zamykania, aby sme sa vyhli súbežným aktualizáciám. Aby sme sa mohli uchýliť k optimistickému uzamknutiu, musí byť systém prísne konzistentný - aby sme počas vykonávania operácie mohli skontrolovať, či už začala iná operácia, a to pomocou nejakej formy riadenia verzií.

Existuje veľa spôsobov, ako dosiahnuť idempotenciu, a každá konkrétna voľba bude závisieť od obmedzení systému a typu vykonávanej operácie. Navrhovanie idempotentných prístupov je pre vývojárov dôstojnou výzvou - stačí sa pozrieť na príspevky Bena Nadela, kde hovorí o rôznych stratégiách, ktoré použil, medzi ktoré patria distribuované zámky aj obmedzenia ( obmedzenia) Databáza. Pri navrhovaní distribuovaného systému môže byť idempotencia ľahko jednou z častí, ktoré ste prehliadli. V našej praxi sme sa stretli s prípadmi, keď sa môj tím „popálil“ tým, že nebol presvedčený o správnej idempotencii pre niektoré kľúčové operácie.

Prečo pri budovaní veľkého platobného systému záleží na idempotencii? Najdôležitejšie: vyhnúť sa dvojitým poplatkom a dvojitému vráteniu peňazí. Vzhľadom na to, že náš systém správ má najmenej jedno bezstratové doručenie, musíme predpokladať, že všetky správy je možné doručiť viackrát a systémy musia zaručovať nedôverčivosť. Rozhodli sme sa to vyriešiť verziou a optimistickým zamykaním, kde naše systémy implementujú idempotentné správanie pomocou silne konzistentného úložiska ako svojho zdroja údajov.

Črepovanie a kvórum

Distribuované systémy musia často uchovávať oveľa viac údajov, ako si môže dovoliť jeden uzol. Ako teda uložíme množinu údajov na správny počet počítačov? Najobľúbenejšou technikou je črepovanie. Dáta sú horizontálne rozdelené pomocou hashu priradeného k oddielu. Zatiaľ čo dnes veľa distribuovaných databáz implementuje tzv. „Sharding“ pod kapotou, samotné rozdelenie je zaujímavá téma, ktorú stojí za preskúmanie - najmä resharding. V roku 2010 mal Foursquare 17-hodinový výpadok v dôsledku incidentu s delením okrajov, po ktorom sa spoločnosť podelila, a objasnila podstatu problému.

Mnoho distribuovaných systémov obsahuje dáta alebo výpočty, ktoré sa replikujú na viacerých uzloch. Aby sa zabezpečilo, že transakcie sa vykonávajú konzistentným spôsobom, je definovaný prístup k hlasovaniu, pri ktorom určitý počet uzlov musí dostať rovnaký výsledok, aby sa operácia mohla považovať za úspešnú. Tento proces sa nazýva kvórum.

Prečo má kvórum a rozdelenie zmysel pri budovaní veľkého platobného systému v spoločnosti Uber? Oba tieto pojmy sú jednoduché a používajú sa takmer univerzálne. Stretol som ich, keď sme nastavovali replikáciu v Cassandre. Cassandra (a ďalšie distribuované systémy) používa kvórum a miestne kvórum ( miestne kvórum), aby sa zabezpečila konzistencia medzi klastrami.

Herecký model

Známa slovná zásoba, ktorú používame na opis programovacích postupov - napríklad premenné, rozhrania, volania metód - predpokladá systémy z jedného počítača. Keď hovoríme o distribuovaných systémoch, musíme použiť iné prístupy. Bežným spôsobom opisu takýchto systémov je herecký model, v rámci ktorého vidíme kód z hľadiska komunikácie. Tento model je populárny, pretože sa zhoduje s mentálnym modelom toho, ako si predstavujeme napríklad interakciu ľudí v organizácii. Ďalším, nemenej populárnym spôsobom popisu distribuovaných systémov je CSP, interagujúci so sekvenčnými procesmi.

Herecký model je založený na hercoch, ktorí si navzájom posielajú správy a odpovedajú na ne. Každý herec môže robiť obmedzený súbor vecí - vytvárať ďalších aktérov, posielať správy ostatným alebo sa rozhodnúť, čo s ďalšou správou. Pomocou niekoľkých jednoduchých pravidiel môžeme celkom dobre opísať zložité distribuované systémy, ktoré sa dokážu znovu vytvoriť po páde herca. Ak tento prístup nepoznáte, potom vám článok odporúčam

V súčasnosti majú všetky integrované obvody vyvinuté na komerčné účely distribuovanú architektúru, ktorá predpokladá použitie globálnych a / alebo lokálnych sietí.

Historicky bola architektúra súborového servera prvá, ktorá sa rozšírila, pretože jej logika je jednoduchá a je najjednoduchšie preniesť na takúto architektúru už používané IS. Potom sa transformovala do architektúry server-klient, ktorú možno interpretovať ako jej logické pokračovanie. Moderné systémy používané v globálnej sieti INTERNET sa týkajú hlavne architektúry distribuovaných objektov (pozri obr. III‑15 )

Je možné si predstaviť IS pozostávajúci z nasledujúcich komponentov (obr. III-16)

III.03.2. a Aplikácie súborového servera.

Je to historicky prvá distribuovaná architektúra (obr. III-17). Je to usporiadané veľmi jednoducho: na serveri sú iba údaje a všetko ostatné patrí klientskemu zariadeniu. Pretože miestne siete sú dosť lacné a vzhľadom na skutočnosť, že s takouto architektúrou je aplikačný softvér autonómny, dnes sa takáto architektúra často používa. Môžeme povedať, že ide o variant architektúry klient-server, v ktorej sa na serveri nachádzajú iba dátové súbory. Rôzne osobné počítače interagujú iba pomocou spoločného úložiska údajov, takže programy napísané pre jeden počítač sa najľahšie prispôsobia takejto architektúre.

Klady:

Výhody architektúry súborového servera:

Ľahkosť organizácie;

Neodporuje to potrebným požiadavkám na databázu na zachovanie integrity a spoľahlivosti.

Preťaženie siete;

Neočakávaná odpoveď na žiadosť.

Tieto nedostatky sa vysvetľujú skutočnosťou, že akákoľvek požiadavka na databázu vedie k prenosu po sieti k značnému množstvu informácií. Napríklad na výber jedného alebo viacerých riadkov z tabuliek sa celá tabuľka stiahne do klientskeho počítača a DBMS ich tam už vyberie. Významný sieťový prenos je obzvlášť plný organizácie vzdialeného prístupu k databáze.

III.03.2. b Aplikácie klient-server.

V takom prípade existuje rozdelenie zodpovedností medzi serverom a klientom. Podľa toho, ako sú oddelené, rozlišujte tučný a tenký klient.

V modeli tenkého klienta sa všetky práce s aplikáciami a správa údajov vykonávajú na serveri. Používateľské rozhranie v týchto systémoch „migruje“ do osobného počítača a samotná softvérová aplikácia vykonáva funkcie servera, t. prevádzkuje všetky aplikačné procesy a spravuje údaje. Model tenkého klienta je možné implementovať aj tam, kde sú klientmi počítače alebo pracovné stanice. Na sieťových zariadeniach je spustený internetový prehliadač a používateľské rozhranie implementované v systéme.

Hlavný nevýhoda modely tenkých klientov - vysoké zaťaženie servera a siete. Všetky výpočty sa vykonávajú na serveri, čo môže viesť k významnému sieťovému prenosu medzi klientom a serverom. V moderných počítačoch je dostatok výpočtového výkonu, ale v modeli / tenkom klientovi banky sa prakticky nepoužíva

Naproti tomu model hrubého klienta využíva výpočtový výkon miestnych strojov: samotná aplikácia je umiestnená na klientskom počítači. Príkladom tohto typu architektúry sú systémy ATM, v ktorých je ATM klient a server je centrálny počítač obsluhujúci databázu zákazníckych účtov.

III.03.2. c Dvoj- a trojvrstvová architektúra klient-server.

Všetky architektúry diskutované vyššie sú dvojstupňové. Líšia sa medzi úrovňou klienta a serverom. Presne povedané, IC sa skladá z troch logických úrovní:

· Používateľská úroveň;

Úroveň aplikácie:

· Dátová vrstva.

Preto v dvojúrovňovom modeli, kde sú zapojené iba dve úrovne, existujú problémy so škálovateľnosťou a výkonom, ak je zvolený model tenkého klienta, alebo problémy so správou systému, ak je zvolený model hrubého klienta. Týmto problémom je možné predísť aplikáciou modelu pozostávajúceho z troch úrovní, kde dvoma z nich sú servery (obr. III-21).

Dátový server

Aplikačný server a dátový server môžu byť v skutočnosti umiestnené na rovnakom stroji, ale nemôžu navzájom vykonávať svoje funkcie. Príjemné na trojvrstvovom modeli je, že logicky oddeľuje vykonávanie aplikácií a správu údajov.

Tabuľka III-5 Aplikácia rôznych typov architektúr

Architektúra	žiadosť
Dvojvrstvový tenký klient	1 Staršie systémy, kde nie je praktické oddeliť vykonávanie aplikácií a správu údajov. 2 Výpočtové aplikácie náročné na správu dát. 3 Aplikácie s veľkým objemom dát, ale s malým výpočtom.
Dvojstupňový hrubý klient	1 Aplikácie, kde používateľ vyžaduje intenzívne spracovanie údajov, t. J. Vizualizáciu údajov. 2 Aplikácie s relatívne konštantnou sadou používateľských funkcií aplikované na dobre spravované systémové prostredie.
Trojstupňový server-klient	1 Veľké aplikácie s bunkami a tisíckami klientov 2 Aplikácie, v ktorých sa často menia údaje aj metódy spracovania. 3 Aplikácie, ktoré integrujú údaje z viacerých zdrojov.

Tento model je vhodný pre mnoho typov aplikácií, ale obmedzuje vývojárov IS, ktorí sa musia rozhodnúť, kde budú poskytovať služby, poskytovať podporu škálovateľnosti a vyvíjať nástroje na spájanie nových zákazníkov.

III.03.2. d Distribuovaná objektová architektúra.

Všeobecnejší prístup poskytuje architektúra distribuovaných objektov, ktorých objekty sú hlavnými súčasťami. Poskytujú súbor služieb prostredníctvom svojich rozhraní. Ostatné objekty odosielajú požiadavky bez rozlišovania medzi klientom a serverom. Objekty môžu byť umiestnené na rôznych počítačoch v sieti a interagovať prostredníctvom middlewaru, podobne ako systémová zbernica, ktorá umožňuje pripojiť rôzne zariadenia a udržiavať komunikáciu medzi hardvérovými zariadeniami.

…

Správca ovládačov ODBC

Vodič 1

Vodič K

DB 1

DB K.

Práca s SQL

…

Architektúra ODBC obsahuje komponenty:

1. Aplikácia (napr. IS). Vykonáva úlohy: požaduje pripojenie k zdroju údajov, odosiela dotazy SQL do zdroja údajov, popisuje oblasť úložiska a formát pre dotazy SQL, spracováva chyby a upozorňuje na ne používateľa, zaväzuje alebo odvoláva transakcie, požaduje pripojenie k serveru Zdroj dát.

2. Správca zariadení. Načíta ovládače na požiadanie aplikácie, ponúka jediné rozhranie pre všetky aplikácie a administrátorské rozhranie ODBC je rovnaké a bez ohľadu na to, s ktorým DBMS bude aplikácia interagovať. Microsoft Driver Driver je dynamicky načítateľná DLL.

3. Ovládač závisí od systému DBMS. Ovládač ODBC je knižnica dynamických odkazov (DLL), ktorá implementuje funkcie ODBC a interaguje so zdrojom údajov. Ovládač je program, ktorý spracuje požiadavku na funkciu špecifickú pre DBMS (môže upravovať dotazy v súlade s DBMS) a vráti výsledok aplikácii. Každý DBMS, ktorý podporuje technológiu ODBC, musí vývojárom aplikácií poskytnúť ovládač pre tento DBMS.

4. Zdroj údajov obsahuje používateľom zadané kontrolné informácie, informácie o zdroji údajov a používa sa na prístup do konkrétneho systému DBMS. V tomto prípade sa používajú prostriedky OS a sieťovej platformy.

Dynamický model

Tento model predpokladá mnoho aspektov, ktoré sú reprezentované v jazyku UML pomocou minimálne 5 diagramov, viď str. 2,04,2 - 2,04,5.

Zvážte aspekt riadenia. Model riadenia dopĺňa štrukturálne modely.

Bez ohľadu na to, ako je opísaná štruktúra systému, pozostáva zo sady štruktúrnych jednotiek (funkcií alebo objektov). Aby mohli fungovať ako celok, musia byť spravovaní a v statických diagramoch nie sú žiadne kontrolné informácie. Kontrolné modely navrhujú tok kontroly medzi systémami.

V softvérových systémoch existujú dva hlavné typy ovládania.

1. Centralizované hospodárenie.

2. Správa založená na udalostiach.

Centralizované riadenie môže byť:

· Hierarchické - na základe princípu „spätného volania“ (takto najčastejšie fungujú vzdelávacie programy)

· Model dispečeraktorý sa používa pre paralelné systémy.

IN modely dispečerov predpokladá sa, že jednou zo súčastí systému je dispečer. Spravuje spustenie aj vypnutie systémov a koordináciu zvyšku systému. Procesy môžu prebiehať navzájom paralelne. Proces je program, subsystém alebo procedúra, ktorá je momentálne spustená. Tento model je možné uplatniť aj v sekvenčných systémoch, kde riadiaci program volá jednotlivé subsystémy v závislosti od niektorých stavových premenných (prostredníctvom operátora prípade).

Správa udalostí predpokladá absenciu akéhokoľvek podprogramu zodpovedného za správu. Ovládanie sa vykonáva pomocou externých udalostí: stlačenie tlačidla myši, stlačenie klávesnice, zmena údajov snímača, zmena údajov časovača atď. Každá externá udalosť je zakódovaná a umiestnená do frontu udalostí. Ak je poskytnutá reakcia na udalosť vo fronte, potom je vyvolaný postup (podprogram), ktorý vykoná reakciu na túto udalosť. Udalosti, na ktoré systém reaguje, sa môžu vyskytnúť buď v iných podsystémoch, alebo vo vonkajšom prostredí systému.

Príkladom takéhoto riadenia je organizácia aplikácií vo Windows.

Všetky vyššie opísané štrukturálne modely je možné implementovať pomocou centralizovaného riadenia alebo riadenia založeného na udalostiach.

Používateľské rozhranie

Pri vývoji modelu rozhrania by sa malo brať do úvahy nielen úlohy navrhnutého softvéru, ale aj vlastnosti mozgu spojené s vnímaním informácií.

III.03.4. a Psychofyzické vlastnosti človeka spojené s vnímaním a spracovaním informácií.

Časť mozgu, ktorú možno konvenčne nazvať procesorom vnímania, neustále, bez účasti vedomia, spracúva prichádzajúce informácie, porovnáva ich s minulými skúsenosťami a ukladá ich do pamäti.

Keď vizuálny obraz priťahuje našu pozornosť, potom sa informácie, ktoré nás zaujímajú, dostanú v krátkodobej pamäti. Ak naša pozornosť nebola priťahovaná, informácie z úložiska zmiznú a nahradia ich nasledujúce časti.

V každom okamihu môže byť zaostrenie pozornosti zafixované v jednom bode, takže ak je potrebné sledovať súčasne niekoľko situácií, potom sa zaostrenie presunie z jedného sledovaného objektu do druhého. Zároveň je rozptýlená pozornosť a niektoré detaily môžu byť prehliadnuté. Je tiež dôležité, že vnímanie je do značnej miery založené na motivácii.

Pri zmene rámca je mozog na chvíľu zablokovaný: získava nový obraz so zvýraznením najdôležitejších detailov. To znamená, že ak potrebujete rýchlu odpoveď používateľa, nemali by ste obrázky náhle meniť.

Krátkodobá pamäť je úzkym miestom v systéme spracovania informácií o osobe. Jeho kapacita je 7 ± 2 neprepojených objektov. Nevyžiadané informácie sa v ňom uchovávajú najviac 30 sekúnd. Aby sme nezabudli na pre nás dôležité informácie, zvyčajne si ich opakujeme a aktualizujeme informácie v krátkodobej pamäti. Pri navrhovaní rozhraní si teda treba uvedomiť, že drvivá väčšina si napríklad ťažko pamätá a zadáva čísla obsahujúce viac ako päť číslic na inej obrazovke.

Aj keď je kapacita a doba skladovania dlhodobej pamäte neobmedzená, prístup k informáciám nie je ľahký. Mechanizmus získavania informácií z dlhodobej pamäte má asociatívnu povahu. Aby sa zlepšilo zapamätanie informácií, sú spojené s údajmi, ktoré už pamäť obsahuje, a uľahčuje ich získanie. Pretože prístup k dlhodobej pamäti je ťažký, odporúča sa neočakávať, že si používateľ bude pamätať tieto informácie, ale že ich používateľ rozpozná.

III.03.4. b Základné kritériá na hodnotenie rozhraní

Početné prieskumy a prieskumy popredných firiem zaoberajúcich sa vývojom softvéru ukázali, že používatelia si na rozhraní cenia:

1) jednoduchosť ovládania a zapamätania - konkrétne odhadnite čas zvládnutia a trvanie uchovania informácií a pamäte;

2) rýchlosť dosahovania výsledkov pri používaní systému, ktorá je určená počtom príkazov a nastavení zadaných alebo vybraných myšou;

3) subjektívna spokojnosť s prevádzkou systému (jednoduchosť použitia, únava atď.).

Pre profesionálnych používateľov, ktorí neustále pracujú s rovnakým balíkom, sa druhé a tretie kritérium rýchlo dostávajú na prvé miesto a pre neprofesionálnych používateľov, ktorí pravidelne pracujú so softvérom a vykonávajú pomerne jednoduché úlohy - prvé a tretie.

Z tohto pohľadu majú dnes rozhrania s bezplatnou navigáciou najlepšie vlastnosti pre profesionálnych používateľov a rozhrania pre priamu manipuláciu pre neprofesionálnych používateľov. Už dávno sa zistilo, že pri kopírovaní súborov, ktoré sú rovnocenné, väčšina profesionálov používa škrupiny ako Far, zatiaľ čo neprofesionáli používajú Windows drag and drop.

III.03.4. c Typy používateľských rozhraní

Rozlišujú sa tieto typy používateľských rozhraní:

Primitívne

Navigácia zdarma

Priama manipulácia.

Rozhranie je primitívne

Primitívne sa nazýva rozhranie, ktoré organizuje interakciu s používateľom a používa sa v konzolovom režime. Jedinou odchýlkou \u200b\u200bod sekvenčného procesu, ktorú poskytujú údaje, je prechádzanie viacerými množinami údajov.

Rozhranie ponuky.

Na rozdiel od primitívneho rozhrania umožňuje používateľovi vybrať operáciu zo špeciálneho zoznamu zobrazeného programom. Tieto rozhrania zahŕňajú implementáciu mnohých pracovných scenárov, ktorých postupnosť je určená používateľmi. Stromová organizácia ponúk naznačuje, že hľadanie položky vo viac ako dvojúrovňových ponukách je ťažké.

Architektúra distribuovaných systémov

V súčasnosti sú distribuované prakticky všetky veľké softvérové \u200b\u200bsystémy. Distribuovaný systém je systém, v ktorom sa spracovanie informácií nesústredí na jeden počítač, ale je distribuované medzi niekoľko počítačov. Pri navrhovaní distribuovaných systémov, ktoré majú veľa spoločného s dizajnom iného softvéru, je stále potrebné brať do úvahy množstvo špecifických funkcií. Niektoré z nich už boli spomenuté v úvode kapitoly 10, keď sme sa zaoberali architektúrou klient / server, a sú tu podrobnejšie diskutované.

Pretože distribuované systémy sú v dnešnej dobe veľmi rozšírené, vývojári softvéru by mali byť oboznámení so špecifikami ich dizajnu. Až donedávna boli všetky veľké systémy z veľkej časti centralizované a fungovali na jednom hostiteľskom počítači (sálovom počítači) s pripojenými terminálmi. Terminály prakticky nespracovávali informácie - všetky výpočty sa uskutočňovali na hostiteľskom počítači. Vývojári takýchto systémov nemuseli premýšľať o problémoch distribuovaných výpočtov.

Všetky moderné softvérové \u200b\u200bsystémy možno rozdeliť do troch širokých tried.

1. Aplikačné softvérové \u200b\u200bsystémy určené na prácu iba na jednom osobnom počítači alebo pracovnej stanici. Patria sem textové procesory, tabuľky, grafické systémy atď.

2. Vstavané systémy určené na prevádzku na jednom procesore alebo na integrovanej skupine procesorov. Patria sem riadiace systémy pre domáce spotrebiče, rôzne spotrebiče atď.

3. Distribuované systémy, v ktorých softvér beží na voľne integrovanej skupine paralelných procesorov prepojených cez sieť. Patria sem bankomatové systémy vo vlastníctve banky, publikačné systémy, zdieľané softvérové \u200b\u200bsystémy atď.

V súčasnosti existujú jasné hranice medzi uvedenými triedami softvérových systémov, ktoré sa v budúcnosti budú čoraz viac stierať. Postupom času, keď budú vysokorýchlostné bezdrôtové siete široko dostupné, bude možné dynamicky integrovať zariadenia so zabudovanými softvérovými systémami, napríklad elektronické organizéry so všeobecnejšími systémami.

Bolo identifikovaných šesť hlavných charakteristík distribuovaných systémov.

1. Zdieľanie zdrojov.Distribuované systémy umožňujú zdieľanie hardvérových a softvérových zdrojov, ako sú pevné disky, tlačiarne, súbory, kompilátory a podobne, ktoré sú prepojené prostredníctvom siete. Je zrejmé, že zdieľanie zdrojov je možné aj v systémoch viacerých používateľov, avšak v takom prípade musí byť za zabezpečenie zdrojov a ich správu zodpovedný centrálny počítač.

2. Otvorenosť.Toto je schopnosť rozšíriť systém pridaním nových zdrojov. Distribuované systémy sú otvorené systémy, ktoré spájajú hardvér a softvér od rôznych výrobcov.

3. Paralelizmus.V distribuovaných systémoch môže na rôznych počítačoch v sieti bežať súčasne viac procesov. Tieto procesy môžu (ale nemusia) navzájom spolupracovať, kým sú spustené.

4. Škálovateľnosť.V zásade sú všetky distribuované systémy škálovateľné: za účelom splnenia nových požiadaviek je možné systém rozšíriť pridaním nových výpočtových zdrojov. V praxi sa však budovanie môže obmedziť na sieť spájajúcu jednotlivé počítače v systéme. Ak je pripojených veľa nových strojov, šírka pásma siete nemusí byť dostatočná.

5. Odolnosť proti chybám.Prítomnosť viacerých počítačov a schopnosť duplikovať informácie znamená, že distribuované systémy sú odolné voči určitým chybám hardvéru a softvéru. Väčšina distribuovaných systémov v prípade chyby zvyčajne podporuje aspoň čiastočnú funkčnosť. Úplné zlyhanie systému nastane iba v prípade sieťových chýb.

6. Transparentnosť.Táto vlastnosť znamená, že používateľom je poskytovaný úplne transparentný prístup k zdrojom a zároveň sú pred nimi skryté informácie o distribúcii zdrojov v systéme. V mnohých prípadoch však špecifické znalosti organizácie systému pomáhajú používateľovi lepšie využívať zdroje.

Distribuované systémy majú samozrejme množstvo nevýhod.

Zložitosť.Distribuované systémy sú zložitejšie ako centralizované. Oveľa ťažšie je pochopiť a vyhodnotiť vlastnosti distribuovaných systémov všeobecne a tiež tieto systémy otestovať. Napríklad tu výkon systému nezávisí od rýchlosti jedného procesora, ale od šírky pásma siete a rýchlosti rôznych procesorov. Presun prostriedkov z jednej časti systému do druhej môže drasticky ovplyvniť výkon systému.

Bezpečnosť.K systému je zvyčajne prístup z niekoľkých rôznych počítačov, správy v sieti je možné prezerať alebo odpočúvať. Preto je v distribuovanom systéme oveľa ťažšie udržať bezpečnosť.

KontrolovateľnosťSystém môže pozostávať z počítačov rôznych typov, na ktoré je možné nainštalovať rôzne verzie operačných systémov. Chyby na jednom počítači sa môžu šíriť na ďalšie počítače s nepredvídateľnými následkami. Preto je potrebné vynaložiť oveľa väčšie úsilie na správu a údržbu systému v prevádzkyschopnom stave.

Nepredvídateľnosť.Ako všetci používatelia webu vedia, reakcia distribuovaných systémov na určité udalosti je nepredvídateľná a závisí od plného zaťaženia systému, jeho organizácie a sieťového zaťaženia. Pretože sa všetky tieto parametre môžu neustále meniť, čas strávený vykonaním žiadosti používateľa v určitom čase sa môže výrazne líšiť.

Pri diskusii o výhodách a nevýhodách distribuovaných systémov je identifikovaných niekoľko kritických problémov pri návrhu týchto systémov (tabuľka 9.1).

Tabuľka 9.1. Problémy s návrhom distribuovaných systémov

Problém s dizajnom	Popis
Identifikácia zdrojov	Zdroje v distribuovanom systéme sú umiestnené na rôznych počítačoch, preto by sa malo myslieť na systém pomenovania zdrojov, aby používatelia mohli ľahko pristupovať a odkazovať na potrebné zdroje. Príkladom je systém Uniform Resource Locator (URL), ktorý definuje adresy webových stránok. Bez ľahko vnímateľného a univerzálneho identifikačného systému bude väčšina zdrojov pre používateľov systému neprístupná.
Komunikácia	Príkladom najefektívnejšieho spôsobu organizácie komunikácie medzi počítačmi je univerzálna funkčnosť internetu a efektívna implementácia protokolov TCP / IP v internete pre väčšinu distribuovaných systémov. Ak sú však na výkon, spoľahlivosť atď. Kladené špeciálne požiadavky, je možné použiť alternatívne spôsoby systémovej komunikácie.
Kvalita systémových služieb	Kvalita služieb ponúkaných systémom odráža jeho výkon, funkčnosť a spoľahlivosť. Na kvalitu služby má vplyv niekoľko faktorov: distribúcia systémových procesov, alokácia zdrojov, hardvér systému a siete a adaptabilita systému.
Softvérová architektúra	Softvérová architektúra popisuje distribúciu systémových funkcií medzi komponentmi systému, ako aj distribúciu týchto komponentov medzi procesormi. Ak potrebujete udržiavať vysoko kvalitnú systémovú službu, ukázalo sa, že výber správnej architektúry je rozhodujúcim faktorom.

Výzvou pre návrhárov distribuovaného systému je navrhnúť softvér alebo hardvér tak, aby poskytovali všetky požadované vlastnosti distribuovaného systému. To si vyžaduje poznanie výhod a nevýhod rôznych architektúr distribuovaných systémov. Vynikajú tu dva súvisiace typy architektúr distribuovaného systému.

1. Architektúra klient / server.V tomto modeli možno systém považovať za súbor služieb poskytovaných servermi klientom. V takýchto systémoch sa servery a klienti navzájom výrazne líšia.

2. Architektúra distribuovaných objektov.V tomto prípade neexistujú žiadne rozdiely medzi servermi a klientmi a systém je možné považovať za množinu interagujúcich objektov, na ktorých umiestnení vlastne nezáleží. Nie je rozdiel medzi poskytovateľom služby a jeho používateľmi.

V distribuovanom systéme môžu byť rôzne komponenty systému implementované v rôznych programovacích jazykoch a spustené na rôznych typoch procesorov. Dátové modely, prezentácia informácií a komunikačné protokoly nemusia byť v distribuovanom systéme nevyhnutne všetky rovnakého typu. Distribuované systémy preto potrebujú softvér, ktorý dokáže tieto heterogénne časti spravovať a zaručiť interakciu a výmenu údajov medzi nimi. Middlewareodkazuje presne na túto triedu softvéru. Je akoby v strede medzi rôznymi časťami komponentov distribuovaného systému.

Distribuované systémy sú zvyčajne navrhnuté s objektovým prístupom. Tieto systémy sú vytvorené z voľne integrovaných častí, z ktorých každá môže priamo interagovať s používateľom aj s ostatnými časťami systému. Tieto časti by mali, kedykoľvek je to možné, reagovať na nezávislé udalosti. Softvérové \u200b\u200bobjekty založené na týchto princípoch sú prirodzenými súčasťami distribuovaných systémov. Ak ešte nie ste oboznámení s pojmom objekty.

IN veľké podniky v dcérskych spoločnostiach pracujú desaťtisíce používateľov. Každá organizácia má svoje vlastné interné obchodné procesy: schvaľovanie dokumentov, vydávanie pokynov atď. Niektoré procesy zároveň presahujú hranice jednej spoločnosti a ovplyvňujú zamestnancov druhej. Napríklad vedúci ústredia vydá príkaz dcérskej spoločnosti alebo zamestnanec dcérskej spoločnosti pošle zmluvu na schválenie právnikom materskej spoločnosti. To si vyžaduje zložitú architektúru, ktorá využíva viac systémov.

Navyše v rámci jedna spoločnosť veľa systémov sa používa na riešenie rôznych úloh: systém ERP pre účtovné operácie, samostatná inštalácia systémov ECM pre organizačnú a administratívnu dokumentáciu, pre dokumentáciu návrhov a odhadov atď.

Systém DIRECTUM pomôže zabezpečiť interakciu rôznych systémov v rámci holdingu aj na úrovni jednej organizácie.

DIRECTUM poskytuje pohodlné nástroje na stavanie riadená distribuovaná architektúra organizovanie a riešenie nasledujúcich úloh:

• organizácia end-to-end obchodných procesov a synchronizácia dát medzi niekoľkými systémami jednej spoločnosti a v holdingu;
• poskytovanie prístupu k údajom z rôznych inštalácií systémov ECM. Napríklad vyhľadajte dokument vo viacerých špecializovaných systémoch: s finančnou dokumentáciou, s dokumentáciou návrhu a odhadu atď.
• správa mnohých systémov a služieb z jedného miesta riadenia a vytváranie pohodlnej IT infraštruktúry;
• pohodlná distribúcia vývoja do distribuovaných výrobných systémov.

Komponenty riadenej distribuovanej architektúry

Mechanizmy prepojenia (DCI)

Mechanizmy DCI sa používajú na organizáciu end-to-end obchodných procesov a synchronizáciu údajov medzi rôznymi systémami v rámci jednej alebo viacerých organizácií (holding).

Toto riešenie spája miestne obchodné procesy existujúce v spoločnostiach do jedného komplexného procesu. Zamestnanci a ich manažéri pracujú s už známym rozhraním úloh, dokumentov a príručiek. Kroky zamestnancov sú zároveň transparentné v každej fáze: môžu si pozrieť text korešpondencie s prepojenou spoločnosťou, pozrieť sa na stav schválenia dokumentu s materskou organizáciou atď.

K DCI je možné pripojiť rôzne inštalácie DIRECTUM a ďalšie triedy systémov (ERP, CRM atď.). Inštalácie sa spravidla delia podľa oblastí podnikania, pričom sa zohľadňuje územné alebo právne umiestnenie organizácií a ďalšie faktory.

Spolu s DCI sú vývojové komponenty dodávané s podrobným popisom a príkladmi kódu, vďaka ktorým môže vývojár vytvoriť algoritmus pre obchodné procesy svojej organizácie.

Mechanizmy DCI sú schopné prenášať veľké množstvo dát a odolávať špičkovým zaťaženiam. Okrem toho poskytujú odolnosť voči chybám v prípade zlyhania komunikácie a ochranu prenášaných údajov.

Federatívne vyhľadávanie

Vďaka združenému vyhľadávaniu môžete naraz nájsť potrebné úlohy alebo dokumenty vo všetkých jednotlivých systémoch DIRECTUM. Napríklad spustíte vyhľadávanie súčasne v pracovnom systéme a v systéme s archivovanými dokumentmi.

Federované vyhľadávanie umožňuje:

• zobraziť prostredníctvom webového klienta priebeh schvaľovania odchádzajúceho dokumentu v pobočke;
• nájsť zmluvy uzavreté s protistranou vo všetkých dcérskych spoločnostiach, napríklad na prípravu rokovaní. V takom prípade môžete prejsť na úlohy, ku ktorým sú uzavreté zmluvy;
• skontrolovať stav vykonania objednávky odoslanej z materskej organizácie do dcérskej spoločnosti alebo dokumentov a úloh v nej vytvorených;
• vyhľadávať dokumenty súčasne vo viacerých systémoch s rôznymi špecializáciami, napríklad s organizačnými a administratívnymi dokumentmi a so zmluvami;
• vyhľadať primárne účtovné doklady na audit alebo zosúladenie s protistranou okamžite v pracovnom systéme a v systéme s archívom dokladov;
• vymieňajte si odkazy na výsledky vyhľadávania s kolegami.

Správca môže meniť štandardné vyhľadávania, pridávať nové a tiež upravovať, ktoré systémy budú pre používateľa viditeľné.

Centrum správy služieb DIRECTUM

Systém DIRECTUM rieši mnoho rôznych úloh: interakciu zamestnancov, ukladanie dokumentov atď. To je možné vďaka spoľahlivému fungovaniu jeho služieb. A vo veľkých spoločnostiach sú celé inštalácie systému DIRECTUM alokované s vlastnou sadou služieb pre konkrétnu úlohu, napríklad pre ukladanie archívnych dokumentov. Inštalácie a služby sú nasadené na viacerých serveroch. Túto infraštruktúru je potrebné spravovať.

Centrum správy služieb DIRECTUM je jediný administratívny vstupný bod na konfiguráciu, monitorovanie a správu služieb a systémov DIRECTUM. Centrum je web s nástrojmi na správu serverov Session Server, Workflow Service, Event Service, File Storage Service, Input and Transform Services, Federated Search a Web Help.

Pohodlná vizuálna konfigurácia vzdialených systémov a služieb zjednodušuje prácu správcu. Nemusí chodiť na každý server a manuálne vykonávať zmeny v konfiguračných súboroch.

Služby sú zastavené a povolené jedným kliknutím. Stav služby sa okamžite zobrazí na obrazovke.

Zoznam nastavení je možné doplniť a filtrovať. Web predvolene zobrazuje iba základné nastavenia. Zároveň môžete pre všetky nastavenia vidieť tipy s odporúčaniami na vyplnenie.

Systém DIRECTUM efektívne organizuje prácu distribuovaných organizácií a poskytuje používateľom transparentnú výmenu dokumentov, úloh a záznamov o adresároch.

Každú súčasť riadenej distribuovanej architektúry je možné použiť samostatne, ale spoločne môžu vašej organizácii priniesť vyššiu obchodnú hodnotu.

Tento typ systému je zložitejší z hľadiska organizácie systému. Podstatou distribuované systémov je uchovať si miestne kópie dôležitých údajov.

Schematicky také architektúry môžu byť znázornené ako je znázornené na obr. 5.6.

Obr. 5.6. Architektúra distribuovaných systémov

Viac ako 95% údajov použitých pri správe podniku je možné umiestniť na jeden osobný počítač, čo umožňuje jeho samostatnú prácu. Prúd opráv a dodatkov generovaných v tomto počítači je v porovnaní s objemom použitých údajov zanedbateľný. Preto, ak ukladáte nepretržite používané údaje do samotných počítačov a organizujete medzi nimi výmenu opráv a dodatkov k uloženým údajom, potom celkový prenesený prenos prudko poklesne. To vám umožní znížiť požiadavky na komunikačné kanály medzi počítačmi a častejšie používať asynchrónnu komunikáciu a vďaka tomu vytvoriť spoľahlivo fungujúce distribuované informačné systémy, ktoré na pripojenie jednotlivých prvkov používajú nestabilnú komunikáciu, ako je internet, mobilná komunikácia a komerčné satelitné kanály. . A minimalizácia prenosu medzi prvkami spôsobí, že náklady na prevádzkovanie takéhoto spojenia budú celkom dostupné. Implementácia takéhoto systému samozrejme nie je elementárna a vyžaduje riešenie množstva problémov, jedným z nich je včasná synchronizácia údajov.

Každý AWS je nezávislý, obsahuje iba informácie, s ktorými musí pracovať, a dôležitosť údajov v celom systéme je zabezpečená prostredníctvom nepretržitej výmeny správ s ostatnými AWS. Výmenu správ medzi pracovnými stanicami je možné realizovať rôznymi spôsobmi, od odosielania údajov e-mailom až po ich prenos cez siete.

Ďalšou z výhod takejto schémy fungovania a architektúry systému, je zabezpečiť možnosť osobnej zodpovednosti za bezpečnosť údajov. Keďže údaje dostupné na konkrétnom pracovisku sa nachádzajú iba v tomto počítači, pomocou šifrovacích nástrojov a osobných hardvérových kľúčov je prístup k údajom vylúčený pre cudzincov vrátane správcov IT.

Taký architektúry systém tiež umožňuje organizovať distribuované výpočty medzi klientskými strojmi. Napríklad výpočet úlohy vyžadujúcej veľké výpočty možno rozdeliť medzi susedné pracovné stanice, pretože spravidla majú vo svojich databázach rovnaké informácie, a tým dosahujú maximálny výkon systému.

Distribuované systémy s replikáciou

Dáta medzi rôznymi pracovnými stanicami a centralizovaným dátovým úložiskom sa prenášajú replikáciou (obr. 5.7). Pri zadávaní informácií na pracovných staniciach sa údaje zapisujú aj do miestnej databázy a až potom sa synchronizujú.

Obr. 5.7. Architektúra distribuovaných systémov s replikáciou

Distribuované systémy s prvkami vzdialeného vykonávania

Existujú určité vlastnosti, ktoré nemožno kvalitatívne implementovať do konvenčného distribuovaného systému replikatívneho typu. Medzi tieto vlastnosti patrí:

pomocou údajov od entít, ktoré sú uložené na vzdialenom serveri (uzle);

čiastočné využitie údajov od entít uložených na rôznych serveroch (uzloch);

použitie izolovanej funkčnosti na dedikovanom serveri (uzol).

Každý z opísaných typov používa všeobecný princíp: klientský program buď pristupuje priamo k dedikovanému (vzdialenému) serveru, alebo pristupuje k lokálnej databáze, ktorá zapuzdruje volanie na vzdialený server (obr. 5.8).

Obr. 5.8. Architektúra distribuovaného systému vzdialeného spustenia