Arhitectura serviciilor este o abordare de proiectare software care rezolvă o problemă cu o serie de servicii autonome.

Analogie

O analogie rezonabilă pentru arhitectura serviciilor este o organizație precum o bancă. Banca împarte munca într-o varietate de servicii, cum ar fi servicii pentru clienți, servicii IT și servicii de gestionare a resurselor umane. Fiecare serviciu este independent și poate fi implementat în diferite birouri. Clienților fiecărui serviciu li se oferă un contract care stabilește ce se poate aștepta de la serviciu. De exemplu, gestionarea resurselor umane poate ajuta o echipă să recruteze personal nou cu un formular pe care echipa îl completează pentru a iniția procesul. Structura de servicii a companiei descompune problema complexă a operării unei bănci în mici funcții de gestionare.

Servicii

Serviciile sunt unități de software care îndeplinește o funcție. Sunt folosite pentru a împărți problemele complexe într-o serie de probleme mai simple. Serviciile sunt, de asemenea, concepute pentru a fi implementabile separat. Acesta este un avantaj major, deoarece vă permite să construiți sisteme extrem de scalabile și rezistente.

Reziliență

Resiliența este un termen pentru software care este fiabil în condițiile lumii reale, care include diverse tensiuni și eșecuri. Arhitectura de servicii este o tehnică utilă pentru construirea sistemelor care continuă să funcționeze atunci când lucrurile eșuează. Acest lucru se realizează prin arhitectura serviciilor pentru a fi autonome, astfel încât să nu depindă unul de celălalt. Serviciile pot fi apoi implementate în infrastructura cloud și scalate în sus și în jos, după cum este necesar. Când o instanță eșuează, serviciile sunt suficient de inteligente pentru a detecta acest lucru și automat găsiți o instanță care funcționează.

Servicii vs Componente

Serviciile și componentele sunt două moduri diferite de a împărți munca în bucăți gestionabile și reutilizabile. Diferența este că serviciile pot fi implementate singure. Componentele sunt implementate cu altceva și, prin urmare, nu sunt autonome. Serviciile pot fi construite din componente. De asemenea, componentele pot utiliza servicii.

Service Oriented Architecture (SOA)

Arhitectura orientată către servicii a fost un termen timpuriu pentru arhitectura de servicii care a fost adoptată și comercializată de mulți mari furnizori IT care l-au folosit pentru a vinde platforme SOA și middleware. Acesta a fost un mare mod al tehnologiei informației în jurul anului 2005, care a văzut multe implementări de sus în jos care implicau cumpărarea unui lot de software și apoi reproiectarea sistemelor existente pentru a se încadra într-o paradigmă SOA. O mare parte din această activitate a ratat complet punctul SOA, iar eșecurile proiectului au fost frecvente. Confuzia a plouat pe măsură ce experții IT au promovat sau au criticat SOA, adesea făcând lucrurile să sune cât mai complex posibil.

Microservicii

Toate gândurile mari și prostii care a înconjurat SOA la vârful popularității sale nu i-a împiedicat pe arhitecții calificați să își folosească ideile de bază în moduri eficiente și ușoare care au produs sisteme și aplicații fiabile, scalabile, gestionabile și rentabile. Aceasta a evoluat într-o nouă cultură a proiectării software cunoscută sub numele de microservicii, care este organizată în jurul unui set de principii pentru proiectarea serviciilor.

Exemplu

O companie de telecomunicații proiectează un sistem de facturare ca o serie de servicii implementabile separat. Fiecare serviciu este privit ca un produs separat care poate fi dezvoltat, întreținut și gestionat de diferite persoane. Serviciile sunt implementate în cloud și cuplate slab. Când o instanță de serviciu eșuează, celelalte servicii trec automat la o instanță care funcționează în continuare. Deși problema facturării telecomunicațiilor este extrem de complexă, niciun serviciu unic în arhitectură nu este complex, astfel încât fiecare să fie relativ ieftin de dezvoltat și administrat. Serviciile sunt în esență auto-organizate. Fiecare publică un API către celelalte servicii. Fiecare știe de ce are nevoie de la celelalte servicii și este suficient de inteligent pentru a parcurge instanțe eșuate pentru a găsi servicii care răspund. Cu alte cuvinte, arhitectura nu are controler central sau middleware.

Prezentare generală: arhitectura serviciilor
Tip
Definiție	O abordare de proiectare software care rezolvă o problemă cu o serie de servicii autonome.
Concepte conexe