Architektura služby je přístup k návrhu softwaru, který řeší problém s řadou autonomních služeb.

Analogie

Rozumnou analogií pro architekturu služeb je organizace, jako je banka. Banka rozděluje práci na různé služby, jako je zákaznický servis, IT služby a služby řízení lidských zdrojů. Každá služba je nezávislá a lze ji nasadit do různých kanceláří. Klientům každé služby je nabídnuta smlouva, která stanoví, co lze od služby očekávat. Například řízení lidských zdrojů může týmu pomoci při náboru nových zaměstnanců pomocí formuláře, který tým vyplní, aby zahájil proces. Struktura služeb společnosti rozděluje komplexní problém provozu banky na malé funkční bloky správy.

Služby

Služby jsou jednotky softwaru, které provést funkci. Používají se k rozdělení složitých problémů na řadu jednodušších problémů. Služby jsou také navrženy tak, aby bylo možné je samostatně nasadit. To je hlavní výhoda, protože vám umožňuje vytvářet vysoce škálovatelné a odolné systémy.

Odolnost

Odolnost je termín pro software, který je spolehlivý v reálných podmínkách a zahrnuje různá napětí a selhání. Architektura služeb je užitečná technika pro vytváření systémů, které fungují i v případě selhání. Děje se to tak, že služby architektury jsou autonomní, takže na sobě navzájem nezávisí. Služby lze poté nasadit do cloudové infrastruktury a podle potřeby škálovat nahoru a dolů. Když instance selže, služby jsou dostatečně chytré, aby to detekovaly a automaticky najít fungující instanci.

Služby vs. komponenty

Služby a komponenty jsou dva různé způsoby, jak rozdělit práci na zvládnutelné a opakovaně použitelné bloky. Rozdíl je že služby lze nasadit samy. Komponenty jsou nasazeny s něčím jiným, a proto nejsou autonomní. Služby mohou být vytvořeny z komponent. Podobně mohou komponenty využívat služby.

Architektura orientovaná na služby (SOA)

Architektura orientovaná na služby byla časným pojmem pro architekturu služeb, který si osvojila a uvedla na trh mnoho velkých prodejců IT, kteří jej používali k prodeji platforem SOA a middlewaru. Jednalo se o velký výstřelek informačních technologií kolem roku 2005, který zaznamenal mnoho implementací shora dolů, které zahrnovaly nákup spousty softwaru a následné přepracování stávajících systémů, aby zapadly do paradigmatu SOA. Velká část této aktivity zcela minula smysl SOA a selhání projektu byla běžná. Když IT vědátoři propagovali nebo kritizovali SOA, pršelo zmatek, často proto, aby věci zněly co nejsložitěji.

Microservices

Všechny velké myšlenky a nesmysly která obklopila SOA na vrcholu své popularity, nezabránila zkušeným architektům v používání jejích klíčových myšlenek efektivním a lehkým způsobem, který produkoval spolehlivé, škálovatelné, spravovatelné a nákladově efektivní systémy a aplikace. To se vyvinulo v novou kulturu softwarového designu známou jako mikroslužby, která je organizována kolem sady zásad pro návrh služeb.

Příklad

Telekomunikační společnost navrhuje fakturační systém jako řadu samostatně nasaditelných služeb. Každá služba je považována za samostatný produkt, který může být vyvíjen, udržován a spravován různými lidmi. Služby jsou nasazeny do cloudu a volně spojené. Když instance služby selže, ostatní služby se automaticky přepnou na instanci, která stále funguje. Přestože je problém telekomunikačního vyúčtování extrémně složitý, žádná jednotlivá služba v architektuře není tak složitá, že vývoj a správa je relativně levná. Služby jsou v zásadě samoorganizující se. Každý z nich publikuje API do ostatních služeb. Každý ví, co potřebuje od ostatních služeb, a je dostatečně chytrý na to, aby směroval kolem neúspěšných instancí a našel služby, které reagují. Jinými slovy, architektura nemá žádný centrální ovladač ani middleware.

Přehled: Architektura služeb
Typ
Definice	Přístup k softwarovému designu, který řeší problém s řadou autonomních služeb.
Související pojmy