TL; DR: Danasîna mîmariya xerîdar-server a pergala rêveberiya meya veavakirina tora navxweyî, QControl. Ew li ser bingeha protokolek veguheztinê ya du-qat e ku bi peyamên gzip-pakêtkirî re bêyî hilweşandina di navbera xalên dawiyê de dixebite. Roter û xalên dawîn ên belavbûyî nûvekirinên veavakirinê distînin, û protokol bixwe rê dide sazkirina releyên navîn ên herêmî. Pergal li ser prensîbê hatiye avakirin ("dawî-bi îstîqrar", li jêr hatî ravekirin) û zimanê pirsiyarê JMESpath ligel motora şablonê Jinja bikar tîne da ku pelên vesazkirinê bide.
Qrator Labs torgilokek kêmkirina êrîşê ya ku li çaraliyê cîhanê hatî belav kirin xebitîne. Tora me li ser prensîba anycast dixebite, û subnet bi BGP ve têne reklam kirin. Ji ber ku torgilokek BGP anycast ku bi fizîkî li gelek deverên Cîhanê ye, em dikarin seyrûsefera neqanûnî ya ku nêzî bingeha Înternetê - Operatorên Tier-1-ê ye pêvajoyê û fîlter bikin.
Ji aliyê din ve, bûna tora erdnîgarî ya belavbûyî ne hêsan e. Ragihandina di navbera nuqteyên hebûna torê de ji bo peydakarê karûbarê ewlehiyê krîtîk e ku xwedan mîhengek domdar a hemî girêkên torê be, wan di wextê xwe de nûve bike. Ji ber vê yekê, ji bo ku em asta herî bilind a karûbarê bingehîn ji xerîdar re peyda bikin, hewce bû ku em rêyek bibînin ku bi pêbawer daneyên mîhengê li seranserê parzemînan hevdeng bikin.
Di destpêkê de Peyv bû. Ew zû bû protokolek ragihandinê ku hewcedariya nûvekirinê heye.
Kevirê bingehîn ê hebûna QControl, û di heman demê de sedema bingehîn a xerckirina gelek dem û çavkaniyan ji bo avakirina vî rengî protokolê, hewcedariya bidestxistina çavkaniyek yekdestdar a veavakirinê ye û, di dawiyê de, hevdemkirina xalên hebûna me ye. bi wê re. Di dema pêşkeftina QControl de hilanîn bi xwe tenê yek ji çend hewcedariyên bû. Digel vê yekê, me hewceyê entegrasyonên bi karûbarên heyî û plansazkirî yên li nuqteyên hebûna (POP), rêbazên jîr (û xwerû) ji bo pejirandina daneyê, û her weha kontrolkirina gihîştinê bû. Ji xeynî vê, me di heman demê de dixwest ku pergalek wusa bi karanîna fermanan li şûna guheztina pelan kontrol bikin. Berî QControlê, dane hema hema bi destan ji xalên hebûnê re hate şandin. Ger yek ji xalên hebûnê ne amade bûya û me ji bîr kir ku wê paşê nûve bikin, dê veavakirin ji hevdeng bi dawî bibe û em neçar in ku wextê xwe winda bikin ku wê ji nû ve vegere û bixebite.
Di encamê de, em bi plana jêrîn derketin:
Pêşkêşkara veavakirinê berpirsiyariya erêkirin û hilanîna daneyê ye; router xwedan çend xalên dawîn e ku nûvekirinên mîhengê ji xerîdar û tîmên piştgiriyê ji serverê re, û ji serverê heya xalên hebûnê distînin û diweşînin.
Qalîteya pêwendiya înternetê hîn jî li çaraliyê cîhanê pir cûda dibe - ji bo ronîkirina vê xalê, em li MTR-ya hêsan ji Prague, Komara Czechek heya Singapûr û Hong Kongê binêrin.
MTR ji Pragê heya Sîngapurê
Heman tişt ji bo Hong Kongê
Derengiya bilind tê wateya leza kêmtir. Wekî din, windabûna pakêtê heye. Berfirehiya kanalê vê pirsgirêkê telafî nake, ku divê her gav gava ku pergalên nemerkezî ava dikin were hesibandin.
Veavakirina bêkêmasî ya xalek hebûna hejmareke girîng a daneyê ye ku divê ji gelek wergiran re li ser girêdanên ne pêbawer were şandin. Xweşbextane, her çend veavakirin bi domdarî diguhezîne, ew bi gavên piçûk diqewime.
Sêwirana nû-îstîqrar
Em dikarin bêjin ku avakirina torgilokek belavkirî li ser bingeha prensîba nûvekirinên zêdebûyî çareseriyek berbiçav e. Lê gelek pirsgirêk bi cudahiyan re hene. Pêdivî ye ku em hemî cûdahiyên di navbera xalên referansê de hilînin, û her weha karibin wan ji nû ve bişînin ger kesek beşek daneyan winda bike. Pêdivî ye ku her cîhek wan di rêzek diyarkirî de bicîh bîne. Bi gelemperî, di rewşa çend deveran de, operasyonek weha dikare demek dirêj bigire. Divê wergir jî bikaribe beşên winda daxwaz bike û, bê guman, beşa navendî divê bersivek rast bide daxwazek wusa, tenê daneyên winda bişîne.
Wekî encamek, em gihîştin çareseriyek balkêş - me tenê yek qatek referansê heye, sabît, em jê re bibêjin stabîl, û tenê yek cûdahiyek ji bo wê - vê dawîyê. Her dawî li ser bingeha îstîqrara paşîn a hilberandî ye û ji bo ji nû ve avakirina daneya veavakirinê bes e. Hema ku ya nû ya nû digihîje cihê xwe, ya kevn êdî hewce nake.
Tiştê ku dimîne ev e ku meriv dem bi dem veavakirinek stabîl a nû bişîne, mînakî ji ber ku vê dawiyê pir mezin bûye. Ya ku li vir jî girîng e ev e ku em van hemî nûvekirinan di moda weşana/pirtûkê de bişînin, bêyî ku xema wergirên takekesî û kapasîteya wan a berhevkirina perçeyên daneyê li hev bikin. Gava ku em pê ewle bin ku her kes xwedan stabîla rast e, em tenê yên nû yên nû dişînin. Ma hêja ye ku were zelal kirin ku ev kar dike? Works. Stable li ser servera veavakirinê û wergiran tê cache kirin, li gorî hewcedariyê vê nû tê afirandin.
Mîmariya veguhestina du-asta
Çima me veguhestina xwe li ser du astan ava kir? Bersiv pir hêsan e - me xwest ku rêvekirinê ji mentiqê asta bilind veqetînin, ji modela OSI bi qatên veguheztin û sepanê îlhamê bigirin. Me Thrift ji bo rola protokola veguheztinê, û formata serialîzasyona msgpack ji bo formata asta bilind a peyamên kontrolê bikar anî. Ji ber vê yekê router (multicast/weşan/relay pêk tîne) di hundurê msgpackê de nanihêre, naverokê paşde venake an pakij nake, û tenê daneyan pêş dixe.
Thrift (ji Îngilîzî - "thrift", tê bilêvkirin [θrift]) zimanek ravekirina navberê ye ku ji bo destnîşankirin û afirandina karûbarên ji bo zimanên bernamenûsê yên cihêreng tê bikar anîn. Ew çarçoveyek ji bo bangên prosedûra dûr (RPC) ye. Xetek nermalavê bi motora hilberîna kodê re dike yek da ku karûbarên ku kêm-zêde bi bandor û bi hêsanî di navbera zimanan de dixebitin pêş bixe.
Me çarçoveya Thrift ji ber RPC û piştgiriya ji bo gelek zimanan hilbijart. Wekî gelemperî, beşên hêsan xerîdar û server bûn. Lêbelê, router derket holê ku çuçikek hişk e, hinekî jî ji ber nebûna çareseriyek amade di dema pêşkeftina me de.
Vebijarkên din jî hene, wek protobuf / gRPC, lêbelê, dema ku me projeya xwe dest pê kir, gRPC pir nû bû û me newêrîbû ku em wê li ser sifrê bigirin.
Bê guman, me dikaribû (û bi rastî jî diviyabû) bisiklêta xwe ava bikira. Dê hêsantir be ku em protokolek ji bo tiştê ku em hewce ne biafirînin ji ber ku mîmariya xerîdar-server li gorî avakirina routerek li ser Thrift bi rêkûpêk hêsan e ku were bicîh kirin. Bi rengekî din, li hember protokolên xwe-nivîsandî û pêkanînên pirtûkxaneyên populer (ji ber sedemek baş) rêgezek kevneşopî heye; ji bilî vê, di dema nîqaşan de her gav pirs derdikeve holê: "Em ê çawa vê yekê ji zimanên din re bişînin?" Ji ber vê yekê me tavilê fikra bisîkletê avêt.
Msgpack mîna JSON e, lê zûtir û piçûktir e. Ew formatek serialîzasyona daneya binary e ku dihêle ku dane di navbera pir zimanan de werin veguheztin.
Di asta yekem de me Thrift bi hindiktirîn agahdariya ku ji router re hewce dike heye ku peyamê bişîne. Di asta duyemîn de strukturên msgpackê yên pakkirî hene.
Me msgpack hilbijart ji ber ku ew li gorî JSON zûtir û tevlihevtir e. Lê ya girîngtir, ew celebên daneya xwerû piştgirî dike, dihêle ku em taybetmendiyên xweşik ên mîna derbaskirina binarên xav an tiştên taybetî yên ku nebûna daneyê destnîşan dikin, ku ji bo nexşeya meya "paşîn-îstîqrar" girîng bû, bikar bînin.
JMESPath
JMESPath zimanek pirsa JSON e.
Ev tam ya ku danasîna ku em ji belgeya fermî ya JMESPath digirin dixuye, lê bi rastî, ew ji wiya pirtir dike. JMESPath destûrê dide te ku hûn di avahiyek dara keyfî de li binê daran bigerin û fîlter bikin, û di firînê de guhertinan li daneyan bicîh bikin. Di heman demê de ew dihêle hûn fîlterên taybetî û prosedurên veguherîna daneyê zêde bikin. Her çend ew, bê guman, hewldana mêjî hewce dike ku fêm bike.
Jinja
Ji bo hin xerîdar, pêdivî ye ku em veavakirinê veguherînin pelek - ji ber vê yekê em motorek şablonê bikar tînin û Jinja bijareya eşkere ye. Bi alîkariya wê, em pelê vesazkirinê ji şablon û daneyên ku li cîhê hatine wergirtin diafirînin.
Ji bo afirandina pelek vesazkirinê, em hewceyê daxwazek JMESPath, şablonek ji bo cîhê pelê di FS-ê de, û şablonek ji bo mîhengê bixwe hewce ne. Di vê qonaxê de jî ramanek baş e ku meriv destûrên pelê zelal bike. Hemî ev di yek pelê de bi serfirazî hate berhev kirin - berî destpêkirina şablonê veavakirinê, me sernivîsek di forma YAML de datîne ku yên mayî vedibêje.
Bo nimûne:
---
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) }}
Ji bo ku em ji bo karûbarek nû pelek vesazkirinê çêbikin, em tenê pelek şablonek nû lê zêde dikin. Li ser xalên hebûna koda çavkaniyê an nermalava guheztinê ne hewce ye.
Ji dema ku QControl zindî çû çi guherî? Ya yekem û ya herî girîng radestkirina domdar û pêbawer a nûvekirinên mîhengê ji hemî girêkên di torê re ye. Ya duyemîn ev e ku ji hêla tîmê meya piştevaniyê, û hem jî ji hêla xerîdarên karûbarê ve ji bo kontrolkirina veavakirinê û guheztina wê ve amûrek hêzdar bistînin.
Me karîbû van hemîyan bi karanîna nexşeya nûvekirina paşîn-stable bikin da ku pêwendiya di navbera servera vesazkirinê û wergirên vesazkirinê de hêsan bikin. Bikaranîna protokolek du-qat ji bo piştgirîkirina rêgezek serbixwe-naverokê ya rêvekirina daneyan. Bi serfirazî motorek hilberîna vesazkirinê ya li ser bingeha Jinja di nav torgilokek fîlterkirina belavbûyî de yek kir. Ev pergal ji bo dorhêlên me yên belavbûyî û heterojen gelek awayên veavakirinê piştgirî dike.
Spas ji bo alîkariya we di nivîsandina materyalê de. , , .
koz.
Source: www.habr.com