# 6. Distribuované systémy

Základní pojmy, principy. Rozdíl mezi centralizovanou a distribuovanou architekturou systému, nevýhody obojího a jejich překonávání. Replikace, sdílení dat. Architektura orientovaná na služby (SOA), webové služby. Příklady existujících technologií a jejich využití. Příklady z praxe pro vše výše uvedené. (PA053)

---

## Základné pojmy, princípy

**Distribuovaný systém** sa skladá z komponentov (počítačov) prepojených komunikačnou sieťou. Distribuované systémy riešia problémy (výpočty, odpovede na dotazy) spoluprácou jednotlivých komponentov. Vďaka tomu dokáže systém horizontálne škálovať.

Charakteristické **vlastnosti** distribuovaných systémov:
- Concurrency - spracováva v jeden čas mnoho požiadaviek
- Lack of global clock - udalosti sa nedajú zoradiť podľa času spracovania
- Independent failures - spadnutie uzlu by nemalo spôsobiť pád celého systému
- Synchronization - spracovávanie požiadaviek a výsledkov musí podliehať pravidlám

**Middleware** je vrstva softvéru poskytujúca rozhranie pre interakciu s rôznymi službami alebo systémami. Môže sa jednať o abstrakcie k často používanej funkcionalite, či o vrstvu, ktorá prepája už existujúce systémy.
- Napríklad ASP.NET je framework, ktorý obsahuje middleware na autorizáciu a autentizáciu

**RPC** (Remote Procedure Call) je technika volania funkcií na vzdialenom uzle. Jedná sa o formu API s pripojením do siete.

Príklady typov middlewarov:
- RPC - gRPC, SOAP
- Message-oriented - RabbitMQ, MPI (Message Passing Interface), REST, MQTT
- Object request broker - CORBA
- Database - JDBC

**Architektúrou** rozumieme organizačnú štruktúru aplikačného systému. Jedná sa o vysokoúrovňovú abstrakciu jednotlivých **komponentov** a **vzťahov** medzi nimi. Veľkou súčasťou architektúry sú **návrhové vzory**.

## Rozdiel medzi centralizovanou a distribuovanou architektúrou systému, nevýhody obidvoch a ich prekonávanie, architektúra orientovaná na služby (SOA)

**Centralizovaná** architektúra zhromažďuje biznisovú logiku a dáta na jednom mieste.
- Jedná sa o **monolitickú architektúru**, zvyčajne o samostatne bežiacu desktop aplikáciu
- Nedokáže horizontálne škálovať, iba vertikálne
- Nedokáže sa replikovať, nemá redundanciu
- Nízka flexibilita, veľký dôraz na kvalitu kódu
- Výhodou je jednoduchosť nasadzovania a rozmýšlania, sústredime sa iba na logiku aplikácie

**Distribuovaná architektúra** spočíva v rozdelení biznisovej logiky a dát na viacero miest.

Často sa jedná o **viacvrstvovú architektúru** typu klient-server:
- **Jednovrstvová** architektúra - thin client, server
- Všetko je uložené na serveri, aj prezentačná vrstva
- Klient je ľahký, slúži iba na pripojenie k serveru (terminál)
- Problém - Single point of failure
- **Dvojvrstvová** architektúra - thick client, server
- Prezentačná vrstva je oddelená od serveru, niektoré výpočty sa môžu presunúť na klienta
- Výhoda: lacnejší server
- Nevýhoda: tight coupling
- **N-vrstvová** architektúra - thin/thick client, layered server services
- Biznis logika sa môže rozvrstvovať v rámci servera
- Výhoda: lepšia škálovatelnosť a spolahlivosť, kvalita kódu
- Nevýhoda: vyššia cena, zložitejší prístup

**Komponentová architektúra** (component-based architecture) definuje systém na jednotlivé komponenty, z ktorých je zložený. **Komponenty** kladú dôraz na znovu-použiteľnosť, jednoduchosť použitia a ľahkosť výmeny.
- Príklad: Windows COM (Component Object Model), React Web Components
- Výhoda: systém, ktorý používa komponenty potrebuje vedieť iba ich interface, nie implementáciu

**Architektúra orientovaná na služby** (SOA, service-oriented architecture) rozďeluje systém na jednotlivé služby, ktoré majú poskytovať zlomkovú funkcionalitu celého systému. Typicky máme nástroj - zbernicu (**enterprise bus**) alebo **API Gateway**, pomocou ktorého vedia služby komunikovať medzi sebou. Prezentačná vrstva sa typicky napája priamo skrz túto zbernicu pomocou API.
- Výhody: loose coupling, fully distributed, easy to maintain, service discovery, redundancy, reusability, statelessness
- Nevýhody: zmeny v interface-och služieb môžu spôsobiť nekompatibilitu

**Microservices architektúra** je subtypom SOA, ktorá sa sústredí na vytvorenie čo najviac, čo najmenších služieb. Dôležitý princíp je **vysoká kohéznosť** v prípade ak máme microservicy, ktoré sú závislé na iných službách, jedná sa o **distribuovaný monolit**, čo je klasický antipattern.
- Mikroslužby majú typicky samostatnú databázu, robia iba jednu konkrétnu funkciu
- V prípade že mikroslužba spadne, ovplyvní to len malú časť aplikácie, ktorá sa dokáže zakryť
- Výhody: škálovatelnosť
- Nevýhody: cena, náročnosť implementácie a udržiavanie

**Peer-to-peer architektúra** sa používa v prípade, ak máme klientov, ktorí komunikujú medzi sebou bez servera. Zvyčajným účelom je zdieľanie dát, replikácia, zdieľanie služieb.
- Príklad: BitTorrent, Napster, cryptocurrency networks
- Výhody: fault-tolerant, vysoko škáloveteľné
- Nevýhody: náročné vyhľadávanie služieb, uzlov, smerovanie, konzistencia siete

**Shared Nothing architektúra** spočíva v použití "shardov", čo sú samostatne stojace uzly, nezávislé na iných. Využíva sa na rozdelenie dát a replikáciu.

## Webové služby

**Webovou službou** rozumieme aplikáciu, ktorá je dostupná pomocou nejakého API na úrovni aplikačných protokolov HTTP. Využívame protokoly a techniky:
- SOAP (Simple Object Access Protocol)
- Používa XML na definíciu správ, je to druh RPC
- WSDL (Web Service Definition Language)
- Používa XML na definíciu SOAP služieb
- REST (Representational State Transfer)
- Architektonický vzor webových služieb na základe HTTP protokolu
- Iba správy GET, POST, UPDATE, DELETE
- Zakázaný stav medzi správami - stateless, princíp idempotencie
- Zvyčajne používa správy typu JSON
- GraphQL
- Moderný protokol na získavanie údajov skrz webovú službu
- Ľahké filtrovanie, niečo ako remote RDBMS
- Slúži iba na dotazovanie

## Replikácia, zdieľanie dát

Typickým problémom distribuovaných systémov je **CAP theorem**. Distribuovaný systém vie mať iba 2 vlastnosti v jeden moment:
- **Consistency** - uzol vždy odpovie správne alebo vôbec
- **Availability** - uzol, ktorý nie je v chybovom stave vždy odpovie
- **Partition tolerance** - systém funguje správne aj napriek tomu, že sa správy nedostanú k uzlu

Príklad: ak máme cluster, ktorému prestanú chodiť dáta, tak odpovieme s chybou a nič neurobí (CP) alebo sa zmena vykoná, a rozdelený systém sa dostane do nekonzistentného stavu (AP).

**Relačné databázové systémy (CA)** ako MySQL, MSSQL, Postgres vedia pracovať v clusteroch, aby bola vždy zabezpečená dvojica vlastností CAP. Dochádza k **replikácii** dát (master-slave) alebo k shardingu.
- Master-slave - dáta sa iba kopírujú z mastra do slave, periodicky alebo po zmene
- Sharding - každý databázový uzol vlastní časť dát a pristupuje sa k nim skrz proxy

V prípade, ak sa vzdáme vlastností **ACID**, môžeme dosiahnuť určitú úroveň vlastností CAP. NoSQL databázy sa často riadia princípom **BASE**:
- Basically available - čítanie a zápis sú dostupné poďla možností, ale nezaručujú konzistenciu dát
- Soft-state - bez garancie konzistencie, po určitom čase existuje nejaká pravdepodobnosť nekonzistencie
- Eventually consistent - po určitej dobe môžeme tvrdiť, že systém sa dostane do konzistentného stavu

Príklad: MongoDB NoSQL (CP) databáza, typicky používaná na OLAP (analytické spracovanie), Big Data (Apache Hadoop, Spark), stream processing, batch processing