గమనిక. అనువాదం.: సర్వీస్ మెష్ అనేది రష్యన్‌లోకి ఇంకా స్థిరమైన అనువాదం లేని దృగ్విషయం (2 సంవత్సరాల క్రితం మేము “సేవల కోసం మెష్” ఎంపికను అందించాము మరియు కొద్దిసేపటి తరువాత, కొంతమంది సహోద్యోగులు “సర్వీస్ జల్లెడ” కలయికను చురుకుగా ప్రచారం చేయడం ప్రారంభించారు) . ఈ సాంకేతికత గురించి నిరంతర చర్చ మార్కెటింగ్ మరియు సాంకేతిక భాగాలు చాలా దగ్గరగా ముడిపడి ఉన్న పరిస్థితికి దారితీసింది. అసలు పదం యొక్క రచయితలలో ఒకరి నుండి వచ్చిన ఈ అద్భుతమైన మెటీరియల్ ఇంజనీర్లకు మాత్రమే కాకుండా స్పష్టతను తీసుకురావడానికి ఉద్దేశించబడింది.
నుండి కామిక్
పరిచయం
మీరు బ్యాకెండ్ సిస్టమ్స్‌లో ఎక్కడైనా పనిచేస్తున్న సాఫ్ట్‌వేర్ ఇంజనీర్ అయితే, "సర్వీస్ మెష్" అనే పదం గత కొన్ని సంవత్సరాలుగా మీ మనస్సులో ఇప్పటికే స్థిరపడిపోయింది. ఒక విచిత్రమైన యాదృచ్చికానికి ధన్యవాదాలు, ఈ పదబంధం పరిశ్రమను మరింతగా ఆక్రమిస్తోంది మరియు హైప్ మరియు సంబంధిత ప్రచార ఆఫర్‌లు స్నోబాల్ లాగా పెరుగుతూ, కొండపైకి ఎగురుతూ మరియు నెమ్మదించే సంకేతాలను చూపడం లేదు.
సేవా మెష్ క్లౌడ్ స్థానిక పర్యావరణ వ్యవస్థ యొక్క మురికి, మొండి నీటిలో పుట్టింది. దురదృష్టవశాత్తూ, దాని చుట్టూ ఉన్న చాలా వివాదాలు "తక్కువ కేలరీల కబుర్లు" నుండి-సాంకేతిక పదాన్ని ఉపయోగించడం-కఠినమైన బుల్‌షిట్ వరకు ఉన్నాయని దీని అర్థం. కానీ మీరు మొత్తం శబ్దాన్ని ఫిల్టర్ చేస్తే, సేవా మెష్ చాలా నిజమైన, ఖచ్చితమైన మరియు ముఖ్యమైన పనితీరును కలిగి ఉందని మీరు కనుగొనవచ్చు.
ఈ పోస్ట్‌లో, నేను అలా చేయడానికి ప్రయత్నిస్తాను: సేవా మెష్‌కి నిజాయితీ, లోతైన, ఇంజనీర్-ఆధారిత మార్గదర్శిని అందించండి. నేను ప్రశ్న కంటే ఎక్కువ సమాధానం ఇవ్వబోతున్నాను: "అదేంటి?", - ఐన కూడా "ఎందుకు?"మరియు "ఇప్పుడు ఎందుకు?". చివరగా, ఈ ప్రత్యేకమైన సాంకేతికత ఇంత క్రేజీ హైప్‌కు ఎందుకు కారణమైందో (నా అభిప్రాయం ప్రకారం) వివరించడానికి ప్రయత్నిస్తాను, ఇది ఒక ఆసక్తికరమైన కథ.
నేను ఎవరు?
అందరికి వందనాలు! నా పేరు . నేను సృష్టికర్తలలో ఒకడిని - మొట్టమొదటి సర్వీస్ మెష్ ప్రాజెక్ట్ మరియు పదం యొక్క రూపానికి కారణమైన ప్రాజెక్ట్ సేవ మెష్ అలాగే (క్షమించండి అబ్బాయిలు!). (గమనిక అనువాదం.: మార్గం ద్వారా, ఈ పదం కనిపించిన ప్రారంభంలో, 2,5 సంవత్సరాల క్రితం, మేము ఇప్పటికే అదే రచయిత యొక్క ప్రారంభ పదార్థాన్ని అనువదించాము "".) నేను కూడా నడిపిస్తాను లింకర్డ్ మరియు వంటి కూల్ సర్వీస్ మెష్ విషయాలను రూపొందించే స్టార్టప్ .
ఈ సమస్యపై నాకు చాలా పక్షపాత మరియు ఆత్మాశ్రయ అభిప్రాయం ఉందని మీరు బహుశా ఊహించవచ్చు. అయినప్పటికీ, నేను పక్షపాతాన్ని కనిష్టంగా ఉంచడానికి ప్రయత్నిస్తాను (ఒక విభాగం మినహా: "సర్వీస్ మెష్ గురించి ఎందుకు చాలా చర్చలు?", - ఇందులో నేను నా ముందస్తు ఆలోచనలను పంచుకుంటాను). ఈ గైడ్‌ని వీలైనంత లక్ష్యం చేయడానికి నేను నా వంతు కృషి చేస్తాను. నిర్దిష్ట ఉదాహరణలలో, ఇతర రకాల సర్వీస్ మెష్‌ల అమలులో నాకు తెలిసిన తేడాలను (ఏదైనా ఉంటే) ఎత్తి చూపుతూ, నేను ప్రధానంగా Linkerd అనుభవంపై ఆధారపడతాను.
సరే, విందులకు వెళ్లే సమయం వచ్చింది.
సర్వీస్ మెష్ అంటే ఏమిటి?
అన్ని హైప్ ఉన్నప్పటికీ, సేవా మెష్ నిర్మాణాత్మకంగా చాలా సులభం. ఇది కేవలం "పక్కన" సేవలు ఉన్న యూజర్‌స్పేస్ ప్రాక్సీల సమూహం మాత్రమే (మేము "సమీపంలో" గురించి కొంచెం తరువాత మాట్లాడుతాము), మరియు నియంత్రణ ప్రక్రియల సమితి. ప్రాక్సీలను సమిష్టిగా పిలుస్తారు డేటా విమానం, మరియు నియంత్రణ ప్రక్రియలు అంటారు నియంత్రణ విమానం. డేటా ప్లేన్ సేవల మధ్య కాల్‌లను అడ్డుకుంటుంది మరియు వాటితో "వేరేదైనా" చేస్తుంది; నియంత్రణ విమానం, వరుసగా, ప్రాక్సీ యొక్క ప్రవర్తనను సమన్వయం చేస్తుంది మరియు మీ కోసం ప్రాప్యతను అందిస్తుంది, అనగా. ఆపరేటర్, APIకి, నెట్‌వర్క్‌ను మార్చడానికి మరియు మొత్తంగా కొలవడానికి అనుమతిస్తుంది.
ఈ ప్రాక్సీ ఏమిటి? ఇది "లేయర్ 7-అవేర్" వర్గం యొక్క TCP ప్రాక్సీ (అనగా OSI మోడల్ యొక్క 7వ పొరను "ఖాతాలోకి తీసుకోవడం") HAProxy మరియు NGINX వంటివి. మీరు మీ ఇష్టానికి ప్రాక్సీని ఎంచుకోవచ్చు; లింకర్డ్ రస్ట్ ప్రాక్సీని ఉపయోగిస్తుంది, ఇది క్లిష్టంగా లేదు . మేము దీన్ని ప్రత్యేకంగా సర్వీస్ మెష్ కోసం కంపైల్ చేసాము. ఇతర మెష్‌లు ఇతర ప్రాక్సీలను ఇష్టపడతారు (దూత అనేది ఒక సాధారణ ఎంపిక). అయితే, ప్రాక్సీని ఎంచుకోవడం కేవలం అమలుకు సంబంధించిన విషయం.
ఈ ప్రాక్సీ సర్వర్లు ఏమి చేస్తాయి? సహజంగానే, వారు సేవలకు మరియు వాటి నుండి కాల్‌లను ప్రాక్సీ చేస్తారు (కచ్చితంగా చెప్పాలంటే, వారు ప్రాక్సీలుగా మరియు రివర్స్ ప్రాక్సీలుగా వ్యవహరిస్తారు, ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ కాల్‌లను నిర్వహిస్తారు). మరియు వారు కాల్‌లపై దృష్టి సారించే ఫీచర్ సెట్‌ను అమలు చేస్తారు మధ్య సేవలు. సేవల మధ్య ట్రాఫిక్‌పై ఈ దృష్టి అనేది API గేట్‌వేలు లేదా ఇన్‌గ్రెస్ ప్రాక్సీల నుండి సర్వీస్ మెష్ ప్రాక్సీని వేరు చేస్తుంది (రెండోది బయటి ప్రపంచం నుండి క్లస్టర్‌లోకి వచ్చే కాల్‌లపై దృష్టి పెడుతుంది). (గమనిక. అనువాదం.: ఇప్పటికే పేర్కొన్న కుబెర్నెట్స్ ఇన్‌గ్రెస్ కంట్రోలర్‌ల పోలిక కోసం, వీటిలో చాలా వరకు ఇప్పటికే పేర్కొన్న ఎన్వోయ్‌ని ఉపయోగిస్తున్నారు, చూడండి .)
కాబట్టి, మేము డేటా ప్లేన్‌ను కనుగొన్నాము. కంట్రోల్ ప్లేన్ సరళమైనది: ఇది సర్వీస్ డిస్కవరీ, TLS సర్టిఫికేట్ జారీ, మెట్రిక్స్ అగ్రిగేషన్ మొదలైన వాటితో సహా డేటా ప్లేన్ సమన్వయంతో పని చేయడానికి అవసరమైన అన్ని మెకానిక్‌లను అందించే భాగాల సమితి. దాని ప్రవర్తన; క్రమంగా, నియంత్రణ విమానం APIని అందిస్తుంది, ఇది మొత్తం డేటా ప్లేన్ యొక్క ప్రవర్తనను మార్చడానికి మరియు ట్రాక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
లింక్‌ర్డ్‌లోని కంట్రోల్ ప్లేన్ మరియు డేటా ప్లేన్ యొక్క రేఖాచిత్రం క్రింద ఉంది. మీరు చూడగలిగినట్లుగా, కంట్రోల్ ప్లేన్ ప్రాక్సీ సర్వర్‌ల నుండి కొలమానాలను సేకరించే ప్రోమేతియస్ ఉదాహరణతో సహా అనేక విభిన్న భాగాలను కలిగి ఉంటుంది, అలాగే ఇతర భాగాలు destination (సేవ ఆవిష్కరణ), identity (సర్టిఫికేట్ అధికారం, CA) మరియు public-api (వెబ్ మరియు CLI కోసం ముగింపు పాయింట్లు). దీనికి విరుద్ధంగా, డేటా ప్లేన్ అనువర్తన ఉదాహరణ పక్కన ఉన్న సాధారణ లింకర్డ్-ప్రాక్సీ. ఇది కేవలం లాజిక్ రేఖాచిత్రం; వాస్తవ ప్రపంచ విస్తరణలో, మీరు ప్రతి కంట్రోల్ ప్లేన్ కాంపోనెంట్‌కి మూడు ప్రతిరూపాలు మరియు డేటా ప్లేన్‌లో వందల లేదా వేల ప్రాక్సీలను కలిగి ఉండవచ్చు.
(ఈ రేఖాచిత్రంలోని నీలి పెట్టెలు కుబెర్నెటెస్ పాడ్‌ల సరిహద్దులను సూచిస్తాయి. మీరు లింకర్డ్-ప్రాక్సీతో ఉన్న కంటైనర్‌లు అప్లికేషన్ కంటైనర్‌ల వలె అదే పాడ్‌లో ఉన్నట్లు చూడవచ్చు. ఈ పథకం ఇలా పిలువబడుతుంది సైడ్‌కార్ కంటైనర్.)
సర్వీస్ మెష్ ఆర్కిటెక్చర్ అనేక ముఖ్యమైన చిక్కులను కలిగి ఉంది. ముందుగా, సేవల మధ్య కాల్‌లను అడ్డగించడం ప్రాక్సీ యొక్క పని కాబట్టి, మీ అప్లికేషన్ సేవల సమితి కోసం రూపొందించబడినట్లయితే మాత్రమే సర్వీస్ మెష్ అర్ధవంతంగా ఉంటుంది. మెష్ చెయ్యవచ్చు మోనోలిత్‌లతో ఉపయోగించండి, కానీ ఇది ఒకే ప్రాక్సీ కొరకు స్పష్టంగా అనవసరం మరియు దాని కార్యాచరణ డిమాండ్‌లో ఉండే అవకాశం లేదు.
మరొక ముఖ్యమైన పరిణామం ఏమిటంటే సర్వీస్ మెష్ అవసరం భారీ ప్రాక్సీల సంఖ్య. వాస్తవానికి, లింకర్డ్ ప్రతి సేవ యొక్క ప్రతి ఉదాహరణకి లింకర్డ్-ప్రాక్సీని కలుపుతుంది (ఇతర అమలులు ప్రతి హోస్ట్/హోస్ట్/VMకి ప్రాక్సీని జోడిస్తాయి. ఏమైనప్పటికీ అది చాలా ఎక్కువ). ప్రాక్సీ యొక్క అటువంటి క్రియాశీల ఉపయోగం అనేక అదనపు సమస్యలను కలిగి ఉంటుంది:
- డేటా ప్లేన్‌లో ప్రాక్సీలు ఉండాలి వేగంగా, ఎందుకంటే ప్రతి కాల్‌కు ప్రాక్సీకి రెండు కాల్‌లు ఉంటాయి: ఒకటి క్లయింట్ వైపు, ఒకటి సర్వర్ వైపు.
- అలాగే, ప్రాక్సీలు తప్పనిసరిగా ఉండాలి చిన్నది и తేలికైన. ప్రతి ఒక్కటి మెమరీ మరియు CPU వనరులను వినియోగిస్తుంది మరియు ఈ వినియోగం అప్లికేషన్‌తో సరళంగా పెరుగుతుంది.
- పెద్ద సంఖ్యలో ప్రాక్సీలను అమలు చేయడానికి మరియు అప్‌డేట్ చేయడానికి మీకు మెకానిజం అవసరం. దీన్ని మాన్యువల్‌గా చేయడం ఎంపిక కాదు.
సాధారణంగా, సర్వీస్ మెష్ ఇలా కనిపిస్తుంది (కనీసం పక్షి దృష్టి నుండి): మీరు అంతర్గత, ఇంటర్-సర్వీస్ ట్రాఫిక్‌తో "ఏదైనా చేసే" యూజర్‌స్పేస్ ప్రాక్సీల సమూహాన్ని అమలు చేస్తారు మరియు వాటిని పర్యవేక్షించడానికి మరియు నిర్వహించడానికి కంట్రోల్ ప్లేన్‌ని ఉపయోగించండి.
"ఎందుకు?" అనే ప్రశ్నకు ఇది సమయం.
సర్వీస్ మెష్ దేనికి?
సేవా మెష్ ఆలోచనను మొదట ఎదుర్కొన్న వారికి, కొంచెం విస్మయం కలిగి ఉండటం క్షమించదగినది. సర్వీస్ మెష్ డిజైన్ అంటే ఇది అప్లికేషన్ జాప్యాన్ని పెంచడమే కాకుండా, అది కూడా చేస్తుంది వినియోగించును వనరులు మరియు జోడిస్తుంది మౌలిక సదుపాయాలలో కొత్త యంత్రాంగాల సమూహం. ముందుగా మీరు సర్వీస్ మెష్‌ని సెటప్ చేయండి, ఆపై మీరు అకస్మాత్తుగా వందల (వేలాది కాకపోయినా) ప్రాక్సీలను అందించాల్సిన అవసరం ఏర్పడింది. దీని కోసం ఎవరు స్వచ్ఛందంగా ముందుకు వస్తారు అనేది ప్రశ్న.
ఈ ప్రశ్నకు సమాధానం రెండు భాగాలను కలిగి ఉంటుంది. మొదట, పర్యావరణ వ్యవస్థలో జరుగుతున్న కొన్ని మార్పుల కారణంగా ఈ ప్రాక్సీలను అమలు చేయడానికి సంబంధించిన లావాదేవీ ఖర్చులను గణనీయంగా తగ్గించవచ్చు (దీనిపై మరింత తర్వాత).
రెండవది, అటువంటి పరికరం వాస్తవానికి సిస్టమ్‌లో అదనపు లాజిక్‌ను పరిచయం చేయడానికి గొప్ప మార్గం. మరియు సేవా మెష్‌ని ఉపయోగించి చాలా కొత్త ఫీచర్లను జోడించడం వల్ల మాత్రమే కాకుండా, పర్యావరణ వ్యవస్థకు అంతరాయం కలగకుండా చేయవచ్చు. వాస్తవానికి, మొత్తం సర్వీస్ మెష్ మోడల్ ఈ ప్రతిపాదనపై ఆధారపడి ఉంటుంది: మల్టీసర్వీస్ సిస్టమ్‌లో, ఏది ఏమైనా చేయండి వ్యక్తిగత సేవలు, ట్రాఫిక్ వాటి మధ్య కార్యాచరణను జోడించడానికి అనువైన పాయింట్.
ఉదాహరణకు, లింకర్డ్‌లో (చాలా మెష్‌లలో వలె) కార్యాచరణ ప్రాథమికంగా HTTP/2 మరియు gRPC*తో సహా HTTP కాల్‌లపై కేంద్రీకరించబడుతుంది. కార్యాచరణ చాలా గొప్పది - దీనిని మూడు తరగతులుగా విభజించవచ్చు:
- సంబంధించిన విధులు విశ్వసనీయత. మళ్లీ ప్రయత్నించండి అభ్యర్థనలు, గడువు ముగిసింది, కానరీ విధానం (ట్రాఫిక్ స్ప్లిట్/రీడైరెక్ట్) మొదలైనవి.
- సంబంధించిన విధులు పర్యవేక్షణ. ప్రతి సేవ లేదా వ్యక్తిగత గమ్యస్థానాలకు విజయ రేట్లు, జాప్యాలు మరియు అభ్యర్థన వాల్యూమ్‌ల సమగ్రత; సేవల యొక్క టోపోలాజికల్ మ్యాప్‌లను రూపొందించడం మొదలైనవి.
- సంబంధించిన విధులు భద్రత. మ్యూచువల్ TLS, యాక్సెస్ కంట్రోల్ మొదలైనవి.
* లింకర్డ్ దృక్కోణం నుండి, gRPC ఆచరణాత్మకంగా HTTP/2 నుండి భిన్నంగా లేదు: ఇది కేవలం పేలోడ్‌లో ప్రోటోబఫ్‌ని ఉపయోగిస్తుంది. డెవలపర్ దృక్కోణం నుండి, ఈ రెండు విషయాలు భిన్నంగా ఉంటాయి.
వీటిలో చాలా యంత్రాంగాలు అభ్యర్థన స్థాయిలో పనిచేస్తాయి (అందుకే "L7 ప్రాక్సీ"). ఉదాహరణకు, సర్వీస్ Foo సర్వీస్ బార్‌కి HTTP కాల్ చేస్తే, ఫూ వైపు ఉన్న లింకర్డ్-ప్రాక్సీ తెలివిగా లోడ్-బ్యాలెన్స్ చేయగలదు మరియు గమనించిన జాప్యం ఆధారంగా ఫూ నుండి బార్‌కు కాల్‌లను రూట్ చేస్తుంది; అవసరమైతే అది అభ్యర్థనను పునరావృతం చేయగలదు (మరియు అది బలహీనమైనట్లయితే); అతను ప్రతిస్పందన కోడ్ మరియు గడువు ముగియడం మొదలైనవాటిని రికార్డ్ చేయగలడు. అదేవిధంగా, బార్ వైపు ఉన్న లింకర్డ్-ప్రాక్సీ అభ్యర్థన అనుమతించబడకపోతే లేదా అభ్యర్థన పరిమితిని మించిపోయినట్లయితే దానిని తిరస్కరించవచ్చు; దాని భాగాన ఆలస్యాన్ని పరిష్కరించవచ్చు, మొదలైనవి.
ప్రాక్సీలు కనెక్షన్ స్థాయిలో కూడా "ఏదైనా చేయగలవు". ఉదాహరణకు, Foo వైపు ఉన్న లింకర్డ్-ప్రాక్సీ TLS కనెక్షన్‌ని ప్రారంభించగలదు మరియు బార్ వైపు ఉన్న లింకర్డ్-ప్రాక్సీ దానిని ముగించగలదు మరియు రెండు వైపులా ఒకరి TLS ప్రమాణపత్రాలను ధృవీకరించవచ్చు*. ఇది సేవల మధ్య ఎన్‌క్రిప్షన్‌ను మాత్రమే కాకుండా, సేవలను గుర్తించడానికి క్రిప్టోగ్రాఫికల్‌గా సురక్షితమైన మార్గాన్ని కూడా అందిస్తుంది: ఫూ మరియు బార్ వారు చెప్పినట్లు వారు "రుజువు" చేయగలరు.
* "స్నేహితుని స్నేహితుడు" అంటే క్లయింట్ యొక్క సర్టిఫికేట్ కూడా ధృవీకరించబడింది (మ్యూచువల్ TLS). "క్లాసిక్" TLSలో, ఉదాహరణకు, బ్రౌజర్ మరియు సర్వర్ మధ్య, కేవలం ఒక వైపు (సర్వర్) సర్టిఫికేట్ సాధారణంగా ధృవీకరించబడుతుంది.
అవి అభ్యర్థన లేదా కనెక్షన్ స్థాయిలో పనిచేసినా, అన్ని సర్వీస్ మెష్ ఫీచర్లు ఉన్నాయని నొక్కి చెప్పడం ముఖ్యం కార్యాచరణ పాత్ర. JSON ఫ్రాగ్‌మెంట్‌కి ఫీల్డ్‌లను జోడించడం లేదా ప్రోటోబఫ్‌కు మార్పులు చేయడం వంటి పేలోడ్ యొక్క అర్థశాస్త్రాన్ని లింక్‌ర్డ్ మార్చలేకపోయింది. మేము ESB మరియు మిడిల్‌వేర్ గురించి మాట్లాడేటప్పుడు ఈ ముఖ్యమైన ఫీచర్ గురించి తరువాత మాట్లాడుతాము.
ఇది సర్వీస్ మెష్ అందించే ఫీచర్ల సెట్. ప్రశ్న తలెత్తుతుంది: వాటిని నేరుగా అప్లికేషన్‌లో ఎందుకు అమలు చేయకూడదు? మరియు ప్రాక్సీతో ఎందుకు గందరగోళం చెందాలి?
సర్వీస్ మెష్ ఎందుకు మంచి ఆలోచన
సర్వీస్ మెష్ యొక్క సామర్థ్యాలు ఆకర్షణీయంగా ఉన్నప్పటికీ, దాని ప్రధాన విలువ నిజంగా ఫీచర్లలో లేదు. చివరికి మేము చెయ్యవచ్చు వాటిని నేరుగా అప్లికేషన్‌లో అమలు చేయండి (ఇది సేవా మెష్ యొక్క మూలం అని మేము తర్వాత చూస్తాము). ఒక వాక్యంలో చెప్పాలంటే, సర్వీస్ మెష్ యొక్క విలువ: ఇది ఆధునిక సర్వర్ సాఫ్ట్‌వేర్‌ను స్థిరమైన, స్టాక్-వైడ్, అప్లికేషన్-కోడ్-అజ్ఞేయ పద్ధతిలో అమలు చేయడానికి కీలకమైన కార్యాచరణను అందిస్తుంది..
ఈ ప్రతిపాదనను విశ్లేషిద్దాం.
«ఆధునిక సర్వర్ సాఫ్ట్‌వేర్‌ను అమలు చేయడంలో ముఖ్యమైన విధులు". మీరు పబ్లిక్ ఇంటర్నెట్‌కు కనెక్ట్ చేయబడిన లావాదేవీల సర్వర్ అప్లికేషన్‌ను రూపొందిస్తున్నట్లయితే, అది బయటి ప్రపంచం నుండి వచ్చే అభ్యర్థనలను అంగీకరించి, తక్కువ సమయంలో వాటికి ప్రతిస్పందిస్తుంటే - ఉదాహరణకు, వెబ్ అప్లికేషన్, API సర్వర్ మరియు ఇతర ఆధునిక అప్లికేషన్‌లలో ఎక్కువ భాగం - మరియు మీరు దీన్ని ఒకదానితో ఒకటి సమకాలీకరించే సేవల సమితిగా అమలు చేస్తే, మరియు మీరు ఈ సాఫ్ట్‌వేర్‌ను నిరంతరం అప్‌గ్రేడ్ చేస్తుంటే, కొత్త ఫీచర్లను జోడిస్తే మరియు సవరణ ప్రక్రియలో మీరు ఈ సిస్టమ్‌ను పని స్థితిలో ఉంచవలసి వస్తే - ఈ సందర్భంలో, అభినందనలు, మీరు ఆధునిక సర్వర్ సాఫ్ట్‌వేర్‌ని సృష్టిస్తున్నారు. మరియు పైన పేర్కొన్న అన్ని గొప్ప ఫీచర్లు నిజానికి మీకు క్లిష్టమైనవిగా మారతాయి. అప్లికేషన్ తప్పనిసరిగా విశ్వసనీయంగా, సురక్షితంగా ఉండాలి మరియు అది ఏమి చేస్తుందో మీరు తప్పక చూడగలరు. ఈ ప్రశ్నలే సర్వీస్ మెష్ పరిష్కరించడానికి సహాయపడతాయి.
(సరే, సర్వర్ సాఫ్ట్‌వేర్‌ను రూపొందించడానికి ఈ విధానం ఆధునిక మార్గమని నా నమ్మకం మునుపటి పేరాలోకి ప్రవేశించింది. ఇతరులు ఏకశిలాలు, "రియాక్టివ్ మైక్రోసర్వీసెస్" మరియు పైన పేర్కొన్న నిర్వచనం కిందకు రాని ఇతర విషయాలను అభివృద్ధి చేయడానికి ఇష్టపడతారు. ఈ వ్యక్తులు బహుశా కలిగి ఉండవచ్చు నా నుండి భిన్నమైన అభిప్రాయం, మరియు అవి "తప్పు" అని నేను నమ్ముతున్నాను - ఏదైనా సందర్భంలో, సర్వీస్ మెష్ వారికి చాలా ఉపయోగకరంగా ఉండదు).
«మొత్తం స్టాక్ కోసం ఏకరీతి". సర్వీస్ మెష్ అందించిన ఫీచర్లు కేవలం క్లిష్టమైనవి కావు. వారు ఏ భాషలో వ్రాసారు, వారు ఏ ఫ్రేమ్‌వర్క్‌ని ఉపయోగిస్తున్నారు, ఎవరు వ్రాసారు, అవి ఎలా ఉపయోగించబడ్డాయి మరియు వాటి అభివృద్ధి మరియు ఉపయోగం యొక్క అన్ని ఇతర సూక్ష్మబేధాలతో సంబంధం లేకుండా అప్లికేషన్‌లోని అన్ని సేవలకు వర్తిస్తాయి.
«అప్లికేషన్ కోడ్ స్వతంత్రం". చివరగా, సర్వీస్ మెష్ మొత్తం స్టాక్‌లో స్థిరమైన కార్యాచరణను అందించడమే కాకుండా, అప్లికేషన్‌ను సవరించాల్సిన అవసరం లేని విధంగా చేస్తుంది. కాన్ఫిగర్ చేయడం, అప్‌డేట్ చేయడం, ఆపరేటింగ్ చేయడం, నిర్వహించడం మొదలైన పనులతో సహా సర్వీస్ మెష్ యొక్క కార్యాచరణ యొక్క ప్రాథమిక ఆధారం పూర్తిగా ప్లాట్‌ఫారమ్ స్థాయిలో ఉంటుంది మరియు అప్లికేషన్ నుండి స్వతంత్రంగా ఉంటుంది. సర్వీస్ మెష్‌ను ప్రభావితం చేయకుండా అప్లికేషన్ మార్చవచ్చు. ప్రతిగా, సేవ మెష్ ఎటువంటి అప్లికేషన్ జోక్యం లేకుండా మార్చవచ్చు.
సంక్షిప్తంగా, సర్వీస్ మెష్ కీలకమైన కార్యాచరణను అందించడమే కాకుండా, గ్లోబల్, యూనిఫాం మరియు అప్లికేషన్-స్వతంత్ర పద్ధతిలో అందిస్తుంది. కాబట్టి, సేవా మెష్ యొక్క కార్యాచరణను సేవ యొక్క కోడ్‌లో అమలు చేయగలిగినప్పటికీ (ఉదాహరణకు, ప్రతి సేవతో కూడిన లైబ్రరీగా), ఈ విధానం ఒక విషయంలో చాలా విలువైన ఏకరూపత మరియు స్వతంత్రతను అందించదు. సేవ మెష్.
మరియు మీరు చేయాల్సిందల్లా ప్రాక్సీల సమూహాన్ని జోడించడమే! నేను వాగ్దానం చేస్తున్నాను, అతి త్వరలో మేము ఈ ప్రాక్సీలను జోడించడానికి సంబంధించిన కార్యాచరణ ఖర్చులను పరిశీలిస్తాము. అయితే మొదట, స్వాతంత్ర్యం యొక్క ఈ ఆలోచనను వివిధ దృక్కోణం నుండి ఆపి చూద్దాం ప్రజలు.
సర్వీస్ మెష్ ఎవరికి సహాయం చేస్తుంది?
సాంకేతికత పర్యావరణ వ్యవస్థలో ఒక ముఖ్యమైన భాగం కావాలంటే, అది ఎంత అసౌకర్యంగా ఉన్నా, దానిని ప్రజలు అంగీకరించాలి. కాబట్టి సేవా మెష్‌పై ఎవరు ఆసక్తి కలిగి ఉన్నారు? దీని ఉపయోగం వల్ల ఎవరికి లాభం?
మీరు ఆధునిక సర్వర్ సాఫ్ట్‌వేర్‌ను అభివృద్ధి చేస్తే, మీరు మీ బృందాన్ని ఒక సమూహంగా ఊహించవచ్చు సేవ యజమానులుఎవరు కలిసి వ్యాపార తర్కాన్ని అభివృద్ధి చేస్తారు మరియు అమలు చేస్తారు, మరియు ప్లాట్‌ఫారమ్ యజమానులుఈ సేవలు అమలు చేసే అంతర్గత ప్లాట్‌ఫారమ్ అభివృద్ధిలో పాల్గొంటుంది. చిన్న సంస్థలలో, ఇవి ఒకే వ్యక్తులు కావచ్చు, కానీ కంపెనీ పెరిగేకొద్దీ, ఈ పాత్రలు మరింత స్పష్టంగా కనిపిస్తాయి మరియు ఉప పాత్రలుగా కూడా విభజించబడతాయి ... (డెవొప్స్ యొక్క మారుతున్న స్వభావం గురించి ఇక్కడ చాలా చెప్పాలి, మైక్రోసర్వీసెస్ యొక్క సంస్థాగత ప్రభావం మొదలైనవి).
ఈ దృక్కోణం నుండి, సేవా మెష్ యొక్క స్పష్టమైన లబ్ధిదారులు ప్లాట్‌ఫారమ్ యొక్క యజమానులు. అన్నింటికంటే, ప్లాట్‌ఫారమ్ బృందం యొక్క అంతిమ లక్ష్యం సేవా యజమానులు వ్యాపార తర్కాన్ని అమలు చేయగల అంతర్గత ప్లాట్‌ఫారమ్‌ను సృష్టించడం మరియు దాని ఆపరేషన్ యొక్క భయంకరమైన వివరాల నుండి వారి గరిష్ట స్వాతంత్ర్యానికి హామీ ఇచ్చే విధంగా దీన్ని చేయడం. సర్వీస్ మెష్ ఈ లక్ష్యాన్ని సాధించడానికి కీలకమైన సామర్థ్యాలను అందించడమే కాకుండా, సేవా యజమానులపై ఆధారపడకుండా ఉండే విధంగా చేస్తుంది.
సేవా యజమానులు కూడా మరింత పరోక్ష మార్గంలో ప్రయోజనం పొందుతారు. సేవా యజమాని యొక్క లక్ష్యం వ్యాపార ప్రక్రియ యొక్క తర్కాన్ని అమలు చేయడంలో సాధ్యమైనంత ఉత్పాదకతను కలిగి ఉంటుంది మరియు అతను కార్యాచరణ సమస్యల గురించి ఎంత తక్కువ ఆందోళన చెందితే అంత మంచిది. పాలసీలు లేదా TLSని అమలు చేయడానికి, చెప్పడానికి, మళ్లీ ప్రయత్నించడానికి బదులుగా, వారు పూర్తిగా వ్యాపారంపై దృష్టి పెట్టవచ్చు మరియు మిగిలిన వాటిని ప్లాట్‌ఫారమ్ చూసుకుంటుంది. వారికి, ఇది పెద్ద ప్రయోజనం.
ప్లాట్‌ఫారమ్‌లు మరియు సేవల యజమానుల మధ్య అటువంటి విభజన యొక్క సంస్థాగత విలువను అతిగా అంచనా వేయలేము. ఆమె సహకరిస్తుంది అని నేను అనుకుంటున్నాను ప్రధాన సేవా మెష్ విలువకు సహకారం.
వారు సర్వీస్ మెష్‌ని ఎందుకు ఎంచుకున్నారు అని ఒక ప్రారంభ లింకర్డ్ అభిమాని మాకు చెప్పినప్పుడు మేము ఈ పాఠాన్ని నేర్చుకున్నాము: ఎందుకంటే ఇది వారిని "కనీసం మాట్లాడటం కొనసాగించడానికి" అనుమతించింది. ఇక్కడ కొన్ని వివరాలు ఉన్నాయి: ఒక పెద్ద కంపెనీకి చెందిన అబ్బాయిలు వారి ప్లాట్‌ఫారమ్‌ను కుబెర్నెటెస్‌కి మార్చారు. అప్లికేషన్ సున్నితమైన సమాచారంతో పనిచేసినందున, వారు క్లస్టర్‌లలోని అన్ని కమ్యూనికేషన్‌లను ఎన్‌క్రిప్ట్ చేయాలనుకున్నారు. అయితే, వందలాది సేవలు మరియు వందలాది అభివృద్ధి బృందాలు ఉండటంతో పరిస్థితి క్లిష్టంగా మారింది. ప్రతి ఒక్కరినీ సంప్రదించడం మరియు వారి ప్లాన్‌లలో TLS కోసం మద్దతును చేర్చమని వారిని ఒప్పించే అవకాశం వారికి ఏమాత్రం నచ్చలేదు. లింకర్డ్‌ని ఇన్‌స్టాల్ చేయడం ద్వారా, వారు వలస వచ్చారు బాధ్యత డెవలపర్‌ల నుండి (ఎవరి కోణం నుండి ఇది అనవసరమైన ఇబ్బంది) ప్లాట్‌ఫారమ్‌ల వరకు, వీరికి ఇది ఉన్నత-స్థాయి ప్రాధాన్యత. మరో మాటలో చెప్పాలంటే, లింకర్డ్ వారికి సంస్థాగత సమస్య వలె చాలా సాంకేతిక సమస్యను పరిష్కరించలేదు.
సంక్షిప్తంగా, సేవ మెష్, బదులుగా, సాంకేతిక పరిష్కారం కాదు, కానీ సామాజిక-సాంకేతిక సమస్యలు. (ధన్యవాదాలు ఈ పదాన్ని పరిచయం చేసినందుకు.
సర్వీస్ మెష్ నా సమస్యలన్నింటినీ పరిష్కరిస్తుందా?
అవును. నా ఉద్దేశ్యం, లేదు!
విశ్వసనీయత, భద్రత మరియు పరిశీలనాత్మకత - పైన పేర్కొన్న మూడు రకాల ఫీచర్లను చూస్తే, సర్వీస్ మెష్ ఈ సమస్యలలో దేనికీ పూర్తి పరిష్కారం కాదని స్పష్టమవుతుంది. లింకర్డ్ పదే పదే అభ్యర్థనలను పంపగలిగినప్పటికీ (అవి అసంపూర్తిగా ఉన్నాయని తెలిస్తే), సేవ చివరకు తగ్గిపోయినట్లయితే వినియోగదారుకు ఏమి తిరిగి ఇవ్వాలనే దాని గురించి నిర్ణయాలు తీసుకునే స్థితిలో లేదు - అటువంటి నిర్ణయాలు తప్పనిసరిగా అప్లికేషన్ ద్వారా తీసుకోవాలి. లింకర్డ్ విజయవంతమైన అభ్యర్థనలపై గణాంకాలను ఉంచగలదు, కానీ అది సేవను పరిశీలించి దాని అంతర్గత కొలమానాలను అందించలేకపోతుంది - అప్లికేషన్‌లో అటువంటి టూల్‌కిట్ ఉండాలి. మరియు లింకర్డ్ mTLSని హోస్ట్ చేయగలిగినప్పటికీ, పూర్తి స్థాయి భద్రతా పరిష్కారాలకు చాలా ఎక్కువ అవసరం.
సర్వీస్ మెష్ అందించే ఈ ప్రాంతాల్లోని ఫీచర్ల ఉపసమితి సంబంధించినవి వేదిక లక్షణాలు. దీని ద్వారా నా ఉద్దేశ్యం విధులు:
- వ్యాపార తర్కం నుండి స్వతంత్రమైనది. కాల్ హిస్టోగ్రామ్‌లు ఫూ మరియు బార్ మధ్య నిర్మించబడే విధానం పూర్తిగా స్వతంత్రంగా ఉంటుంది ఎందుకు ఫూ బార్‌కి కాల్ చేస్తుంది.
- సరిగ్గా అమలు చేయడం కష్టం. లింకర్డ్‌లో, మళ్లీ ప్రయత్నించే బడ్జెట్‌ల వంటి అన్ని రకాల ఫ్యాన్సీ స్టఫ్‌లతో రీట్రీలు పారామీటర్ చేయబడి ఉంటాయి. (బడ్జెట్‌లను మళ్లీ ప్రయత్నించండి), అటువంటి విషయాలను అమలు చేయడానికి సరళమైన ఆలోచనా విధానం ఖచ్చితంగా "అభ్యర్థనల హిమపాతం" అని పిలవబడే ఆవిర్భావానికి దారి తీస్తుంది. (తుఫాను మళ్లీ ప్రయత్నించండి) మరియు పంపిణీ వ్యవస్థలకు సంబంధించిన ఇతర సమస్యలు.
- స్థిరంగా దరఖాస్తు చేసినప్పుడు అత్యంత ప్రభావవంతంగా ఉంటుంది. TLS మెకానిజం ప్రతిచోటా వర్తింపజేస్తేనే అర్ధమవుతుంది.
ఈ ఫీచర్లు ప్రాక్సీ లేయర్‌లో అమలు చేయబడినందున (మరియు అప్లికేషన్ లేయర్‌లో కాదు), సర్వీస్ మెష్ వాటిని వేదిక, అప్లికేషన్లు కాదు. అందువల్ల, సేవలు ఏ భాషలో వ్రాయబడ్డాయి, అవి ఏ ఫ్రేమ్‌వర్క్‌ను ఉపయోగిస్తాయి, ఎవరు వ్రాసారు మరియు ఎందుకు అనేవి పట్టింపు లేదు. ప్రాక్సీలు ఈ వివరాలన్నింటికీ మించి పని చేస్తాయి మరియు కాన్ఫిగర్ చేయడం, అప్‌డేట్ చేయడం, ఆపరేటింగ్ చేయడం, నిర్వహించడం మొదలైన పనులతో సహా ఈ ఫంక్షనాలిటీ యొక్క ప్రాథమిక ఆధారం ప్లాట్‌ఫారమ్ స్థాయిలో మాత్రమే ఉంటుంది.
సర్వీస్ మెష్ సామర్థ్యాలకు ఉదాహరణలు
సారాంశంలో, విశ్వసనీయత, పరిశీలన లేదా భద్రత కోసం సర్వీస్ మెష్ పూర్తి పరిష్కారం కాదు. ఈ ప్రాంతాల పరిధి సేవా యజమానులు, Ops / SRE బృందాలు మరియు ఇతర కంపెనీ వాటాదారుల తప్పనిసరి భాగస్వామ్యాన్ని సూచిస్తుంది. సర్వీస్ మెష్ ఈ ప్రాంతాలలో ప్రతిదానికి ప్లాట్‌ఫారమ్ స్థాయిలో "స్లైస్"ని మాత్రమే అందిస్తుంది.
ప్రస్తుతం సర్వీస్ మెష్ ఎందుకు జనాదరణ పొందింది?
మీరు బహుశా ప్రస్తుతం ఆశ్చర్యపోతున్నారా: సరే, సర్వీస్ మెష్ చాలా బాగుంటే, మేము పది సంవత్సరాల క్రితం స్టాక్‌లో మిలియన్ల కొద్దీ ప్రాక్సీలను అమలు చేయడం ఎందుకు ప్రారంభించలేదు?
ఈ ప్రశ్నకు సామాన్యమైన సమాధానం ఉంది: పది సంవత్సరాల క్రితం ప్రతి ఒక్కరూ ఏకశిలాలను నిర్మించారు మరియు ఎవరికీ సేవ మెష్ అవసరం లేదు. ఇది నిజం, కానీ నా అభిప్రాయం ప్రకారం, ఈ సమాధానం పాయింట్‌ను కోల్పోతుంది. పదేళ్ల క్రితం కూడా, పెద్ద ఎత్తున వ్యవస్థలను రూపొందించడానికి మైక్రోసర్వీసెస్ అనే భావన విస్తృతంగా చర్చించబడింది మరియు Twitter, Facebook, Google మరియు Netflix వంటి కంపెనీలలో వర్తించబడింది. సాధారణ అవగాహన - కనీసం పరిశ్రమలోని కొన్ని భాగాలలో నేను పరిచయం కలిగి ఉన్నాను - పెద్ద సిస్టమ్‌లను నిర్మించడానికి మైక్రోసర్వీస్‌లు "సరైన మార్గం", ఇది చాలా కష్టమైనప్పటికీ.
వాస్తవానికి, పది సంవత్సరాల క్రితం మైక్రోసర్వీస్‌లను దోపిడీ చేసే కంపెనీలు ఉన్నప్పటికీ, వారు సర్వీస్ మెష్‌ను రూపొందించడానికి ప్రతిచోటా ప్రాక్సీలను అంటుకోలేదు. అయితే, మీరు నిశితంగా పరిశీలిస్తే, వారు ఇలాంటిదే చేశారు: వీటిలో చాలా కంపెనీలు నెట్‌వర్కింగ్ కోసం ప్రత్యేక అంతర్గత లైబ్రరీని ఉపయోగించడాన్ని తప్పనిసరి చేశాయి (కొన్నిసార్లు ఫ్యాట్ క్లయింట్ లైబ్రరీ అని పిలుస్తారు, కొవ్వు క్లయింట్ లైబ్రరీ).
నెట్‌ఫ్లిక్స్‌లో హిస్టెరిక్స్, గూగుల్‌కు స్టబ్బి, ట్విట్టర్‌లో ఫినాగల్ లైబ్రరీ ఉన్నాయి. ఉదాహరణకు, Twitterలో ప్రతి కొత్త సేవకు Finagle తప్పనిసరి. ఇది కనెక్షన్ల క్లయింట్ మరియు సర్వర్ వైపు రెండింటినీ నిర్వహించింది, పునరావృత అభ్యర్థనలు, మద్దతు ఉన్న అభ్యర్థన రూటింగ్, లోడ్ బ్యాలెన్సింగ్ మరియు మీటరింగ్ కోసం అనుమతించబడుతుంది. ఇది సేవ ఏమి చేస్తున్నప్పటికీ, మొత్తం Twitter స్టాక్‌లో విశ్వసనీయత మరియు పరిశీలన యొక్క స్థిరమైన పొరను అందించింది. వాస్తవానికి, ఇది JVM భాషల కోసం మాత్రమే పని చేస్తుంది మరియు మొత్తం అప్లికేషన్ కోసం ఉపయోగించాల్సిన ప్రోగ్రామింగ్ మోడల్‌పై ఆధారపడింది. అయినప్పటికీ, దాని కార్యాచరణ సేవా మెష్‌తో సమానంగా ఉంటుంది. (వాస్తవానికి, లింకర్డ్ యొక్క మొదటి వెర్షన్ కేవలం ఫినాగల్ ప్రాక్సీ రూపంలో చుట్టబడింది.)
ఈ విధంగా, పది సంవత్సరాల క్రితం మైక్రోసర్వీస్‌లు మాత్రమే కాకుండా, ప్రత్యేక ప్రోటో-సర్వీస్-మెష్ లైబ్రరీలు కూడా ఉన్నాయి, ఇవి ఈ రోజు సర్వీస్ మెష్ పరిష్కరించే సమస్యలను పరిష్కరించాయి. అయితే, అప్పుడు సేవా మెష్ ఉనికిలో లేదు. ఆమె కనిపించకముందే మరో షిఫ్ట్ చేయాల్సి వచ్చింది.
మరియు ఇక్కడే లోతైన సమాధానం ఉంది, గత 10 సంవత్సరాలలో జరిగిన మరొక మార్పులో దాగి ఉంది: మైక్రోసర్వీస్‌లను అమలు చేసే ఖర్చులో తీవ్ర క్షీణత ఉంది. ఒక దశాబ్దం క్రితం మైక్రోసర్వీస్‌లను ఉపయోగించిన పైన పేర్కొన్న కంపెనీలు-ట్విట్టర్, నెట్‌ఫ్లిక్స్, ఫేస్‌బుక్, గూగుల్-భారీ స్థాయి మరియు భారీ వనరులు కలిగిన కంపెనీలు. వారికి అవసరాన్ని మాత్రమే కాకుండా, మైక్రోసర్వీస్‌ల ఆధారంగా పెద్ద అప్లికేషన్‌లను నిర్మించడం, అమలు చేయడం మరియు ఆపరేట్ చేయగల సామర్థ్యం కూడా ఉన్నాయి. ట్విట్టర్ ఇంజనీర్లు ఏకశిలా నుండి మైక్రోసర్వీస్ విధానానికి మారడానికి చేసిన శక్తి మరియు కృషి అద్భుతమైనది. (నిజాయితీగా, ఇది పనిచేసిన వాస్తవం.) చిన్న కంపెనీలకు ఈ రకమైన మౌలిక సదుపాయాల కల్పన అసాధ్యం.
ప్రస్తుతానికి వెళ్దాం. డెవలపర్‌లకు మైక్రోసర్వీస్‌ల నిష్పత్తి 5:1 (లేదా కూడా) ఉన్న స్టార్టప్‌లు నేడు ఉన్నాయి ), మరియు అంతేకాకుండా, వారు వాటిని విజయవంతంగా ఎదుర్కొంటారు! 5 మంది వ్యక్తులతో కూడిన స్టార్టప్ 50 మైక్రోసర్వీస్‌లను ఒత్తిడి లేకుండా ఆపరేట్ చేయగలిగితే, వాటి అమలు ఖర్చును ఏదో స్పష్టంగా తగ్గించింది.
మోంజోలో 1500 మైక్రోసర్వీసులు; ప్రతి లైన్ ట్రాఫిక్‌ని అనుమతించే నిర్దేశిత నెట్‌వర్క్ నియమం
మైక్రోసర్వీస్ నిర్వహణ ఖర్చులో నాటకీయ తగ్గింపు ఒకే ప్రక్రియ యొక్క ఫలితం: కంటైనర్లకు పెరుగుతున్న ప్రజాదరణ и ఆర్కెస్ట్రేటర్లు. సేవా మెష్ యొక్క ఆవిర్భావానికి దోహదపడిన ప్రశ్నకు ఇది ఖచ్చితంగా లోతైన సమాధానం. అదే సాంకేతికత సర్వీస్ మెష్ మరియు మైక్రోసర్వీస్ రెండింటినీ ఆకర్షణీయంగా చేసింది: కుబెర్నెటెస్ మరియు డాకర్.
ఎందుకు? సరే, డాకర్ ఒక పెద్ద సమస్యను పరిష్కరిస్తాడు - ప్యాకేజింగ్ సమస్య. ఒక అప్లికేషన్‌ను మరియు దాని (నెట్‌వర్క్ కాని) రన్‌టైమ్ డిపెండెన్సీలను కంటైనర్‌లో ప్యాక్ చేయడం ద్వారా, డాకర్ అప్లికేషన్‌ను ఫంగబుల్ యూనిట్‌గా మారుస్తుంది, అది ఎక్కడైనా హోస్ట్ చేయబడవచ్చు మరియు అమలు చేయవచ్చు. అదే సమయంలో, ఇది ఆపరేషన్ను చాలా సులభతరం చేస్తుంది. బహుభాషా స్టాక్: కంటైనర్ అనేది ఎగ్జిక్యూషన్ యొక్క అటామిక్ యూనిట్ కాబట్టి, అది JVM, నోడ్, గో, పైథాన్ లేదా రూబీ అప్లికేషన్ అయినా, డిప్లాయ్‌మెంట్ మరియు కార్యాచరణ ప్రయోజనాల కోసం లోపల ఏముందో పట్టింపు లేదు. మీరు దీన్ని అమలు చేయండి మరియు అంతే.
కుబెర్నెటెస్ ప్రతిదీ తదుపరి స్థాయికి తీసుకువెళతాడు. ఇప్పుడు "ఎక్జిక్యూటబుల్ థింగ్స్" మరియు వాటిని అమలు చేయడానికి అనేక యంత్రాలు ఉన్నాయి, వాటిని ఒకదానితో ఒకటి సరిపోల్చగల సాధనం అవసరం. విస్తృత కోణంలో, మీరు కుబెర్నెట్‌లకు అనేక కంటైనర్‌లు మరియు అనేక మెషీన్‌లను ఇస్తారు మరియు అది వాటిని ఒకదానితో ఒకటి సరిపోల్చుతుంది (అయితే, ఇది డైనమిక్ మరియు నిరంతరం మారుతున్న ప్రక్రియ: కొత్త కంటైనర్‌లు సిస్టమ్ చుట్టూ తిరుగుతాయి, యంత్రాలు ప్రారంభించడం మరియు ఆగిపోవడం మొదలైనవి. అయితే, కుబెర్నెటెస్ ఇవన్నీ పరిగణనలోకి తీసుకుంటాడు).
కుబెర్నెటెస్‌ని సెటప్ చేసిన తర్వాత, ఒక సర్వీస్‌ని అమలు చేయడానికి మరియు ఆపరేట్ చేయడానికి పట్టే సమయం పది సేవలను అమలు చేయడానికి మరియు ఆపరేట్ చేయడానికి అయ్యే ఖర్చు కంటే చాలా భిన్నంగా ఉండదు (వాస్తవానికి, ఇది 100 సేవలకు దాదాపు సమానంగా ఉంటుంది). బహుభాషా అమలును ప్రోత్సహించే ప్యాకేజింగ్ మెకానిజమ్‌గా ఈ కంటైనర్లకు జోడించండి మరియు మీరు బహుళ భాషలలో వ్రాసిన మైక్రోసర్వీస్‌ల వలె అమలు చేయబడిన టన్నుల కొద్దీ కొత్త అప్లికేషన్‌లను కలిగి ఉన్నారు, సేవా మెష్ బాగా సరిపోయే వాతావరణం మాత్రమే.
కాబట్టి, ప్రస్తుతం సర్వీస్ మెష్ ఆలోచన ఎందుకు జనాదరణ పొందింది అనే ప్రశ్నకు మేము సమాధానానికి వచ్చాము: సేవల కోసం కుబెర్నెటెస్ అందించే ఏకరూపత సేవా మెష్ ఎదుర్కొంటున్న కార్యాచరణ పనులకు నేరుగా వర్తిస్తుంది. మీరు ప్రాక్సీలను కంటైనర్‌లలో ప్యాక్ చేయండి, కుబెర్నెట్‌లకు సాధ్యమైన చోట వాటిని అంటుకునే పనిని ఇవ్వండి మరియు వోయిలా! ఫలితంగా, మీరు సర్వీస్ మెష్‌ని పొందుతారు, అయితే కుబెర్నెటెస్ దాని విస్తరణ యొక్క అన్ని మెకానిక్‌లను నియంత్రిస్తుంది. (కనీసం పక్షి దృష్టి నుండి. అయితే, ఈ ప్రక్రియకు చాలా సూక్ష్మ నైపుణ్యాలు ఉన్నాయి.)
మొత్తానికి: సర్వీస్ మెష్ ఇప్పుడు ప్రజాదరణ పొందింది మరియు పదేళ్ల క్రితం కాదు, కుబెర్నెట్స్ మరియు డాకర్ గణనీయంగా పెరగడమే కాదు. అవసరం దానిలో, బహుభాషా మైక్రోసర్వీస్‌ల సెట్‌లుగా అప్లికేషన్‌ల అమలును సులభతరం చేస్తుంది, కానీ గణనీయంగా తగ్గించబడింది ఖర్చులు సైడ్‌కార్ ప్రాక్సీ పార్కులను అమలు చేయడానికి మరియు నిర్వహించడానికి యంత్రాంగాలను అందించడం ద్వారా దాని ఆపరేషన్ కోసం.
సేవా మెష్ గురించి ఎందుకు అంత చర్చ జరుగుతోంది?
నివారణ: ఈ విభాగంలో, నేను అన్ని రకాల ఊహలు, ఊహలు, కల్పనలు మరియు అంతర్గత సమాచారాన్ని ఆశ్రయిస్తాను.
"సర్వీస్ మెష్" కోసం శోధించడం వలన రీసైకిల్ చేయబడిన, తక్కువ కేలరీల కంటెంట్, బేసి ప్రాజెక్ట్‌లు మరియు ఎకో చాంబర్‌కు తగిన వక్రీకరణ యొక్క కాలిడోస్కోప్ సమూహాన్ని పొందుతాయి. ఏదైనా అధునాతన కొత్త సాంకేతికత ఇది కలిగి ఉంటుంది, కానీ సర్వీస్ మెష్ విషయంలో, సమస్య ముఖ్యంగా తీవ్రంగా ఉంటుంది. ఎందుకు?
బాగా, ఇది పాక్షికంగా నా తప్పు. ఇలాంటి లెక్కలేనన్ని బ్లాగ్ పోస్ట్‌లు మరియు కథనాల ద్వారా ప్రతి అవకాశంలోనూ లింకర్డ్ మరియు సర్వీస్ మెష్‌ను ప్రోత్సహించడానికి నేను నా వంతు కృషి చేసాను. కానీ నేను అంత శక్తివంతుడిని కాదు. ఈ ప్రశ్నకు నిజంగా సమాధానం ఇవ్వడానికి, మేము సాధారణ పరిస్థితి గురించి కొంచెం మాట్లాడాలి. మరియు ఒక ప్రాజెక్ట్ గురించి ప్రస్తావించకుండా దాని గురించి మాట్లాడటం అసాధ్యం: Google, IBM మరియు Lyft సంయుక్తంగా అభివృద్ధి చేసిన ఓపెన్ సోర్స్ సర్వీస్ మెష్.
(ఆ మూడు కంపెనీలు చాలా భిన్నమైన పాత్రలను కలిగి ఉన్నాయి: లిఫ్ట్ యొక్క ప్రమేయం కేవలం పేరుకు మాత్రమే పరిమితమైంది; వారు రాయబారిని రచించారు కానీ ఇస్టియోను ఉపయోగించరు లేదా అభివృద్ధి చేయడంలో పాలుపంచుకోలేదు. IBM ఇస్టియో అభివృద్ధిలో పాలుపంచుకుంది మరియు దానిని ఉపయోగిస్తుంది. Google భారీగా ఉంది ఇస్టియో అభివృద్ధిలో పాలుపంచుకున్నారు, కానీ నేను చెప్పగలిగినంతవరకు, నిజానికి దానిని ఉపయోగించలేదు.)
ఇస్టియో ప్రాజెక్ట్ రెండు విషయాల కోసం గుర్తించదగినది. ముందుగా, ఇది Google, ప్రత్యేకించి, దాని ప్రమోషన్‌లో ఉంచే భారీ మార్కెటింగ్ ప్రయత్నం. సర్వీస్ మెష్ కాన్సెప్ట్ గురించి ప్రస్తుతం అవగాహన ఉన్న చాలా మంది వ్యక్తులు దాని గురించి మొదట తెలుసుకున్నారని నేను అంచనా వేస్తున్నాను. ఇస్టియోను ఎంత దారుణంగా రిసీవ్ చేసుకున్నారనేది రెండో విశేషం. ఈ విషయంలో, నేను, సహజంగానే, ఆసక్తిగల పార్టీని, కానీ వీలైనంత లక్ష్యంతో ఉండటానికి ప్రయత్నిస్తున్నాను, నేను ఇప్పటికీ సహాయం చేయలేను , చాలా నిర్దిష్టంగా లేదు (ప్రత్యేకంగా లేనప్పటికీ: systemd గుర్తుకు వస్తుంది, ...) ఓపెన్ సోర్స్ ప్రాజెక్ట్ కోసం.
(ఆచరణలో, Istio సంక్లిష్టత మరియు UXతో మాత్రమే కాకుండా పనితీరుతో కూడా సమస్యలను కలిగి ఉన్నట్లు కనిపిస్తోంది. ఉదాహరణకు, సమయంలో మూడవ పక్షం ద్వారా నిర్వహించబడింది, నిపుణులు లింకర్డ్ యొక్క టెయిల్ లాటెన్సీ కంటే 100 రెట్లు ఎక్కువగా ఉన్న పరిస్థితులను కనుగొన్నారు, అలాగే లింకర్డ్ విజయవంతంగా పని చేయడం కొనసాగించినప్పుడు మరియు ఇస్టియో పూర్తిగా పని చేయడం ఆపివేసినప్పుడు వనరుల కొరత ఉన్న పరిస్థితులను కనుగొన్నారు.)
ఇది ఎందుకు జరిగిందనే దాని గురించి నా సిద్ధాంతాలను పక్కన పెడితే, Google ప్రమేయం కారణంగా సేవా మెష్ చుట్టూ ఆఫ్-స్కేల్ హైప్ వచ్చిందని నేను నమ్ముతున్నాను. అవి, కింది మూడు కారకాల కలయిక:
- Google ద్వారా Istio యొక్క అబ్సెసివ్ ప్రచారం;
- ప్రాజెక్ట్ పట్ల తగిన నిరాకరణ, విమర్శనాత్మక వైఖరి;
- కుబెర్నెటెస్ యొక్క ఇటీవలి ఆకాశాన్ని తాకుతున్న జనాదరణ, దాని జ్ఞాపకం ఇప్పటికీ తాజాగా ఉంది.
కలిసి, ఈ కారకాలు ఒక రకమైన మత్తు, అనాక్సిక్ వాతావరణంలో కలిసిపోతాయి, దీనిలో హేతుబద్ధమైన తీర్పు సామర్థ్యం బలహీనపడింది మరియు అద్భుతమైన వైవిధ్యం మాత్రమే మిగిలి ఉంది. .
లింకర్డ్ యొక్క దృక్కోణం నుండి, ఇది… నేను దీనిని మిశ్రమ ఆశీర్వాదంగా వర్ణిస్తాను. నా ఉద్దేశ్యం, సర్వీస్ మెష్ ప్రధాన స్రవంతిలోకి ప్రవేశించడం చాలా గొప్ప విషయం - ఇది 2016లో మొదటిసారిగా లింకర్డ్ కనిపించినప్పుడు కాదు మరియు ప్రాజెక్ట్‌పై ప్రజల దృష్టిని ఆకర్షించడం చాలా కష్టం. ఇప్పుడు అలాంటి సమస్య లేదు! కానీ చెడ్డ వార్త ఏమిటంటే, ఈరోజు సర్వీస్ మెష్ పరిస్థితి చాలా గందరగోళంగా ఉంది, ఏ ప్రాజెక్ట్‌లు నిజంగా సర్వీస్ మెష్ కేటగిరీకి చెందినవో గుర్తించడం దాదాపు అసాధ్యం (ఒక నిర్దిష్ట ఉపయోగ సందర్భంలో ఏది ఉత్తమమో గుర్తించండి). ఇది ఖచ్చితంగా ప్రతి ఒక్కరికీ దారి తీస్తుంది (మరియు ఖచ్చితంగా కొన్ని సందర్భాల్లో ఇస్టియో లేదా మరొక ప్రాజెక్ట్ లింకర్డ్ కంటే మెరుగ్గా ఉంటుంది, ఎందుకంటే రెండోది ఒకే పరిమాణానికి సరిపోయే పరిష్కారం కాదు).
లింకర్డ్ వైపు నుండి, శబ్దాన్ని విస్మరించడం, సంఘంలోని నిజమైన సమస్యలను పరిష్కరించడంపై దృష్టి పెట్టడం మరియు హైప్ తగ్గే వరకు వేచి ఉండటం మా వ్యూహం. చివరికి హైప్ తగ్గుతుంది మరియు మేము ప్రశాంతంగా పనిని కొనసాగించవచ్చు.
అప్పటి వరకు మనందరం ఓపిక పట్టాలి.
నిరాడంబరమైన సాఫ్ట్‌వేర్ ఇంజనీర్ అయిన నాకు సర్వీస్ మెష్ ఉపయోగపడుతుందా?
ఈ ప్రశ్నకు సమాధానమివ్వడానికి క్రింది ప్రశ్నాపత్రం సహాయం చేస్తుంది:
మీరు వ్యాపార తర్కం అమలుతో ప్రత్యేకంగా వ్యవహరిస్తారా? ఈ సందర్భంలో, సర్వీస్ మెష్ మీకు ఉపయోగపడదు. అంటే, వాస్తవానికి, మీరు దానిపై ఆసక్తి కలిగి ఉండవచ్చు, కానీ ఆదర్శంగా, సేవా మెష్ మీ వాతావరణంలో ఏదైనా నేరుగా ప్రభావితం చేయకూడదు. మీరు చెల్లించినదానిపై పని చేస్తూ ఉండండి.
మీరు Kubernetes ఉపయోగించే కంపెనీలో ప్లాట్‌ఫారమ్‌ను నిర్వహిస్తున్నారా? అవును, ఈ సందర్భంలో మీకు సర్వీస్ మెష్ అవసరం (వాస్తవానికి, మీరు ఒక మోనోలిత్ లేదా బ్యాచ్ ప్రాసెసింగ్‌ని అమలు చేయడానికి K8లను ఉపయోగించకపోతే - అయితే మీకు K8లు ఎందుకు అవసరం అని నేను అడగాలనుకుంటున్నాను). చాలా మటుకు, మీరు వేర్వేరు వ్యక్తులచే వ్రాయబడిన అనేక మైక్రోసర్వీస్‌లతో పరిస్థితిలో మిమ్మల్ని మీరు కనుగొంటారు. అవన్నీ ఒకదానితో ఒకటి సంకర్షణ చెందుతాయి మరియు రన్‌టైమ్ డిపెండెన్సీల చిక్కుముడితో ముడిపడి ఉంటాయి మరియు వీటన్నింటిని ఎదుర్కోవటానికి మీరు ఒక మార్గాన్ని కనుగొనాలి. Kubernetes ఉపయోగం "మీ కోసం" సేవ మెష్‌ను ఎంచుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. దీన్ని చేయడానికి, వారి సామర్థ్యాలు మరియు లక్షణాలతో మిమ్మల్ని మీరు పరిచయం చేసుకోండి మరియు అందుబాటులో ఉన్న ఏవైనా ప్రాజెక్ట్‌లు మీకు సరిపోతాయా అనే ప్రశ్నకు సమాధానం ఇవ్వండి (లింకర్డ్‌తో మీ పరిశోధనను ప్రారంభించమని నేను సిఫార్సు చేస్తున్నాను).
మీరు Kubernetes ఉపయోగించని కానీ మైక్రోసర్వీస్‌లను ఉపయోగించే కంపెనీ కోసం ప్లాట్‌ఫారమ్‌ను నడుపుతున్నారా? ఈ సందర్భంలో, సర్వీస్ మెష్ మీకు ఉపయోగకరంగా ఉంటుంది, కానీ దాని ఉపయోగం అల్పమైనది కాదు. అయితే మీరు చెయ్యగలరు అనుకరించు ప్రాక్సీల సమూహాన్ని హోస్ట్ చేయడం ద్వారా సర్వీస్ మెష్, కానీ కుబెర్నెటెస్ యొక్క ముఖ్యమైన ప్రయోజనం ఖచ్చితంగా విస్తరణ నమూనా: ఈ ప్రాక్సీలను మాన్యువల్‌గా నిర్వహించడానికి ఎక్కువ సమయం, కృషి మరియు ఖర్చు అవసరం.
మోనోలిత్‌లతో పనిచేసే కంపెనీలో ప్లాట్‌ఫారమ్‌కి మీరు బాధ్యత వహిస్తున్నారా? ఈ సందర్భంలో, మీకు బహుశా సర్వీస్ మెష్ అవసరం లేదు. మీరు బాగా నిర్వచించబడిన మరియు అరుదుగా మారుతున్న పరస్పర చర్యలను కలిగి ఉన్న ఏకశిలాలతో (లేదా మోనోలిత్‌ల సేకరణలు కూడా) పని చేస్తుంటే, సేవా మెష్ మీకు అందించేది చాలా తక్కువ. కాబట్టి మీరు దానిని విస్మరించవచ్చు మరియు ఇది చెడ్డ కలలాగా అదృశ్యమవుతుందని ఆశిస్తున్నాము...
తీర్మానం
బహుశా, సర్వీస్ మెష్ ఇప్పటికీ "ప్రపంచంలో అత్యంత హైప్డ్ టెక్నాలజీ" అని పిలవకూడదు - ఈ సందేహాస్పద గౌరవం బహుశా బిట్‌కాయిన్ లేదా AIకి చెందినది. బహుశా ఆమె మొదటి ఐదు స్థానాల్లో ఉండవచ్చు. కానీ మీరు శబ్దం మరియు డన్ యొక్క పొరలను విచ్ఛిన్నం చేస్తే, కుబెర్నెట్స్‌లో అప్లికేషన్‌లను సృష్టించే వారికి సేవా మెష్ నిజమైన ప్రయోజనాలను తెస్తుందని స్పష్టమవుతుంది.
మీరు లింకర్డ్‌ని ప్రయత్నించాలని నేను కోరుకుంటున్నాను - దీన్ని కుబెర్నెట్స్ క్లస్టర్‌లో ఇన్‌స్టాల్ చేయడం (లేదా ల్యాప్‌టాప్‌లో మినీక్యూబ్ కూడా) మరియు నేను ఏమి మాట్లాడుతున్నానో మీరే చూడగలరు.
FAQ
- నేను సర్వీస్ మెష్‌ను విస్మరిస్తే, అది అదృశ్యమవుతుందా?
- నేను మిమ్మల్ని నిరాశపరచాలి: సేవా మెష్ చాలా కాలం పాటు మాతో ఉంది.
— కానీ నేను సర్వీస్ మెష్‌ని ఉపయోగించాలనుకోవడం లేదు!
- బాగా, ఇది అవసరం లేదు! పైన ఉన్న నా ప్రశ్నాపత్రాన్ని చదవండి, మీరు కనీసం దాని బేసిక్స్‌తో మీ గురించి తెలుసుకోవాలా.
— ఇది కొత్త సాస్‌తో మంచి పాత ESB/మిడిల్‌వేర్ కాదా?
- సర్వీస్ మెష్ సెమాంటిక్ కాకుండా ఆపరేషనల్ లాజిక్‌తో వ్యవహరిస్తుంది. ఎంటర్‌ప్రైజ్ సర్వీస్ బస్సు () ఈ విభజనను ఉంచడం సేవా మెష్‌కు అదే విధిని నివారించడానికి సహాయపడుతుంది.
- API గేట్‌వేలకు సర్వీస్ మెష్ ఎలా భిన్నంగా ఉంటుంది?
ఈ అంశంపై మిలియన్ వ్యాసాలు ఉన్నాయి. కేవలం గూగుల్.
రాయబారి సేవా మెష్‌నా?
- లేదు, ఎన్వాయ్ సర్వీస్ మెష్ కాదు, ఇది ప్రాక్సీ సర్వర్. ఇది సేవా మెష్‌ను నిర్వహించడానికి ఉపయోగించవచ్చు (మరియు చాలా ఎక్కువ - ఇది సాధారణ ప్రయోజన ప్రాక్సీ). కానీ స్వతహాగా, ఇది సేవా మెష్ కాదు.
- నెట్‌వర్క్ సర్వీస్ మెష్ - ఇది సర్వీస్ మెష్ కాదా?
- లేదు. పేరు ఉన్నప్పటికీ, ఇది సేవా మెష్ కాదు (మార్కెటింగ్ యొక్క అద్భుతాలను మీరు ఎలా ఇష్టపడతారు?).
- మెసేజ్ క్యూ ఆధారంగా నా రియాక్టివ్ అసమకాలిక సిస్టమ్‌తో సర్వీస్ మెష్ సహాయం చేస్తుందా?
- లేదు, సర్వీస్ మెష్ మీకు సహాయం చేయదు.
- నేను ఏ సర్వీస్ మెష్ ఉపయోగించాలి?
- , తెలివి అవసరం లేని.
- వ్యాసం సరదా! / రచయిత - సబ్బు మీద!
— దయచేసి దీనికి లింక్‌ను మీ స్నేహితులందరితో పంచుకోండి, తద్వారా వారు దీన్ని ఒప్పించగలరు!
రసీదులు
మీరు టైటిల్ నుండి ఊహించినట్లుగా, ఈ వ్యాసం జే క్రెప్స్ యొక్క అద్భుతమైన గ్రంథం నుండి ప్రేరణ పొందింది "". నేను పదేళ్ల క్రితం లింక్డ్ ఇన్‌లో ఇంటర్వ్యూ చేస్తున్నప్పుడు జేని కలిశాను మరియు అప్పటి నుండి అతను నాకు స్ఫూర్తిగా నిలిచాడు.
నేను నన్ను "లింకర్డ్ డెవలపర్" అని పిలవాలనుకుంటున్నాను, వాస్తవానికి నేను ప్రాజెక్ట్‌లో README.md ఫైల్‌ని మెయింటెయిన్ చేసేవాడిని. ఈరోజు Linkerdలో పని చేస్తున్నారు , , ప్రజలు, మరియు ఈ ప్రాజెక్ట్ కంట్రిబ్యూటర్లు మరియు వినియోగదారుల అద్భుతమైన సంఘం లేకుండా సాధ్యం కాదు.
చివరగా, లింకర్డ్ సృష్టికర్తకు ప్రత్యేక ధన్యవాదాలు, (ప్రైమస్ ఇంటర్ పరేస్), చాలా సంవత్సరాల క్రితం నాతో పాటు, సేవా మెష్‌తో ఈ తతంగం అంతా తలకిందులు.
అనువాదకుని నుండి PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «";
- «".
మూలం: www.habr.com