సెప్టెంబర్ 19 మాస్కోలో మొదటి నేపథ్య సమావేశం HUG (హైలోడ్++ యూజర్ గ్రూప్), ఇది మైక్రోసర్వీస్‌లకు అంకితం చేయబడింది. "ఆపరేటింగ్ మైక్రోసర్వీసెస్: సైజ్ మేటర్స్, మీకు కుబెర్నెట్స్ ఉన్నప్పటికీ" అనే ప్రెజెంటేషన్ ఉంది, దీనిలో మేము మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌తో ప్రాజెక్ట్‌లను ఆపరేట్ చేయడంలో ఫ్లాంట్ యొక్క విస్తృతమైన అనుభవాన్ని పంచుకున్నాము. అన్నింటిలో మొదటిది, వారి ప్రస్తుత లేదా భవిష్యత్తు ప్రాజెక్ట్‌లో ఈ విధానాన్ని ఉపయోగించడం గురించి ఆలోచిస్తున్న డెవలపర్‌లందరికీ ఇది ఉపయోగకరంగా ఉంటుంది.
పరిచయం చేస్తోంది (50 నిమిషాలు, వ్యాసం కంటే చాలా ఎక్కువ సమాచారం), అలాగే దాని నుండి టెక్స్ట్ రూపంలో ప్రధాన సారం.
NB: ఈ పోస్ట్ చివరిలో వీడియో మరియు ప్రదర్శన కూడా అందుబాటులో ఉన్నాయి.
పరిచయం
సాధారణంగా మంచి కథకు ప్రారంభం, ప్రధాన కథాంశం మరియు స్పష్టత ఉంటాయి. ఈ నివేదిక ఒక పల్లవి లాంటిది మరియు విషాదకరమైనది. ఇది మైక్రోసర్వీస్‌ల గురించి బయటి వ్యక్తుల అభిప్రాయాన్ని అందిస్తుంది అని కూడా గమనించడం ముఖ్యం. ఆపరేటింగ్.
నేను ఈ గ్రాఫ్‌తో ప్రారంభిస్తాను, దీని రచయిత (2015లో) మార్టిన్ ఫౌలర్:
ఒక నిర్దిష్ట విలువను చేరుకునే ఏకశిలా అప్లికేషన్ విషయంలో, ఉత్పాదకత ఎలా తగ్గుముఖం పడుతుందో ఇది చూపిస్తుంది. మైక్రోసర్వీస్‌లు భిన్నంగా ఉంటాయి, వాటితో ప్రారంభ ఉత్పాదకత తక్కువగా ఉంటుంది, కానీ సంక్లిష్టత పెరిగేకొద్దీ, సామర్థ్యంలో క్షీణత వారికి అంతగా గుర్తించబడదు.
కుబెర్నెట్‌లను ఉపయోగించే విషయంలో నేను ఈ గ్రాఫ్‌కి జోడిస్తాను:
మైక్రోసర్వీస్‌తో కూడిన అప్లికేషన్ ఎందుకు మంచిది? ఎందుకంటే అటువంటి వాస్తుశిల్పం వాస్తుశిల్పం కోసం తీవ్రమైన అవసరాలను ముందుకు తెస్తుంది, ఇది కుబెర్నెట్స్ యొక్క సామర్థ్యాలతో సంపూర్ణంగా కవర్ చేయబడింది. మరోవైపు, ఈ ఫంక్షనాలిటీలో కొన్ని ఏకశిలా కోసం ఉపయోగపడతాయి, ప్రత్యేకించి ఈ రోజు సాధారణ ఏకశిలా ఖచ్చితంగా ఏకశిలా కాదు (వివరాలు నివేదికలో తర్వాత ఉంటాయి).
మీరు చూడగలిగినట్లుగా, చివరి గ్రాఫ్ (ఏకశిలా మరియు మైక్రోసర్వీస్ అప్లికేషన్‌లు రెండూ కుబెర్నెట్స్‌తో ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఉన్నప్పుడు) అసలు దాని నుండి చాలా భిన్నంగా లేదు. తదుపరి మేము Kubernetes ఉపయోగించి నిర్వహించబడే అప్లికేషన్ల గురించి మాట్లాడుతాము.
ఉపయోగకరమైన మరియు హానికరమైన మైక్రోసర్వీస్
మరియు ఇక్కడ ప్రధాన ఆలోచన ఉంది:
ఏమిటి సాధారణ మైక్రోసర్వీస్ ఆర్కిటెక్చర్? ఇది మీకు నిజమైన ప్రయోజనాలను తెస్తుంది, మీ పని సామర్థ్యాన్ని పెంచుతుంది. మేము గ్రాఫ్‌కి తిరిగి వెళితే, ఇదిగోండి:
మీరు ఆమెను పిలిస్తే ఉపయోగకరమైన, అప్పుడు గ్రాఫ్ యొక్క ఇతర వైపు ఉంటుంది హానికరమైన మైక్రోసర్వీసెస్ (పనిలో జోక్యం చేసుకుంటుంది):
"ప్రధాన ఆలోచన"కి తిరిగి రావడం: నా అనుభవాన్ని నేను నమ్మాలా? ఈ సంవత్సరం ప్రారంభం నుండి నేను చూస్తున్నాను 85 ప్రాజెక్టులు. అవన్నీ మైక్రోసర్వీస్‌లు కావు (వాటిలో మూడింట ఒక వంతు నుండి సగం మంది అలాంటి నిర్మాణాన్ని కలిగి ఉన్నారు), కానీ ఇది ఇప్పటికీ పెద్ద సంఖ్యలో ఉంది. మేము (ఫ్లాంట్ కంపెనీ) అవుట్‌సోర్సర్‌గా చిన్న కంపెనీలలో (5 డెవలపర్‌లతో) మరియు పెద్ద వాటిల్లో (~500 డెవలపర్‌లు) అభివృద్ధి చేయబడిన అనేక రకాల అప్లికేషన్‌లను చూడగలుగుతున్నాము. అదనపు ప్రయోజనం ఏమిటంటే, ఈ అప్లికేషన్‌లు సంవత్సరాలుగా ప్రత్యక్షంగా మరియు అభివృద్ధి చెందడాన్ని మనం చూస్తాము.
మైక్రోసర్వీసెస్ ఎందుకు?
మైక్రోసర్వీస్ యొక్క ప్రయోజనాల గురించి ప్రశ్నకు ఉంది ఇప్పటికే పేర్కొన్న మార్టిన్ ఫౌలర్ నుండి:
- మాడ్యులారిటీ యొక్క స్పష్టమైన సరిహద్దులు;
- స్వతంత్ర విస్తరణ;
- సాంకేతికతలను ఎంచుకునే స్వేచ్ఛ.
నేను సాఫ్ట్‌వేర్ ఆర్కిటెక్ట్‌లు మరియు డెవలపర్‌లతో చాలా మాట్లాడాను మరియు వారికి మైక్రోసర్వీస్‌లు ఎందుకు అవసరం అని అడిగాను. మరియు నేను వారి అంచనాల జాబితాను తయారు చేసాను. ఏమి జరిగిందో ఇక్కడ ఉంది:
మేము "అనుభూతులలో" కొన్ని పాయింట్లను వివరిస్తే:
- మాడ్యూల్స్ యొక్క స్పష్టమైన సరిహద్దులు: ఇక్కడ మనకు భయంకరమైన ఏకశిలా ఉంది, మరియు ఇప్పుడు ప్రతిదీ Git రిపోజిటరీలలో చక్కగా అమర్చబడుతుంది, దీనిలో ప్రతిదీ “అల్మారాల్లో” ఉంది, వెచ్చని మరియు మృదువైనవి మిశ్రమంగా లేవు;
- విస్తరణ స్వాతంత్ర్యం: మేము స్వతంత్రంగా సేవలను అందించగలుగుతాము, తద్వారా అభివృద్ధి వేగంగా జరుగుతుంది (సమాంతరంగా కొత్త లక్షణాలను ప్రచురించండి);
- అభివృద్ధి స్వాతంత్ర్యం: మేము ఈ మైక్రోసర్వీస్‌ని ఒక టీమ్/డెవలపర్‌కి మరియు ఒకరికి మరొకరికి అందించగలము, దానికి ధన్యవాదాలు మనం వేగంగా అభివృద్ధి చేయగలము;
- боఎక్కువ విశ్వసనీయత: పాక్షిక క్షీణత సంభవించినట్లయితే (20లో ఒక మైక్రోసర్వీస్ పతనం), అప్పుడు ఒక బటన్ మాత్రమే పని చేయడం ఆపివేస్తుంది మరియు సిస్టమ్ మొత్తం పని చేస్తూనే ఉంటుంది.
సాధారణ (హానికరమైన) మైక్రోసర్వీస్ ఆర్కిటెక్చర్
వాస్తవికత మనం ఆశించేది కాదు అని వివరించడానికి, నేను అందజేస్తాను సామూహిక అనేక విభిన్న ప్రాజెక్ట్‌ల అనుభవం ఆధారంగా మైక్రోసర్వీస్ ఆర్కిటెక్చర్ యొక్క చిత్రం.
అమెజాన్ లేదా కనీసం ఓజోన్‌తో పోటీ పడే వియుక్త ఆన్‌లైన్ స్టోర్ ఒక ఉదాహరణ. దీని మైక్రోసర్వీస్ ఆర్కిటెక్చర్ ఇలా కనిపిస్తుంది:
కారణాల కలయిక కోసం, ఈ మైక్రోసర్వీస్‌లు వేర్వేరు ప్లాట్‌ఫారమ్‌లలో వ్రాయబడ్డాయి:
ప్రతి మైక్రోసర్వీస్‌కు స్వయంప్రతిపత్తి ఉండాలి కాబట్టి, వాటిలో చాలా వరకు వారి స్వంత డేటాబేస్ మరియు కాష్ అవసరం. తుది నిర్మాణం క్రింది విధంగా ఉంది:
దాని పర్యవసానాలు ఏమిటి?
ఫౌలర్‌కి ఇది కూడా ఉంది - మైక్రోసర్వీస్‌లను ఉపయోగించడం కోసం "చెల్లింపు" గురించి:
మరి మన అంచనాలు అందుకుంటాయో లేదో చూడాలి.
మాడ్యూళ్ల సరిహద్దులను క్లియర్ చేయండి...
కానీ వాస్తవానికి మనం ఎన్ని మైక్రోసర్వీస్‌లను పరిష్కరించాలి?మార్పును అమలు చేయాలా? పంపిణీ చేయబడిన ట్రేసర్ లేకుండా ప్రతిదీ ఎలా పని చేస్తుందో కూడా మనం గుర్తించగలమా (అన్ని తరువాత, ఏదైనా అభ్యర్థన మైక్రోసర్వీస్‌లలో సగం ద్వారా ప్రాసెస్ చేయబడుతుంది)?
ఒక నమూనా ఉంది"", మరియు ఇక్కడ అది మురికి యొక్క పంపిణీ ముద్దగా మారింది. దీన్ని నిర్ధారించడానికి, అభ్యర్థనలు ఎలా జరుగుతాయి అనేదానికి ఇక్కడ ఉజ్జాయింపు ఉదాహరణ:
విస్తరణ స్వతంత్రత...
సాంకేతికంగా, ఇది సాధించబడింది: మేము ప్రతి మైక్రోసర్వీస్‌ను విడిగా రూపొందించవచ్చు. కానీ ఆచరణలో మీరు ఎల్లప్పుడూ బయటకు రోల్స్ అని పరిగణనలోకి తీసుకోవాలి అనేక సూక్ష్మసేవలు, మరియు మనం పరిగణనలోకి తీసుకోవాలి వారి రోల్ అవుట్ యొక్క క్రమం. మంచి మార్గంలో, మేము సాధారణంగా విడుదలను సరైన క్రమంలో విడుదల చేస్తున్నామో లేదో ప్రత్యేక సర్క్యూట్‌లో పరీక్షించాలి.
టెక్నాలజీని ఎంచుకునే స్వేచ్ఛ...
ఆమె. స్వేచ్ఛ తరచుగా అన్యాయానికి సరిహద్దుగా ఉంటుందని గుర్తుంచుకోండి. సాంకేతికతలను వారితో "ప్లే" చేయడానికి మాత్రమే ఎంచుకోకుండా ఉండటం ఇక్కడ చాలా ముఖ్యం.
అభివృద్ధి స్వతంత్రం...
మొత్తం అప్లికేషన్ కోసం (చాలా భాగాలతో) టెస్ట్ లూప్‌ను ఎలా తయారు చేయాలి? కానీ మీరు ఇప్పటికీ దానిని తాజాగా ఉంచాలి. అన్ని ఈ వాస్తవం దారితీస్తుంది పరీక్ష సర్క్యూట్ల వాస్తవ సంఖ్య, మేము సూత్రప్రాయంగా కలిగి ఉండవచ్చు, కనిష్టంగా మారుతుంది.
ఇవన్నీ స్థానికంగా అమలు చేయడం ఎలా?.. తరచుగా డెవలపర్ తన పనిని స్వతంత్రంగా చేస్తాడు, కానీ "యాదృచ్ఛికంగా" చేస్తాడు, ఎందుకంటే అతను సర్క్యూట్ పరీక్ష కోసం ఉచితమయ్యే వరకు వేచి ఉండవలసి వస్తుంది.
ప్రత్యేక స్కేలింగ్...
అవును, కానీ ఇది ఉపయోగించిన DBMS ప్రాంతంలో పరిమితం చేయబడింది. ఇచ్చిన ఆర్కిటెక్చర్ ఉదాహరణలో, కాసాండ్రాకు సమస్యలు ఉండవు, కానీ MySQL మరియు PostgreSQL ఉంటాయి.
Боఎక్కువ విశ్వసనీయత...
వాస్తవానికి ఒక మైక్రోసర్వీస్ యొక్క వైఫల్యం మొత్తం సిస్టమ్ యొక్క సరైన పనితీరును తరచుగా విచ్ఛిన్నం చేయడమే కాకుండా, కొత్త సమస్య కూడా ఉంది: ప్రతి మైక్రోసర్వీస్ లోపాలను తట్టుకునేలా చేయడం చాలా కష్టం. మైక్రోసర్వీస్‌లు వేర్వేరు సాంకేతికతలను (మెమ్‌కాష్, రెడిస్, మొదలైనవి) ఉపయోగిస్తున్నందున, ప్రతిదానికీ మీరు ప్రతిదాని గురించి ఆలోచించి, దానిని అమలు చేయాలి, ఇది సాధ్యమే, కానీ భారీ వనరులు అవసరం.
లోడ్ మెజర్బిలిటీ...
ఇది నిజంగా బాగుంది.
మైక్రో సర్వీసెస్ యొక్క "తేలిక"...
మాకు భారీ మాత్రమే కాదు నెట్‌వర్క్ ఓవర్‌హెడ్ (DNS కోసం అభ్యర్థనలు గుణించడం మొదలైనవి), కానీ మేము ప్రారంభించిన అనేక సబ్‌క్వెరీల కారణంగా కూడా డేటా ప్రతిరూపం (స్టోర్ కాష్‌లు), ఇది గణనీయమైన నిల్వకు దారితీసింది.
మరియు మా అంచనాలను అందుకోవడం యొక్క ఫలితం ఇక్కడ ఉంది:
అయితే అంతే కాదు!
ఎందుకంటే:
- చాలా మటుకు మనకు మెసేజ్ బస్సు అవసరం కావచ్చు.
- సరైన సమయంలో స్థిరమైన బ్యాకప్‌ను ఎలా తయారు చేయాలి? ఒకే ఒక реальный దీని కోసం ట్రాఫిక్‌ను ఆఫ్ చేయడం ఎంపిక. కానీ ఉత్పత్తిలో దీన్ని ఎలా చేయాలి?
- మేము అనేక ప్రాంతాలకు మద్దతు ఇవ్వడం గురించి మాట్లాడుతుంటే, వాటిలో ప్రతిదానిలో స్థిరత్వాన్ని నిర్వహించడం చాలా శ్రమతో కూడుకున్న పని.
- కేంద్రీకృత మార్పులు చేయడంలో సమస్య తలెత్తుతుంది. ఉదాహరణకు, మేము PHP సంస్కరణను నవీకరించవలసి వస్తే, మేము ప్రతి రిపోజిటరీకి కట్టుబడి ఉండాలి (మరియు వాటిలో డజన్ల కొద్దీ ఉన్నాయి).
- కార్యాచరణ సంక్లిష్టతలో పెరుగుదల ఆఫ్‌హ్యాండ్, ఎక్స్‌పోనెన్షియల్.
వీటన్నింటితో ఏమి చేయాలి?
ఏకశిలా అప్లికేషన్‌తో ప్రారంభించండి. ఫౌలర్ అనుభవం దాదాపు అన్ని విజయవంతమైన మైక్రోసర్వీస్ అప్లికేషన్‌లు ఏకశిలాగా ప్రారంభమయ్యాయి, అది చాలా పెద్దదిగా మారింది మరియు ఆ తర్వాత విరిగిపోయింది. అదే సమయంలో, మైక్రోసర్వీస్‌గా నిర్మించబడిన దాదాపు అన్ని సిస్టమ్‌లు ప్రారంభం నుండి ముందుగానే లేదా తరువాత తీవ్రమైన సమస్యలను ఎదుర్కొన్నాయి.
మరొక విలువైన ఆలోచన ఏమిటంటే, మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌తో ప్రాజెక్ట్ విజయవంతం కావాలంటే, మీరు బాగా తెలుసుకోవాలి మరియు సబ్జెక్ట్ ఏరియా మరియు మైక్రోసర్వీస్‌లను ఎలా తయారు చేయాలి. మరియు సబ్జెక్ట్ ఏరియాను నేర్చుకోవడానికి ఉత్తమ మార్గం ఏకశిలాను తయారు చేయడం.
అయితే మనం ఇప్పటికే ఈ పరిస్థితిలో ఉంటే?
ఏదైనా సమస్యను పరిష్కరించడానికి మొదటి అడుగు దానితో ఏకీభవించడం మరియు అది ఒక సమస్య అని అర్థం చేసుకోవడం, మనం ఇక బాధపడకూడదనుకోవడం.
ఒకవేళ, పెరిగిన ఏకశిలా విషయంలో (దాని కోసం అదనపు వనరులను కొనుగోలు చేసే అవకాశం లేనప్పుడు), మేము దానిని కత్తిరించినట్లయితే, ఈ సందర్భంలో వ్యతిరేక కథ మారుతుంది: అధిక మైక్రోసర్వీస్‌లు ఇకపై సహాయం చేయనప్పుడు, కానీ అడ్డుపడినప్పుడు - అదనపు కత్తిరించండి మరియు విస్తరించండి!
ఉదాహరణకు, పైన చర్చించిన సామూహిక చిత్రం కోసం...
అత్యంత సందేహాస్పద మైక్రోసర్వీస్‌లను వదిలించుకోండి:
ఫ్రంటెండ్ ఉత్పత్తికి బాధ్యత వహించే అన్ని మైక్రోసర్వీస్‌లను కలపండి:
... ఒక మైక్రోసర్వీస్‌లోకి, ఒకటి (ఆధునిక మరియు సాధారణ, మీరే అనుకున్నట్లుగా) భాష/ఫ్రేమ్‌వర్క్‌లో వ్రాయబడింది:
ఇది ఒక ORM (ఒక DBMS) మరియు ముందుగా రెండు అప్లికేషన్‌లను కలిగి ఉంటుంది:
... కానీ సాధారణంగా మీరు ఈ క్రింది ఫలితాన్ని పొందుతూ చాలా ఎక్కువ అక్కడకు బదిలీ చేయవచ్చు:
అంతేకాకుండా, కుబెర్నెటెస్‌లో మనం ఇవన్నీ వేర్వేరు సందర్భాల్లో అమలు చేస్తాము, అంటే మనం ఇప్పటికీ లోడ్‌ను కొలవవచ్చు మరియు వాటిని విడిగా స్కేల్ చేయవచ్చు.
సంగ్రహించడం
పెద్ద చిత్రాన్ని చూడండి. చాలా తరచుగా, మైక్రోసర్వీస్‌తో ఈ సమస్యలన్నీ తలెత్తుతాయి ఎందుకంటే ఎవరైనా తమ పనిని తీసుకున్నారు, కానీ “మైక్రోసర్వీస్‌తో ఆడాలని” కోరుకున్నారు.
"మైక్రోసర్వీసెస్" అనే పదంలో "మైక్రో" భాగం అనవసరంగా ఉంటుంది.. అవి భారీ ఏకశిలా కంటే చిన్నవిగా ఉన్నందున అవి "మైక్రో" మాత్రమే. కానీ వాటిని చిన్నవిగా భావించవద్దు.
మరియు తుది ఆలోచన కోసం, అసలు చార్ట్‌కి తిరిగి వెళ్దాం:
దాని మీద వ్రాసిన నోట్ (ఎగువ కుడి) అని దిమ్మతిరిగిపోతుంది మీ ప్రాజెక్ట్‌ను రూపొందించే బృందం యొక్క నైపుణ్యాలు ఎల్లప్పుడూ ప్రాథమికంగా ఉంటాయి — మైక్రోసర్వీస్ మరియు మోనోలిత్ మధ్య మీ ఎంపికలో అవి కీలక పాత్ర పోషిస్తాయి. జట్టుకు తగినంత నైపుణ్యాలు లేకపోయినా, మైక్రోసర్వీస్‌ను తయారు చేయడం ప్రారంభిస్తే, కథ ఖచ్చితంగా ప్రాణాంతకం అవుతుంది.
వీడియోలు మరియు స్లయిడ్‌లు
ప్రసంగం నుండి వీడియో (~50 నిమిషాలు; దురదృష్టవశాత్తు, ఇది సందర్శకుల యొక్క అనేక భావోద్వేగాలను తెలియజేయదు, ఇది నివేదిక యొక్క మానసిక స్థితిని ఎక్కువగా నిర్ణయించింది, కానీ అది ఎలా ఉంది):
నివేదిక ప్రదర్శన:
PS
మా బ్లాగ్‌లోని ఇతర నివేదికలు:
- «» (డిమిత్రి స్టోలియారోవ్; మే 28, 2018 రూట్‌కాన్ఫ్‌లో);
- «» (డిమిత్రి స్టోలియారోవ్; నవంబర్ 7, 2017 హైలోడ్++లో);
- «» (డిమిత్రి స్టోలియారోవ్; జూన్ 6, 2017 రూట్‌కాన్ఫ్‌లో);
- «» (డిమిత్రి స్టోలియారోవ్; నవంబర్ 8, 2016 హైలోడ్++లో);
- «» (డిమిత్రి స్టోలియారోవ్; మే 31, 2016 రూట్‌కాన్ఫ్‌లో).
మీరు ఈ క్రింది ప్రచురణలపై కూడా ఆసక్తి కలిగి ఉండవచ్చు:
- «";
- «";
- «".
మూలం: www.habr.com