TL; DR: Maelezo ya usanifu wa seva ya mteja wa mfumo wetu wa usimamizi wa usanidi wa mtandao wa ndani, QControl. Inatokana na itifaki ya usafiri ya safu mbili ambayo inafanya kazi na jumbe zilizojaa gzip bila mfinyazo kati ya ncha. Routa zilizosambazwa na vituo vya mwisho hupokea sasisho za usanidi, na itifaki yenyewe inaruhusu usakinishaji wa relays za kati zilizojanibishwa. Mfumo umejengwa juu ya kanuni ("imara ya hivi majuzi", imefafanuliwa hapa chini) na hutumia lugha ya swali ya JMESpath pamoja na injini ya kiolezo ya Jinja kutoa faili za usanidi.
Maabara ya Qrator huendesha mtandao wa kupunguza mashambulizi unaosambazwa duniani kote. Mtandao wetu unafanya kazi kwa kanuni ya utangazaji wowote, na nyavu ndogo hutangazwa kupitia BGP. Kwa kuwa BGP mtandao wowote wa utangazaji ulio katika maeneo kadhaa ya Dunia, tunaweza kuchakata na kuchuja trafiki haramu karibu na msingi wa Mtandao - waendeshaji wa Tier-1.
Kwa upande mwingine, kuwa mtandao unaosambazwa kijiografia si rahisi. Mawasiliano kati ya pointi za mtandao ni muhimu kwa mtoa huduma wa usalama kuwa na usanidi thabiti wa nodi zote za mtandao, kuzisasisha kwa wakati unaofaa. Kwa hivyo, ili kutoa kiwango cha juu zaidi cha huduma ya msingi kwa mtumiaji, tulihitaji kutafuta njia ya kusawazisha data ya usanidi kwa uaminifu katika mabara yote.
Hapo mwanzo kulikuwako Neno. Kwa haraka ikawa itifaki ya mawasiliano inayohitaji sasisho.
Msingi wa kuwepo kwa QControl, na wakati huo huo sababu kuu ya kutumia kiasi kikubwa cha muda na rasilimali katika kujenga aina hii ya itifaki, ni haja ya kupata chanzo kimoja cha mamlaka cha usanidi na, hatimaye, kusawazisha pointi zetu za uwepo. nayo. Hifadhi yenyewe ilikuwa moja tu ya mahitaji kadhaa wakati wa ukuzaji wa QControl. Zaidi ya hayo, tulihitaji pia miunganisho na huduma zilizopo na zilizopangwa mahali unapopatikana (POP), mbinu mahiri (na zinazoweza kugeuzwa kukufaa) za uthibitishaji wa data, pamoja na udhibiti wa ufikiaji. Kando na hili, pia tulitaka kudhibiti mfumo kama huo kwa kutumia amri badala ya kufanya marekebisho kwa faili. Kabla ya QControl, data ilitumwa kwa maeneo ya kupatikana karibu kwa mikono. Iwapo mojawapo ya vipengele vya kuwepo havikupatikana na tukasahau kuisasisha baadaye, usanidi utaisha bila kusawazishwa na tungelazimika kupoteza muda kuirejesha na kuiendesha.
Kama matokeo, tulikuja na mpango ufuatao:
Seva ya usanidi inawajibika kwa uthibitishaji na uhifadhi wa data; kipanga njia kina sehemu kadhaa za mwisho ambazo hupokea na kutangaza masasisho ya usanidi kutoka kwa wateja na timu za usaidizi hadi kwa seva, na kutoka kwa seva hadi sehemu za uwepo.
Ubora wa muunganisho wa mtandao bado unatofautiana kote ulimwenguni - ili kufafanua hoja hii, hebu tuangalie MTR rahisi kutoka Prague, Jamhuri ya Cheki hadi Singapore na Hong Kong.
MTR kutoka Prague hadi Singapore
Kitu sawa na Hong Kong
Ucheleweshaji wa juu unamaanisha kasi ya chini. Kwa kuongeza, kuna upotezaji wa pakiti. Upana wa njia haitoi fidia kwa shida hii, ambayo lazima izingatiwe wakati wa kujenga mifumo ya madaraka.
Usanidi kamili wa mahali pa kuwepo ni kiasi kikubwa cha data ambacho lazima kipelekwe kwa wapokeaji wengi juu ya miunganisho isiyoaminika. Kwa bahati nzuri, ingawa usanidi hubadilika kila wakati, hufanyika kwa nyongeza ndogo.
Muundo thabiti wa hivi karibuni
Tunaweza kusema kwamba kujenga mtandao uliosambazwa kulingana na kanuni ya sasisho za ziada ni suluhisho la wazi kabisa. Lakini kuna shida nyingi na tofauti. Tunahitaji kuhifadhi tofauti zote kati ya pointi za marejeleo, na pia tuweze kuzituma tena ikiwa mtu amekosa sehemu ya data. Kila lengwa lazima itumike katika mlolongo uliobainishwa kabisa. Kwa kawaida, katika kesi ya marudio kadhaa, operesheni hiyo inaweza kuchukua muda mrefu. Mpokeaji lazima pia awe na uwezo wa kuomba sehemu zilizopotea na, bila shaka, sehemu ya kati inapaswa kujibu ombi hilo kwa usahihi, kutuma data tu iliyopotea.
Kama matokeo, tulikuja kwa suluhisho la kupendeza - tuna safu moja tu ya kumbukumbu, iliyowekwa, wacha tuiite kuwa thabiti, na tofauti moja tu kwa hiyo - ya hivi karibuni. Kila hivi majuzi ni msingi wa dhabiti la mwisho lililotolewa na inatosha kuunda upya data ya usanidi. Mara tu mpya ya hivi karibuni inapofikia lengo lake, ya zamani haihitajiki tena.
Kilichobaki ni kutuma usanidi mpya thabiti mara kwa mara, kwa mfano kwa sababu hivi karibuni imekuwa kubwa sana. Kilicho muhimu pia hapa ni kwamba tutume masasisho haya yote katika hali ya utangazaji/utangazaji anuwai, bila kuwa na wasiwasi kuhusu wapokeaji binafsi na uwezo wao wa kuunganisha vipande vya data. Mara tu tunapohakikisha kuwa kila mtu ana uthabiti sahihi, tunatuma tu mpya za hivi majuzi. Inafaa kufafanua kuwa hii inafanya kazi? Inafanya kazi. Imara imehifadhiwa kwenye seva ya usanidi na wapokeaji, hivi karibuni huundwa kama inahitajika.
Usanifu wa usafiri wa ngazi mbili
Kwa nini tulijenga usafiri wetu katika ngazi mbili? Jibu ni rahisi sana - tulitaka kutenganisha uelekezaji kutoka kwa mantiki ya kiwango cha juu, tukipata msukumo kutoka kwa mfano wa OSI na tabaka zake za usafiri na matumizi. Tulitumia Thrift kwa jukumu la itifaki ya usafiri, na umbizo la utayarishaji wa msgpack kwa umbizo la kiwango cha juu la ujumbe wa udhibiti. Hii ndiyo sababu kipanga njia (inayofanya utangazaji/matangazo/relay) haiangalii ndani ya msgpack, haifungui au kupaki yaliyomo nyuma, na inapeleka mbele data pekee.
Thrift (kutoka Kiingereza - βthriftβ, hutamkwa [ΞΈrift]) ni lugha ya maelezo ya kiolesura ambayo hutumiwa kufafanua na kuunda huduma za lugha tofauti za programu. Ni mfumo wa simu za utaratibu wa mbali (RPC). Inachanganya bomba la programu na injini ya kuzalisha msimbo ili kuendeleza huduma zinazofanya kazi kwa ufanisi zaidi au kidogo na kwa urahisi kati ya lugha.
Tulichagua mfumo wa Uwekevu kwa sababu ya RPC na usaidizi wa lugha nyingi. Kama kawaida, sehemu rahisi zilikuwa mteja na seva. Hata hivyo, router iligeuka kuwa nati ngumu ya kupasuka, kwa sehemu kutokana na ukosefu wa suluhisho tayari wakati wa maendeleo yetu.
Kuna chaguzi zingine, kama vile protobuf / gRPC, hata hivyo, tulipoanzisha mradi wetu, gRPC ilikuwa mpya kabisa na hatukuthubutu kuichukua.
Bila shaka, tunaweza (na kwa kweli tunapaswa kuwa) kujenga baiskeli yetu wenyewe. Itakuwa rahisi kuunda itifaki ya kile tunachohitaji kwa sababu usanifu wa seva ya mteja ni rahisi kutekeleza ikilinganishwa na kujenga kipanga njia kwenye Thrift. Kwa njia moja au nyingine, kuna upendeleo wa kitamaduni kuelekea itifaki zilizojiandika na utekelezaji wa maktaba maarufu (kwa sababu nzuri); kwa kuongezea, wakati wa majadiliano swali huibuka kila wakati: "Tutawasilishaje hii kwa lugha zingine?" Kwa hivyo mara moja tulitupa wazo la baiskeli.
Msgpack ni sawa na JSON, lakini haraka na ndogo zaidi. Ni umbizo la uratibu wa data ya jozi ambayo inaruhusu data kubadilishana kati ya lugha nyingi.
Katika kiwango cha kwanza tuna Udhibiti na maelezo ya chini yanayohitajika ili kipanga njia kusambaza ujumbe. Katika ngazi ya pili kuna miundo ya msgpack iliyofungwa.
Tulichagua msgpack kwa sababu ni ya haraka na thabiti zaidi ikilinganishwa na JSON. Lakini muhimu zaidi, inasaidia aina maalum za data, zinazoturuhusu kutumia vipengele vyema kama vile kupitisha jozi mbichi au vitu maalum vinavyoonyesha kutokuwepo kwa data, ambayo ilikuwa muhimu kwa mpango wetu wa "imara wa hivi majuzi".
JMESPath
JMESPath ni lugha ya maswali ya JSON.
Hivi ndivyo maelezo tunayopata kutoka kwa hati rasmi ya JMESPath inaonekana, lakini kwa kweli, hufanya zaidi ya hiyo. JMESPath hukuruhusu kutafuta na kuchuja miti midogo katika muundo wa miti holela, na kutumia mabadiliko kwenye data kwenye nzi. Pia hukuruhusu kuongeza vichungi maalum na taratibu za kubadilisha data. Ingawa, kwa kweli, inahitaji bidii ya ubongo kuelewa.
Jinja
Kwa watumiaji wengine, tunahitaji kugeuza usanidi kuwa faili - kwa hivyo tunatumia injini ya kiolezo na Jinja ndio chaguo dhahiri. Kwa msaada wake, tunazalisha faili ya usanidi kutoka kwa template na data iliyopokelewa kwenye marudio.
Ili kutengeneza faili ya usanidi, tunahitaji ombi la JMESPath, kiolezo cha eneo la faili katika FS, na kiolezo cha usanidi yenyewe. Pia ni wazo nzuri katika hatua hii kufafanua ruhusa za faili. Haya yote yaliunganishwa kwa ufanisi katika faili moja - kabla ya kuanza kwa kiolezo cha usanidi, tunaweka kichwa katika umbizo la YAML ambalo linaelezea mengine.
Kwa mfano:
---
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) }}
Ili kutengeneza faili ya usanidi kwa huduma mpya, tunaongeza tu faili mpya ya kiolezo. Hakuna mabadiliko ya msimbo wa chanzo au programu kwenye maeneo ya uwepo yanahitajika.
Ni nini kimebadilika tangu QControl kuanza kutumika? Jambo la kwanza na muhimu zaidi ni utoaji thabiti na wa kuaminika wa sasisho za usanidi kwa nodes zote kwenye mtandao. Ya pili ni kupokea zana yenye nguvu ya kuangalia usanidi na kufanya mabadiliko kwayo na timu yetu ya usaidizi, na vile vile watumiaji wa huduma.
Tuliweza kufanya haya yote kwa kutumia mpango wa sasisho thabiti wa hivi majuzi ili kurahisisha mawasiliano kati ya seva ya usanidi na wapokezi wa usanidi. Kutumia itifaki ya safu mbili kusaidia njia inayojitegemea ya maudhui ya kuelekeza data. Imefaulu kuunganisha injini ya kutengeneza usanidi kulingana na Jinja kwenye mtandao uliosambazwa wa vichujio. Mfumo huu unaauni mbinu mbalimbali za usanidi kwa viambajengo vyetu vilivyosambazwa na tofauti tofauti.
Asante kwa msaada wako katika kuandika nyenzo. , , .
chapisho.
Chanzo: mapenzi.com