Hierdie artikel bevat 'n paar algemene patrone om ingenieurs te help om met grootskaalse dienste te werk waartoe miljoene gebruikers toegang kry.
Volgens die skrywer se ervaring is dit nie 'n volledige lys nie, maar inderdaad effektief raad. So, kom ons begin.
Met ondersteuning vertaal .
Toegangsvlak
Die maatreëls wat hieronder gelys word, is relatief eenvoudig om te implementeer, maar het 'n hoë impak. As jy dit nog nie voorheen probeer het nie, sal jy verbaas wees oor die beduidende verbeterings.
Infrastruktuur as kode
Die eerste deel van die advies is om infrastruktuur as kode te implementeer. Dit beteken dat jy 'n programmatiese manier moet hê om die hele infrastruktuur te ontplooi. Dit klink ingewikkeld, maar ons praat eintlik van die volgende kode:
Ontplooiing van 100 virtuele masjiene
- met Ubuntu
- 2 GB RAM elk
- hulle sal die volgende kode hê
- met hierdie parameters
Jy kan veranderinge aan jou infrastruktuur opspoor en vinnig daarna terugkeer met weergawebeheer.
Die modernis in my sê jy kan Kubernetes/Docker gebruik om al die bogenoemde te doen, en hy is reg.
Daarbenewens kan u outomatisering verskaf deur Chef, Puppet of Terraform te gebruik.
Deurlopende integrasie en aflewering
Om 'n skaalbare diens te skep, is dit belangrik om 'n bou- en toetspyplyn vir elke trekversoek te hê. Selfs al is die toets baie eenvoudig, sal dit ten minste verseker dat die kode wat jy ontplooi saamstel.
Elke keer op hierdie stadium beantwoord jy die vraag: sal my vergadering toetse saamstel en slaag, is dit geldig? Dit lyk dalk na 'n lae balk, maar dit los baie probleme op.
Daar is niks mooier as om hierdie bosluise te sien nie
Vir hierdie tegnologie kan jy Github, CircleCI of Jenkins evalueer.
Lasbalanseerders
Dus, ons wil 'n lasbalanseerder gebruik om verkeer te herlei en gelyke las op alle nodusse te verseker of die diens gaan voort in geval van mislukking:
'n Lasbalanseerder doen gewoonlik 'n goeie werk om verkeer te versprei. Die beste praktyk is om te oorbalanseer sodat jy nie 'n enkele punt van mislukking het nie.
Tipies word lasbalanseerders opgestel in die wolk wat jy gebruik.
RayID, korrelasie ID of UUID vir versoeke
Het jy al ooit 'n toepassingsfout teëgekom met 'n boodskap soos hierdie: "Iets het verkeerd geloop. Stoor hierdie ID en stuur dit na ons ondersteuningspan"?
'n Unieke identifiseerder, korrelasie-ID, RayID, of enige van die variasies, is 'n unieke identifiseerder wat jou toelaat om 'n versoek regdeur sy lewensiklus op te spoor. Dit laat jou toe om die hele versoekpad in die logs op te spoor.
Die gebruiker rig 'n versoek aan stelsel A, dan kontak A B, wat C kontak, stoor dit in X, en dan word die versoek teruggestuur na A
As jy op afstand aan virtuele masjiene sou koppel en probeer om die versoekpad op te spoor (en met die hand korreleer watter oproepe gemaak word), sal jy mal word. Om 'n unieke identifiseerder te hê, maak die lewe baie makliker. Dit is een van die eenvoudigste dinge wat u kan doen om tyd te bespaar namate u diens groei.
Gemiddelde vlak
Die advies hier is meer kompleks as die voriges, maar die regte gereedskap maak die taak makliker en bied selfs vir klein en mediumgrootte maatskappye 'n opbrengs op belegging.
Gesentraliseerde aantekening
Baie geluk! Jy het 100 virtuele masjiene ontplooi. Die volgende dag kom die HUB en kla oor 'n fout wat hy gekry het terwyl hy die diens getoets het. Dit rapporteer die ooreenstemmende ID waaroor ons hierbo gepraat het, maar jy sal deur die logs van 100 masjiene moet kyk om die een te vind wat die ongeluk veroorsaak het. En dit moet gevind word voor môre se aanbieding.
Alhoewel dit na 'n prettige avontuur klink, is dit die beste om seker te maak dat jy die vermoë het om al die tydskrifte op een plek te deursoek. Ek het die probleem opgelos om logs te sentraliseer deur die ingeboude funksionaliteit van die ELK-stapel te gebruik: dit ondersteun soekbare logboekversameling. Dit sal regtig help om die probleem op te los om 'n spesifieke joernaal te vind. As 'n bonus kan jy kaarte en ander prettige dinge soos dit skep.
ELK stapel funksionaliteit
Moniteringsagente
Noudat jou diens aan die gang is, moet jy seker maak dat dit glad verloop. Die beste manier om dit te doen is om verskeie uit te voer agente, wat parallel werk en kyk of dit werk en basiese bewerkings uitgevoer word.
Op hierdie stadium kontroleer jy dit die hardloopbou voel goed en werk goed.
Vir klein tot mediumgrootte projekte beveel ek Postman aan vir die monitering en dokumentasie van API's. Maar oor die algemeen wil u net seker maak dat u 'n manier het om te weet wanneer 'n onderbreking plaasgevind het en betyds in kennis gestel word.
Outoskaal afhangende van vrag
Dit is baie eenvoudig. As jy 'n VM-diensversoeke het en dit nader 80% geheuegebruik, kan jy óf sy hulpbronne vergroot óf meer VM's by die groep voeg. Outomatiese uitvoering van hierdie bewerkings is uitstekend vir elastiese kragveranderings onder las. Maar jy moet altyd versigtig wees oor hoeveel geld jy spandeer en redelike perke stel.
Met die meeste wolkdienste kan u dit instel om outomaties te skaal deur meer bedieners of kragtiger bedieners te gebruik.
Eksperiment stelsel
'n Goeie manier om opdaterings veilig uit te voer, is om iets vir 'n uur vir 1% van gebruikers te kan toets. Jy het natuurlik sulke meganismes in aksie gesien. Byvoorbeeld, Facebook wys dele van die gehoor 'n ander kleur of verander die lettergrootte om te sien hoe gebruikers die veranderinge waarneem. Dit word A/B-toetsing genoem.
Selfs die vrystelling van 'n nuwe kenmerk kan as 'n eksperiment begin word en dan bepaal word hoe om dit vry te stel. Jy kry ook die vermoë om die konfigurasie dadelik te "onthou" of te verander op grond van die funksie wat agteruitgang in jou diens veroorsaak.
Gevorderde vlak
Hier is wenke wat nogal moeilik is om te implementeer. Jy sal waarskynlik 'n bietjie meer hulpbronne nodig hê, so 'n klein of mediumgrootte maatskappy sal dit moeilik vind om dit te bestuur.
Blou-groen ontplooiings
Dit is wat ek die "Erlang" manier van ontvou noem. Erlang het wyd gebruik geword toe telefoonmaatskappye verskyn het. Sagteskakelaars het begin gebruik word om telefoonoproepe te stuur. Die hoofdoel van die sagteware op hierdie skakelaars was om nie oproepe tydens stelselopgraderings te laat val nie. Erlang het 'n lekker manier om 'n nuwe module te laai sonder om die vorige een te crash.
Hierdie stap hang af van die teenwoordigheid van 'n lasbalanseerder. Kom ons stel ons voor dat jy weergawe N van jou sagteware het, en dan wil jy weergawe N+1 ontplooi.
Вы ons kon stop net die diens en ontplooi die volgende weergawe op 'n tyd wat vir jou gebruikers werk en kry 'n bietjie stilstand. Maar gestel jy het werklik streng SLA voorwaardes. Dus, SLA 99,99% beteken dat u vanlyn kan gaan slegs met 52 minute per jaar.
As jy regtig sulke aanwysers wil bereik, benodig jy twee ontplooiings op dieselfde tyd:
- die een wat nou reg is (N);
- volgende weergawe (N+1).
Jy vertel die lasbalanseerder om 'n persentasie verkeer na die nuwe weergawe (N+1) te herlei terwyl jy aktief monitor vir regressies.
Hier het ons 'n groen N-ontplooiing wat goed werk. Ons probeer om na die volgende weergawe van hierdie ontplooiing te beweeg
Eerstens stuur ons 'n baie klein toets om te sien of ons N+1-ontplooiing met 'n klein hoeveelheid verkeer werk:
Ten slotte het ons 'n stel outomatiese kontroles wat ons uiteindelik uitvoer totdat ons ontplooiing voltooi is. As jy baie baie versigtig, jy kan ook jou N-ontplooiing vir ewig stoor vir 'n vinnige terugrol in geval van slegte regressie:
As jy na 'n selfs meer gevorderde vlak wil gaan, laat alles in die blougroen-ontplooiing outomaties loop.
Anomalie opsporing en outomatiese versagting
Aangesien u gesentraliseerde aantekening en goeie loginsameling het, kan u reeds hoër doelwitte stel. Voorspel byvoorbeeld mislukkings proaktief. Funksies word op monitors en in logs nagespoor en verskeie diagramme word gebou - en jy kan vooraf voorspel wat verkeerd gaan loop:
Sodra afwykings opgespoor is, begin jy om sommige van die leidrade wat die diens verskaf, te ondersoek. Byvoorbeeld, 'n styging in SVE-lading kan aandui dat 'n hardeskyf misluk, terwyl 'n styging in versoeke kan aandui dat jy moet opskaal. Hierdie soort statistiese data laat jou toe om die diens proaktief te maak.
Met hierdie insigte kan jy in enige dimensie skaal en proaktief en reaktief die eienskappe van masjiene, databasisse, verbindings en ander hulpbronne verander.
Dit is al!
Hierdie lys van prioriteite sal jou baie probleme bespaar as jy 'n wolkdiens opstel.
Die skrywer van die oorspronklike artikel nooi lesers uit om hul kommentaar te lewer en veranderinge aan te bring. Die artikel word as oopbron versprei, trek versoeke deur die skrywer .
Wat anders om te lees oor die onderwerp:
Bron: will.com