మేము మోనోలిథిక్ అప్లికేషన్ నుండి మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌కి మారినప్పుడు, మేము కొత్త సవాళ్లను ఎదుర్కొంటాము.
ఏకశిలా అప్లికేషన్‌లో, సిస్టమ్‌లోని ఏ భాగంలో లోపం సంభవించిందో గుర్తించడం సాధారణంగా చాలా సులభం. చాలా మటుకు, సమస్య ఏకశిలా యొక్క కోడ్‌లో లేదా డేటాబేస్లో ఉంటుంది. కానీ మేము మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లో సమస్య కోసం వెతకడం ప్రారంభించినప్పుడు, ప్రతిదీ అంత స్పష్టంగా కనిపించదు. మేము అభ్యర్థన ప్రారంభం నుండి ముగింపు వరకు తీసుకున్న మొత్తం మార్గాన్ని కనుగొని, వందలాది మైక్రోసర్వీస్‌ల నుండి దాన్ని ఎంచుకోవాలి. అంతేకాకుండా, వాటిలో చాలా వరకు వారి స్వంత నిల్వ సౌకర్యాలు కూడా ఉన్నాయి, ఇది తార్కిక లోపాలు, అలాగే పనితీరు మరియు తప్పు సహనంతో సమస్యలను కూడా కలిగిస్తుంది.
అటువంటి సమస్యలను ఎదుర్కోవడంలో సహాయపడే సాధనం కోసం నేను చాలా కాలంగా వెతుకుతున్నాను (నేను దీని గురించి హాబ్రేలో వ్రాసాను: , ), కానీ చివరికి నేను నా స్వంత ఓపెన్ సోర్స్ పరిష్కారాన్ని తయారు చేసాను. ఈ వ్యాసంలో నేను సర్వీస్ మెష్ విధానం యొక్క ప్రయోజనాల గురించి మాట్లాడుతాను మరియు దాని అమలు కోసం కొత్త సాధనాన్ని పంచుకుంటాను.
పంపిణీ చేయబడిన వ్యవస్థలలో లోపాలను కనుగొనే సమస్యకు పంపిణీ చేయబడిన ట్రేసింగ్ అనేది ఒక సాధారణ పరిష్కారం. నెట్‌వర్క్ ఇంటరాక్షన్‌ల గురించి సమాచారాన్ని సేకరించే ఈ విధానం సిస్టమ్‌లో ఇంకా అమలు చేయబడకపోతే లేదా, అధ్వాన్నంగా, సిస్టమ్‌లో కొంత భాగం ఇది ఇప్పటికే సరిగ్గా పని చేస్తుంది, కానీ కొంతవరకు అది పాత సేవలకు జోడించబడనందున అది ఏమి చేయాలి ? సమస్య యొక్క ఖచ్చితమైన మూలకారణాన్ని గుర్తించడానికి, సిస్టమ్‌లో ఏమి జరుగుతుందో పూర్తి చిత్రాన్ని కలిగి ఉండటం అవసరం. కీలకమైన వ్యాపార-క్లిష్టమైన మార్గాలలో ఏ మైక్రోసర్వీస్‌లు పాల్గొంటున్నాయో అర్థం చేసుకోవడం చాలా ముఖ్యం.
ఇక్కడ సర్వీస్ మెష్ విధానం మా సహాయానికి రావచ్చు, ఇది నెట్‌వర్క్ సమాచారాన్ని సేకరించే అన్ని యంత్రాంగాలతో తాము నిర్వహించే సేవల కంటే తక్కువ స్థాయిలో వ్యవహరిస్తుంది. ఈ విధానం మాకు అన్ని ట్రాఫిక్‌లను అడ్డగించడానికి మరియు ఫ్లైలో విశ్లేషించడానికి అనుమతిస్తుంది. అంతేకాకుండా, అప్లికేషన్లు దాని గురించి ఏమీ తెలుసుకోవలసిన అవసరం లేదు.
సర్వీస్ మెష్ విధానం
సర్వీస్ మెష్ విధానం యొక్క ప్రధాన ఆలోచన ఏమిటంటే, నెట్‌వర్క్‌లో మరొక ఇన్‌ఫ్రాస్ట్రక్చర్ లేయర్‌ని జోడించడం, ఇది ఇంటర్-సర్వీస్ ఇంటరాక్షన్‌తో ఏదైనా పని చేయడానికి మమ్మల్ని అనుమతిస్తుంది. చాలా అమలులు క్రింది విధంగా పని చేస్తాయి: ప్రతి మైక్రోసర్వీస్‌కు పారదర్శక ప్రాక్సీతో కూడిన అదనపు సైడ్‌కార్ కంటైనర్ జోడించబడుతుంది, దీని ద్వారా సేవ యొక్క అన్ని ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ ట్రాఫిక్ పాస్ చేయబడుతుంది. మరియు ఇది మేము క్లయింట్ బ్యాలెన్సింగ్ చేయగల ప్రదేశం, భద్రతా విధానాలను వర్తింపజేయడం, అభ్యర్థనల సంఖ్యపై పరిమితులను విధించడం మరియు ఉత్పత్తిలో సేవల పరస్పర చర్యపై ముఖ్యమైన సమాచారాన్ని సేకరించడం.
సొల్యూషన్స్
ఈ విధానం యొక్క అనేక అమలులు ఇప్పటికే ఉన్నాయి: и . వారు బాక్స్ వెలుపల చాలా లక్షణాలను అందిస్తారు. కానీ అదే సమయంలో, వనరులపై పెద్ద ఓవర్ హెడ్ వస్తుంది. అంతేకాకుండా, అటువంటి వ్యవస్థ పనిచేసే పెద్ద క్లస్టర్, కొత్త అవస్థాపనను నిర్వహించడానికి ఎక్కువ వనరులు అవసరమవుతాయి. Avito వద్ద, మేము వేలకొద్దీ సేవా సందర్భాలను కలిగి ఉన్న kubernetes క్లస్టర్‌లను నిర్వహిస్తాము (మరియు వాటి సంఖ్య వేగంగా పెరుగుతూనే ఉంది). దాని ప్రస్తుత అమలులో, ఇస్టియో ఒక్కో సేవా ఉదాహరణకి ~300Mb RAMని వినియోగిస్తుంది. పెద్ద సంఖ్యలో అవకాశాల కారణంగా, పారదర్శక బ్యాలెన్సింగ్ సేవల మొత్తం ప్రతిస్పందన సమయాన్ని కూడా ప్రభావితం చేస్తుంది (10ms వరకు).
ఫలితంగా, మేము ప్రస్తుతం మనకు అవసరమైన సామర్థ్యాలను సరిగ్గా పరిశీలించాము మరియు మేము అటువంటి పరిష్కారాలను అమలు చేయడం ప్రారంభించిన ప్రధాన కారణం మొత్తం సిస్టమ్ నుండి ట్రేసింగ్ సమాచారాన్ని పారదర్శకంగా సేకరించే సామర్థ్యం అని నిర్ణయించుకున్నాము. మేము సేవల పరస్పర చర్యపై నియంత్రణను కలిగి ఉండాలనుకుంటున్నాము మరియు సేవల మధ్య బదిలీ చేయబడిన హెడర్‌లతో వివిధ అవకతవకలు చేయాలనుకుంటున్నాము.
ఫలితంగా, మేము మా నిర్ణయానికి వచ్చాము: .
నేత్రమేష్
సిస్టమ్‌లోని సేవల సంఖ్యతో సంబంధం లేకుండా, అనంతంగా స్కేల్ చేయగల సామర్థ్యంతో తేలికపాటి సర్వీస్ మెష్ పరిష్కారం.
కొత్త పరిష్కారం యొక్క ప్రధాన లక్ష్యాలు తక్కువ రిసోర్స్ ఓవర్ హెడ్ మరియు అధిక పనితీరు. ప్రధాన లక్షణాలలో, మేము వెంటనే మా జేగర్ సిస్టమ్‌కు ట్రేసింగ్ స్పాన్‌లను పారదర్శకంగా పంపగలగాలి.
నేడు, చాలా క్లౌడ్ పరిష్కారాలు గోలాంగ్‌లో అమలు చేయబడ్డాయి. మరియు, వాస్తవానికి, దీనికి కారణాలు ఉన్నాయి. I/Oతో అసమకాలికంగా పని చేసే నెట్‌వర్క్ అప్లికేషన్‌లను గోలాంగ్‌లో రాయడం మరియు అవసరమైన విధంగా కోర్ల అంతటా స్కేల్ చేయడం అనుకూలమైనది మరియు చాలా సులభం. మరియు, చాలా ముఖ్యమైనది ఏమిటంటే, ఈ సమస్యను పరిష్కరించడానికి పనితీరు సరిపోతుంది. అందుకే గోలాంగ్‌ని కూడా ఎంచుకున్నాం.
ఉత్పాదకత
గరిష్ట ఉత్పాదకతను సాధించడంపై మేము మా ప్రయత్నాలను కేంద్రీకరించాము. సేవ యొక్క ప్రతి ఉదాహరణకి ప్రక్కన అమలు చేయబడిన పరిష్కారం కోసం, RAM మరియు CPU సమయం యొక్క చిన్న వినియోగం అవసరం. మరియు, వాస్తవానికి, ప్రతిస్పందన ఆలస్యం కూడా చిన్నదిగా ఉండాలి.
ఎలాంటి ఫలితాలు వచ్చాయో చూద్దాం.
RAM
Netramesh ట్రాఫిక్ లేకుండా ~10Mb మరియు గరిష్టంగా 50 RPS వరకు లోడ్‌తో 10000Mb వినియోగిస్తుంది.
ఇస్టియో ఎన్వోయ్ ప్రాక్సీ ఎల్లప్పుడూ మా క్లస్టర్‌లలో వేల సంఖ్యలో ఉదాహరణలతో ~300Mbని వినియోగిస్తుంది. ఇది మొత్తం క్లస్టర్‌కు స్కేల్ చేయడానికి అనుమతించదు.
Netrameshతో మేము మెమరీ వినియోగంలో ~10x తగ్గింపు పొందాము.
CPU
CPU వినియోగం లోడ్ కింద సాపేక్షంగా సమానంగా ఉంటుంది. ఇది సైడ్‌కార్‌కి సమయం యూనిట్‌కు వచ్చిన అభ్యర్థనల సంఖ్యపై ఆధారపడి ఉంటుంది. గరిష్టంగా సెకనుకు 3000 అభ్యర్థనల వద్ద విలువలు:
మరో ముఖ్యమైన అంశం ఉంది: Netramesh - నియంత్రణ విమానం లేకుండా మరియు లోడ్ లేకుండా ఒక పరిష్కారం CPU సమయాన్ని వినియోగించదు. ఇస్టియోతో, సైడ్‌కార్‌లు ఎల్లప్పుడూ సర్వీస్ ఎండ్ పాయింట్‌లను అప్‌డేట్ చేస్తాయి. ఫలితంగా, మేము ఈ చిత్రాన్ని లోడ్ లేకుండా చూడవచ్చు:
మేము సేవల మధ్య కమ్యూనికేషన్ కోసం HTTP/1ని ఉపయోగిస్తాము. రాయబారి ద్వారా ప్రాక్సీ చేస్తున్నప్పుడు ఇస్టియోకి ప్రతిస్పందన సమయం 5-10ms వరకు పెరిగింది, ఇది మిల్లీసెకన్లలో ప్రతిస్పందించడానికి సిద్ధంగా ఉన్న సేవలకు చాలా ఎక్కువ. Netramesh తో ఈ సమయం 0.5-2ms కు తగ్గింది.
స్కేలబిలిటీ
ప్రతి ప్రాక్సీ వినియోగించే తక్కువ మొత్తంలో వనరులు ప్రతి సేవకు పక్కన ఉంచడం సాధ్యం చేస్తుంది. ప్రతి సైడ్‌కార్‌ను తేలికగా ఉంచడానికి కంట్రోల్ ప్లేన్ కాంపోనెంట్ లేకుండా నేత్రమేష్ ఉద్దేశపూర్వకంగా సృష్టించబడింది. తరచుగా సర్వీస్ మెష్ సొల్యూషన్స్‌లో, కంట్రోల్ ప్లేన్ ప్రతి సైడ్‌కార్‌కు సర్వీస్ డిస్కవరీ సమాచారాన్ని పంపిణీ చేస్తుంది. దానితో పాటు సమయం ముగిసింది మరియు బ్యాలెన్సింగ్ సెట్టింగ్‌ల గురించి సమాచారం వస్తుంది. అన్ని ఈ మీరు ఉపయోగకరమైన విషయాలు చాలా చేయడానికి అనుమతిస్తుంది, కానీ, దురదృష్టవశాత్తు, అది పరిమాణంలో sidecars ఉబ్బు.
సేవ ఆవిష్కరణ
Netramesh సర్వీస్ డిస్కవరీ కోసం ఎలాంటి అదనపు మెకానిజమ్‌లను జోడించదు. నేత్ర సైడ్‌కార్ ద్వారా అన్ని ట్రాఫిక్ పారదర్శకంగా ప్రాక్సిడ్ చేయబడుతుంది.
Netramesh HTTP/1 అప్లికేషన్ ప్రోటోకాల్‌కు మద్దతు ఇస్తుంది. దీన్ని నిర్వచించడానికి, పోర్ట్‌ల కాన్ఫిగర్ చేయదగిన జాబితా ఉపయోగించబడుతుంది. సాధారణంగా, సిస్టమ్ అనేక పోర్ట్‌లను కలిగి ఉంటుంది, దీని ద్వారా HTTP కమ్యూనికేషన్ జరుగుతుంది. ఉదాహరణకు, మేము సేవలు మరియు బాహ్య అభ్యర్థనల మధ్య పరస్పర చర్య కోసం 80, 8890, 8080ని ఉపయోగిస్తాము. ఈ సందర్భంలో, వాటిని పర్యావరణ వేరియబుల్ ఉపయోగించి సెట్ చేయవచ్చు. NETRA_HTTP_PORTS.
మీరు కుబెర్నెట్స్‌ను ఆర్కెస్ట్రేటర్‌గా మరియు సేవల మధ్య ఇంట్రా-క్లస్టర్ కమ్యూనికేషన్ కోసం దాని సర్వీస్ ఎంటిటీ మెకానిజమ్‌ని ఉపయోగిస్తే, అప్పుడు మెకానిజం సరిగ్గా అలాగే ఉంటుంది. ముందుగా, మైక్రోసర్వీస్ kube-dnsని ఉపయోగించి సర్వీస్ IP చిరునామాను పొందుతుంది మరియు దానికి కొత్త కనెక్షన్‌ను తెరుస్తుంది. ఈ కనెక్షన్ మొదట స్థానిక నేత్రా-సైడ్‌కార్‌తో స్థాపించబడింది మరియు అన్ని TCP ప్యాకెట్‌లు మొదట్లో నేత్ర వద్దకు చేరుకుంటాయి. తర్వాత, నేత్రా-సైడ్‌కార్ అసలు గమ్యస్థానంతో కనెక్షన్‌ని ఏర్పరుస్తుంది. నోడ్‌లోని పాడ్ IPపై NAT నేత్ర లేకుండా సరిగ్గా అలాగే ఉంటుంది.
పంపిణీ చేయబడిన ట్రేసింగ్ మరియు సందర్భం ఫార్వార్డింగ్
HTTP పరస్పర చర్యల గురించి ట్రేసింగ్ స్పాన్‌లను పంపడానికి అవసరమైన కార్యాచరణను Netramesh అందిస్తుంది. Netra-sidecar HTTP ప్రోటోకాల్‌ను అన్వయిస్తుంది, అభ్యర్థన ఆలస్యాన్ని కొలుస్తుంది మరియు HTTP హెడర్‌ల నుండి అవసరమైన సమాచారాన్ని సంగ్రహిస్తుంది. అంతిమంగా, మేము ఒకే జేగర్ సిస్టమ్‌లో అన్ని జాడలను పొందుతాము. ఫైన్-గ్రెయిన్డ్ కాన్ఫిగరేషన్ కోసం, మీరు అధికారిక లైబ్రరీ అందించిన ఎన్విరాన్మెంట్ వేరియబుల్స్‌ని కూడా ఉపయోగించవచ్చు .
కానీ ఒక సమస్య ఉంది. సేవలు ప్రత్యేక ఉబెర్ హెడర్‌ను రూపొందించి పంపే వరకు, సిస్టమ్‌లో కనెక్ట్ చేయబడిన ట్రేసింగ్ స్పాన్‌లను మేము చూడలేము. మరియు ఈ మేము త్వరగా సమస్యల కారణం కనుగొనేందుకు అవసరం ఏమిటి. ఇక్కడ మళ్ళీ నేత్రమేష్ ఒక పరిష్కారం ఉంది. ప్రాక్సీలు HTTP హెడర్‌లను చదివి, అవి uber ట్రేస్ ఐడిని కలిగి లేకుంటే, ఒకదాన్ని రూపొందించండి. నేత్రమేష్ ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ అభ్యర్థనల గురించిన సమాచారాన్ని సైడ్‌కార్‌లో నిల్వ చేస్తుంది మరియు అవసరమైన అవుట్‌గోయింగ్ అభ్యర్థన హెడర్‌లతో వాటిని మెరుగుపరచడం ద్వారా వాటిని సరిపోల్చుతుంది. సేవల్లో మీరు చేయాల్సిందల్లా కేవలం ఒక హెడర్‌ని పంపడమే X-Request-Id, ఇది ఎన్విరాన్మెంట్ వేరియబుల్ ఉపయోగించి కాన్ఫిగర్ చేయబడుతుంది NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netrameshలో సందర్భం యొక్క పరిమాణాన్ని నియంత్రించడానికి, మీరు క్రింది పర్యావరణ వేరియబుల్‌లను సెట్ చేయవచ్చు: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (సందర్భం నిల్వ చేయబడే సమయం) మరియు NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (సందర్భ శుభ్రత యొక్క ఫ్రీక్వెన్సీ).
ప్రత్యేక సెషన్ టోకెన్‌తో గుర్తించడం ద్వారా మీ సిస్టమ్‌లో బహుళ మార్గాలను కలపడం కూడా సాధ్యమే. Netra మీరు ఇన్స్టాల్ అనుమతిస్తుంది HTTP_HEADER_TAG_MAP HTTP హెడర్‌లను సంబంధిత ట్రేసింగ్ స్పాన్ ట్యాగ్‌లుగా మార్చడానికి. ఇది పరీక్షకు ప్రత్యేకంగా ఉపయోగపడుతుంది. ఫంక్షనల్ పరీక్షలో ఉత్తీర్ణత సాధించిన తర్వాత, సంబంధిత సెషన్ కీ ద్వారా ఫిల్టర్ చేయడం ద్వారా సిస్టమ్‌లోని ఏ భాగం ప్రభావితమైందో మీరు చూడవచ్చు.
అభ్యర్థన మూలాన్ని నిర్ణయించడం
అభ్యర్థన ఎక్కడ నుండి వచ్చిందో నిర్ణయించడానికి, మీరు మూలంతో స్వయంచాలకంగా హెడర్‌ని జోడించే కార్యాచరణను ఉపయోగించవచ్చు. పర్యావరణ వేరియబుల్ ఉపయోగించడం NETRA_HTTP_X_SOURCE_HEADER_NAME మీరు స్వయంచాలకంగా ఇన్స్టాల్ చేయబడే హెడర్ పేరును పేర్కొనవచ్చు. ఉపయోగించడం ద్వార NETRA_HTTP_X_SOURCE_VALUE మీరు అన్ని అవుట్‌గోయింగ్ అభ్యర్థనలకు X-సోర్స్ హెడర్ సెట్ చేయబడే విలువను సెట్ చేయవచ్చు.
ఇది ఈ ఉపయోగకరమైన హెడర్ యొక్క పంపిణీని నెట్‌వర్క్ అంతటా ఒకే విధంగా పంపిణీ చేయడానికి అనుమతిస్తుంది. అప్పుడు మీరు దీన్ని సేవల్లో ఉపయోగించవచ్చు మరియు లాగ్‌లు మరియు మెట్రిక్‌లకు జోడించవచ్చు.
ట్రాఫిక్ రూటింగ్ మరియు నేత్రమేష్ ఇంటర్నల్‌లు
నేత్రమేష్ రెండు ప్రధాన భాగాలను కలిగి ఉంటుంది. మొదటిది, netra-init, ట్రాఫిక్‌ను అడ్డగించడానికి నెట్‌వర్క్ నియమాలను సెట్ చేస్తుంది. అతను ఉపయోగిస్తాడు నేత్రమేష్ యొక్క రెండవ ప్రధాన భాగం అయిన సైడ్‌కార్‌లోని ట్రాఫిక్‌ను పూర్తిగా లేదా కొంత భాగాన్ని అడ్డగించడానికి. ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ TCP సెషన్‌ల కోసం ఏ పోర్ట్‌లను అడ్డగించాలో మీరు కాన్ఫిగర్ చేయవచ్చు: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
సాధనం ఒక ఆసక్తికరమైన లక్షణాన్ని కూడా కలిగి ఉంది - సంభావ్య రూటింగ్. మీరు ట్రేసింగ్ స్పాన్‌లను సేకరించడం కోసం ప్రత్యేకంగా Netrameshని ఉపయోగిస్తే, ఉత్పత్తి వాతావరణంలో మీరు వనరులను ఆదా చేయవచ్చు మరియు వేరియబుల్‌లను ఉపయోగించి ప్రాబబిలిస్టిక్ రూటింగ్‌ని ప్రారంభించవచ్చు. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 నుండి 1 వరకు). డిఫాల్ట్ విలువ 1 (అన్ని ట్రాఫిక్ అంతరాయం కలిగిస్తుంది).
విజయవంతమైన అంతరాయం తర్వాత, నేత్ర సైడ్‌కార్ కొత్త కనెక్షన్‌ని అంగీకరిస్తుంది మరియు ఉపయోగిస్తుంది SO_ORIGINAL_DST అసలు గమ్యాన్ని పొందడానికి సాకెట్ ఎంపిక. నేత్రా అసలు IP చిరునామాకు కొత్త కనెక్షన్‌ని తెరుస్తుంది మరియు పార్టీల మధ్య రెండు-మార్గం TCP కమ్యూనికేషన్‌ను ఏర్పాటు చేస్తుంది, అన్ని ట్రాఫిక్‌లను వింటుంది. పోర్ట్ HTTPగా నిర్వచించబడితే, నేత్రా దానిని అన్వయించి ట్రేస్ చేయడానికి ప్రయత్నిస్తుంది. HTTP పార్సింగ్ విఫలమైతే, Netra TCPకి తిరిగి వస్తుంది మరియు బైట్‌లను పారదర్శకంగా ప్రాక్సీ చేస్తుంది.
డిపెండెన్సీ గ్రాఫ్‌ను రూపొందించడం
జేగర్‌లో పెద్ద మొత్తంలో ట్రేసింగ్ సమాచారాన్ని స్వీకరించిన తర్వాత, నేను సిస్టమ్‌లోని పరస్పర చర్యల యొక్క పూర్తి గ్రాఫ్‌ని పొందాలనుకుంటున్నాను. కానీ మీ సిస్టమ్ చాలా లోడ్ చేయబడి, రోజుకు బిలియన్ల కొద్దీ ట్రేసింగ్ స్పాన్‌లు పేరుకుపోతే, వాటిని సమగ్రపరచడం అంత తేలికైన పని కాదు. దీన్ని చేయడానికి అధికారిక మార్గం ఉంది: . అయినప్పటికీ, పూర్తి గ్రాఫ్‌ను రూపొందించడానికి గంటల సమయం పడుతుంది మరియు గత XNUMX గంటలలో జేగర్ నుండి మొత్తం డేటాసెట్‌ను డౌన్‌లోడ్ చేయమని మిమ్మల్ని బలవంతం చేస్తుంది.
ట్రేసింగ్ స్పాన్‌లను నిల్వ చేయడానికి మీరు సాగే శోధనను ఉపయోగిస్తుంటే, మీరు ఉపయోగించవచ్చు , ఇది సాగే శోధన యొక్క లక్షణాలు మరియు సామర్థ్యాలను ఉపయోగించి నిమిషాల్లో అదే గ్రాఫ్‌ను నిర్మిస్తుంది.
Netramesh ఎలా ఉపయోగించాలి
ఏదైనా ఆర్కెస్ట్రేటర్‌ను నడుపుతున్న ఏ సేవకైనా నేత్ర సులభంగా జోడించబడుతుంది. మీరు ఒక ఉదాహరణను చూడవచ్చు .
ప్రస్తుతానికి, సేవలకు సైడ్‌కార్‌లను స్వయంచాలకంగా అమలు చేసే సామర్థ్యం నేత్రాకు లేదు, కానీ అమలు కోసం ప్రణాళికలు ఉన్నాయి.
నేత్రమేష్ భవిష్యత్తు
ప్రధాన ఉద్దేశ్యం కనీస వనరుల వ్యయాలు మరియు అధిక పనితీరును సాధించడం, ఇంటర్-సర్వీస్ కమ్యూనికేషన్ యొక్క పరిశీలన మరియు నియంత్రణ కోసం ప్రాథమిక సామర్థ్యాలను అందించడం.
భవిష్యత్తులో, HTTPతో పాటు ఇతర అప్లికేషన్ లేయర్ ప్రోటోకాల్‌లకు Netramesh మద్దతు ఇస్తుంది. L7 రూటింగ్ సమీప భవిష్యత్తులో అందుబాటులో ఉంటుంది.
మీరు ఇలాంటి సమస్యలను ఎదుర్కొంటే Netrameshని ఉపయోగించండి మరియు ప్రశ్నలు మరియు సూచనలతో మాకు వ్రాయండి.
మూలం: www.habr.com