Serverių architektūra
REST serveriai ir paslaugos — apžvalga
API. Paslaugos. Eksploatavimas.
REST-serveriai ir paslaugos kaip tos pačios sistemos architektūros funkcinė plėtra.
Daugelis verslo programų šiandien reikalauja daugiau nei vieno kliento. Sąsajos, portalai, laiko valdymas, integracijos, foninis apdorojimas ir techninė eksploatavimo logika tam priskiriami. Būtent todėl mes planuojame REST-Server und Services nicht als nachtraeglichen Anbau, sondern als Teil derselben Architektur.
API, turinčios tikrą sritinę reikšmę
Mums REST-Server ist für uns nicht nur eine technische Schicht, sondern die kontrollierte Exponierung von Rollen, Prozessen, Daten und Geschaeftsregeln.
Windows- und Linux-paslaugos realiems procesams
Sinchronizacija, importai, eksportai, laiko valdymas, licencijų tikrinimas arba pranešimai veikia stabiliau, kai jie sąmoningai iškelti į paslaugas ir tinkamai stebimi.
Monitoringas, klaidų scenarijai ir diegimas
Tvarkingi žurnalai, atkūrimas, konfigūracija, paleidimo keliai ir atsakomybės yra dizaino dalis, o ne tema tik po produkcinio paleidimo.
Kada prasminga paslaugomis orientuota architektūra
- kai keli klientai turi prieiti prie tos pačios verslo logikos
- kai foniniai procesai neturėtų būti priklausomi nuo atskirų darbo vietų
- kai portalai, darbalaukio programos ir trečiųjų šalių sistemos kontroliuojamai naudoja tą pačią duomenų bazę
- kai leidimų valdymas, eksploatavimas ir techninė atsakomybė turi išlikti skaliuojami
Nėra API be architektūros
Tikroji pridėtinė vertė nekyla dėl vieno endpoint’o, o dėl serverio suskirstymo, kuris nuosekliai perkelia teises, procesus ir duomenis į eksploatavimą.
REST-Server und Dienste als Teil derselben Fachlogik
Daugelyje įmonių API ir foninės paslaugos atsiranda per vėlai ir spaudimo sąlygomis. Tada darbalaukio sistema vėliau praplėtoma sąsajomis, o verslo taisyklės lieka paslėptos kliento pusėje. Tai beveik neišvengiamai veda prie neatitikimų: ta pati taisyklė egzistuoja kelis kartus, klaidų vaizdai tampa sunkiau sekti ir eksploatacija priklauso nuo specifinių žinių.
Mes einame priešinga kryptimi. Jei sistema reikalauja portalų, integracijų, importų, eksportų, licencijų patikrinimų ar foninio apdorojimo, atsakomybė tarp kliento, REST-Server und Dienst frueh geklaert werden. Welche Logik ist fachlich zentral? Welche Aktionen müssen reproduzierbar sein? Wie werden Fehlersituationen protokolliert? Wie können Datenflüsse später erweitert werden, ohne wieder am Monolithen haengen zu bleiben?
Ypač svarbu tai Delphi-Systemuose. Daugelė vertingos verslo logikos dažnai jau yra esamame kode. Tas, kas iš to išveda REST-Server oder Linux- und Windows-Services, neturėtų tiesiog kopijuoti šaltinio kodo, o turi aiškiai atskirti bendrą sritinę bazę nuo programos. Tik tada atsiranda API ir paslaugos, kurios naudoja tą pačią semantiką kaip ir klientas.
Serverio logika su domenine autoriteta
Endpointai neturėtų tik tiek duomenų, bet atspindėti tas pačias taisykles, teises ir proceso žingsnius, kurie galioja ir pagrindinėje sistemoje.
Paslaugos pasikartojantiems proceso žingsniams
Importai, sulyginimai, eksportai, sinchronizacijos ir pranešimai neturėtų būti dedami į atsitiktinius kliento šalutinius keliukus, o į stebimus servisus.
Eksploatavimą įtraukti nuo pat pradžių
Monitoringas, žurnalavimas, perkrovimo elgsena, konfigūracija ir leidimų procesas priklauso Services ir REST-serverių architektūros branduoliui ir neturėtų būti perkeliami į pataisų etapą po paleidimo.
Ką įmonės turėtų žinoti apie REST ir servisus
Svarbiausia klaida dažniausiai nėra techninė, o struktūrinė: projektas mano, kad su API architektūros klausimas jau išspręstas. Iš tiesų jis ten tik prasideda. API, portalai, darbalaukio klientai ir servisai turi suprasti tą pačią duomenų bazę, tas pačias vaidmenis ir tas pačias dalykines taisykles.
Kai ši linija nustatyta, plėtinius galima planuoti kur kas saugiau. Portalas gali pasiekti tą pačią serverio logiką, foniniai servisai gali kontroliuojamai apdoroti tuos pačius objektus ir trečiųjų šalių integracijos lieka prijungtos prie aiškios dalykinės vietos. Iš šios perspektyvos mes traktuojame Daugiaplatforminius klientus, serverio logiką ir duomenų saugojimą kaip vieningą sistemą, o ne kaip laisvus atskirus komponentus.
Galiausiai gerą REST ir servisų architektūrą galima atpažinti ne pagal tai, kaip moderniai ji skamba, o pagal tai, kaip ramiai ją vėliau bus galima eksploatuoti. Kai palaikymo atvejai lieka suprantami, klaidų keliai matomi ir nauji reikalavimai nebe baigiasi per specialius sprendimus senajame kode, tikrasis techninis laimėjimas pasiekiamas.
Kaip atpažinti, kad REST ir servisai turi būti architektūriškai tvarkingai paruošti
Kai keli klientai, integracijos ar foniniai procesai reikalauja tų pačių taisyklių, iš API idėjos tampa sistemos klausimas. Būtent ten nusprendžiama, ar vėliau bus ramybė, ar nuolatinė trintis.
Dalykinės taisyklės turi būti vieningoje vietoje
API ir servisai tampa tvarūs tik tada, kai jie veikia pagal tą pačią logiką kaip klientas, portalas ir duomenų modelis.
Žurnalai, perkrovimai ir klaidų matomumas yra projekto dalis
Švari foninė logika matoma ne pagal galinį tašką, o pagal ramų elgesį gamybinėje eksploatacijoje.
Naujos integracijos lieka valdomos
Kas anksti aiškiai atskiria serverio logiką, gali žymiai kontroliuojamiau plėsti portalus, eksportus ir trečiųjų šalių integracijas.
Ką pirmasis architektūros įvertinimas REST ir servisams turėtų pateikti
Didžiausias svertas dažnai nėra framework’e, o aiškioje atsakomybių paskirstyme tarp kliento, serverio ir foninių procesų.
- įvertinimą, kuri logika turi likti dalykinė ir centralizuota, o kas turi būti perkelta į servisus
- apžvalgą apie vaidmenis, duomenų srautus, žurnalavimą ir technines eksploatacijos būsenas
- pradinį įgyvendinimo kelią API, foniniams darbams ir integracijoms, be nekontroliuojamos paralelinės sistemos
Tvarkyti serverio logiką prieš jos nekontroliuojamą išsiplėtimą
Jei API, darbai ar portalai jau kelia problemų, dabar yra tinkamas laikas aiškiai sutvirtinti bendrą dalykinį branduolį.
DUK apie REST serverius ir paslaugas
Daugeliu atvejų sistemos žlunga ne dėl API idėjos, o dėl to, kad serverio logika vėliau improvizuojamai pridedama prie esamos darbalaukio kodo bazės. Mes šias dalis sąmoningai planuojame kartu.
Kada įmonės programai papildomai reikalingas REST serveris?
Kai keli klientai, portalai, mobilios prieigos, išorinės integracijos arba atjungti procesai turi valdomai naudoti tą pačią verslo logiką.
Ar palaikote ir Windows bei Linux paslaugas?
Taip. Foniniai procesai, laiko valdymas, sinchronizacija, eksportai, licencijų paslaugos ir techniniai lydintys procesai yra mūsų įprastų užduočių dalis.
Kaip išlaikomas verslo logikos nuoseklumas tarp kliento, REST ir paslaugos?
Per architektūrą, kur verslo taisyklės nėra paslėptos atskirose vartotojo sąsajose, o lieka bendrai prieinamos ir lengvai atsekamos.
Peržiūrėti surinktus papildomus klausimus
Šie trumpi atsakymai lieka čia puslapyje. Pagrindinėje DUK pradžios puslapyje mes šią temą papildomai susiejame su architektūra, modernizavimu, platformomis ir eksploatavimu.