Vad är ett servicenät? Lättare containernätverk

En av de förändringar som sker inom IT under flaggan för digital transformation är nedbrytningen av stora, monolitiska applikationer till mikrotjänster - små, diskreta funktioner - som körs i behållare - mjukvarupaket som innehåller all tjänstens kod och beroenden som kan isoleras och enkelt flyttas från en server till en annan.

Containeriserade arkitekturer som dessa är lätta att skala upp och köras i molnet, och enskilda mikrotjänster kan snabbt rullas ut och upprepas. Kommunikationen mellan dessa mikrotjänster blir dock alltmer komplex eftersom applikationer blir större och flera instanser av samma tjänst körs samtidigt. Ett servicenät är en framväxande arkitektonisk form som syftar till att dynamiskt ansluta dessa mikrotjänster på ett sätt som minskar administrativt och programmeringsutgifter.

Vad är ett servicenät?

I vid bemärkelse är ett servicenät, som Red Hat beskriver det, ”ett sätt att kontrollera hur olika delar av en applikation delar data med varandra.” Denna beskrivning kan dock omfatta många olika saker. Det låter faktiskt väldigt mycket som den mellanprogramvara som de flesta utvecklare känner till från klientserverapplikationer.

Det som gör ett servicenät unikt är att det är byggt för att tillgodose distribuerade mikroservicemiljöers unika natur. I en storskalig applikation byggd från mikrotjänster kan det finnas flera instanser av en viss tjänst som körs över olika lokala servrar eller molnservrar. Alla dessa rörliga delar gör det uppenbarligen svårt för enskilda mikrotjänster att hitta de andra tjänsterna de behöver kommunicera med. Ett servicenät tar hand om att upptäcka och ansluta tjänster direkt från ögonblick så att både mänskliga utvecklare och enskilda mikrotjänster inte behöver.

Tänk på ett servicenät som motsvarande mjukvarudefinierat nätverk (SDN) för nivå 7 i OSI-nätverksmodellen. Precis som SDN skapar ett abstraktionslager så att nätverksadministratörer inte behöver hantera fysiska nätverksanslutningar, avkopplar ett servicenät applikationens underliggande infrastruktur från den abstrakta arkitekturen som du interagerar med.

Idén om ett servicenät uppstod organiskt när utvecklare började ta itu med problemen med riktigt enorma distribuerade arkitekturer. Linkerd, det första projektet inom detta område, föddes som en utlöpare för ett internt projekt på Twitter. Istio, ett annat populärt servicenät med stor företagsstöd, har sitt ursprung i Lyft. (Vi kommer att titta mer detaljerat på båda dessa projekt på ett ögonblick.)

Lastnätbalansering för service

En av de viktigaste funktionerna som ett servicenät tillhandahåller är lastbalansering . Vi tänker vanligtvis på lastbalansering som en nätverksfunktion - du vill förhindra att någon server eller nätverkslänk blir överväldigad av trafik, så du dirigerar dina paket därefter. Servicemaskor gör något liknande på applikationsnivå, som Twain Taylor beskriver, och förståelse som ger dig en god känsla för vad vi menar när vi säger att ett servicenät är som programvarudefinierat nätverk för applikationslagret.

I grund och botten är ett av uppdragen i servicenätet att hålla reda på vilka förekomster av olika mikrotjänster fördelade över infrastrukturen som är "hälsosammaste". Det kan undersöka dem för att se hur de gör eller hålla reda på vilka instanser som svarar långsamt på tjänsteförfrågningar och skicka efterfrågade förfrågningar till andra instanser. Tjänstnätet kan göra liknande arbete för nätverksvägar, och märker när meddelanden tar för lång tid att nå sin destination och tar andra vägar för att kompensera. Dessa avmattningar kan bero på problem med den underliggande hårdvaran, eller helt enkelt på att tjänsterna är överbelastade med förfrågningar eller arbetar med deras bearbetningskapacitet. Det viktiga är att servicenätet kan hitta en annan instans av samma tjänst och väg till den istället och därmed utnyttja den totala applikationens kapacitet mest effektivt.

Servicenät mot Kubernetes

Om du är lite bekant med containerbaserade arkitekturer kanske du undrar var Kubernetes, den populära open source container orkestreringsplattformen, passar in i den här bilden. Trots allt är inte hela poängen med Kubernetes att den hanterar hur dina containrar kommunicerar med varandra? Som Kublr-teamet påpekar på sin företagsblogg kan du tänka på Kubernetes ”service” -resurs som en mycket grundläggande typ av servicenät, eftersom det tillhandahåller tjänsteupptäckt och balansering av förfrågningar. Men fullt utrustade servicemaskor ger mycket mer funktionalitet, som att hantera säkerhetspolicyer och kryptering, "kretsbrytning" för att avbryta förfrågningar om långsamma svar, belastningsbalansering som vi beskriver ovan och mycket mer.

Tänk på att de flesta servicemaskor faktiskt kräver att ett orkestreringssystem som Kubernetes är på plats. Servicemaskor erbjuder utökad funktionalitet, inte en ersättning.

Servicemesh kontra API-gateways

Varje mikrotjänst tillhandahåller ett applikationsprogrammeringsgränssnitt (API) som fungerar som det sätt på vilket andra tjänster kommunicerar med den. Detta väcker frågan om skillnaderna mellan ett servicenät och andra mer traditionella former av API-hantering, som API-gateways . Som IBM förklarar står en API-gateway mellan en grupp mikrotjänster och den "externa" världen och routar tjänsteförfrågningar efter behov så att begäran inte behöver veta att den har att göra med en mikrotjänstbaserad applikation. Ett servicenät förmedlar däremot förfrågningar "inuti" mikroserviceappen, där de olika komponenterna är fullt medvetna om sin miljö.

Ett annat sätt att tänka på det, som Justin Warren skriver i Forbes , är att ett servicenät är för öst-väst-trafik inom ett kluster och en API-gateway är för nord-syd-trafik som går in och ut ur klustret. Men hela idén om ett servicenät är fortfarande tidigt och i flöde. Många servicenätverk - inklusive Linkerd och Istio - erbjuder nu också nord-syd-funktionalitet.

Service mesh-arkitektur

Idén om ett servicenät har dykt upp först under de senaste åren, och det finns många olika sätt att lösa problemet med "servicenät", dvs hantera kommunikation för mikrotjänster. Andrew Jenkins från Aspen Mesh identifierar tre möjliga val angående var kommunikationslagret som skapas av servicenätet kan leva:

  • I ett bibliotek som alla dina mikrotjänster importerar
  • I en nodagent som tillhandahåller tjänster till alla behållare på en viss nod
  • I en sidovagnscontainer som körs bredvid din applikationsbehållare

Sidobilarbaserade mönster är ett av de mest populära servicemaskmönstren där ute - så mycket att det på vissa sätt har blivit synonymt med servicemaskor i allmänhet. Även om det inte strikt är sant, har sidovagnstillvägagångssättet fått så mycket dragkraft att det här är arkitekturen vi ska titta mer detaljerat på.

Sidovagnar i servicenät

Vad betyder det att säga att en sidovagnscontainer "körs bredvid" din applikationsbehållare? Red Hat har en ganska bra förklaring. Varje mikrotjänstbehållare i ett servicenät av denna typ har en annan proxybehållare som motsvarar den. All logik som krävs för kommunikation mellan tjänst och tjänst dras ut ur mikrotjänsten och läggs i sidovagnen.

Detta kan verka komplicerat - trots allt fördubblar du faktiskt antalet containrar i din applikation! Men du använder också ett designmönster som är nyckeln till att förenkla distribuerade appar. Genom att lägga all den nätverks- och kommunikationskoden i en separat behållare har du gjort den till en del av infrastrukturen och befriat utvecklare från att implementera den som en del av applikationen.

I grund och botten är det du har kvar en mikrotjänst som kan vara laserfokuserad på dess affärslogik. Mikrotjänsten behöver inte veta hur man kommunicerar med alla andra tjänster i den vilda och galna miljö där de arbetar. Det behöver bara veta hur man kommunicerar med sidovagnen, som tar hand om resten.

Servicemaskor: Linkerd, Envio, Istio, Consul

Så vad är servicemaskorna tillgängliga för användning? Tja, det finns inte precis kommersiella produkter utan hylla där ute. De flesta servicenätverk är öppen källkodsprojekt som tar lite finagling att implementera. De stora namnen är:

  • Linkerd (uttalad "linker-dee") - Släpptes 2016, och därmed den äldsta av dessa erbjudanden, Linkerd skenades bort från ett bibliotek utvecklat på Twitter. En annan tung hitter i detta utrymme, Conduit, rullades in i Linkerd-projektet och utgör grunden för Linkerd 2.0.
  • Envoy - Skapad i Lyft upptar Envoy "dataplan" -delen av ett servicenät. För att tillhandahålla ett fullservicenät måste det paras ihop med ett "kontrollplan", som ...
  • Istio — Istio har utvecklats i samarbete av Lyft, IBM och Google och är en kontrollplan för att serva ombud som Envoy. Medan Istio och Envoy är ett standardpar kan var och en paras ihop med andra plattformar.
  • HashiCorp Consul — Introducerad med Consul 1.2, en funktion som heter Connect lagt till tjänstekryptering och identitetsbaserad auktorisering till HashiCorps distribuerade system för tjänsteupptäckt och konfiguration, vilket gör det till ett fullservicenät.

Vilket servicenät passar dig? En jämförelse ligger utanför denna artikel, men det är värt att notera att alla produkterna ovan har bevisats i stora och krävande miljöer. Linkerd och Istio har de mest omfattande funktionsuppsättningarna, men alla utvecklas snabbt. Du kanske vill kolla in George Mirandas uppdelning av funktionerna i Linkerd, Envoy och Istio, men kom ihåg att hans artikel skrevs innan Conduit och Linkerd gick ihop.

Tänk också på att detta utrymme är nytt och att nya konkurrenter kan dyka upp när som helst. Till exempel började Amazon i november 2018 erbjuda en offentlig förhandsvisning av ett AWS-servicenät. Med tanke på hur många butiker som använder Amazons offentliga moln bör AWS App Mesh ha stor inverkan.