Den här artikeln innehåller några vanliga mönster som hjälper ingenjörer att arbeta med storskaliga tjänster som miljontals användare har tillgång till.
Enligt författarens erfarenhet är detta inte en uttömmande lista, men faktiskt effektiv råd. Så, låt oss börja.
Översatt med support .
Första nivån
Åtgärderna nedan är relativt enkla att genomföra men har stor effekt. Om du inte har provat dem tidigare kommer du att bli förvånad över de betydande förbättringarna.
Infrastruktur som kod
Den första delen av rådet är att implementera infrastruktur som kod. Det betyder att du måste ha ett programmatiskt sätt att distribuera hela infrastrukturen. Det låter komplicerat, men vi pratar faktiskt om följande kod:
Utplacering av 100 virtuella maskiner
- med Ubuntu
- 2 GB RAM vardera
- de kommer att ha följande kod
- med dessa parametrar
Du kan spåra ändringar i din infrastruktur och snabbt återgå till dem med hjälp av versionskontroll.
Modernisten i mig säger att du kan använda Kubernetes/Docker för att göra allt ovan, och han har rätt.
Dessutom kan du tillhandahålla automatisering med hjälp av Chef, Puppet eller Terraform.
Kontinuerlig integration och leverans
För att skapa en skalbar tjänst är det viktigt att ha en bygg- och testpipeline för varje pull-begäran. Även om testet är väldigt enkelt kommer det åtminstone att säkerställa att koden du distribuerar kompilerar.
Varje gång i detta skede svarar du på frågan: kommer min assembly att kompilera och klara tester, är den giltig? Detta kan tyckas vara en låg nivå, men det löser många problem.
Det finns inget vackrare än att se dessa fästingar
För denna teknik kan du utvärdera Github, CircleCI eller Jenkins.
Lastbalanserare
Så vi vill köra en lastbalanserare för att omdirigera trafik och säkerställa lika belastning på alla noder eller så fortsätter tjänsten i händelse av fel:
En lastbalanserare gör vanligtvis ett bra jobb med att fördela trafiken. Den bästa praxisen är att överbalansera så att du inte har en enda punkt av misslyckande.
Vanligtvis konfigureras lastbalanserare i molnet du använder.
RayID, korrelations-ID eller UUID för förfrågningar
Har du någonsin stött på ett programfel med ett meddelande som detta: "Något gick fel. Spara detta id och skicka det till vårt supportteam"?
En unik identifierare, korrelations-ID, RayID eller någon av varianterna är en unik identifierare som låter dig spåra en begäran under hela dess livscykel. Detta låter dig spåra hela sökvägen för begäran i loggarna.
Användaren gör en förfrågan till system A, sedan kontaktar A B, som kontaktar C, lagrar den i X, och sedan returneras förfrågan till A
Om du skulle fjärransluta till virtuella maskiner och försöka spåra sökvägen för begäran (och manuellt korrelera vilka samtal som görs), skulle du bli galen. Att ha en unik identifierare gör livet mycket enklare. Detta är en av de enklaste sakerna du kan göra för att spara tid när din tjänst växer.
Genomsnittlig nivå
Råden här är mer komplexa än de tidigare, men rätt verktyg gör uppgiften lättare och ger avkastning på investeringen även för små och medelstora företag.
Centraliserad loggning
Grattis! Du har distribuerat 100 virtuella maskiner. Dagen efter kommer vd:n och klagar på ett fel han fått när han testade tjänsten. Den rapporterar motsvarande ID som vi pratade om ovan, men du måste titta igenom loggarna på 100 maskiner för att hitta den som orsakade kraschen. Och det måste hittas innan morgondagens presentation.
Även om det här låter som ett roligt äventyr, är det bäst att se till att du har möjlighet att söka i alla tidningar på ett ställe. Jag löste problemet med att centralisera loggar med den inbyggda funktionen i ELK-stacken: den stöder sökbar logginsamling. Detta kommer verkligen att hjälpa till att lösa problemet med att hitta en specifik tidskrift. Som en bonus kan du skapa diagram och andra roliga saker som det.
ELK stack funktionalitet
Övervakningsagenter
Nu när din tjänst är igång måste du se till att den fungerar smidigt. Det bästa sättet att göra detta är att köra flera agenter, som arbetar parallellt och kontrollerar att det fungerar och grundläggande operationer utförs.
Vid det här laget kontrollerar du det löpbygget känns bra och fungerar bra.
För små till medelstora projekt rekommenderar jag Postman för att övervaka och dokumentera API:er. Men generellt sett vill du bara se till att du har ett sätt att veta när ett avbrott har inträffat och bli meddelad i tid.
Autoskalning beroende på belastning
Det är väldigt enkelt. Om du har en virtuell datorservicebegäran och den närmar sig 80 % minnesanvändning kan du antingen öka dess resurser eller lägga till fler virtuella datorer i klustret. Automatisk utförande av dessa operationer är utmärkt för elastiska kraftförändringar under belastning. Men du bör alltid vara försiktig med hur mycket pengar du spenderar och sätta rimliga gränser.
Med de flesta molntjänster kan du konfigurera den för att automatiskt skala med fler servrar eller kraftfullare servrar.
Experimentsystem
Ett bra sätt att säkert rulla ut uppdateringar är att kunna testa något för 1 % av användarna under en timme. Du har naturligtvis sett sådana mekanismer i aktion. Till exempel visar Facebook delar av publiken en annan färg eller ändrar teckenstorleken för att se hur användarna uppfattar förändringarna. Detta kallas A/B-testning.
Även att släppa en ny funktion kan startas som ett experiment och sedan bestämmas hur den ska släppas. Du får också möjligheten att "komma ihåg" eller ändra konfigurationen i farten baserat på den funktion som orsakar försämring i din tjänst.
avancerad nivå
Här kommer tips som är ganska svåra att genomföra. Du kommer förmodligen att behöva lite mer resurser, så ett litet eller medelstort företag kommer att ha svårt att hantera detta.
Blågröna installationer
Detta är vad jag kallar "Erlang" sättet att utvecklas. Erlang blev mycket använd när telefonbolagen dök upp. Softswitchar började användas för att dirigera telefonsamtal. Huvudsyftet med programvaran på dessa switchar var att inte tappa samtal under systemuppgraderingar. Erlang har ett bra sätt att ladda en ny modul utan att krascha den tidigare.
Detta steg beror på närvaron av en lastbalanserare. Låt oss föreställa oss att du har version N av din programvara, och sedan vill du distribuera version N+1.
Вы vi kunde stoppa bara tjänsten och rulla ut nästa version vid en tidpunkt som fungerar för dina användare och få lite driftstopp. Men antar att du har verkligen strikta SLA-villkor. Så SLA 99,99% betyder att du kan gå offline endast med 52 minuter per år.
Om du verkligen vill uppnå sådana indikatorer behöver du två implementeringar samtidigt:
- den som är just nu (N);
- nästa version (N+1).
Du säger åt lastbalanseraren att omdirigera en procentandel av trafiken till den nya versionen (N+1) medan du aktivt övervakar efter regressioner.
Här har vi en grön N-utbyggnad som fungerar bra. Vi försöker gå vidare till nästa version av den här distributionen
Först skickar vi ett riktigt litet test för att se om vår N+1-distribution fungerar med en liten mängd trafik:
Slutligen har vi en uppsättning automatiska kontroller som vi så småningom kör tills vår implementering är klar. Om du väldigt mycket försiktig, du kan också spara din N-distribution för alltid för en snabb återställning i händelse av dålig regression:
Om du vill gå till en ännu mer avancerad nivå, låt allt i den blågröna driftsättningen köras automatiskt.
Avvikelsedetektering och automatisk minskning
Med tanke på att du har centraliserad loggning och bra logginsamling kan du redan nu sätta högre mål. Till exempel, proaktivt förutsäga misslyckanden. Funktioner spåras på monitorer och i loggar och olika diagram byggs - och du kan förutsäga i förväg vad som kommer att gå fel:
När anomalier upptäcks börjar du undersöka några av ledtrådarna som tjänsten tillhandahåller. Till exempel kan en topp i CPU-belastning indikera att en hårddisk går sönder, medan en ökning av förfrågningar kan indikera att du behöver skala upp. Denna typ av statistisk data gör att du kan göra tjänsten proaktiv.
Med dessa insikter kan du skala i vilken dimension som helst och proaktivt och reaktivt ändra egenskaperna hos maskiner, databaser, anslutningar och andra resurser.
Det är allt!
Den här prioriteringslistan kommer att spara dig många problem om du skaffar en molntjänst.
Författaren till den ursprungliga artikeln uppmanar läsarna att lämna sina kommentarer och göra ändringar. Artikeln distribueras som öppen källkod, pull-förfrågningar av författaren .
Vad mer att läsa om ämnet:
Källa: will.com