Diferente intre serviciile in cloud si fabricul de servicii – Azure Service Fabric

• 11/02/2017
• 6 minute de citit

In acest articol

Microsoft Azure Service Fabric este platforma de aplicatii cloud de generatie urmatoare pentru aplicatii distribuite extrem de scalabile si extrem de fiabile. Introduce multe functii noi pentru ambalare, implementare, actualizare si gestionare a aplicatiilor cloud distribuite.

Acesta este un ghid introductiv pentru migrarea aplicatiilor de la Cloud Services la Service Fabric. Se concentreaza in principal pe diferentele de arhitectura si design intre serviciile cloud si serviciile fabric.

Aplicatii si infrastructura

O diferenta fundamentala intre Cloud Services si Service Fabric este relatia dintre VM-uri, sarcini de lucru si aplicatii. O sarcina de lucru aici este definita ca fiind codul pe care il scrieti pentru a efectua o anumita sarcina sau pentru a furniza un serviciu.

• Serviciile cloud se refera la implementarea aplicatiilor ca VM-uri. Codul pe care il scrieti este strans cuplat la o instanta VM, cum ar fi un rol web sau de lucru. Pentru a implementa o sarcina de lucru in Cloud Services este sa implementati una sau mai multe instante VM care ruleaza volumul de lucru. Nu exista separare de aplicatii si VM-uri, deci nu exista o definitie formala a unei aplicatii. O aplicatie poate fi considerata ca un set de instante Web sau Rol de lucrator in cadrul unei implementari Cloud Services sau ca o intreaga implementare Cloud Services. In acest exemplu, o aplicatie este afisata ca un set de instante de rol.

• Service Fabric se refera la implementarea aplicatiilor pe masinile virtuale sau masinile existente care ruleaza Service Fabric pe Windows sau Linux. Serviciile pe care le scrieti sunt complet decuplate de infrastructura de baza, care este extrasa de platforma de aplicatii Service Fabric, astfel incat o aplicatie poate fi implementata in mai multe medii. O incarcatura de lucru in Service Fabric se numeste „serviciu” si unul sau mai multe servicii sunt grupate intr-o aplicatie definita formal care ruleaza pe platforma de aplicatii Service Fabric. Mai multe aplicatii pot fi implementate intr-un singur cluster Service Fabric.

Service Fabric in sine este un strat de platforma de aplicatie care ruleaza pe Windows sau Linux, in timp ce Cloud Services este un sistem pentru implementarea de masini virtuale gestionate de Azure cu incarcaturi de lucru atasate. Modelul aplicatiei Service Fabric prezinta o serie de avantaje:

• Timpi de implementare rapide. Crearea instantelor VM poate necesita mult timp. In Service Fabric, VM-urile sunt implementate o singura data pentru a forma un cluster care gazduieste platforma de aplicatii Service Fabric. Din acel moment, pachetele de aplicatii pot fi implementate in cluster foarte repede.
• Gazduire de inalta densitate. In Cloud Services, o masina virtuala cu rol de lucrator gazduieste o singura sarcina de lucru. In Service Fabric, aplicatiile sunt separate de VM-urile care le ruleaza, ceea ce inseamna ca puteti implementa un numar mare de aplicatii intr-un numar mic de VM-uri, ceea ce poate reduce costul global pentru implementari mai mari.
• Platforma Service Fabric poate rula oriunde are masini Windows Server sau Linux, indiferent daca este Azure sau local. Platforma ofera un strat de abstractizare asupra infrastructurii de baza, astfel incat aplicatia dvs. sa poata rula pe diferite medii.
• Gestionarea distribuita a aplicatiilor. Service Fabric este o platforma care gazduieste nu numai aplicatiile distribuite, ci ajuta si la gestionarea ciclului lor de viata independent de VM-ul de gazduire sau de ciclul de viata al masinii.

Arhitectura aplicatiei

Arhitectura unei aplicatii Cloud Services include, de obicei, numeroase dependente de servicii externe, cum ar fi Service Bus, Azure Table si Blob Storage, SQL, Redis si altele pentru a gestiona starea si datele unei aplicatii si comunicarea intre rolurile web si lucratorii intr-un cloud Implementarea serviciilor. Un exemplu de aplicatie completa Cloud Services ar putea arata astfel:

Aplicatiile Service Fabric pot alege, de asemenea, sa utilizeze aceleasi servicii externe intr-o aplicatie completa. Folosind acest exemplu de arhitectura Cloud Services, cea mai simpla cale de migrare de la Cloud Services la Service Fabric este de a inlocui doar implementarea Cloud Services cu o aplicatie Service Fabric, pastrand arhitectura generala la fel. Rolurile web si ale lucratorilor pot fi portate la serviciile fara stare Service Fabric cu modificari minime de cod.

In aceasta etapa, sistemul ar trebui sa continue sa functioneze la fel ca inainte. Profitand de caracteristicile de stare ale Service Fabric, magazinele de stat externe pot fi internalizate ca servicii de stare, daca este cazul. Acest lucru este mai implicat decat o simpla migrare a rolurilor web si ale lucratorilor catre serviciile fara stare Service Fabric, deoarece necesita scrierea de servicii personalizate care sa ofere functionalitati echivalente aplicatiei dvs., asa cum faceau anterior serviciile externe. Beneficiile acestui lucru includ:

• Eliminarea dependentelor externe
• Unificarea modelelor de implementare, gestionare si actualizare.

Un exemplu arhitectural rezultat de internalizare a acestor servicii ar putea arata astfel:

Comunicare si flux de lucru

Majoritatea aplicatiilor Cloud Service constau din mai multe niveluri. In mod similar, o aplicatie Service Fabric consta din mai multe servicii (de obicei mai multe servicii). Doua modele comune de comunicare sunt comunicarea directa si prin intermediul unui stocare durabila externa.

Comunicare directa

Cu comunicarea directa, nivelurile pot comunica direct prin punctul final expus de fiecare nivel. In medii fara stat, cum ar fi Cloud Services, aceasta inseamna selectarea unei instante a unui rol VM, fie aleatoriu, fie round-robin pentru a echilibra incarcatura si conectarea directa la punctul sau final.

Comunicarea directa este un model comun de comunicare in Service Fabric. Diferenta cheie intre Service Fabric si Cloud Services este ca in Cloud Services va conectati la o VM, in timp ce in Service Fabric va conectati la un serviciu. Aceasta este o distinctie importanta din cateva motive:

• Serviciile din Service Fabric nu sunt legate de VM-urile care le gazduiesc; serviciile se pot deplasa in cluster si, de fapt, se asteapta sa se deplaseze din diverse motive: echilibrarea resurselor, trecerea la eroare, actualizarea aplicatiilor si infrastructurii si constrangeri de plasare sau incarcare. Aceasta inseamna ca adresa unei instante de serviciu se poate modifica oricand.
• O VM din Service Fabric poate gazdui mai multe servicii, fiecare cu puncte finale unice.

Service Fabric ofera un mecanism de descoperire a serviciilor, numit Serviciu de denumire, care poate fi utilizat pentru a rezolva adresele punctelor finale ale serviciilor.

Cozi

Un mecanism comun de comunicare intre niveluri in medii fara stat, cum ar fi Cloud Services, este utilizarea unei cozi de stocare externe pentru a stoca in mod durabil sarcinile de lucru de la un nivel la altul. Un scenariu obisnuit este un nivel web care trimite lucrari la o coada Azure sau la un autobuz de serviciu, unde instantele Rolului lucratorului pot stoarce si procesa lucrarile.

Acelasi model de comunicare poate fi utilizat in Service Fabric. Acest lucru poate fi util atunci cand migrati o aplicatie Cloud Services existenta la Service Fabric.

Paritate

Cloud Services este similar cu Service Fabric in ceea ce priveste gradul de control fata de usurinta de utilizare, dar acum este un serviciu vechi si Service Fabric este recomandat pentru o noua dezvoltare; urmatoarea este o comparatie API:

Cloud Service API Service Fabric API NoteGetClusterManifest si apucati tipurile de rol / nod de acolo. RoleEnvironment.GetIsAvailable Connect-WindowsFabricCluster sau creati un FabricRuntime indreptat catre un anumit nod * RoleEnvironment.GetLocalResource CodePackageActivationContext.Log / Temp / Work * RoleEnvironment.GetCurrentRoleInstance CodePackageActivationContext / LocalCage / Code .GetInstances FabricClient.QueryManager.GetNodeList sau ResolveService * RoleInstanceEndpoint.GetIPEndpoint FabricRuntime.GetActivationContext sau Naming (ResolveService) *

Pasii urmatori

Cea mai simpla cale de migrare de la Cloud Services la Service Fabric este de a inlocui doar implementarea Cloud Services cu o aplicatie Service Fabric, pastrand arhitectura generala a aplicatiei dvs. aproximativ aceeasi. Urmatorul articol ofera un ghid care va ajuta sa convertiti un rol Web sau de lucrator intr-un serviciu apatrid Service Fabric.

• Migratie simpla: convertiti un rol web sau de lucrator intr-un serviciu apatrid Service Fabric