TL; DR: Lýsing á arkitektúr biðlara-miðlara innra netstillingastjórnunarkerfis okkar, QControl. Það er byggt á tveggja laga samskiptareglum sem virkar með gzip-pakkuðum skilaboðum án þjöppunar á milli endapunkta. Dreifðir beinar og endapunktar fá stillingaruppfærslur og samskiptareglurnar sjálfar leyfa uppsetningu staðbundinna milliliða. Kerfið er byggt á meginreglunni ("nýlegt-stöðugt", útskýrt hér að neðan) og notar JMESpath fyrirspurnarmálið ásamt Jinja sniðmátsvélinni til að gera stillingarskrár.
Qrator Labs rekur alþjóðlegt dreift net til að draga úr árásum. Netið okkar starfar eftir anycast meginreglunni og undirnet eru auglýst í gegnum BGP. Þar sem við erum BGP anycast net sem er líkamlega staðsett á nokkrum svæðum á jörðinni, getum við unnið úr og síað ólögmæta umferð nær kjarna internetsins - Tier-1 rekstraraðila.
Aftur á móti er ekki auðvelt að vera landfræðilega dreift net. Samskipti milli viðverustaða nets eru mikilvæg fyrir öryggisþjónustuveituna til að hafa samræmda uppsetningu á öllum nethnútum og uppfæra þá tímanlega. Þess vegna þurftum við að finna leið til að samstilla stillingargögn á áreiðanlegan hátt milli heimsálfa til þess að veita neytendum sem mesta grunnþjónustu.
Í upphafi var Orðið. Það varð fljótt samskiptareglur sem þarfnast uppfærslu.
Hornsteinninn í tilveru QControl, og á sama tíma aðalástæðan fyrir því að eyða miklum tíma og fjármagni í að byggja upp samskiptareglur af þessu tagi, er þörfin á að fá eina viðurkennda uppsetningu og að lokum samstilla viðverustað okkar. með því. Geymslan sjálf var aðeins ein af nokkrum kröfum við þróun QControl. Að auki þurftum við einnig samþættingu við núverandi og fyrirhugaða þjónustu á viðverustöðum (POP), snjallar (og sérhannaðar) aðferðir fyrir gagnastaðfestingu, auk aðgangsstýringar. Fyrir utan þetta vildum við líka stjórna slíku kerfi með því að nota skipanir frekar en að gera breytingar á skrám. Fyrir QControl voru gögn send til viðverustaða nánast handvirkt. Ef einn af viðverustöðum væri ekki tiltækur og við gleymdum að uppfæra hann seinna myndi uppsetningin fara úr samstillingu og við þyrftum að eyða tíma í að koma henni aftur í gang.
Fyrir vikið komum við fram með eftirfarandi áætlun:
Stillingarþjónninn er ábyrgur fyrir sannprófun og geymslu gagna; beininn hefur nokkra endapunkta sem taka á móti og senda út stillingaruppfærslur frá viðskiptavinum og stuðningsteymum á netþjóninn og frá þjóninum til viðverustaða.
Gæði nettengingar eru enn mjög mismunandi um allan heim - til að sýna þetta atriði skulum við líta á einfaldan MTR frá Prag, Tékklandi til Singapúr og Hong Kong.
MTR frá Prag til Singapore
Sama með Hong Kong
Mikil leynd þýðir minni hraða. Að auki er pakkatap. Rásbreidd bætir ekki upp þennan vanda sem alltaf þarf að taka með í reikninginn þegar byggt er upp dreifð kerfi.
Full stilling á viðverustað er umtalsvert magn gagna sem þarf að senda til margra viðtakenda um óáreiðanlegar tengingar. Sem betur fer, þó að uppsetningin breytist stöðugt, gerist það í litlum skrefum.
Nýleg stöðug hönnun
Við getum sagt að það sé nokkuð augljós lausn að byggja upp dreift net byggt á meginreglunni um stigvaxandi uppfærslur. En það eru mörg vandamál með diff. Við þurfum að vista alla mismuni milli viðmiðunarpunktanna og einnig geta sent þá aftur ef einhver missti af hluta af gögnunum. Hver áfangastaður verður að beita þeim í strangt tilgreindri röð. Venjulega, ef um er að ræða nokkra áfangastaði, getur slík aðgerð tekið langan tíma. Viðtakandinn þarf líka að geta óskað eftir þeim hlutum sem vantar og að sjálfsögðu verður miðhlutinn að svara slíkri beiðni rétt og senda aðeins þau gögn sem vantar.
Fyrir vikið komumst við að frekar áhugaverðri lausn - við höfum aðeins eitt viðmiðunarlag, fast, við skulum kalla það stöðugt, og aðeins einn diff fyrir það - nýlegt. Hver nýleg er byggð á síðasta myndaða stöðugleika og nægir til að endurbyggja stillingargögnin. Um leið og sú nýlega nýlega nær áfangastað er ekki lengur þörf á því gamla.
Það eina sem er eftir er að senda nýja stöðuga stillingu af og til, til dæmis vegna þess að nýlegt er orðið of stórt. Það sem er líka mikilvægt hér er að við sendum allar þessar uppfærslur út í útsendingar-/fjölvarpsham, án þess að hafa áhyggjur af einstökum viðtakendum og getu þeirra til að púsla saman gögnum. Þegar við erum viss um að allir séu með rétta hesthúsið sendum við bara nýjar nýlegar. Er það þess virði að skýra að þetta virkar? Virkar. Stöðugt er í skyndiminni á stillingarþjóninum og viðtakendum, nýlegt er búið til eftir þörfum.
Arkitektúr tveggja þrepa flutninga
Hvers vegna byggðum við samgöngur okkar á tveimur hæðum? Svarið er frekar einfalt - við vildum aftengja leiðsögn frá rökfræði á háu stigi, með innblástur frá OSI líkaninu með flutnings- og notkunarlögum þess. Við notuðum Thrift fyrir hlutverk flutningssamskiptareglunnar og msgpack serialization sniðið fyrir háttsett snið stjórnunarskilaboða. Þetta er ástæðan fyrir því að beininn (sem framkvæmir multicast/broadcast/relay) lítur ekki inn í msgpack, pakkar ekki upp eða pakkar innihaldinu til baka og heldur aðeins áfram gögnum.
Thrift (úr ensku - „thrift“, borið fram [θrift]) er viðmótslýsingartungumál sem er notað til að skilgreina og búa til þjónustu fyrir mismunandi forritunarmál. Það er rammi fyrir fjarstýringarsímtöl (RPC). Sameinar hugbúnaðarleiðslu með kóðaframleiðsluvél til að þróa þjónustu sem virkar meira eða minna á skilvirkan og auðveldan hátt á milli tungumála.
Við völdum Thrift rammann vegna RPC og stuðnings fyrir mörg tungumál. Eins og venjulega voru auðveldu hlutarnir viðskiptavinurinn og þjónninn. Hins vegar reyndist beininn vera erfið hneta að brjóta, að hluta til vegna skorts á tilbúinni lausn við þróun okkar.
Það eru aðrir valkostir, eins og protobuf / gRPC, en þegar við byrjuðum verkefnið okkar var gRPC frekar nýtt og við þorðum ekki að taka það inn.
Auðvitað gætum við (og í raun átt að) smíðað okkar eigin hjól. Það væri auðveldara að búa til samskiptareglur fyrir það sem við þurfum vegna þess að arkitektúr viðskiptavinar-miðlara er tiltölulega einfaldur í framkvæmd miðað við að byggja bein á Thrift. Með einum eða öðrum hætti er hefðbundin hlutdrægni gagnvart sjálfskrifuðum samskiptareglum og útfærslum á vinsælum bókasöfnum (af góðri ástæðu); auk þess kemur alltaf upp spurningin í umræðum: "Hvernig ætlum við að flytja þetta yfir á önnur tungumál?" Svo við hentum strax út hugmyndinni um reiðhjól.
Msgpack er svipað og JSON, en hraðari og minni. Það er tvöfaldur gagnaraðgreiningarsnið sem gerir kleift að skiptast á gögnum á milli margra tungumála.
Á fyrsta stigi höfum við Thrift með lágmarksupplýsingunum sem nauðsynlegar eru til að beininn geti framsent skilaboðin. Á öðru stigi eru pökkuð msgpack mannvirki.
Við völdum msgpack vegna þess að það er hraðvirkara og þéttara miðað við JSON. En það sem meira er um vert, það styður sérsniðnar gagnagerðir, sem gerir okkur kleift að nota flotta eiginleika eins og að senda hráa tvíþætti eða sérstaka hluti sem gefa til kynna að gögn séu ekki til, sem var mikilvægt fyrir „nýlega stöðuga“ kerfið okkar.
JMESPath
JMESPath er JSON fyrirspurnarmál.
Þetta er nákvæmlega hvernig lýsingin sem við fáum frá opinberu JMESPath skjölunum lítur út, en í raun gerir hún miklu meira en það. JMESPath gerir þér kleift að leita og sía undirtré í handahófskenndri trébyggingu og beita breytingum á gögnum á flugu. Það gerir þér einnig kleift að bæta við sérstökum síum og gagnaumbreytingaraðferðum. Þó það þurfi auðvitað heilaátak til að skilja.
Jinja
Fyrir suma neytendur þurfum við að breyta stillingunum í skrá - svo við notum sniðmátsvél og Jinja er augljós kostur. Með hjálp þess búum við til stillingarskrá úr sniðmátinu og gögnum sem berast á áfangastað.
Til að búa til stillingarskrá þurfum við JMESPath beiðni, sniðmát fyrir staðsetningu skráarinnar í FS og sniðmát fyrir stillinguna sjálfa. Það er líka góð hugmynd á þessu stigi að skýra skráarheimildir. Allt þetta tókst að sameina í eina skrá - áður en stillingarsniðmátið hófst, settum við haus á YAML sniði sem lýsir restinni.
Til dæmis:
---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}
Til að búa til stillingarskrá fyrir nýja þjónustu bætum við aðeins við nýrri sniðmátsskrá. Engar breytingar á frumkóða eða hugbúnaði á viðverustöðum eru nauðsynlegar.
Hvað hefur breyst síðan QControl fór í loftið? Það fyrsta og mikilvægasta er samkvæm og áreiðanleg afhending stillingaruppfærslu til allra hnúta á netinu. Annað er að fá öflugt tól til að athuga stillingar og gera breytingar á henni af stuðningsteymi okkar, sem og neytendum þjónustunnar.
Við gátum gert þetta allt með því að nota nýlega stöðuga uppfærslukerfið til að einfalda samskipti milli stillingaþjónsins og stillingarviðtakenda. Notkun tveggja laga samskiptareglur til að styðja við innihaldsóháða leið til að beina gögnum. Tókst að samþætta Jinja-byggða stillingarframleiðsluvél í dreift síunarnet. Þetta kerfi styður fjölbreytt úrval af stillingaraðferðum fyrir dreifð og ólík jaðartæki okkar.
Takk fyrir hjálpina við að skrifa efnið. , , .
færslu.
Heimild: www.habr.com