Serverio architektūra
REST serveriai ir paslaugos apžvalga
Daugeliui įmonių taikomųjų sistemų šiandien reikia daugiau nei vieno kliento. Tam priklauso sąsajos, portalai, laiko planavimas, integracijos, foninis apdorojimas ir techninė eksploatacinė logika. Būtent todėl REST serverių ir paslaugų neplanuojame kaip vėliau „prijungiamo“ priedo, o kaip tos pačios architektūros dalį.
API su tikra dalykine reikšme
REST serveris mums nėra vien techninis sluoksnis, o kontroliuojamas vaidmenų, procesų, duomenų ir verslo taisyklių atvėrimas.
Windows ir Linux paslaugos realiems procesams
Sinchronizacija, importai, eksportai, laiko planavimas, licencijų tikrinimas ar pranešimai veikia stabiliau, kai sąmoningai iškeliami į paslaugas ir švariai stebimi.
Stebėsena, klaidų scenarijai ir diegimas
Tvarkingi logai, automatinis paleidimas iš naujo, konfigūracija, leidimų keliai ir atsakomybės yra dizaino dalis, o ne tema tik po Go-live.
Kada prasmingas paslaugomis orientuotas skaidymas
- kai keli klientai turi pasiekti tą pačią dalykinę logiką
- kai foniniai procesai nebeturėtų būti pririšti prie atskirų darbo vietų
- kai portalai, darbalaukis ir trečiųjų šalių sistemos kontroliuojamai naudoja tą pačią duomenų bazę
- kai leidimų išleidimas, eksploatavimas ir techninė atsakomybė turi išlikti keičiamo mastelio
Jokio API be architektūros
Tikroji pridėtinė vertė atsiranda ne iš vieno endpointo, o iš serverio skaidymo, kuris teises, procesus ir duomenis nuosekliai perkelia į eksploatavimą.
REST serveriai ir paslaugos kaip tos pačios dalykinės logikos dalis
Daugelyje įmonių API ir foninės paslaugos atsiranda per vėlai ir veikiant spaudimui. Tuomet esamas darbalaukio sprendimas vėliau papildomas sąsajomis, o verslo taisyklės ir toliau lieka paslėptos kliente. Tai beveik neišvengiamai veda prie nenuoseklumų: ta pati taisyklė egzistuoja kelis kartus, klaidų vaizdus tampa sunkiau atsekti, o eksploatavimas remiasi išskirtinėmis žiniomis.
Mes einame priešingu keliu. Jei sistemai reikia portalų, integracijų, importų, eksportų, licencijų patikrų ar foninio apdorojimo, atsakomybė tarp kliento, REST serverio ir paslaugos turi būti aiškiai apibrėžta anksti. Kuri logika yra dalykiškai centrinė? Kurie veiksmai turi būti atkartojami? Kaip protokoluojamos klaidinės situacijos? Kaip vėliau galima plėsti duomenų srautus, kad vėl neliktume „prikibę“ prie monolito?
Ypač Delphi sistemose šis punktas svarbus. Daug vertingos verslo logikos dažnai jau slypi esamoje sistemoje. Kas iš jos išveda REST serverius arba Linux ir Windows paslaugas, neturėtų tiesiog kopijuoti šaltinio kodo, o turi tvarkingai atskirti bendrą dalykinį pagrindą nuo taikomosios programos. Tik tada atsiranda API ir paslaugos, kurios kalba ta pačia kalba kaip klientas.
Serverio logika su dalykine autoritete
Endpointai turėtų ne tik pateikti duomenis, bet ir atvaizduoti tas pačias taisykles, teises ir proceso žingsnius, kurie galioja ir branduolinėje sistemoje.
Paslaugos pasikartojantiems proceso žingsniams
Importai, sulyginimai, eksportai, sinchronizacijos ir pranešimai neturi atsidurti atsitiktiniuose kliento šalutiniuose keliuose, o stebimuose servisuose.
Eksploatavimą numatyti nuo pat pradžių
Stebėsena, žurnalizavimas, persikrovimo elgsena, konfigūracija ir leidimų procesas servisams ir REST serveriams priklauso architektūros branduoliui, o ne taisymams po Go-live.
Į ką įmonėms reikėtų atkreipti dėmesį dėl REST ir servisų
Svarbiausia klaida dažniausiai nėra techninė, o struktūrinė: projektas mano, kad su API architektūros klausimas jau išspręstas. Iš tikrųjų jis tik tada prasideda. API, portalai, darbalaukio klientai ir servisai turi suprasti tą pačią duomenų bazę, tas pačias roles ir tas pačias dalykines taisykles.
Kai ši linija aiški, plėtrą galima planuoti gerokai saugiau. Portalas gali pasiekti tą pačią serverio logiką, foniniai servisai gali kontroliuotai apdoroti tuos pačius objektus, o trečiųjų šalių integracijos lieka prijungtos aiškiai apibrėžtoje dalykinėje vietoje. Būtent iš šios perspektyvos daugiaplatformius klientus, serverio logiką ir duomenų laikymą vertiname kaip vientisą sistemą, o ne kaip laisvai susietus atskirus komponentus.
Galiausiai gera REST ir servisų architektūra atpažįstama ne pagal tai, kaip moderniai skamba, o pagal tai, kaip ramiai ją vėliau galima eksploatuoti. Jei palaikymo atvejai išlieka atsekami, klaidų keliai matomi, o nauji reikalavimai nebeužsibaigia apėjimais sename kode, tuomet pasiektas tikrasis techninis laimėjimas.
Kaip atpažinti, kad REST ir servisus reikia architektūriškai švariai paruošti
Kai tik keli klientai, integracijos ar foniniai procesai ima reikalauti tų pačių taisyklių, API idėja virsta sistemos klausimu. Būtent čia sprendžiasi, ar vėliau bus ramybė, ar nuolatinė trintis.
Dalykinės taisyklės turi būti bendrame centre
API ir servisai tampa tvarūs tik tada, kai kalba ta pačia logika kaip klientas, portalas ir duomenų modelis.
Logai, restartas ir klaidų matomumas yra dizaino dalis
Švarią foninę logiką atpažinsi ne pagal endpointą, o pagal ramią elgseną realioje eksploatacijoje.
Naujos integracijos išlieka valdomos
Kas anksti švariai atskiria serverio logiką, gali portalus, eksportus ir trečiųjų šalių prijungimus plėsti gerokai kontroliuojamiau.
Ką turėtų pateikti pirminė architektūros apžvalga dėl REST ir servisų
Didžiausias svertas dažnai slypi ne frameworke, o švariame atsakomybių paskirstyme tarp kliento, serverio ir foninių procesų.
- įvardijimą, kuri logika dalykiškai turi likti centralizuota ir kas priklauso servisams
- vaizdą apie roles, duomenų kelius, žurnalizavimą ir technines eksploatavimo būsenas
- startinį kelią API, foniniams darbams ir integracijoms be nekontroliuojamos paralelinės realybės
Serverio logiką sutvarkyti prieš išsikerojimą
Jei API, jobai ar portalai jau spaudžia, dabar yra tinkamas laikas švariai suveržti bendrą dalykinį centrą.
DUK apie REST-Server ir paslaugas
Daugelis sistemų žlunga ne dėl API idėjos, o dėl to, kad serverio logika vėliau improvizuotai prikabinama prie esamos darbalaukio bazės. Šias dalis sąmoningai planuojame kartu.
Kada įmonės programai papildomai reikia REST-Server?
Kai keli klientai, portalai, mobilios prieigos, išorinės integracijos ar atsieti procesai turi kontroliuojamai naudoti tą pačią dalykinę logiką.
Ar taip pat palaikote Windows- ir Linux-paslaugas?
Taip. Fono procesai, laiko planavimas, sinchronizavimas, eksportai, licencijų paslaugos ir techniniai lydintys procesai priklauso mūsų tipinėms užduotims.
Kaip išlaikomas dalykinis nuoseklumas tarp kliento, REST ir paslaugos?
Per architektūrą, kurioje verslo taisyklės nėra paslėptos atskirose sąsajose, o išlieka bendrai naudojamos ir atsekamos.
Daugiau klausimų – skaitykite sugrupuotus
Šie trumpi atsakymai lieka šiame puslapyje. Centrinėje DUK nukreipimo (landing) puslapyje temą papildomai susiejame su architektūra, modernizavimu, platformomis ir eksploatavimu.