Proč je potřeba architektura orientovaná na služby

Jak rozdělit aplikaci na moduly

Náklady na vývoj závisí na množství nových funkcí. Čím více funkcí je v aplikaci implementováno, tím více času zabere jejich implementace. Náklady na vývoj ovlivňuje také technologický stack produktu a architektonické přístupy, které tým uplatňuje.

Architektura orientovaná na služby (SOA, service-oriented architecture) pomáhá dosáhnout rovnováhy mezi náklady a rychlostí. SOA je založena na rozdělení aplikace na volně vázané komponenty (služby).

Vysvětlíme, jak rozdělení logiky do modulů zjednodušuje vývoj.

Služby jako samostatné části

Základní jednotkou SOA je služba odpovědná za konkrétní obchodní proces. Aplikace může mít například samostatné služby pro:

autorizace uživatelů;
přihlašování;
upozornění.

Velké úkoly jsou sdíleny mezi moduly. Neexistují žádná přísná pravidla pro popis obsahu a funkcí služby. Tým sám definuje, co služba potřebuje. Současně se samotné služby řídí smlouvami (jasnými pravidly):

co přesně se může ke službě připojit;
podle jakého protokolu a přes jaké rozhraní se data přenášejí;
s jakými daty služba pracuje;
za jaké funkce je služba zodpovědná;
co služba vrací jako odpověď na požadavky.

Moduly nižší úrovně nevědí nic o implementaci modulů vyšší úrovně kromě protokolu, který používají pro práci s prostředky. Služby pouze předávají a přijímají data bez přístupu k metodám ostatních modulů. Kromě toho jsou všechny události zpracovávány asynchronně. Nemělo by docházet k situacím, kdy služby selžou, protože čekají na odpověď od jiných systémů.

Protože služby představují samostatné funkce, lze je opakovaně používat v různých aplikacích. Spojování služeb do větších celků se nazývá orchestrace. Vývojář získá konstruktor, ze kterého může sestavovat aplikace.

Komponenty spolu komunikují pomocí protokolů využívajících frontu událostí. Je poskytována prostřednictvím sběrnice ESB (Enterprise Service Bus), softwaru, který řídí předávání zpráv mezi komponentami systému.

Vrstvená architektura

Aplikace podle SOA se obvykle dělí na vrstvy, z nichž každá je zodpovědná za určitou úlohu:

Business Process Layer – vrstva pro kombinování služeb a řešení aplikačních úloh.
Service – vrstva se službami.
Components – vrstva s komponentami, které zajišťují práci jednotlivých služeb. Například komponenta nemá vlastní databázi – přistupuje k databázi, kterou používá několik služeb;
Integration Layer (integrační vrstva) – vrstva spojující komponenty samostatného modulu.

Výhody a nevýhody SOA

Výhody SOA:

Flexibilita – moduly lze provozovat samostatně. Díky tomu je architektura distribuovaná a nezávislá na platformě. Různé komponenty lze napsat v různých programovacích jazycích a frameworcích a následně je umístit na samostatné servery.
Integrace nových funkcí je snadná – stačí napsat novou službu a definovat, jaké protokoly bude používat pro komunikaci s ostatními.
SOA poskytuje zapouzdření – obchodní funkce jsou od sebe izolovány, což zvyšuje odolnost proti chybám. Pokud se některá ze služeb změní, je třeba restartovat pouze ty části, které s ní komunikují. Aplikace může fungovat, i když s omezenou funkčností. Když vypadne služba odpovědná za odesílání e-mailů, služba pro autorizaci uživatelů funguje dál.
Služba není vázána na jednu aplikaci a může být použita v jiné. Vývojář může napsat dvě implementace téže služby: jedna z nich poskytuje základní obchodní logiku a druhá slouží k testování nových funkcí.

Minusy SOA:

Propojené moduly jsou na sobě závislé.
Čím více vazeb mezi službami, tím více změn je třeba sledovat.
Pokud na různých službách pracuje mnoho týmů, je pro ně obtížné spolupracovat na podpoře produktu a provádět změny, které ovlivňují více služeb. V takovém případě není možné udržet vysokou rychlost agilního vývoje.
Vysoké náklady na produkt s rostoucím počtem služeb.

Přechod k architektuře mikroslužeb (další iterace vývoje SOA) tyto nedostatky řeší. Komponenty se zmenšují, mají vlastní zdroje a datová úložiště a pro komunikaci používají pouze protokol HTTP.

Autor: Dmitry Bidenko

Sdílet: