TL; DR: మా అంతర్గత నెట్వర్క్ కాన్ఫిగరేషన్ మేనేజ్మెంట్ సిస్టమ్, QControl యొక్క క్లయింట్-సర్వర్ ఆర్కిటెక్చర్ వివరణ. ఇది రెండు-పొరల రవాణా ప్రోటోకాల్పై ఆధారపడి ఉంటుంది, ఇది ముగింపు బిందువుల మధ్య డికంప్రెషన్ లేకుండా gzip-ప్యాక్డ్ సందేశాలతో పనిచేస్తుంది. పంపిణీ చేయబడిన రూటర్లు మరియు ముగింపు పాయింట్లు కాన్ఫిగరేషన్ అప్డేట్లను అందుకుంటాయి మరియు ప్రోటోకాల్ కూడా స్థానికీకరించిన ఇంటర్మీడియట్ రిలేల ఇన్స్టాలేషన్ను అనుమతిస్తుంది. వ్యవస్థ సూత్రం మీద నిర్మించబడింది (“ఇటీవలి-స్థిరమైనది”, క్రింద వివరించబడింది) మరియు కాన్ఫిగరేషన్ ఫైల్లను రెండర్ చేయడానికి JMESpath ప్రశ్న భాషను జింజా టెంప్లేటింగ్ ఇంజిన్తో పాటు ఉపయోగిస్తుంది.
Qrator ల్యాబ్స్ ప్రపంచవ్యాప్తంగా పంపిణీ చేయబడిన దాడి ఉపశమన నెట్వర్క్ను నిర్వహిస్తుంది. మా నెట్వర్క్ ఏదైనా కాస్ట్ సూత్రంపై పనిచేస్తుంది మరియు సబ్నెట్లు BGP ద్వారా ప్రచారం చేయబడతాయి. BGP ఏదైనాకాస్ట్ నెట్వర్క్ భౌతికంగా భూమిపై అనేక ప్రాంతాల్లో ఉన్నందున, మేము చట్టవిరుద్ధమైన ట్రాఫిక్ను ఇంటర్నెట్ యొక్క ప్రధానమైన టైర్-1 ఆపరేటర్లకు దగ్గరగా ప్రాసెస్ చేయవచ్చు మరియు ఫిల్టర్ చేయవచ్చు.
మరోవైపు, భౌగోళికంగా పంపిణీ చేయబడిన నెట్వర్క్గా ఉండటం అంత సులభం కాదు. అన్ని నెట్వర్క్ నోడ్ల యొక్క స్థిరమైన కాన్ఫిగరేషన్ను కలిగి ఉండటానికి, వాటిని సకాలంలో అప్డేట్ చేయడానికి సెక్యూరిటీ సర్వీస్ ప్రొవైడర్కు ఉనికిని కలిగి ఉన్న నెట్వర్క్ పాయింట్ల మధ్య కమ్యూనికేషన్ కీలకం. అందువల్ల, వినియోగదారుకు సాధ్యమయ్యే అత్యధిక స్థాయి కోర్ సేవను అందించడానికి, మేము ఖండాలలో కాన్ఫిగరేషన్ డేటాను విశ్వసనీయంగా సమకాలీకరించడానికి ఒక మార్గాన్ని కనుగొనవలసి ఉంటుంది.
ప్రారంభంలో వాక్యం ఉంది. ఇది త్వరగా నవీకరణ అవసరమైన కమ్యూనికేషన్ ప్రోటోకాల్గా మారింది.
QControl యొక్క ఉనికికి మూలస్తంభం, మరియు అదే సమయంలో ఈ రకమైన ప్రోటోకాల్ను రూపొందించడానికి గణనీయమైన సమయం మరియు వనరులను వెచ్చించడానికి ప్రధాన కారణం, కాన్ఫిగరేషన్ యొక్క ఒకే అధికారిక మూలాన్ని పొందడం మరియు చివరికి, మా ఉనికిని సమకాలీకరించడం. దానితో. QControl అభివృద్ధి సమయంలో నిల్వ అనేక అవసరాలలో ఒకటి. అదనంగా, మేము ఉనికిలో ఉన్న పాయింట్ల వద్ద (POP), డేటా ధ్రువీకరణ కోసం స్మార్ట్ (మరియు అనుకూలీకరించదగిన) పద్ధతులు, అలాగే యాక్సెస్ నియంత్రణలో ఇప్పటికే ఉన్న మరియు ప్రణాళికాబద్ధమైన సేవలతో ఏకీకరణలు కూడా అవసరం. ఇది కాకుండా, మేము ఫైళ్ళకు సవరణలు చేయడం కంటే ఆదేశాలను ఉపయోగించి అటువంటి సిస్టమ్ను నియంత్రించాలనుకుంటున్నాము. QControlకి ముందు, డేటా దాదాపు మాన్యువల్గా ఉన్న పాయింట్లకు పంపబడింది. ప్రెజెన్స్ పాయింట్లలో ఒకటి అందుబాటులో లేకుంటే మరియు మేము దానిని తర్వాత అప్డేట్ చేయడం మరచిపోతే, కాన్ఫిగరేషన్ సమకాలీకరించబడదు మరియు దానిని తిరిగి అప్ మరియు రన్ చేయడానికి మేము సమయాన్ని వృథా చేయాల్సి ఉంటుంది.
ఫలితంగా, మేము ఈ క్రింది పథకంతో ముందుకు వచ్చాము:
కాన్ఫిగరేషన్ సర్వర్ డేటా ధృవీకరణ మరియు నిల్వకు బాధ్యత వహిస్తుంది, ఇది క్లయింట్లు మరియు సపోర్ట్ టీమ్ల నుండి సర్వర్కు మరియు సర్వర్ నుండి ఉనికిని కలిగి ఉండే పాయింట్లకు కాన్ఫిగరేషన్ అప్డేట్లను స్వీకరించి ప్రసారం చేస్తుంది.
ఇంటర్నెట్ కనెక్షన్ నాణ్యత ఇప్పటికీ ప్రపంచవ్యాప్తంగా విస్తృతంగా మారుతూ ఉంటుంది - ఈ విషయాన్ని వివరించడానికి, ప్రేగ్, చెక్ రిపబ్లిక్ నుండి సింగపూర్ మరియు హాంకాంగ్ వరకు ఒక సాధారణ MTRని చూద్దాం.
ప్రేగ్ నుండి సింగపూర్ వరకు MTR
హాంకాంగ్కి అదే విషయం
అధిక జాప్యం అంటే తక్కువ వేగం. అదనంగా, ప్యాకెట్ నష్టం ఉంది. ఛానెల్ వెడల్పు ఈ సమస్యను భర్తీ చేయదు, ఇది వికేంద్రీకృత వ్యవస్థలను నిర్మించేటప్పుడు ఎల్లప్పుడూ పరిగణనలోకి తీసుకోవాలి.
ఒక పాయింట్ ఆఫ్ ప్రెజెన్స్ యొక్క పూర్తి కాన్ఫిగరేషన్ అనేది నమ్మదగని కనెక్షన్ల ద్వారా చాలా మంది గ్రహీతలకు తప్పనిసరిగా పంపబడే ముఖ్యమైన డేటా. అదృష్టవశాత్తూ, కాన్ఫిగరేషన్ నిరంతరం మారుతున్నప్పటికీ, ఇది చిన్న ఇంక్రిమెంట్లలో జరుగుతుంది.
ఇటీవలి స్థిరమైన డిజైన్
పెరుగుతున్న నవీకరణల సూత్రం ఆధారంగా పంపిణీ చేయబడిన నెట్వర్క్ను నిర్మించడం చాలా స్పష్టమైన పరిష్కారం అని మేము చెప్పగలం. కానీ తేడాలతో చాలా సమస్యలు ఉన్నాయి. మేము రిఫరెన్స్ పాయింట్ల మధ్య అన్ని తేడాలను సేవ్ చేయాలి మరియు ఎవరైనా డేటాలో కొంత భాగాన్ని కోల్పోయినట్లయితే వాటిని మళ్లీ పంపగలగాలి. ప్రతి గమ్యస్థానం తప్పనిసరిగా వాటిని ఖచ్చితంగా పేర్కొన్న క్రమంలో వర్తింపజేయాలి. సాధారణంగా, అనేక గమ్యస్థానాల విషయంలో, అటువంటి ఆపరేషన్ చాలా సమయం పట్టవచ్చు. రిసీవర్ తప్పనిసరిగా తప్పిపోయిన భాగాలను అభ్యర్థించగలగాలి మరియు, వాస్తవానికి, కేంద్ర భాగం అటువంటి అభ్యర్థనకు సరిగ్గా ప్రతిస్పందించాలి, తప్పిపోయిన డేటాను మాత్రమే పంపాలి.
ఫలితంగా, మేము చాలా ఆసక్తికరమైన పరిష్కారానికి వచ్చాము - మనకు ఒకే ఒక రిఫరెన్స్ లేయర్ ఉంది, పరిష్కరించబడింది, దానిని స్థిరంగా పిలుద్దాం మరియు దాని కోసం ఒకే ఒక తేడా - ఇటీవలిది. ప్రతి ఇటీవలి చివరిగా రూపొందించబడిన స్థిరత్వంపై ఆధారపడి ఉంటుంది మరియు కాన్ఫిగరేషన్ డేటాను పునర్నిర్మించడానికి సరిపోతుంది. తాజా ఇటీవలి దాని గమ్యస్థానానికి చేరుకున్న వెంటనే, పాతది ఇక అవసరం లేదు.
ఎప్పటికప్పుడు తాజా స్థిరమైన కాన్ఫిగరేషన్ను పంపడమే మిగిలి ఉంది, ఉదాహరణకు ఇటీవలిది చాలా పెద్దదిగా మారింది. ఇక్కడ కూడా ముఖ్యమైనది ఏమిటంటే, మేము ఈ అప్డేట్లన్నింటినీ ప్రసారం/మల్టీకాస్ట్ మోడ్లో పంపుతాము, వ్యక్తిగత గ్రహీతలు మరియు వారి డేటా ముక్కలను కలపగల సామర్థ్యం గురించి చింతించకుండా. ప్రతి ఒక్కరికీ సరైన స్థిరత్వం ఉందని మేము నిర్ధారించుకున్న తర్వాత, మేము కొత్త ఇటీవలి వాటిని మాత్రమే పంపుతాము. ఇది పని చేస్తుందని స్పష్టం చేయడం విలువైనదేనా? పనిచేస్తుంది. స్థిరమైన కాన్ఫిగరేషన్ సర్వర్ మరియు గ్రహీతలపై కాష్ చేయబడింది, ఇటీవల అవసరమైన విధంగా సృష్టించబడింది.
రెండు-స్థాయి రవాణా యొక్క ఆర్కిటెక్చర్
మేము మా రవాణాను రెండు స్థాయిలలో ఎందుకు నిర్మించాము? సమాధానం చాలా సులభం - మేము దాని రవాణా మరియు అప్లికేషన్ లేయర్లతో OSI మోడల్ నుండి ప్రేరణ పొంది, హై-లెవల్ లాజిక్ నుండి రౌటింగ్ను వేరు చేయాలనుకుంటున్నాము. మేము రవాణా ప్రోటోకాల్ పాత్ర కోసం పొదుపును మరియు నియంత్రణ సందేశాల యొక్క ఉన్నత-స్థాయి ఫార్మాట్ కోసం msgpack సీరియలైజేషన్ ఆకృతిని ఉపయోగించాము. అందుకే రౌటర్ (మల్టీకాస్ట్/బ్రాడ్కాస్ట్/రిలే చేయడం) msgpack లోపల కనిపించదు, కంటెంట్లను అన్ప్యాక్ చేయదు లేదా ప్యాక్ చేయదు మరియు డేటాను మాత్రమే ఫార్వార్డ్ చేస్తుంది.
పొదుపు (ఇంగ్లీష్ నుండి - “పొదుపు”, ఉచ్ఛరిస్తారు [θrift]) అనేది వివిధ ప్రోగ్రామింగ్ భాషల కోసం సేవలను నిర్వచించడానికి మరియు సృష్టించడానికి ఉపయోగించే ఇంటర్ఫేస్ వివరణ భాష. ఇది రిమోట్ ప్రొసీజర్ కాల్స్ (RPC) కోసం ఒక ఫ్రేమ్వర్క్. భాషల మధ్య ఎక్కువ లేదా తక్కువ సమర్ధవంతంగా మరియు సులభంగా పనిచేసే సేవలను అభివృద్ధి చేయడానికి సాఫ్ట్వేర్ పైప్లైన్ను కోడ్ జనరేషన్ ఇంజిన్తో మిళితం చేస్తుంది.
RPC మరియు అనేక భాషలకు మద్దతు ఉన్నందున మేము పొదుపు ఫ్రేమ్వర్క్ని ఎంచుకున్నాము. ఎప్పటిలాగే, సులభమైన భాగాలు క్లయింట్ మరియు సర్వర్. అయినప్పటికీ, రౌటర్ పగులగొట్టడానికి కఠినమైన గింజగా మారింది, పాక్షికంగా మా అభివృద్ధి సమయంలో సిద్ధంగా ఉన్న పరిష్కారం లేకపోవడం.
ప్రోటోబఫ్ / జిఆర్పిసి వంటి ఇతర ఎంపికలు ఉన్నాయి, అయితే, మేము మా ప్రాజెక్ట్ను ప్రారంభించినప్పుడు, జిఆర్పిసి చాలా కొత్తది మరియు మేము దానిని బోర్డులోకి తీసుకునే ధైర్యం చేయలేదు.
వాస్తవానికి, మేము మా స్వంత బైక్ను నిర్మించగలము (మరియు వాస్తవానికి కలిగి ఉండాలి). క్లయింట్-సర్వర్ ఆర్కిటెక్చర్ పొదుపుపై రూటర్ను నిర్మించడంతో పోల్చితే అమలు చేయడం సాపేక్షంగా సూటిగా ఉంటుంది కాబట్టి మనకు అవసరమైన వాటి కోసం ప్రోటోకాల్ను రూపొందించడం సులభం అవుతుంది. ఒక మార్గం లేదా మరొకటి, స్వీయ-వ్రాతపూర్వక ప్రోటోకాల్లు మరియు ప్రసిద్ధ లైబ్రరీల అమలుల పట్ల సాంప్రదాయ పక్షపాతం ఉంది (అదనంగా, చర్చల సమయంలో మేము దీన్ని ఇతర భాషలకు ఎలా పోర్ట్ చేయబోతున్నాం?" కాబట్టి మేము వెంటనే సైకిల్ ఆలోచనను విసిరివేసాము.
Msgpack JSONని పోలి ఉంటుంది, కానీ వేగంగా మరియు చిన్నదిగా ఉంటుంది. ఇది బహుళ భాషల మధ్య డేటాను మార్పిడి చేసుకోవడానికి అనుమతించే బైనరీ డేటా సీరియలైజేషన్ ఫార్మాట్.
మొదటి స్థాయిలో మేము సందేశాన్ని ఫార్వార్డ్ చేయడానికి రూటర్కు అవసరమైన కనీస సమాచారంతో పొదుపును కలిగి ఉన్నాము. రెండవ స్థాయిలో ప్యాక్ చేయబడిన msgpack నిర్మాణాలు ఉన్నాయి.
మేము msgpackను ఎంచుకున్నాము ఎందుకంటే ఇది JSONతో పోలిస్తే వేగంగా మరియు మరింత కాంపాక్ట్గా ఉంటుంది. కానీ మరీ ముఖ్యంగా, ఇది కస్టమ్ డేటా రకాలను సపోర్ట్ చేస్తుంది, ఇది మా “ఇటీవలి-స్థిర” స్కీమ్కు ముఖ్యమైన డేటా లేకపోవడాన్ని సూచించే ముడి బైనరీలు లేదా ప్రత్యేక వస్తువులను పాస్ చేయడం వంటి అద్భుతమైన ఫీచర్లను ఉపయోగించడానికి అనుమతిస్తుంది.
JMESPath
JMESPath అనేది JSON ప్రశ్న భాష.
అధికారిక JMESPath డాక్యుమెంటేషన్ నుండి మనకు లభించే వివరణ సరిగ్గా ఇదే, కానీ వాస్తవానికి, ఇది దాని కంటే చాలా ఎక్కువ చేస్తుంది. JMESPath మిమ్మల్ని ఏకపక్ష ట్రీ స్ట్రక్చర్లో సబ్ట్రీలను శోధించడానికి మరియు ఫిల్టర్ చేయడానికి మరియు ఫ్లైలో డేటాకు మార్పులను వర్తింపజేయడానికి అనుమతిస్తుంది. ఇది ప్రత్యేక ఫిల్టర్లు మరియు డేటా ట్రాన్స్ఫర్మేషన్ విధానాలను జోడించడానికి కూడా మిమ్మల్ని అనుమతిస్తుంది. అయినప్పటికీ, అర్థం చేసుకోవడానికి మెదడు ప్రయత్నం అవసరం.
జింజ
కొంతమంది వినియోగదారుల కోసం, మేము కాన్ఫిగరేషన్ను ఫైల్గా మార్చాలి - కాబట్టి మేము టెంప్లేట్ ఇంజిన్ని ఉపయోగిస్తాము మరియు జింజా అనేది స్పష్టమైన ఎంపిక. దాని సహాయంతో, మేము గమ్యస్థానంలో స్వీకరించిన టెంప్లేట్ మరియు డేటా నుండి కాన్ఫిగరేషన్ ఫైల్ను రూపొందిస్తాము.
కాన్ఫిగరేషన్ ఫైల్ను రూపొందించడానికి, మాకు JMESPath అభ్యర్థన, FSలో ఫైల్ లొకేషన్ కోసం టెంప్లేట్ మరియు కాన్ఫిగరేషన్ కోసం ఒక టెంప్లేట్ అవసరం. ఫైల్ అనుమతులను స్పష్టం చేయడం కూడా ఈ దశలో మంచి ఆలోచన. ఇవన్నీ ఒక ఫైల్లో విజయవంతంగా మిళితం చేయబడ్డాయి - కాన్ఫిగరేషన్ టెంప్లేట్ ప్రారంభానికి ముందు, మేము మిగిలిన వాటిని వివరించే YAML ఆకృతిలో హెడర్ను ఉంచాము.
ఉదాహరణకు:
---
selector: "[@][?@.fft._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) }}
కొత్త సేవ కోసం కాన్ఫిగరేషన్ ఫైల్ చేయడానికి, మేము కొత్త టెంప్లేట్ ఫైల్ను మాత్రమే జోడిస్తాము. ఉనికి యొక్క పాయింట్లపై సోర్స్ కోడ్ లేదా సాఫ్ట్వేర్కు ఎటువంటి మార్పులు అవసరం లేదు.
QControl ప్రత్యక్ష ప్రసారం చేయబడినప్పటి నుండి ఏమి మారింది? నెట్వర్క్లోని అన్ని నోడ్లకు కాన్ఫిగరేషన్ నవీకరణల యొక్క స్థిరమైన మరియు నమ్మదగిన డెలివరీ మొదటి మరియు అతి ముఖ్యమైన విషయం. రెండవది కాన్ఫిగరేషన్ను తనిఖీ చేయడానికి మరియు మా మద్దతు బృందం ద్వారా అలాగే సేవ యొక్క వినియోగదారుల ద్వారా దానికి మార్పులు చేయడం కోసం శక్తివంతమైన సాధనాన్ని స్వీకరించడం.
కాన్ఫిగరేషన్ సర్వర్ మరియు కాన్ఫిగరేషన్ స్వీకర్తల మధ్య కమ్యూనికేషన్ను సులభతరం చేయడానికి మేము ఇటీవలి-స్థిరమైన నవీకరణ పథకాన్ని ఉపయోగించి ఇవన్నీ చేయగలిగాము. రౌటింగ్ డేటా యొక్క కంటెంట్-స్వతంత్ర మార్గానికి మద్దతు ఇవ్వడానికి రెండు-లేయర్ ప్రోటోకాల్ను ఉపయోగించడం. పంపిణీ చేయబడిన ఫిల్టరింగ్ నెట్వర్క్లో జింజా-ఆధారిత కాన్ఫిగరేషన్ జనరేషన్ ఇంజిన్ విజయవంతంగా విలీనం చేయబడింది. ఈ సిస్టమ్ మా పంపిణీ చేయబడిన మరియు భిన్నమైన పెరిఫెరల్స్ కోసం విస్తృత శ్రేణి కాన్ఫిగరేషన్ పద్ధతులకు మద్దతు ఇస్తుంది.
మెటీరియల్ రాయడంలో మీ సహాయానికి ధన్యవాదాలు. , , .
పోస్ట్.
మూలం: www.habr.com
