హలో, హబ్ర్. ఈ రోజు నేను కోర్సు యొక్క కొత్త స్ట్రీమ్ ప్రారంభం కోసం ప్రత్యేకంగా వ్రాసిన ప్రచురణల శ్రేణిని కొనసాగిస్తున్నాను. .
పరిచయం
సమాచార వ్యవస్థను నిర్మించేటప్పుడు నిర్మాణ శైలి యొక్క ఎంపిక ప్రాథమిక సాంకేతిక నిర్ణయాలలో ఒకటి. ఈ కథనాల శ్రేణిలో, అప్లికేషన్‌లను రూపొందించడానికి అత్యంత ప్రాచుర్యం పొందిన నిర్మాణ శైలులను విశ్లేషించాలని నేను ప్రతిపాదిస్తున్నాను మరియు ఏ నిర్మాణ శైలి అత్యంత ప్రాధాన్యతనిస్తుంది అనే ప్రశ్నకు సమాధానం ఇవ్వండి. ప్రదర్శన ప్రక్రియలో, నేను ఏకశిలాల నుండి మైక్రోసర్వీస్‌ల వరకు నిర్మాణ శైలుల అభివృద్ధిని వివరించే తార్కిక గొలుసును గీయడానికి ప్రయత్నిస్తాను.
В మేము ఏకశిలాతో వ్యవహరించాము మరియు ఏకశిలాకు అనేక సమస్యలు ఉన్నాయని నిర్ధారణకు వచ్చాము: పరిమాణం, కనెక్టివిటీ, విస్తరణ, స్కేలబిలిటీ, విశ్వసనీయత మరియు దృఢత్వం.
ఈసారి మాడ్యూల్స్/లైబ్రరీల (కాంపోనెంట్-ఓరియెంటెడ్ ఆర్కిటెక్చర్) లేదా సర్వీసెస్ (సర్వీస్-ఓరియెంటెడ్ ఆర్కిటెక్చర్) సెట్‌గా సిస్టమ్‌ను ఆర్గనైజ్ చేసే అవకాశాల గురించి మాట్లాడాలని నేను ప్రతిపాదిస్తున్నాను.
కాంపోనెంట్-ఓరియెంటెడ్ ఆర్కిటెక్చర్
కాంపోనెంట్-ఓరియెంటెడ్ ఆర్కిటెక్చర్ అనేది సిస్టమ్‌ను ప్రస్తుత మరియు భవిష్యత్తు ప్రాజెక్ట్‌లలో ఉపయోగించగల భాగాల సమితిగా అమలు చేయడం. సిస్టమ్‌ను భాగాలుగా విభజించేటప్పుడు, కింది వాటిని పరిగణనలోకి తీసుకుంటారు: వాటి పునర్వినియోగం, వాటి భర్తీ, సందర్భ స్వాతంత్ర్యం, విస్తరణ, ఎన్‌క్యాప్సులేషన్ మరియు స్వాతంత్ర్యం.
భాగాల సరైన ఉపయోగంతో, “పెద్ద బాల్ ఆఫ్ డర్ట్” (పెద్ద పరిమాణం + అధిక కలపడం) సమస్య పరిష్కరించబడుతుంది మరియు భాగాలు అసెంబ్లీ యూనిట్లు (మాడ్యూల్స్, లైబ్రరీలు) మరియు విస్తరణ యూనిట్లు (సేవలు) రెండూ కావచ్చు. అమలు చేసే ప్రక్రియకు విస్తరణ యూనిట్లు ఎల్లప్పుడూ మ్యాప్ చేయబడవు: ఉదాహరణకు, వెబ్ అప్లికేషన్ మరియు డేటాబేస్ కలిసి అమర్చబడి ఉంటాయి.
చాలా తరచుగా, ఏకశిలాలు మాడ్యూల్స్ సమితిగా అభివృద్ధి చేయబడ్డాయి. ఈ విధానం స్వతంత్ర అభివృద్ధికి దారి తీస్తుంది, అయితే స్వతంత్ర స్కేలింగ్ మరియు విస్తరణ, తప్పు సహనం మరియు మొత్తం సాంకేతిక స్టాక్ నుండి స్వతంత్రత వంటి సమస్యలు అలాగే ఉన్నాయి. అందుకే మాడ్యూల్ పాక్షికంగా స్వతంత్ర భాగం.
అటువంటి ఏకశిలాతో అతిపెద్ద సమస్య ఏమిటంటే, మాడ్యూల్స్‌గా విభజించడం పూర్తిగా తార్కికం మరియు డెవలపర్‌లచే సులభంగా ఉల్లంఘించబడవచ్చు. ఒక కోర్ మాడ్యూల్ కనిపించవచ్చు, ఇది క్రమంగా చెత్త డంప్‌గా మారుతుంది, మాడ్యూళ్ల మధ్య డిపెండెన్సీల గ్రాఫ్ పెరగవచ్చు మరియు మొదలైనవి. అటువంటి సమస్యలను నివారించడానికి, అభివృద్ధిని చాలా పరిణతి చెందిన బృందం లేదా పూర్తి-సమయం కోడ్ సమీక్షలో నిమగ్నమై ఉన్న మరియు తార్కిక నిర్మాణాన్ని ఉల్లంఘించే డెవలపర్ల చేతులను కొట్టే "ఆర్కిటెక్ట్" మార్గదర్శకత్వంలో నిర్వహించబడాలి.
"ఆదర్శ" ఏకశిలా అనేది తార్కికంగా వేరు చేయబడిన మాడ్యూల్స్ యొక్క సమితి, వీటిలో ప్రతి ఒక్కటి దాని స్వంత డేటాబేస్లోకి చూస్తుంది.
సేవా ఆధారిత నిర్మాణం
సిస్టమ్ సేవల సమితి రూపంలో నిర్వహించబడాలని భావించినట్లయితే, మేము సేవా-ఆధారిత నిర్మాణం గురించి మాట్లాడుతున్నాము. దీని సూత్రాలు వినియోగదారు-కేంద్రీకృత అప్లికేషన్ ఇంటర్‌పెరాబిలిటీ, బిజినెస్ సర్వీస్ రీయూజ్, టెక్నాలజీ స్టాక్ స్వాతంత్ర్యం మరియు స్వయంప్రతిపత్తి (స్వతంత్ర పరిణామం, స్కేలబిలిటీ మరియు విస్తరణ).
సర్వీస్-ఓరియెంటెడ్ ఆర్కిటెక్చర్ (SOA = సర్వీస్ ఓరియెంటెడ్ ఆర్కిటెక్చర్) ఏకశిలా యొక్క అన్ని గుర్తించబడిన సమస్యలను పరిష్కరిస్తుంది: మార్పు సంభవించినప్పుడు ఒక సేవ మాత్రమే ప్రభావితమవుతుంది మరియు బాగా నిర్వచించబడిన API భాగాలు మంచి ఎన్‌క్యాప్సులేషన్‌కు మద్దతు ఇస్తుంది.
కానీ ప్రతిదీ చాలా మృదువైనది కాదు: SOA కొత్త సమస్యలను సృష్టిస్తుంది. రిమోట్ కాల్‌లు స్థానిక వాటి కంటే ఖరీదైనవి మరియు భాగాల మధ్య బాధ్యతలను పునఃపంపిణీ చేయడం చాలా ఖరీదైనదిగా మారింది.
మార్గం ద్వారా, స్వతంత్ర విస్తరణ అవకాశం సేవ యొక్క చాలా ముఖ్యమైన లక్షణం. సేవలను తప్పనిసరిగా కలిసి అమలు చేయాలి లేదా, ఒక నిర్దిష్ట క్రమంలో ఉంటే, అప్పుడు సిస్టమ్ సేవ-ఆధారితంగా పరిగణించబడదు. ఈ సందర్భంలో, వారు పంపిణీ చేయబడిన ఏకశిలా గురించి మాట్లాడతారు (SOA యొక్క కోణం నుండి మాత్రమే కాకుండా, మైక్రోసర్వీస్ ఆర్కిటెక్చర్ కోణం నుండి కూడా వ్యతిరేక నమూనాగా పరిగణించబడుతుంది).
సేవా-ఆధారిత నిర్మాణానికి నిర్మాణ సంఘం మరియు విక్రేతల నుండి మంచి మద్దతు ఉంది. ఇది అనేక కోర్సులు మరియు ధృవపత్రాలు, బాగా అభివృద్ధి చెందిన నమూనాల ఉనికిని సూచిస్తుంది. రెండోది, ఉదాహరణకు, బాగా తెలిసిన ఎంటర్‌ప్రైజ్ సర్వీస్ బస్సు (ESB = ఎంటర్‌ప్రైజ్ సర్వీస్ బస్సు)ని కలిగి ఉంటుంది. అదే సమయంలో, ESB అనేది విక్రేతల నుండి వచ్చిన సామాను తప్పనిసరిగా SOAలో ఉపయోగించాల్సిన అవసరం లేదు.
సేవా-ఆధారిత నిర్మాణం యొక్క ప్రజాదరణ 2008లో గరిష్ట స్థాయికి చేరుకుంది, ఆ తర్వాత అది క్షీణించడం ప్రారంభించింది, మైక్రోసర్వీసెస్ (~2015) వచ్చిన తర్వాత ఇది మరింత నాటకీయంగా మారింది.
తీర్మానం
సేవలు మరియు మాడ్యూల్స్ రూపంలో సమాచార వ్యవస్థలను నిర్వహించే అవకాశాలను మేము చర్చించిన తర్వాత, నేను చివరకు మైక్రోసర్వీస్ ఆర్కిటెక్చర్ సూత్రాలకు వెళ్లాలని ప్రతిపాదిస్తున్నాను మరియు తదుపరి భాగంలో మైక్రోసర్వీస్ ఆర్కిటెక్చర్ మరియు సర్వీస్-ఓరియెంటెడ్ ఆర్కిటెక్చర్ మధ్య వ్యత్యాసంపై ప్రత్యేక శ్రద్ధ చూపుతాను.
మూలం: www.habr.com