గమనిక. అనువాదం.: ఈ ఆర్టికల్ రచయిత (Luc Perkins) CNCF సంస్థలో డెవలపర్ అడ్వకేట్, ఇది లింకర్డ్, SMI (సర్వీస్ మెష్ ఇంటర్ఫేస్) మరియు కుమా వంటి ఓపెన్ సోర్స్ ప్రాజెక్ట్లకు నిలయం (ఇస్టియో ఎందుకు అని మీరు కూడా ఆలోచిస్తున్నారా? ఈ జాబితాలో లేదా?.). "సర్వీస్ మెష్" అని పిలువబడే అధునాతన హైప్ గురించి DevOps కమ్యూనిటీకి మంచి అవగాహన తీసుకురావడానికి మరోసారి ప్రయత్నిస్తూ, అటువంటి పరిష్కారాలు అందించే 16 లక్షణ సామర్థ్యాలను అతను జాబితా చేశాడు.
నేడు ― సాఫ్ట్వేర్ ఇంజనీరింగ్ రంగంలో హాటెస్ట్ టాపిక్లలో ఒకటి (మరియు సరిగ్గా!). ఈ సాంకేతికత చాలా ఆశాజనకంగా ఉందని నేను భావిస్తున్నాను మరియు దీనిని విస్తృతంగా స్వీకరించడాన్ని చూడాలనుకుంటున్నాను (అది అర్ధవంతంగా ఉన్నప్పుడు). అయినప్పటికీ, ఇది ఇప్పటికీ చాలా మందికి మిస్టరీ యొక్క ప్రకాశంతో చుట్టుముట్టబడి ఉంది. అదే సమయంలో, ఎవరు కూడా బాగా తెలిసిన దానితో, దాని ప్రయోజనాలను మరియు అది సరిగ్గా ఏమిటో (నిజంగా మీతో సహా) స్పష్టంగా చెప్పడం చాలా కష్టం. ఈ ఆర్టికల్లో నేను వివిధ జాబితాలను జాబితా చేయడం ద్వారా పరిస్థితిని సరిచేయడానికి ప్రయత్నిస్తాను కేసులు వాడండి "సర్వీస్ మెష్లు"*.
* గమనిక transl.: ఇక్కడ మరియు తదుపరి కథనంలో ఖచ్చితంగా ఈ అనువాదం ("సర్వీస్ మెష్") ఇప్పటికీ కొత్త పదం సర్వీస్ మెష్ కోసం ఉపయోగించబడుతుంది.
కానీ మొదట నేను కొన్ని వ్యాఖ్యలు చేయాలనుకుంటున్నాను:
- నేను ఎప్పుడూ సర్వీస్ మెష్లతో పని చేయలేదు లేదా నా స్వంత విద్య కోసం ప్రారంభించిన ప్రాజెక్ట్ల వెలుపల వాటిని ఉపయోగించలేదు. మరోవైపు, నేను 2015లో Twitter యొక్క అంతర్గత సేవా మెష్ కోసం డాక్యుమెంటేషన్ను వ్రాసాను (దీనిని "సర్వీస్ మెష్" అని కూడా పిలవలేదు) మరియు వెబ్సైట్ మరియు డాక్యుమెంటేషన్ అభివృద్ధిలో పాల్గొన్నాను , కాబట్టి ఏదో అర్థం.
- నా జాబితా సుమారుగా మరియు అసంపూర్ణంగా ఉంది. నాకు తెలియని వినియోగ సందర్భాలు ఉండవచ్చు మరియు సాంకేతికత అభివృద్ధి చెందుతున్నప్పుడు మరియు దాని ప్రజాదరణ పెరిగేకొద్దీ కాలక్రమేణా కొత్త ఎంపికలు తలెత్తుతాయి.
- అదే సమయంలో, ఇప్పటికే ఉన్న ప్రతి సర్వీస్ మెష్ అమలు జాబితా చేయబడిన అన్ని వినియోగ కేసులకు మద్దతు ఇవ్వదు. అందువల్ల, “సర్వీస్ మెష్ కెన్...” వంటి నా స్టేట్మెంట్లను “వ్యక్తిగతమైనది మరియు బహుశా అన్ని ప్రముఖ సర్వీస్ మెష్ అమలులు చేయగలవు...” అని చదవాలి.
- ఉదాహరణల క్రమం ఎటువంటి తేడా లేదు.
చిన్న జాబితా:
- సేవ ఆవిష్కరణ;
- ఎన్క్రిప్షన్;
- ప్రమాణీకరణ మరియు అధికారం;
- లోడ్ బ్యాలెన్సింగ్;
- సర్క్యూట్ బ్రేకింగ్;
- ఆటోస్కేలింగ్;
- కానరీ విస్తరణలు;
- నీలం-ఆకుపచ్చ విస్తరణలు;
- ఆరోగ్య పరీక్ష;
- లోడ్ షెడ్డింగ్;
- ట్రాఫిక్ మిర్రరింగ్;
- ఇన్సులేషన్;
- అభ్యర్థన రేటు పరిమితి, పునఃప్రయత్నాలు మరియు గడువు ముగిసింది;
- టెలిమెట్రీ;
- ఆడిట్;
- విజువలైజేషన్.
1. సేవ ఆవిష్కరణ
TL;DR: సాధారణ పేర్లను ఉపయోగించి నెట్వర్క్లోని ఇతర సేవలకు కనెక్ట్ చేయండి.
తగిన పేర్లను ఉపయోగించి సేవలు స్వయంచాలకంగా ఒకదానికొకటి "కనుగొనగలవు" - ఉదాహరణకు, service.api.production, pets/staging లేదా cassandra. క్లౌడ్ పరిసరాలు సాగేవి మరియు ఒకే పేరు సేవ యొక్క అనేక సందర్భాలను దాచవచ్చు. అటువంటి పరిస్థితిలో అన్ని IP చిరునామాలను హార్డ్కోడ్ చేయడం భౌతికంగా అసాధ్యం అని స్పష్టమవుతుంది.
అదనంగా, ఒక సేవ మరొకదాన్ని కనుగొన్నప్పుడు, అది ఆ సేవకు అభ్యర్థనలను పంపగలగాలి, అవి దాని విరిగిన ఉదాహరణ యొక్క ఇన్పుట్లో ముగుస్తాయి. మరో మాటలో చెప్పాలంటే, సర్వీస్ మెష్ తప్పనిసరిగా అన్ని సర్వీస్ ఇన్స్టాన్స్ల ఆరోగ్యాన్ని పర్యవేక్షించాలి మరియు హోస్ట్ల జాబితాను వీలైనంత వరకు తాజాగా ఉంచాలి.
ప్రతి సర్వీస్ మెష్ సర్వీస్ డిస్కవరీ మెకానిజంను విభిన్నంగా అమలు చేస్తుంది. ప్రస్తుతానికి, Kubernetes DNS వంటి బాహ్య ప్రక్రియలకు అప్పగించడం అత్యంత సాధారణ మార్గం. గతంలో ట్విట్టర్లో మేము ఈ ప్రయోజనం కోసం నామకరణ వ్యవస్థను ఉపయోగించాము . అదనంగా, సర్వీస్ మెష్ సాంకేతికత కస్టమ్ నేమింగ్ మెకానిజమ్లు ఉద్భవించడాన్ని సాధ్యం చేస్తుంది (అయితే అలాంటి కార్యాచరణతో నేను ఇంకా ఏ SM అమలును చూడలేదు).
2. ఎన్క్రిప్షన్
TL;DR: సేవల మధ్య గుప్తీకరించని ట్రాఫిక్ను వదిలించుకోండి మరియు ఈ ప్రక్రియను స్వయంచాలకంగా మరియు స్కేలబుల్గా చేయండి.
దాడి చేసేవారు మీ అంతర్గత నెట్వర్క్లోకి ప్రవేశించలేరని తెలుసుకోవడం ఆనందంగా ఉంది. ఫైర్వాల్లు దీనికి గొప్ప పని చేస్తాయి. కానీ ఒక హ్యాకర్ లోపలికి వస్తే ఏమి జరుగుతుంది? ఇంట్రా సర్వీస్ ట్రాఫిక్తో అతను కోరుకున్నది చేయగలడా? ఇంత జరిగినా ఇలా జరగకూడదని ఆశిద్దాం. ఈ దృష్టాంతాన్ని నివారించడానికి, మీరు జీరో-ట్రస్ట్ నెట్వర్క్ని అమలు చేయాలి, దీనిలో సేవల మధ్య ట్రాఫిక్ మొత్తం గుప్తీకరించబడుతుంది. చాలా ఆధునిక సేవా మెష్లు పరస్పరం ద్వారా దీనిని సాధిస్తాయి (మ్యూచువల్ TLS, mTLS). కొన్ని సందర్భాల్లో, mTLS మొత్తం మేఘాలు మరియు క్లస్టర్లలో పనిచేస్తుంది (ఇంటర్ ప్లానెటరీ కమ్యూనికేషన్లు ఏదో ఒకరోజు ఇలాగే ఏర్పాటు చేయబడతాయని నేను అనుకుంటున్నాను).
వాస్తవానికి, mTLS సర్వీస్ మెష్ కోసం ఐచ్ఛికం. ప్రతి సేవ దాని స్వంత TLSని చూసుకోగలదు, అయితే మీరు ధృవపత్రాలను రూపొందించడానికి, సేవా హోస్ట్లలో వాటిని పంపిణీ చేయడానికి మరియు ఫైల్ల నుండి ఈ ప్రమాణపత్రాలను లోడ్ చేసే అప్లికేషన్లో కోడ్ని చేర్చడానికి ఒక మార్గాన్ని కనుగొనవలసి ఉంటుందని దీని అర్థం. అవును, ఈ సర్టిఫికేట్లను క్రమమైన వ్యవధిలో పునరుద్ధరించడం మర్చిపోవద్దు. సర్వీస్ మెష్లు వంటి సిస్టమ్లతో mTLSని ఆటోమేట్ చేస్తాయి , ఇది, సర్టిఫికేట్లను జారీ చేసే మరియు తిరిగే ప్రక్రియను ఆటోమేట్ చేస్తుంది.
3. ప్రమాణీకరణ మరియు అధికారం
TL;DR: రిక్వెస్ట్ చేసే వ్యక్తి ఎవరో గుర్తించండి మరియు అభ్యర్థన సేవకు చేరుకోవడానికి ముందు వారు ఏమి చేయడానికి అనుమతించబడతారో నిర్వచించండి.
సేవలు తరచుగా తెలుసుకోవాలి ఎవరు అభ్యర్థన (ప్రామాణీకరణ) నిర్వహిస్తుంది మరియు ఈ సమాచారాన్ని ఉపయోగించి, నిర్ణయిస్తుంది ఆ ఇచ్చిన ఎంటిటీని చేయడానికి అనుమతించబడుతుంది (అధికారం). ఈ సందర్భంలో, "ఎవరు" అనే సర్వనామం దాచవచ్చు:
- ఇతర సేవలు. దీనిని "ప్రామాణీకరణ" అంటారు తోటివాడు" ఉదాహరణకు, సేవ
webసేవను యాక్సెస్ చేయాలనుకుంటున్నారుdb. సేవా మెష్లు సాధారణంగా ఇటువంటి సమస్యలను mTLSని ఉపయోగించి పరిష్కరిస్తాయి: ఈ సందర్భంలో సర్టిఫికెట్లు అవసరమైన ఐడెంటిఫైయర్గా పనిచేస్తాయి. - కొంతమంది మానవ వినియోగదారులు. దీనిని "ప్రామాణీకరణ" అంటారు అభ్యర్థన" ఉదాహరణకు, వినియోగదారు
haxor69కొత్త దీపం కొనాలనుకుంటున్నారు. సేవా మెష్లు వివిధ యంత్రాంగాలను అందిస్తాయి, ఉదా. .మనలో చాలా మంది అప్లికేషన్ కోడ్లో దీన్ని చేసారు. ఒక అభ్యర్థన వస్తుంది, మేము టేబుల్ ద్వారా చూస్తాము
users, వినియోగదారుని కనుగొని, పాస్వర్డ్ను సరిపోల్చండి, ఆపై నిలువు వరుసను తనిఖీ చేయండిpermissionsమొదలైనవి సర్వీస్ మెష్ విషయంలో, అభ్యర్థన సేవకు చేరుకోవడానికి ముందే ఇది జరుగుతుంది.
అభ్యర్థన ఎవరి నుండి వచ్చిందో మేము నిర్ధారించిన తర్వాత, ఈ ఎంటిటీ ఏమి చేయడానికి అనుమతించబడుతుందో మేము గుర్తించాలి. కొన్ని సర్వీస్ మెష్లు YAML ఫైల్లుగా లేదా కమాండ్ లైన్లో ప్రాథమిక విధానాలను (ఎవరు ఏమి చేయగలరు అనే దాని గురించి) సెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తాయి, మరికొన్ని ఫ్రేమ్వర్క్లతో ఏకీకరణను అందిస్తాయి . మీ సేవలు విశ్వసనీయ మూలం నుండి వచ్చినట్లు భావించి, ఏదైనా అభ్యర్థనను సురక్షితంగా ఆమోదించడమే అంతిమ లక్ష్యం и ఈ చర్య అనుమతించబడింది.
4. లోడ్ బ్యాలెన్సింగ్
TL;DR: నిర్దిష్ట నమూనా ప్రకారం సేవా సందర్భాలలో లోడ్ను పంపిణీ చేయండి.
సేవా విభాగంలోని "సేవ" చాలా తరచుగా అనేక సారూప్య సందర్భాలను కలిగి ఉంటుంది. ఉదాహరణకు, ఈ రోజు సేవ cache 5 కాపీలు ఉంటాయి మరియు రేపు వాటి సంఖ్య 11కి పెరగవచ్చు. అభ్యర్థనలు పంపబడ్డాయి cache, ఒక నిర్దిష్ట ప్రయోజనానికి అనుగుణంగా పంపిణీ చేయాలి. ఉదాహరణకు, జాప్యాన్ని కనిష్టీకరించండి లేదా పని చేసే సందర్భాన్ని పొందే సంభావ్యతను పెంచండి. సాధారణంగా ఉపయోగించే అల్గోరిథం రౌండ్-రాబిన్, కానీ అనేక ఇతరాలు ఉన్నాయి - ఉదాహరణకు, వెయిటెడ్ పద్ధతి (బరువు) ప్రశ్నలు (మీరు ఇష్టపడే లక్ష్యాలను ఎంచుకోవచ్చు), రింగ్ చేయండి (రింగ్) హ్యాషింగ్ (అప్స్ట్రీమ్ హోస్ట్లలో స్థిరమైన హ్యాషింగ్ ఉపయోగించడం) లేదా కనీసం అభ్యర్థన పద్ధతి (అత్యల్ప అభ్యర్థనలు ఉన్న ఉదాహరణకి ప్రాధాన్యత ఇవ్వబడుతుంది).
క్లాసిక్ బ్యాలెన్సర్లు HTTP కాషింగ్ మరియు DDoS రక్షణ వంటి ఇతర ఫంక్షన్లను కలిగి ఉంటాయి, కానీ అవి తూర్పు-పశ్చిమ ట్రాఫిక్కు (అంటే డేటా సెంటర్లో ప్రవహించే ట్రాఫిక్కు - ఇంచుమించుగా. ట్రాన్స్ఎల్.) (సర్వీస్ మెష్ యొక్క సాధారణ పరిధి) చాలా సందర్భోచితంగా ఉండవు. వాస్తవానికి, లోడ్ బ్యాలెన్సింగ్ కోసం సర్వీస్ మెష్ను ఉపయోగించాల్సిన అవసరం లేదు, కానీ ఇది కేంద్రీకృత నియంత్రణ లేయర్ నుండి ప్రతి సేవకు బ్యాలెన్సింగ్ విధానాలను సెట్ చేయడానికి మరియు నియంత్రించడానికి మిమ్మల్ని అనుమతిస్తుంది, తద్వారా నెట్వర్క్ స్టాక్లో ప్రత్యేక లోడ్ బ్యాలెన్సర్లను అమలు చేయడం మరియు కాన్ఫిగర్ చేయడం అవసరం లేదు. .
5. సర్క్యూట్ బ్రేకింగ్
TL;DR: సమస్యాత్మక సేవకు ట్రాఫిక్ను ఆపివేయండి మరియు అధ్వాన్నమైన సందర్భాల్లో నష్టాన్ని నియంత్రించండి.
కొన్ని కారణాల వలన సేవ ట్రాఫిక్ను భరించలేకపోతే, ఈ సమస్యను పరిష్కరించడానికి సర్వీస్ మెష్ అనేక ఎంపికలను అందిస్తుంది (ఇతరులు తగిన విభాగాలలో చర్చించబడతాయి). ట్రాఫిక్ నుండి సేవను డిస్కనెక్ట్ చేయడానికి సర్క్యూట్ బ్రేకింగ్ అత్యంత తీవ్రమైన ఎంపిక. అయినప్పటికీ, అది అర్ధవంతం కాదు - బ్యాకప్ ప్లాన్ అవసరం. వెనుక ఒత్తిడి అందించవచ్చు () అభ్యర్థనలు చేసే సేవలకు (దీని కోసం మీ సర్వీస్ మెష్ని కాన్ఫిగర్ చేయడం మర్చిపోవద్దు!), లేదా, ఉదాహరణకు, స్టేటస్ పేజీకి ఎరుపు రంగు వేయడం మరియు వినియోగదారులను “ఫాలింగ్ వేల్” (“ట్విట్టర్)తో పేజీ యొక్క మరొక వెర్షన్కి మళ్లించడం డౌన్").
సర్వీస్ మెష్లు మిమ్మల్ని నిర్వచించడానికి మాత్రమే అనుమతించవు ఉన్నప్పుడు షట్డౌన్ అనుసరించబడుతుంది మరియు ఆ ఇది అనుసరిస్తుంది. ఈ సందర్భంలో, “ఎప్పుడు” అనేది పేర్కొన్న పారామితుల కలయికను కలిగి ఉంటుంది: నిర్దిష్ట వ్యవధికి సంబంధించిన మొత్తం అభ్యర్థనల సంఖ్య, సమాంతర కనెక్షన్ల సంఖ్య, పెండింగ్లో ఉన్న అభ్యర్థనలు, క్రియాశీల పునఃప్రయత్నాలు మొదలైనవి.
మీరు బహుశా సర్క్యూట్ బ్రేకింగ్ను దుర్వినియోగం చేయకూడదనుకుంటున్నారు, అయితే అత్యవసర పరిస్థితుల్లో మీ వద్ద బ్యాకప్ ప్లాన్ ఉందని తెలుసుకోవడం ఆనందంగా ఉంది.
6. ఆటోస్కేలింగ్
TL;DR: పేర్కొన్న ప్రమాణాలను బట్టి సేవా సందర్భాల సంఖ్యను పెంచండి లేదా తగ్గించండి.
సర్వీస్ మెష్లు షెడ్యూలర్లు కావు, కాబట్టి అవి అలా చేయవు చేపట్టు మీరే స్కేలింగ్. అయినప్పటికీ, ఏ ప్లానర్లు తమ నిర్ణయాలను ఆధారం చేసుకుంటారో వారు సమాచారాన్ని అందించగలరు. సర్వీస్ మెష్లు సేవల మధ్య ఉన్న అన్ని ట్రాఫిక్లకు ప్రాప్యతను కలిగి ఉన్నందున, ఏమి జరుగుతుందో వాటి గురించి విస్తృతమైన సమాచారం ఉంది: ఏ సేవలు సమస్యలను ఎదుర్కొంటున్నాయి, ఏ సేవలు చాలా తేలికగా లోడ్ చేయబడ్డాయి (వాటికి కేటాయించిన సామర్థ్యం వృధా అవుతుంది) మొదలైనవి.
ఉదాహరణకు, పాడ్ల CPU మరియు మెమరీ వినియోగం ఆధారంగా Kubernetes సేవలను స్కేల్ చేస్తుంది (మా నివేదిక చూడండి""- సుమారు. అనువాదం.), కానీ మీరు ఏదైనా ఇతర మెట్రిక్ (మా విషయంలో, ట్రాఫిక్ సంబంధిత) ఆధారంగా స్కేల్ చేయాలని నిర్ణయించుకుంటే, మీకు ప్రత్యేక మెట్రిక్ అవసరం. నిర్వహణ దీన్ని ఎలా చేయాలో చూపిస్తుంది , и , కానీ ప్రక్రియ చాలా క్లిష్టంగా ఉంటుంది. "సేవా ఉదంతాల సంఖ్యను పెంచండి auth, పెండింగ్లో ఉన్న అభ్యర్థనల సంఖ్య ఒక నిమిషంలోపు థ్రెషోల్డ్ను మించి ఉంటే."
7. కానరీ విస్తరణలు
TL;DR: వినియోగదారుల ఉపసమితిలో కొత్త ఫీచర్లు లేదా సర్వీస్ వెర్షన్లను పరీక్షించండి.
మీరు SaaS ఉత్పత్తిని అభివృద్ధి చేస్తున్నారని అనుకుందాం మరియు దాని యొక్క కొత్త వెర్షన్ను విడుదల చేయాలనుకుంటున్నారు. మీరు దీన్ని స్టేజింగ్లో పరీక్షించారు మరియు ఇది గొప్పగా పనిచేసింది. కానీ వాస్తవ పరిస్థితులలో ఆమె ప్రవర్తన గురించి ఇప్పటికీ కొన్ని ఆందోళనలు ఉన్నాయి. మరో మాటలో చెప్పాలంటే, మీరు వినియోగదారు నమ్మకాన్ని రిస్క్ చేయకుండా నిజమైన సమస్యలపై కొత్త సంస్కరణను పరీక్షించాలి. కానరీ విస్తరణలు దీనికి గొప్పవి. వినియోగదారుల ఉపసమితికి కొత్త ఫీచర్ను ప్రదర్శించడానికి అవి మిమ్మల్ని అనుమతిస్తాయి. ఈ ఉపసమితి అత్యంత విశ్వసనీయ వినియోగదారులు లేదా ఉత్పత్తి యొక్క ఉచిత సంస్కరణతో పని చేసేవారు లేదా "గినియా పిగ్స్" కావాలనే కోరికను వ్యక్తం చేసిన వినియోగదారులను కలిగి ఉండవచ్చు.
సర్వీస్ మెష్లు అప్లికేషన్ యొక్క ఏ వెర్షన్ను ఎవరు చూస్తారో నిర్ణయించే ప్రమాణాలను పేర్కొనడానికి మిమ్మల్ని అనుమతించడం ద్వారా మరియు తదనుగుణంగా ట్రాఫిక్ను రూట్ చేయడం ద్వారా దీన్ని అమలు చేస్తారు. అయితే, సేవలకు ఏమీ మారదు. సేవ యొక్క సంస్కరణ 1.0 అన్ని అభ్యర్థనలను చూడవలసిన వినియోగదారుల నుండి వస్తుందని విశ్వసిస్తుంది మరియు వెర్షన్ 1.1 దాని వినియోగదారులకు కూడా అదే నమ్మకం. ఇంతలో, మీరు పాత మరియు కొత్త వెర్షన్ల మధ్య ట్రాఫిక్ శాతాన్ని మార్చవచ్చు, ఇది స్థిరంగా పనిచేస్తే మరియు మీ “గినియా పిగ్లు” ముందుకు సాగితే పెరుగుతున్న వినియోగదారుల సంఖ్యను కొత్త దానికి దారి మళ్లించవచ్చు.
8. బ్లూ-గ్రీన్ విస్తరణలు
TL;DR: ఒక చక్కని కొత్త ఫీచర్ను రూపొందించండి, అయితే వెంటనే ప్రతిదీ వెనక్కి తీసుకోవడానికి సిద్ధంగా ఉండండి.
అర్థం పాత, "ఆకుపచ్చ"తో సమాంతరంగా కొత్త "నీలం" సేవను ప్రారంభించడం. ప్రతిదీ సజావుగా జరిగి, కొత్త సేవ బాగా పనిచేస్తే, పాతది క్రమంగా నిలిపివేయబడుతుంది. (అయ్యో, ఏదో ఒక రోజు ఈ కొత్త "బ్లూ" సర్వీస్ "ఆకుపచ్చ" యొక్క విధిని పునరావృతం చేస్తుంది మరియు అదృశ్యమవుతుంది...) కొత్త ఫంక్షన్ కవర్ చేసే కానరీ వాటి నుండి బ్లూ-గ్రీన్ విస్తరణలు భిన్నంగా ఉంటాయి అందరూ ఒకేసారి వినియోగదారులు (భాగం కాదు); ఏదైనా తప్పు జరిగితే "సురక్షిత నౌకాశ్రయం" సిద్ధంగా ఉండటమే ఇక్కడ ముఖ్యాంశం.
సర్వీస్ మెష్లు "బ్లూ" సేవను పరీక్షించడానికి చాలా అనుకూలమైన మార్గాన్ని అందిస్తాయి మరియు సమస్యల విషయంలో తక్షణమే పని చేసే "ఆకుపచ్చ"కి మారతాయి. "బ్లూ" యొక్క పని గురించి వారు చాలా సమాచారాన్ని (క్రింద "టెలిమెట్రీ" చూడండి) అందిస్తారనే వాస్తవం చెప్పనవసరం లేదు, ఇది పూర్తి ఆపరేషన్ కోసం సిద్ధంగా ఉందో లేదో అర్థం చేసుకోవడానికి సహాయపడుతుంది.
గమనిక. అనువాదం.: మీరు Kubernetes లో వివిధ విస్తరణ వ్యూహాల గురించి మరింత చదువుకోవచ్చు (ప్రస్తావించిన కానరీ, నీలం/ఆకుపచ్చ మరియు ఇతర వాటితో సహా) .
9. ఆరోగ్య తనిఖీ
TL;DR: ఏ సేవా సందర్భాలు ఫంక్షనల్గా ఉన్నాయో ట్రాక్ చేయండి మరియు ఇకపై పని చేయని వాటికి ప్రతిస్పందించండి.
ఆరోగ్య పరీక్ష (ఆరోగ్య పరీక్ష) ట్రాఫిక్ని అంగీకరించడానికి మరియు ప్రాసెస్ చేయడానికి సేవా సందర్భాలు సిద్ధంగా ఉన్నాయో లేదో నిర్ణయించడంలో సహాయపడుతుంది. ఉదాహరణకు, HTTP సేవల విషయంలో, ఆరోగ్య తనిఖీ అనేది ఎండ్ పాయింట్కి GET అభ్యర్థన వలె కనిపిస్తుంది /health. సమాధానం 200 OK ఉదాహరణ ఆరోగ్యంగా ఉందని అర్థం, మరేదైనా - ఇది ట్రాఫిక్ని స్వీకరించడానికి సిద్ధంగా లేదు. సేవా మెష్లు కార్యాచరణను ఏ విధంగా తనిఖీ చేయాలి మరియు ఈ తనిఖీని నిర్వహించే ఫ్రీక్వెన్సీ రెండింటినీ పేర్కొనడానికి మిమ్మల్ని అనుమతిస్తాయి. ఈ సమాచారం ఇతర ప్రయోజనాల కోసం ఉపయోగించబడుతుంది - ఉదాహరణకు, లోడ్ బ్యాలెన్సింగ్ మరియు సర్క్యూట్ బ్రేకింగ్ కోసం.
అందువల్ల, ఆరోగ్య తనిఖీలు ఒక స్వతంత్ర ఉపయోగం కాదు, కానీ సాధారణంగా ఇతర లక్ష్యాలను సాధించడానికి ఉపయోగిస్తారు. అలాగే, ఆరోగ్య తనిఖీల ఫలితాలపై ఆధారపడి, బాహ్య చర్యలు (ఇతర సేవా మెష్ లక్ష్యాలకు సంబంధించి) అవసరం కావచ్చు: ఉదాహరణకు, స్థితి పేజీని నవీకరించడం, GitHubలో సమస్యను సృష్టించడం లేదా JIRA టిక్కెట్ను పూరించడం. మరియు సర్వీస్ మెష్ ఇవన్నీ ఆటోమేట్ చేయడానికి అనుకూలమైన యంత్రాంగాన్ని అందిస్తుంది.
10. లోడ్ షెడ్డింగ్
TL;DR: వినియోగంలో తాత్కాలిక పెరుగుదలకు ప్రతిస్పందనగా ట్రాఫిక్ను దారి మళ్లించండి.
ఒక నిర్దిష్ట సేవ ట్రాఫిక్తో ఓవర్లోడ్ చేయబడితే, మీరు ఈ ట్రాఫిక్లో కొంత భాగాన్ని తాత్కాలికంగా మరొక స్థానానికి మళ్లించవచ్చు (అంటే "డంప్", "ట్రాన్స్ఫర్" (షెడ్) అతను అక్కడ). ఉదాహరణకు, బ్యాకప్ సేవ లేదా డేటా సెంటర్కు లేదా శాశ్వతంగా అంశం. ఫలితంగా, సేవ క్రాష్ అయ్యే బదులు కొన్ని అభ్యర్థనలను ప్రాసెస్ చేయడాన్ని కొనసాగిస్తుంది మరియు అన్నింటినీ పూర్తిగా ప్రాసెస్ చేయడం ఆపివేస్తుంది. సర్క్యూట్ను విచ్ఛిన్నం చేయడం కంటే లోడ్ షెడ్డింగ్ ఉత్తమం, కానీ ఇప్పటికీ దానిని దుర్వినియోగం చేయడం మంచిది కాదు. దిగువ సేవలు విఫలమయ్యేలా చేసే క్యాస్కేడింగ్ వైఫల్యాలను నిరోధించడంలో ఇది సహాయపడుతుంది.
11. ట్రాఫిక్ పారలలైజేషన్/మిర్రరింగ్
TL;DR: ఒకేసారి అనేక ప్రదేశాలకు ఒక అభ్యర్థనను పంపండి.
కొన్నిసార్లు ఒకేసారి అనేక సేవలకు అభ్యర్థనను (లేదా నిర్దిష్ట అభ్యర్థనల ఎంపిక) పంపాల్సిన అవసరం ఉంది. ఉత్పత్తి ట్రాఫిక్లో కొంత భాగాన్ని స్టేజింగ్ సేవకు పంపడం ఒక విలక్షణ ఉదాహరణ. ప్రధాన ఉత్పత్తి వెబ్ సర్వర్ దిగువ సేవకు అభ్యర్థనను పంపుతుంది products.production మరియు అతనికి మాత్రమే. మరియు సర్వీస్ మెష్ ఈ అభ్యర్థనను తెలివిగా కాపీ చేసి, దీనికి పంపుతుంది products.staging, ఇది వెబ్ సర్వర్కు కూడా తెలియదు.
ట్రాఫిక్ పారలలైజేషన్ పైన అమలు చేయగల మరొక సంబంధిత సర్వీస్ మెష్ వినియోగ కేసు . ఇది సేవ యొక్క విభిన్న సంస్కరణలకు ఒకే అభ్యర్థనలను పంపడం మరియు అన్ని సంస్కరణలు ఒకేలా ప్రవర్తిస్తున్నాయో లేదో తనిఖీ చేయడం. నేను ఇంకా ఇంటిగ్రేటెడ్ రిగ్రెషన్ టెస్టింగ్ సిస్టమ్తో సర్వీస్ మెష్ అమలును చూడలేదు , కానీ ఆలోచన కూడా ఆశాజనకంగా ఉంది.
12. ఇన్సులేషన్
TL;DR: మీ సేవా మెష్ను మినీ-నెట్వర్క్లుగా విభజించండి.
ఇలా కూడా అనవచ్చు విభజనఐసోలేషన్ అనేది సేవా మెష్ను ఒకదానికొకటి ఏమీ తెలియని తార్కికంగా విభిన్నమైన విభాగాలుగా విభజించే కళ. ఐసోలేషన్ అనేది వర్చువల్ ప్రైవేట్ నెట్వర్క్లను సృష్టించడం లాంటిది. ప్రాథమిక వ్యత్యాసం ఏమిటంటే, మీరు సర్వీస్ మెష్ యొక్క అన్ని ప్రయోజనాలను (సేవ ఆవిష్కరణ వంటివి) ఇంకా అదనపు భద్రతతో ఆస్వాదించవచ్చు. ఉదాహరణకు, దాడి చేసే వ్యక్తి ఒక సబ్నెట్లో సేవలోకి ప్రవేశించగలిగితే, అతను ఇతర సబ్నెట్లలో ఏ సేవలు రన్ అవుతున్నాయో చూడలేరు లేదా వారి ట్రాఫిక్ను అడ్డగించలేరు.
అదనంగా, ప్రయోజనాలు సంస్థాగతంగా కూడా ఉండవచ్చు. మీరు మీ కంపెనీ నిర్మాణం ఆధారంగా మీ సేవలను సబ్నెట్ చేయాలనుకోవచ్చు మరియు డెవలపర్లు మొత్తం సేవా మెష్ను దృష్టిలో ఉంచుకునే అభిజ్ఞా భారం నుండి ఉపశమనం పొందవచ్చు.
13. అభ్యర్థన రేటు పరిమితి, పునఃప్రయత్నాలు మరియు గడువు ముగిసింది
TL;DR: మీరు ఇకపై మీ కోడ్బేస్లో నైటీ-గ్రిట్టీ రిక్వెస్ట్ మేనేజ్మెంట్ టాస్క్లను చేర్చాల్సిన అవసరం లేదు.
ఈ విషయాలన్నీ ప్రత్యేక వినియోగ సందర్భాలుగా పరిగణించబడతాయి, కానీ ఒక సాధారణ లక్షణం కారణంగా నేను వాటిని కలపాలని నిర్ణయించుకున్నాను: అవి సాధారణంగా అప్లికేషన్ లైబ్రరీలు నిర్వహించే అభ్యర్థన లైఫ్సైకిల్ మేనేజ్మెంట్ టాస్క్లను తీసుకుంటాయి. మీరు రూబీ ఆన్ రైల్స్లో వెబ్ సర్వర్ను అభివృద్ధి చేస్తుంటే (సర్వీస్ మెష్తో అనుసంధానించబడలేదు) దీని ద్వారా బ్యాకెండ్ సేవలకు అభ్యర్థనలు చేస్తుంది , N అభ్యర్థనలు విఫలమైతే ఏమి చేయాలో అప్లికేషన్ నిర్ణయించుకోవాలి. ఈ సేవలు ప్రత్యేక లైబ్రరీని ఉపయోగించి ఈ పారామితులను ప్రాసెస్ చేయగల మరియు హార్డ్కోడ్ చేయగల ఎంత ట్రాఫిక్ను కూడా మీరు కనుగొనవలసి ఉంటుంది. అదనంగా, అప్లికేషన్ ఎప్పుడు విరమించుకోవాలో నిర్ణయించుకోవాలి మరియు అభ్యర్థనను ఖాళీ చేయనివ్వాలి (సమయ గడువు ఆధారంగా). మరియు పైన పేర్కొన్న పారామితులలో దేనినైనా మార్చడానికి, వెబ్ సర్వర్ ఆపివేయబడాలి, మళ్లీ కాన్ఫిగర్ చేయబడాలి మరియు మళ్లీ ప్రారంభించాలి.
ఈ టాస్క్లను సర్వీస్ మెష్కి ఆఫ్లోడ్ చేయడం అంటే సర్వీస్ డెవలపర్లు వాటి గురించి ఆలోచించాల్సిన అవసరం ఉండదు, కానీ వాటిని మరింత గ్లోబల్గా వీక్షించవచ్చు. సంక్లిష్టమైన సేవల శ్రేణిని ఉపయోగించినట్లయితే, A -> B -> C -> D -> E అని చెప్పండి, అభ్యర్థన యొక్క మొత్తం జీవితచక్రాన్ని తప్పనిసరిగా పరిగణనలోకి తీసుకోవాలి. సేవ Cలో గడువును పొడిగించడమే పని అయితే, దీన్ని ఒకేసారి చేయడం లాజికల్గా ఉంటుంది మరియు భాగాలుగా కాదు: సేవా కోడ్ను నవీకరించడం ద్వారా మరియు పుల్ అభ్యర్థన ఆమోదించబడే వరకు వేచి ఉండటం మరియు CI సిస్టమ్ నవీకరించబడిన సేవను అమలు చేసే వరకు వేచి ఉండటం ద్వారా.
14. టెలిమెట్రీ
TL;DR: సేవల నుండి అవసరమైన (మరియు చాలా కాదు) సమాచారాన్ని సేకరించండి.
టెలిమెట్రీ అనేది కొలమానాలు, పంపిణీ చేయబడిన ట్రేసింగ్ మరియు లాగ్లను కలిగి ఉన్న సాధారణ పదం. సర్వీస్ మెష్లు మూడు రకాల డేటాను సేకరించడం మరియు ప్రాసెస్ చేయడం కోసం మెకానిజమ్లను అందిస్తాయి. సాధ్యమయ్యే ఎంపికల సంఖ్య చాలా పెద్దదిగా ఉన్నందున ఇక్కడ విషయాలు కొద్దిగా అస్పష్టంగా ఉంటాయి. కొలమానాలను సేకరించడానికి ఉంది మరియు లాగ్లను సేకరించడానికి ఉపయోగించే ఇతర సాధనాలు , , మరియు ఇతరులు. (ఉదాహరణకు మాతో క్లిక్హౌస్ K8s కోసం - సుమారు. అనువాదం.), పంపిణీ ట్రేసింగ్ కోసం ఉంది మరియు అందువలన న. ప్రతి సర్వీస్ మెష్ కొన్ని సాధనాలకు మద్దతివ్వవచ్చు మరియు ఇతరులకు మద్దతు ఇవ్వదు. ఈ ప్రాజెక్ట్ సాధ్యమేనా అనేది ఆసక్తికరంగా ఉంటుంది కొంత కలయికను అందిస్తాయి.
ఈ సందర్భంలో, సర్వీస్ మెష్ టెక్నాలజీ యొక్క ప్రయోజనం ఏమిటంటే, సైడ్కార్ కంటైనర్లు సూత్రప్రాయంగా, వారి సేవల నుండి పై డేటా మొత్తాన్ని సేకరించగలవు. మరో మాటలో చెప్పాలంటే, మీ వద్ద ఒకే టెలిమెట్రీ సేకరణ వ్యవస్థ ఉంది మరియు సర్వీస్ మెష్ ఈ సమాచారాన్ని వివిధ మార్గాల్లో ప్రాసెస్ చేయగలదు. ఉదాహరణకి:
- CLIలోని నిర్దిష్ట సేవ నుండి టెయిల్ లాగ్లు;
- సర్వీస్ మెష్ డాష్బోర్డ్ నుండి అభ్యర్థనల పరిమాణాన్ని పర్యవేక్షించండి;
- పంపిణీ చేసిన జాడలను సేకరించి, వాటిని జేగర్ వంటి సిస్టమ్కు ఫార్వార్డ్ చేయండి.
శ్రద్ధ, ఆత్మాశ్రయ తీర్పు: సాధారణంగా చెప్పాలంటే, టెలిమెట్రీ అనేది సర్వీస్ మెష్ నుండి బలమైన జోక్యం అవాంఛనీయమైన ప్రాంతం. ప్రాథమిక సమాచారాన్ని సేకరించడం మరియు ప్రయాణంలో అభ్యర్థన విజయ రేటు మరియు జాప్యం వంటి కొన్ని గోల్డెన్ మెట్రిక్లను ట్రాక్ చేయడం మంచిది, అయితే ప్రత్యేకమైన సిస్టమ్లను భర్తీ చేయడానికి ప్రయత్నించే ఫ్రాంకెన్స్టైయిన్ స్టాక్లు ఉద్భవించడాన్ని మనం చూడలేమని ఆశిద్దాం, వాటిలో కొన్ని ఇప్పటికే నిరూపించబడ్డాయి మరియు బాగా అధ్యయనం చేయబడ్డాయి. .
15. ఆడిట్
TL;DR: చరిత్ర యొక్క పాఠాలను మరచిపోయిన వారు వాటిని పునరావృతం చేయడం విచారకరం.
ఆడిటింగ్ అనేది సిస్టమ్లోని ముఖ్యమైన సంఘటనలను పరిశీలించే కళ. సర్వీస్ మెష్ విషయంలో, నిర్దిష్ట సేవల కోసం నిర్దిష్ట ఎండ్పాయింట్లకు ఎవరు అభ్యర్థనలు చేసారు లేదా గత నెలలో కొన్ని భద్రతా సంబంధిత ఈవెంట్లు ఎన్నిసార్లు జరిగాయి అనేదానిని ట్రాక్ చేయడం దీని అర్థం.
ఆడిటింగ్కి టెలిమెట్రీకి చాలా దగ్గర సంబంధం ఉందని స్పష్టమైంది. వ్యత్యాసం ఏమిటంటే, టెలిమెట్రీ సాధారణంగా ఉత్పాదకత మరియు సాంకేతిక సమగ్రత వంటి వాటితో ముడిపడి ఉంటుంది, అయితే ఆడిటింగ్ అనేది చట్టపరమైన మరియు ఇతర సమస్యలతో సంబంధం కలిగి ఉంటుంది, ఇది ఖచ్చితంగా సాంకేతిక పరిధికి మించినది (ఉదాహరణకు, GDPR - డేటా రక్షణపై EU సాధారణ నియంత్రణ).
16. విజువలైజేషన్
TL;DR: లాంగ్ లైవ్ React.js - ఫ్యాన్సీ ఇంటర్ఫేస్ల యొక్క తరగని మూలం.
మంచి పదం ఉండవచ్చు, కానీ అది నాకు తెలియదు. నా ఉద్దేశ్యం సర్వీస్ మెష్ లేదా దానిలోని కొన్ని భాగాల యొక్క గ్రాఫికల్ ప్రాతినిధ్యం. ఈ విజువలైజేషన్లలో సగటు లేటెన్సీలు, సైడ్కార్ కాన్ఫిగరేషన్ సమాచారం, ఆరోగ్య తనిఖీ ఫలితాలు మరియు హెచ్చరికలు వంటి సూచికలు ఉంటాయి.
సేవ-ఆధారిత వాతావరణంలో పనిచేయడం అనేది అతని మెజెస్టి ది మోనోలిత్తో పోలిస్తే చాలా ఎక్కువ కాగ్నిటివ్ లోడ్ను కలిగి ఉంటుంది. అందువల్ల, అభిజ్ఞా ఒత్తిడిని అన్ని ఖర్చులతో తగ్గించాలి. బటన్పై క్లిక్ చేసి, ఆశించిన ఫలితాన్ని పొందగల సామర్థ్యంతో సేవా మెష్ కోసం ఒక సాధారణ గ్రాఫికల్ ఇంటర్ఫేస్ ఈ సాంకేతికత యొక్క ప్రజాదరణ పెరుగుదలకు నిర్ణయాత్మకమైనది.
జాబితాలో చేర్చబడలేదు
నేను మొదట జాబితాలో మరికొన్ని వినియోగ సందర్భాలను చేర్చాలని అనుకున్నాను, కానీ తర్వాత చేయకూడదని నిర్ణయించుకున్నాను. నా నిర్ణయానికి గల కారణాలతో పాటు అవి ఇక్కడ ఉన్నాయి:
- మల్టీ-డేటా సెంటర్. నా అభిప్రాయం ప్రకారం, సర్వీస్ మెష్ల అప్లికేషన్ లేదా సర్వీస్ డిస్కవరీ వంటి కొన్ని ఫంక్షన్ల యొక్క ఇరుకైన మరియు నిర్దిష్ట ప్రాంతంగా ఇది చాలా వినియోగ సందర్భం కాదు.
- ప్రవేశం మరియు ఎగ్రెస్. ఇది సంబంధిత ప్రాంతం, కానీ నేను "తూర్పు-పశ్చిమ ట్రాఫిక్" వినియోగ కేసుకు (బహుశా కృత్రిమంగా) పరిమితం చేసుకున్నాను. ప్రవేశం మరియు ఎగ్రెస్ ప్రత్యేక కథనానికి అర్హమైనవి.
తీర్మానం
ఇప్పటికి ఇంతే! మళ్ళీ, ఈ జాబితా చాలా ఏకపక్షంగా మరియు అసంపూర్ణంగా ఉంటుంది. నేను ఏదైనా కోల్పోయానని లేదా ఏదైనా తప్పు జరిగిందని మీరు భావిస్తే, దయచేసి నన్ను Twitterలో సంప్రదించండి () దయచేసి మర్యాద నియమాలను గౌరవించండి.
అనువాదకుని నుండి PS
వ్యాసం యొక్క టైటిల్ ఇలస్ట్రేషన్ "" అనే వ్యాసంలోని చిత్రం ఆధారంగా రూపొందించబడింది."(గ్రెగొరీ మాకిన్నన్ ద్వారా). అప్లికేషన్ల నుండి కొంత ఫంక్షనాలిటీ (ఆకుపచ్చ రంగులో) వాటి మధ్య ఇంటర్కనెక్షన్లను అందించే సర్వీస్ మెష్కి ఎలా తరలించబడిందో ఇది చూపిస్తుంది (నీలం రంగులో).
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com
