మైక్రోసర్వీస్ ఆర్కిటెక్చర్ అనే అంశంపై నేను చాలా కాలంగా ఒక వ్యాసం రాయాలనుకున్నాను, కానీ రెండు విషయాలు నన్ను ఆపివేస్తూనే ఉన్నాయి - నేను టాపిక్‌లోకి ఎంతగా మునిగిపోయానో, నాకు తెలిసినది స్పష్టంగా ఉంది మరియు నేను ఏమి చేయను అని నాకు అనిపించింది. t తెలుసు అధ్యయనం మరియు అధ్యయనం అవసరం. మరోవైపు, విస్తృత ప్రేక్షకుల మధ్య చర్చించడానికి ఇప్పటికే ఏదో ఉందని నేను భావిస్తున్నాను. కాబట్టి ప్రత్యామ్నాయ అభిప్రాయాలకు స్వాగతం.
కాన్వే యొక్క చట్టం మరియు వ్యాపారం, సంస్థ మరియు సమాచార వ్యవస్థ మధ్య సంబంధం
మరోసారి నేను కోట్ చేయడానికి అనుమతిస్తాను:
"ఒక వ్యవస్థను రూపొందించే ఏదైనా సంస్థ (విస్తృత కోణంలో) ఆ సంస్థలోని జట్ల నిర్మాణాన్ని ప్రతిబింబించే డిజైన్‌ను అందుకుంటుంది."
- మెల్విన్ కాన్వే, 1967
నా అభిప్రాయం ప్రకారం, ఈ చట్టం నేరుగా సమాచార వ్యవస్థకు కాకుండా వ్యాపారాన్ని నిర్వహించే సాధ్యాసాధ్యాలకు సంబంధించినది. ఒక ఉదాహరణతో వివరిస్తాను. ఎంటర్‌ప్రైజ్‌ను నిర్వహించడం అర్ధమయ్యే జీవిత చక్రంతో మాకు చాలా స్థిరమైన వ్యాపార అవకాశం ఉందని చెప్పండి (ఇది అక్షర దోషం కాదు, కానీ నేను దొంగిలించిన ఈ పదాన్ని నేను నిజంగా ఇష్టపడుతున్నాను). సహజంగానే, ఈ వ్యాపారం యొక్క మద్దతు వ్యవస్థ సంస్థాగతంగా మరియు ప్రక్రియలో ఈ వ్యాపారానికి అనుగుణంగా ఉంటుంది.
సమాచార వ్యవస్థల వ్యాపార ధోరణి
ఒక ఉదాహరణతో వివరిస్తాను. పిజ్జా విక్రయించే వ్యాపారాన్ని నిర్వహించడానికి వ్యాపార అవకాశం ఉందని చెప్పండి. V1 వెర్షన్‌లో (దీన్ని ప్రీ-ఇన్ఫర్మేషన్ అని పిలుద్దాం), కంపెనీ పిజ్జేరియా, నగదు రిజిస్టర్ మరియు డెలివరీ సేవ. తక్కువ పర్యావరణ వైవిధ్యం ఉన్న పరిస్థితులలో ఈ సంస్కరణ దీర్ఘకాలం జీవించింది. అప్పుడు వెర్షన్ 2 దాని స్థానంలో వచ్చింది - మరింత అధునాతనమైనది మరియు ఏకశిలా నిర్మాణంతో వ్యాపారం కోసం సమాచార వ్యవస్థను ఉపయోగించగలదు. మరియు ఇక్కడ, నా అభిప్రాయం ప్రకారం, ఏకశిలాలకు సంబంధించి భయంకరమైన అన్యాయం ఉంది - మోనోలిథిక్ ఆర్కిటెక్చర్ డొమైన్ వ్యాపార నమూనాకు అనుగుణంగా లేదని ఆరోపించారు. అవును, ఇది అలా జరిగితే, సిస్టమ్ అస్సలు పని చేయదు - అదే కాన్వే చట్టం మరియు ఇంగితజ్ఞానానికి విరుద్ధంగా. లేదు, ఏకశిలా నిర్మాణం వ్యాపార అభివృద్ధి యొక్క ఈ దశలో వ్యాపార నమూనాతో పూర్తిగా స్థిరంగా ఉంటుంది - నేను, వాస్తవానికి, సిస్టమ్ ఇప్పటికే సృష్టించబడిన మరియు ఆపరేషన్‌లో ఉంచబడిన దశ అని అర్థం. ఆర్కిటెక్చరల్ విధానంతో సంబంధం లేకుండా, సర్వీస్-ఓరియెంటెడ్ ఆర్కిటెక్చర్ వెర్షన్ 3 మరియు మైక్రోసర్వీసెస్ ఆర్కిటెక్చర్ వెర్షన్ N రెండూ సమానంగా పనిచేస్తాయనేది ఖచ్చితంగా అద్భుతమైన వాస్తవం. క్యాచ్ ఏమిటి?
ప్రతిదీ ప్రవహిస్తుంది, ప్రతిదీ మారుతుంది, లేదా మైక్రోసర్వీస్ సంక్లిష్టతను ఎదుర్కోవడానికి ఒక సాధనమా?
మేము కొనసాగించే ముందు, మైక్రోసర్వీస్ ఆర్కిటెక్చర్ గురించి కొన్ని అపోహలను చూద్దాం.
మైక్రోసర్వీస్ విధానాన్ని ఉపయోగించే ప్రతిపాదకులు తరచుగా ఏకశిలాను మైక్రోసర్వీస్‌లుగా విభజించడం వ్యక్తిగత సేవల కోడ్ బేస్‌ను తగ్గించడం ద్వారా అభివృద్ధి విధానాన్ని సులభతరం చేస్తుందని వాదించారు. నా అభిప్రాయం ప్రకారం, ఈ ప్రకటన పూర్తి అర్ధంలేనిది. గంభీరంగా, ఏకశిలా మరియు సజాతీయ కోడ్‌లోని స్పష్టమైన పరస్పర చర్య సంక్లిష్టంగా ఉన్నట్లు అనిపిస్తుందా? ఇది నిజంగా జరిగితే, అన్ని ప్రాజెక్ట్‌లు ప్రారంభంలో మైక్రోసర్వీస్‌గా నిర్మించబడతాయి, అయితే ప్రాక్టీస్ ఏకశిలా నుండి మైక్రోసర్వీస్‌లకు వలసలు చాలా సాధారణం అని చూపిస్తుంది. సంక్లిష్టత అదృశ్యం కాదు; ఇది కేవలం వ్యక్తిగత మాడ్యూల్స్ నుండి ఇంటర్‌ఫేస్‌లకు (డేటా బస్సులు, RPC, APIలు మరియు ఇతర ప్రోటోకాల్‌లు కావచ్చు) మరియు ఆర్కెస్ట్రేటింగ్ సిస్టమ్‌లకు కదులుతుంది. మరియు ఇది కష్టం!
వైవిధ్యమైన స్టాక్‌ను ఉపయోగించడం వల్ల కలిగే ప్రయోజనం కూడా సందేహాస్పదంగా ఉంది. ఇది కూడా సాధ్యమేనని నేను వాదించను, కానీ వాస్తవానికి ఇది చాలా అరుదుగా జరుగుతుంది (ముందుగా చూస్తే - ఇది జరగాలి - కానీ ప్రయోజనం కంటే పర్యవసానంగా).
ఉత్పత్తి జీవిత చక్రం మరియు సేవా జీవిత చక్రం
పైన ఉన్న రేఖాచిత్రాన్ని మరొకసారి చూడండి. వ్యాపారం యొక్క ప్రత్యేక సంస్కరణ యొక్క జీవిత చక్రం తగ్గుతున్నట్లు నేను గుర్తించడం యాదృచ్చికం కాదు - ఆధునిక పరిస్థితులలో, సంస్కరణల మధ్య వ్యాపారాన్ని మార్చడం యొక్క త్వరణం దాని విజయానికి నిర్ణయాత్మకమైనది. ఒక ఉత్పత్తి యొక్క విజయం దానిలోని వ్యాపార పరికల్పనలను పరీక్షించే వేగం ద్వారా నిర్ణయించబడుతుంది. మరియు ఇక్కడ, నా అభిప్రాయం ప్రకారం, మైక్రోసర్వీస్ ఆర్కిటెక్చర్ యొక్క ముఖ్య ప్రయోజనం ఉంది. కానీ క్రమంలో వెళ్దాం.
సమాచార వ్యవస్థల పరిణామంలో తదుపరి దశకు వెళ్దాం - SOA యొక్క సేవా-ఆధారిత నిర్మాణానికి. కాబట్టి, కొన్ని నిర్దిష్ట సమయంలో మేము మా ఉత్పత్తిలో హైలైట్ చేసాము దీర్ఘకాల సేవలు - ఉత్పత్తి యొక్క సంస్కరణల మధ్య కదులుతున్నప్పుడు, సేవ యొక్క జీవిత చక్రం ఉత్పత్తి యొక్క తదుపరి సంస్కరణ యొక్క జీవిత చక్రం కంటే ఎక్కువ కాలం ఉండే అవకాశం ఉంది. వాటిని అస్సలు మార్చకపోవడం తార్కికంగా ఉంటుంది - మేము ముఖ్యమైనది తదుపరి సంస్కరణకు మారే వేగం. కానీ అయ్యో, మేము సేవలకు నిరంతరం మార్పులు చేయవలసి వస్తుంది - మరియు ఇక్కడ ప్రతిదీ మాకు పని చేస్తుంది, DevOps అభ్యాసాలు, కంటైనర్‌లీకరణ మరియు మొదలైనవి - గుర్తుకు వచ్చే ప్రతిదీ. అయితే ఇవి ఇప్పటికీ మైక్రోసర్వీస్ కావు!
సంక్లిష్టతను ఎదుర్కోవడానికి మైక్రోసర్వీస్‌లు... కాన్ఫిగరేషన్ నిర్వహణ
మరియు ఇక్కడ మనం చివరకు మైక్రోసర్వీస్ యొక్క నిర్వచించే పాత్రకు వెళ్లవచ్చు - ఇది ఉత్పత్తి కాన్ఫిగరేషన్ నిర్వహణను సులభతరం చేసే విధానం. మరింత వివరంగా, ప్రతి మైక్రోసర్వీస్ యొక్క ఫంక్షన్ డొమైన్ మోడల్ ప్రకారం ఉత్పత్తి లోపల వ్యాపార పనితీరును ఖచ్చితంగా వివరిస్తుంది - మరియు ఇవి స్వల్పకాలిక సంస్కరణలో కాకుండా దీర్ఘకాల వ్యాపార అవకాశంలో జీవించే విషయాలు. మరియు ఉత్పత్తి యొక్క తదుపరి సంస్కరణకు మారడం అక్షరాలా గుర్తించబడదు - మీరు ఒక మైక్రోసర్వీస్‌ను మార్చడం/జోడించడం, మరియు బహుశా వారి పరస్పర చర్య యొక్క స్కీమ్‌ను మార్చడం మరియు అకస్మాత్తుగా మీరు భవిష్యత్తులో మిమ్మల్ని మీరు కనుగొంటారు, దీని సంస్కరణల మధ్య దూకడం కొనసాగించే ఏడుపు పోటీదారులను వదిలివేస్తారు. వారి ఏకశిలాలు. ముందే నిర్వచించబడిన ఇంటర్‌ఫేస్‌లు మరియు వ్యాపార సామర్థ్యాలతో చాలా పెద్ద పరిమాణంలో మైక్రోసర్వీస్‌లు ఉన్నాయని ఇప్పుడు ఊహించండి. మరియు మీరు వచ్చి రెడీమేడ్ మైక్రోసర్వీస్‌ల నుండి మీ ఉత్పత్తి యొక్క నిర్మాణాన్ని నిర్మించండి - ఉదాహరణకు ఒక రేఖాచిత్రాన్ని గీయడం ద్వారా. అభినందనలు - మీకు ప్లాట్‌ఫారమ్ ఉంది - మరియు ఇప్పుడు మీరు మీ కోసం వ్యాపారాన్ని ఆకర్షించవచ్చు. డ్రీమ్స్ డ్రీమ్స్.
కనుగొన్న
- వ్యవస్థ యొక్క నిర్మాణం దాని భాగాల జీవిత చక్రం ద్వారా నిర్ణయించబడాలి. ఒక భాగం ఉత్పత్తి సంస్కరణలో నివసిస్తుంటే, మైక్రోసర్వీస్ విధానాన్ని ఉపయోగించడం ద్వారా సిస్టమ్ సంక్లిష్టతను పెంచడంలో అర్థం లేదు.
- మైక్రోసర్వీస్ ఆర్కిటెక్చర్ డొమైన్ మోడల్‌పై ఆధారపడి ఉండాలి - ఎందుకంటే వ్యాపార అవకాశం ఎక్కువ కాలం జీవించే డొమైన్
- డెలివరీ పద్ధతులు (DevOps పద్ధతులు) మరియు ఆర్కెస్ట్రేషన్ మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌కు అత్యంత ముఖ్యమైన వాటిలో ఒకటి - కాంపోనెంట్‌ల మార్పు రేటు పెరుగుదల కారణంగా డెలివరీ వేగం మరియు నాణ్యతపై డిమాండ్ పెరిగింది.
మూలం: www.habr.com