Context

Dezvoltați o aplicație de întreprindere pe partea de server. Acesta trebuie să accepte o varietate de clienți diferiți, inclusiv browsere desktop, browsere mobile aplicații mobile native. Aplicația ar putea expune, de asemenea, un API pe care îl pot consuma terți. S-ar putea integra, de asemenea, cu alte aplicații, fie prin servicii web, fie printr-un broker de mesaje. accesarea unei baze de date; schimbul de mesaje cu alte sisteme; și returnarea unui răspuns HTML / JSON / XML. Există componente logice corespunzătoare diferitelor zone funcționale ale aplicației.

Problemă

Care este arhitectura de implementare a aplicației?

Forțe

• Există o echipă de dezvoltatori care lucrează la aplicație
• Noii membri ai echipei trebuie să devină rapid productivi
• Aplicația trebuie să fie ușor de înțeles și modificați
• Doriți să practicați implementarea continuă a aplicației
• Trebuie să rulați mai multe instanțe ale aplicației pe mai multe mașini pentru a satisface cerințele de scalabilitate și disponibilitate
• Doriți să profitați de tehnologiile emergente (cadre, limbaje de programare etc.)

Soluție

Definiți o arhitectură care structurează aplicația ca un set de cuplate slab, servicii de colaborare. Această abordare corespunde axei Y a Scale Cube. Fiecare serviciu este:

• Foarte întreținibil și testabil – permite ra dezvoltarea și implementarea frecventă și frecventă
• Împreună cu alte servicii – permite unei echipe să lucreze independent majoritatea timpului la serviciile lor, fără a fi afectate de modificările aduse altor servicii și fără a afecta alte servicii
• Implementabil independent – permite unei echipe să-și desfășoare serviciul fără a fi nevoie să se coordoneze cu alte echipe
• Capabil să fie dezvoltat de o echipă mică – esențial pentru o productivitate ridicată, evitând capul de comunicare ridicat al celor mari echipele

Serviciile comunică utilizând fie protocoale sincrone precum HTTP / REST sau protocoale asincrone precum AMQP. Serviciile pot fi dezvoltate și implementate independent unul de celălalt. Fiecare serviciu are propria bază de date pentru a fi decuplat de alte servicii. Coerența datelor între servicii este menținută folosind modelul Saga

Pentru a afla mai multe despre natura unui serviciu, vă rugăm să citiți acest articol.

Exemple

Aplicații de comerț electronic fictive pe

Să ne imaginăm că construiți o aplicație de comerț electronic care preia comenzi de la clienți, verifică stocurile și creditele disponibile și le expediază. Aplicația constă din mai multe componente, inclusiv StoreFrontUI, care implementează interfața cu utilizatorul , împreună cu unele servicii backend pentru verificarea creditului, menținerea inventarului și a comenzilor de expediere. Aplicația constă dintr-un set de servicii.

Arată-mi codul

Vă rugăm să consultați exemplele de aplicații dezvoltate de Chris Richardson. Aceste exemple de pe Github ilustrează diferite aspecte ale arhitecturii microservice.

Context rezultat

Beneficii

Această soluție are o serie de avantaje:

• Permite livrarea și implementarea continuă a aplicațiilor mari și complexe.
  • Mentenabilitate îmbunătățită – fiecare serviciu este relativ mic și, prin urmare, este mai ușor de înțeles și de modificat
  • Testabilitate mai bună – serviciile sunt mai mici și mai rapide de testat
  • Implementabilitate mai bună – servicii poate fi implementat independent
  • Vă permite să organizați efortul de dezvoltare în jurul mai multor echipe autonome. Fiecare echipă (așa-numitele două pizza) deține și este responsabilă pentru unul sau mai multe servicii. Fiecare echipă își poate dezvolta, testa, implementa și scala serviciile independent de toate celelalte echipe.
• Fiecare microserviciu este relativ mic:
  • Mai ușor pentru un dezvoltatorul să înțeleagă
  • IDE este mai rapid, făcând dezvoltatorii mai productivi
  • Aplicația pornește mai repede, ceea ce îi face pe dezvoltatori mai productivi și accelerează implementările
• Îmbunătățirea izolării defecțiunilor. De exemplu, dacă există o scurgere de memorie într-un singur serviciu, atunci doar acel serviciu va fi afectat. Celelalte servicii vor continua să gestioneze cererile. În comparație, o componentă care nu se comportă bine a unei arhitecturi monolitice poate duce la întreruperea întregului sistem.
• Elimină orice angajament pe termen lung față de o stivă de tehnologie. Când dezvoltați un serviciu nou, puteți alege o stivă de tehnologie nouă. În mod similar, atunci când faceți modificări majore unui serviciu existent, îl puteți rescrie folosind o stivă de tehnologie nouă.

Dezavantaje

Această soluție are mai multe dezavantaje:

• Dezvoltatorii trebuie să facă față complexității suplimentare a creării unui sistem distribuit:
  • Dezvoltatorii trebuie să implementeze mecanismul de comunicare între servicii și să facă față eșecului parțial
  • Implementarea cererilor care acoperă mai multe servicii este mai dificilă
  • Testarea interacțiunilor dintre servicii este mai mare dificil
  • Implementarea cererilor care acoperă mai multe servicii necesită o coordonare atentă între echipe
  • Instrumentele pentru dezvoltatori / IDE sunt orientate spre crearea de aplicații monolitice și nu oferă suport explicit pentru dezvoltarea aplicațiilor distribuite.
• Complexitatea implementării. În producție, există, de asemenea, complexitatea operațională a implementării și gestionării unui sistem format din mai multe servicii diferite.
• Consum crescut de memorie. Arhitectura microservice înlocuiește N instanțe de aplicație monolitice cu instanțe de servicii NxM. Dacă fiecare serviciu rulează în propria JVM (sau echivalent), care este de obicei necesar pentru a izola instanțele, atunci există cheltuielile generale de M ori mai multe runtime JVM. Mai mult, dacă fiecare serviciu rulează pe propria sa mașină virtuală (de exemplu, instanță EC2), așa cum este cazul la Netflix, cheltuielile generale sunt chiar mai mari.

Probleme

Există multe probleme pe care trebuie să le abordați.

Când să utilizați arhitectura microserviciului?

O provocare în utilizarea acestei abordări este să decideți când are sens să o utilizați. Când dezvoltați prima versiune a o aplicație, de multe ori nu aveți problemele pe care această abordare le rezolvă. În plus, utilizarea unei arhitecturi elaborate și distribuite va încetini dezvoltarea. Aceasta poate fi o problemă majoră pentru startup-urile a căror cea mai mare provocare este adesea modul de a evolua rapid modelul de afaceri și însoțirea Utilizarea divizărilor pe axa Y ar putea face mult mai dificilă iterarea rapidă. Mai târziu, însă, când provocarea este cum să scalați și trebuie să utilizați descompunerea funcțională, dependențele încurcate ar putea face dificilă descompunerea aplicației dvs. monolitice în un set de servicii.

Cum se descompune aplicația o altă provocare este aceea de a decide cum să partiționăm sistemul în microservicii. Aceasta este foarte mult o artă, dar există o serie de strategii care vă pot ajuta:

• Descompuneți-vă după capacitatea afacerii și definiți serviciile corespunzătoare capacităților afacerii.
• Descompuneți-vă după subdomeniul de proiectare bazat pe domenii.
• Descompuneți-vă prin verb sau caz de utilizare și definiți servicii care sunt responsabile pentru acțiuni specifice . de exemplu. un Shipping Service care este responsabil pentru expedierea comenzilor complete.
• Descompuneți prin nume sau resurse definind un serviciu care este responsabil pentru toate operațiunile asupra entităților / resurselor unui anumit tip. de exemplu. un Account Service care este responsabil pentru gestionarea conturilor de utilizator.

În mod ideal, fiecare serviciu ar trebui să aibă doar un set mic de responsabilități. (Unchiul) Bob Martin vorbește despre proiectarea de clase folosind Principiul de responsabilitate unică (SRP). SRP definește responsabilitatea unei clase ca un motiv de schimbare și afirmă că o clasă ar trebui să aibă un singur motiv de schimbare. Este logic să aplici SRP la proiectarea serviciilor. De asemenea.

O altă analogie care ajută la proiectarea serviciilor este proiectarea utilităților Unix. Unix oferă un număr mare de utilități, cum ar fi grep, cat și find. Fiecare utilitar face exact un lucru, adesea excepțional de bine, și este destinat să fie combinat cu alte utilitare care utilizează un script shell pentru a efectua sarcini complexe.

Cum se menține consistența datelor?

Pentru a asigura o cuplare slabă, fiecare serviciu are propriul său serviciu Menținerea coerenței datelor între servicii este o provocare, deoarece tranzacțiile de comitere / distribuire în două faze nu sunt o opțiune pentru multe aplicații. O aplicație trebuie să utilizeze în schimb modelul Saga. Un serviciu publică un eveniment atunci când datele sale se schimbă. Alte servicii consumă acel eveniment și își actualizează datele. Există mai multe moduri de actualizare fiabilă a datelor și publicarea evenimentelor, inclusiv Sourcing de evenimente și Transaction Log Tailing.

Cum să implementați interogări?

O altă provocare este implementarea interogărilor care trebuie să recupereze date deținute de mai multe servicii.

• API-ul Compoziție și comandă de interogare a modelelor de separare a responsabilității (CQRS).

Există multe modele legate de modelul de microservicii. Arhitectura monolitică este o alternativă la arhitectura microserviciului. Celelalte tipare abordează problemele pe care le veți întâlni atunci când aplicați arhitectura microserviciului.

• Modele de descompunere
  • Descompuneți în funcție de capacitatea afacerii
  • Decompuneți în funcție de subdomeniu
• Modelul bazei de date pe serviciu descrie modul în care fiecare serviciul are propria bază de date pentru a asigura cuplarea liberă.
• Modelul API Gateway definește modul în care clienții accesează serviciile într-o arhitectură de microserviciu.
• Modelele Discovery partea client și Server-side Discovery sunt utilizate pentru a direcționa cererile unui client către un instanță de serviciu disponibilă într-o arhitectură de microservice.
• Modelele de invocare a procedurilor de mesagerie și la distanță sunt două moduri diferite prin care serviciile pot comunica.
• Serviciile unice pe gazdă și serviciile multiple pentru fiecare gazdă sunt două strategii de implementare diferite.
• Modele de preocupări transversale: modelul șasiului Microservice și configurația externalizată
• Modelele de testare: Testul componentelor serviciului și Testul contractului de integrare a serviciilor
• Circuitul Întrerupător
• Jeton de acces
• Modele de observabilitate:
  • Agregare jurnal
  • Valori de aplicație
  • Jurnal de audit
  • Urmărirea distribuită
  • Urmărirea excepțiilor
  • API pentru verificarea stării
  • Jurnalul implementărilor și modificărilor
• Modele UI:
  • Compoziția fragmentului de pagină pe partea de server
  • Compoziția UI pe partea clientului

Utilizări cunoscute

Majoritatea site-urilor web la scară largă, inclusiv Netflix, Amazon și eBay, au evoluat de la o arhitectură monolitică la o arhitectură de microserviciu.

Netflix, care este un serviciu de streaming video foarte popular, responsabil pentru până la 30% din traficul pe Internet, are o arhitectură pe scară largă, orientată spre servicii. Se ocupă de peste un miliard de apeluri pe zi către API-ul lor de streaming video de la peste 800 de tipuri diferite de dispozitive. Fiecare API apelează fanii la o medie de șase apeluri către servicii de backend.

Amazon.com avea inițial o arhitectură pe două niveluri. Pentru a le scala au migrat către o arhitectură orientată spre servicii formată din sute de servicii backend. Mai multe aplicații apelează aceste servicii, inclusiv aplicațiile care implementează site-ul web Amazon.com și serviciul web API. Aplicația site-ului web Amazon.com apelează serviciile 100-150 pentru a obține date care obișnuiau să construiască o pagină web.

Site-ul de licitații ebay.com a evoluat, de asemenea, de la o arhitectură monolitică la o arhitectură orientată spre servicii. Nivelul aplicației constă din mai multe aplicații independente. Fiecare aplicație implementează logica de afaceri. pentru o anumită zonă funcțională, cum ar fi cumpărarea sau vânzarea. Fiecare aplicație utilizează divizări pe axa X și unele aplicații, cum ar fi căutarea, utilizează divizări pe axa Z. Ebay.com aplică, de asemenea, o combinație de scalare în stil X, Y și Z nivel de baze de date.

Există numeroase alte exemple de companii care utilizează arhitectura microservice.

Chris Richardson are exemple de aplicații bazate pe microservicii.

Vezi și

Consultați keynote-ul meu Code Freeze 2018, care oferă o bună introducere în arhitectura microservice.