ఈ కథనంలో, నేను పని చేస్తున్న ప్రాజెక్ట్ పెద్ద ఏకశిలా నుండి మైక్రోసర్వీస్ల సెట్గా ఎలా రూపాంతరం చెందిందనే దాని గురించి మాట్లాడుతాను.
ప్రాజెక్ట్ దాని చరిత్రను చాలా కాలం క్రితం, 2000 ప్రారంభంలో ప్రారంభించింది. మొదటి సంస్కరణలు విజువల్ బేసిక్ 6లో వ్రాయబడ్డాయి. కాలక్రమేణా, IDE నుండి భవిష్యత్తులో ఈ భాషలో అభివృద్ధికి మద్దతు ఇవ్వడం కష్టమని స్పష్టమైంది. మరియు భాష కూడా పేలవంగా అభివృద్ధి చెందింది. 2000ల చివరలో, మరింత ఆశాజనకంగా ఉన్న C#కి మారాలని నిర్ణయించారు. కొత్త సంస్కరణ పాత సంస్కరణకు సమాంతరంగా వ్రాయబడింది, క్రమంగా మరింత ఎక్కువ కోడ్ .NETలో వ్రాయబడింది. C#లోని బ్యాకెండ్ మొదట్లో సర్వీస్ ఆర్కిటెక్చర్పై దృష్టి పెట్టింది, అయితే అభివృద్ధి సమయంలో, లాజిక్తో కూడిన సాధారణ లైబ్రరీలు ఉపయోగించబడ్డాయి మరియు సేవలు ఒకే ప్రక్రియలో ప్రారంభించబడ్డాయి. ఫలితంగా మేము "సర్వీస్ మోనోలిత్" అని పిలిచే ఒక అప్లికేషన్.
ఈ కలయిక యొక్క కొన్ని ప్రయోజనాల్లో ఒకటి బాహ్య API ద్వారా ఒకదానికొకటి కాల్ చేసుకునే సేవల సామర్థ్యం. మరింత సరైన సేవకు మరియు భవిష్యత్తులో మైక్రోసర్వీస్ ఆర్కిటెక్చర్కి మారడానికి స్పష్టమైన అవసరాలు ఉన్నాయి.
మేము 2015లో కుళ్ళిపోయే పనిని ప్రారంభించాము. మేము ఇంకా ఆదర్శ స్థితికి చేరుకోలేదు - పెద్ద ప్రాజెక్ట్ యొక్క భాగాలు ఇప్పటికీ మోనోలిత్లు అని పిలవబడవు, కానీ అవి మైక్రోసర్వీస్ల వలె కనిపించవు. అయినప్పటికీ, పురోగతి ముఖ్యమైనది.
నేను దాని గురించి వ్యాసంలో మాట్లాడుతాను.
కంటెంట్
ఆర్కిటెక్చర్ మరియు ఇప్పటికే ఉన్న పరిష్కారం యొక్క సమస్యలు
ప్రారంభంలో, ఆర్కిటెక్చర్ ఇలా కనిపించింది: UI అనేది ఒక ప్రత్యేక అప్లికేషన్, ఏకశిలా భాగం విజువల్ బేసిక్ 6లో వ్రాయబడింది, .NET అప్లికేషన్ అనేది చాలా పెద్ద డేటాబేస్తో పనిచేసే సంబంధిత సేవల సమితి.
మునుపటి పరిష్కారం యొక్క ప్రతికూలతలు
వైఫల్యం యొక్క ఒకే పాయింట్
మేము ఒక వైఫల్యాన్ని కలిగి ఉన్నాము: .NET అప్లికేషన్ ఒకే ప్రక్రియలో అమలు చేయబడింది. ఏదైనా మాడ్యూల్ విఫలమైతే, మొత్తం అప్లికేషన్ విఫలమైంది మరియు పునఃప్రారంభించవలసి ఉంటుంది. మేము వేర్వేరు వినియోగదారుల కోసం పెద్ద సంఖ్యలో ప్రాసెస్లను ఆటోమేట్ చేస్తున్నందున, వాటిలో ఒకదానిలో వైఫల్యం కారణంగా, ప్రతి ఒక్కరూ కొంత సమయం వరకు పని చేయలేరు. మరియు సాఫ్ట్వేర్ లోపం విషయంలో, బ్యాకప్ కూడా సహాయం చేయలేదు.
మెరుగుదలల వరుస
ఈ లోపం సంస్థాగతమైనది. మా అప్లికేషన్ చాలా మంది కస్టమర్లను కలిగి ఉంది మరియు వారందరూ వీలైనంత త్వరగా దాన్ని మెరుగుపరచాలనుకుంటున్నారు. గతంలో, దీన్ని సమాంతరంగా చేయడం అసాధ్యం, మరియు వినియోగదారులందరూ వరుసలో నిలబడ్డారు. ఈ ప్రక్రియ వ్యాపారాలకు ప్రతికూలంగా ఉంది ఎందుకంటే వారు తమ పని విలువైనదని నిరూపించుకోవాల్సి వచ్చింది. మరియు అభివృద్ధి బృందం ఈ క్యూను నిర్వహించడానికి సమయాన్ని వెచ్చించింది. దీనికి చాలా సమయం మరియు కృషి పట్టింది మరియు ఉత్పత్తి చివరికి వారు కోరుకున్నంత త్వరగా మారదు.
వనరుల ఉపయోగం
ఒకే ప్రక్రియలో సేవలను హోస్ట్ చేస్తున్నప్పుడు, మేము ఎల్లప్పుడూ సర్వర్ నుండి సర్వర్కు కాన్ఫిగరేషన్ను పూర్తిగా కాపీ చేస్తాము. వనరులను వృథా చేయకుండా మరియు మా విస్తరణ పథకంపై మరింత సౌకర్యవంతమైన నియంత్రణను పొందేందుకు మేము అత్యంత భారీగా లోడ్ చేయబడిన సేవలను విడిగా ఉంచాలనుకుంటున్నాము.
ఆధునిక సాంకేతికతలను అమలు చేయడం కష్టం
డెవలపర్లందరికీ తెలిసిన సమస్య: ప్రాజెక్ట్లో ఆధునిక సాంకేతిక పరిజ్ఞానాన్ని పరిచయం చేయాలనే కోరిక ఉంది, కానీ అవకాశం లేదు. ఒక పెద్ద ఏకశిలా పరిష్కారంతో, ప్రస్తుత లైబ్రరీ యొక్క ఏదైనా నవీకరణ, కొత్తదానికి పరివర్తన గురించి చెప్పనవసరం లేదు, ఇది చిన్నవిషయం కాని పనిగా మారుతుంది. ఇది వృధా నరాల కంటే ఎక్కువ బోనస్లను తెస్తుందని జట్టు నాయకుడికి నిరూపించడానికి చాలా సమయం పడుతుంది.
మార్పులను జారీ చేయడంలో ఇబ్బంది
ఇది అత్యంత తీవ్రమైన సమస్య - మేము ప్రతి రెండు నెలలకు ఒకసారి విడుదలలను విడుదల చేస్తున్నాము.
డెవలపర్ల పరీక్షలు మరియు ప్రయత్నాలు ఉన్నప్పటికీ, ప్రతి విడుదల బ్యాంక్కు నిజమైన విపత్తుగా మారింది. వారం ప్రారంభంలో దాని కార్యాచరణలో కొంత భాగం పని చేయదని వ్యాపారం అర్థం చేసుకుంది. మరియు డెవలపర్లు ఒక వారం తీవ్రమైన సంఘటనలు తమ కోసం ఎదురుచూస్తున్నారని అర్థం చేసుకున్నారు.
పరిస్థితిని మార్చాలనే కోరిక ప్రతి ఒక్కరిలో ఉంది.
మైక్రోసర్వీస్ నుండి అంచనాలు
సిద్ధంగా ఉన్నప్పుడు భాగాల సమస్య. ద్రావణాన్ని విచ్ఛిన్నం చేయడం మరియు వివిధ ప్రక్రియలను వేరు చేయడం ద్వారా సిద్ధంగా ఉన్నప్పుడు భాగాల పంపిణీ.
చిన్న ఉత్పత్తి బృందాలు. ఇది చాలా ముఖ్యం ఎందుకంటే పాత ఏకశిలాపై పనిచేసే పెద్ద బృందం నిర్వహించడం కష్టం. అటువంటి బృందం కఠినమైన ప్రక్రియ ప్రకారం పని చేయవలసి వచ్చింది, కానీ వారు మరింత సృజనాత్మకత మరియు స్వాతంత్ర్యం కోరుకున్నారు. చిన్న జట్లు మాత్రమే దీన్ని భరించగలవు.
ప్రత్యేక ప్రక్రియలలో సేవలను వేరుచేయడం. ఆదర్శవంతంగా, నేను దానిని కంటైనర్లలో వేరుచేయాలనుకుంటున్నాను, కానీ .NET ఫ్రేమ్వర్క్లో వ్రాసిన చాలా సేవలు కేవలం వాటి కింద మాత్రమే నడుస్తాయి. Windows.NET కోర్ ఆధారిత సేవలు ఇప్పుడు వస్తున్నాయి, కానీ వాటి సంఖ్య ఇంకా తక్కువగానే ఉంది.
విస్తరణ వశ్యత. మేము సేవలను మనకు అవసరమైన విధంగా కలపాలనుకుంటున్నాము మరియు కోడ్ బలవంతం చేసే విధంగా కాదు.
కొత్త సాంకేతికతలను ఉపయోగించడం. ఏ ప్రోగ్రామర్కైనా ఇది ఆసక్తికరంగా ఉంటుంది.
పరివర్తన సమస్యలు
అయితే, మైక్రోసర్వీస్లలో ఏకశిలాను విచ్ఛిన్నం చేయడం సులభం అయితే, సమావేశాలలో దాని గురించి మాట్లాడటం మరియు వ్యాసాలు రాయడం అవసరం లేదు. ఈ ప్రక్రియలో చాలా ఆపదలు ఉన్నాయి;
మొదటి సమస్య చాలా ఏకశిలాలకు విలక్షణమైనది: వ్యాపార తర్కం యొక్క పొందిక. మేము ఏకశిలా వ్రాసేటప్పుడు, అనవసరమైన కోడ్ను వ్రాయకుండా ఉండటానికి మేము మా తరగతులను మళ్లీ ఉపయోగించాలనుకుంటున్నాము. మరియు మైక్రోసర్వీస్లకు వెళ్లేటప్పుడు, ఇది సమస్యగా మారుతుంది: అన్ని కోడ్లు చాలా గట్టిగా జతచేయబడి ఉంటాయి మరియు సేవలను వేరు చేయడం కష్టం.
పని ప్రారంభ సమయంలో, రిపోజిటరీలో 500 కంటే ఎక్కువ ప్రాజెక్టులు మరియు 700 వేల కంటే ఎక్కువ లైన్ల కోడ్ ఉన్నాయి. ఇది చాలా పెద్ద నిర్ణయం మరియు రెండవ సమస్య. దీన్ని కేవలం తీసుకుని మైక్రోసర్వీస్లుగా విభజించడం సాధ్యం కాదు.
మూడవ సమస్య - అవసరమైన మౌలిక సదుపాయాల కొరత. నిజానికి, మేము సర్వర్లకు సోర్స్ కోడ్ను మాన్యువల్గా కాపీ చేస్తున్నాము.
ఏకశిలా నుండి మైక్రోసర్వీస్కి ఎలా మారాలి
మైక్రోసర్వీస్లను అందించడం
ముందుగా, మైక్రోసర్వీస్ల విభజన అనేది ఒక పునరుక్తి ప్రక్రియ అని మేము వెంటనే నిర్ణయించుకున్నాము. మేము ఎల్లప్పుడూ వ్యాపార సమస్యలను సమాంతరంగా అభివృద్ధి చేయవలసి ఉంటుంది. మేము దీన్ని సాంకేతికంగా ఎలా అమలు చేస్తాము అనేది ఇప్పటికే మా సమస్య. అందువల్ల, మేము పునరావృత ప్రక్రియ కోసం సిద్ధం చేసాము. మీరు పెద్ద అప్లికేషన్ని కలిగి ఉంటే మరియు అది తిరిగి వ్రాయడానికి మొదట సిద్ధంగా లేకుంటే అది వేరే విధంగా పని చేయదు.
మైక్రోసర్వీస్లను వేరు చేయడానికి మేము ఏ పద్ధతులను ఉపయోగిస్తాము?
మొదటి మార్గం — ఇప్పటికే ఉన్న మాడ్యూళ్లను సేవలుగా తరలించండి. ఈ విషయంలో, మేము అదృష్టవంతులం: WCF ప్రోటోకాల్ను ఉపయోగించి పనిచేసిన రిజిస్టర్డ్ సేవలు ఇప్పటికే ఉన్నాయి. అవి వేర్వేరు అసెంబ్లీలుగా విభజించబడ్డాయి. మేము వాటిని విడిగా పోర్ట్ చేసాము, ప్రతి బిల్డ్కి ఒక చిన్న లాంచర్ని జోడించాము. ఇది అద్భుతమైన టాప్షెల్ఫ్ లైబ్రరీని ఉపయోగించి వ్రాయబడింది, ఇది అప్లికేషన్ను సేవగా మరియు కన్సోల్గా అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. పరిష్కారంలో అదనపు ప్రాజెక్ట్లు అవసరం లేనందున డీబగ్గింగ్ కోసం ఇది సౌకర్యవంతంగా ఉంటుంది.
సర్వీసెస్ బిజినెస్ లాజిక్ ప్రకారం కనెక్ట్ చేయబడ్డాయి, ఎందుకంటే అవి సాధారణ సమావేశాలను ఉపయోగించాయి మరియు సాధారణ డేటాబేస్తో పని చేస్తాయి. వాటిని వాటి స్వచ్ఛమైన రూపంలో మైక్రోసర్వీస్ అని పిలవలేము. అయితే, మేము ఈ సేవలను వేర్వేరు ప్రక్రియలలో విడిగా అందించగలము. ఇది ఒకదానికొకటి వారి ప్రభావాన్ని తగ్గించడం సాధ్యం చేసింది, సమాంతర అభివృద్ధి మరియు వైఫల్యం యొక్క ఒకే పాయింట్తో సమస్యను తగ్గిస్తుంది.
హోస్ట్తో అసెంబ్లీ అనేది ప్రోగ్రామ్ క్లాస్లో కోడ్ యొక్క ఒక లైన్ మాత్రమే. మేము Topshelfతో పనిని సహాయక తరగతిలో దాచాము.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
మైక్రోసర్వీస్లను కేటాయించడానికి రెండవ మార్గం: కొత్త సమస్యలను పరిష్కరించడానికి వాటిని సృష్టించండి. అదే సమయంలో ఏకశిలా పెరగకపోతే, ఇది ఇప్పటికే అద్భుతమైనది, అంటే మనం సరైన దిశలో కదులుతున్నామని అర్థం. కొత్త సమస్యలను పరిష్కరించడానికి, మేము ప్రత్యేక సేవలను రూపొందించడానికి ప్రయత్నించాము. అటువంటి అవకాశం ఉన్నట్లయితే, మేము వారి స్వంత డేటా మోడల్ను, ప్రత్యేక డేటాబేస్ను పూర్తిగా నిర్వహించే మరిన్ని “కానానికల్” సేవలను సృష్టించాము.
మేము, చాలా మందిలాగే, ప్రామాణీకరణ మరియు అధికార సేవలతో ప్రారంభించాము. వారు దీనికి సరైనవారు. వారు స్వతంత్రంగా ఉంటారు, ఒక నియమం వలె, వారికి ప్రత్యేక డేటా మోడల్ ఉంటుంది. వారు తాము ఏకశిలాతో సంకర్షణ చెందరు, కొన్ని సమస్యలను పరిష్కరించడానికి మాత్రమే అది వారి వైపుకు మారుతుంది. ఈ సేవలను ఉపయోగించి, మీరు కొత్త ఆర్కిటెక్చర్కు పరివర్తనను ప్రారంభించవచ్చు, వాటిపై మౌలిక సదుపాయాలను డీబగ్ చేయవచ్చు, నెట్వర్క్ లైబ్రరీలకు సంబంధించిన కొన్ని విధానాలను ప్రయత్నించవచ్చు. మా సంస్థలో ప్రామాణీకరణ సేవను సృష్టించలేని బృందాలు ఏవీ మా వద్ద లేవు.
మైక్రోసర్వీస్లను కేటాయించడానికి మూడవ మార్గంమనం ఉపయోగించేది మనకు కొంచెం ప్రత్యేకంగా ఉంటుంది. ఇది UI లేయర్ నుండి వ్యాపార లాజిక్ను తీసివేయడం. మా ప్రధాన UI అప్లికేషన్ డెస్క్టాప్, ఇది బ్యాకెండ్ లాగా C#లో వ్రాయబడింది. డెవలపర్లు క్రమానుగతంగా పొరపాట్లు చేస్తారు మరియు బ్యాకెండ్లో ఉండి తిరిగి ఉపయోగించాల్సిన లాజిక్ భాగాలను UIకి బదిలీ చేశారు.
మీరు UI భాగం యొక్క కోడ్ నుండి నిజమైన ఉదాహరణను చూస్తే, ఈ సొల్యూషన్లో ఎక్కువ భాగం UI ఫారమ్ను రూపొందించడానికి మాత్రమే కాకుండా ఇతర ప్రక్రియలలో ఉపయోగపడే నిజమైన వ్యాపార లాజిక్ని కలిగి ఉన్నట్లు మీరు చూడవచ్చు.
నిజమైన UI లాజిక్ చివరి రెండు పంక్తులలో మాత్రమే ఉంది. మేము దానిని సర్వర్కు బదిలీ చేసాము, తద్వారా దానిని తిరిగి ఉపయోగించుకోవచ్చు, తద్వారా UIని తగ్గించడం మరియు సరైన నిర్మాణాన్ని సాధించడం.
మైక్రోసర్వీస్లను వేరు చేయడానికి నాల్గవ మరియు అతి ముఖ్యమైన మార్గం, ఇది ఏకశిలాను తగ్గించడం సాధ్యం చేస్తుంది, ఇది ప్రాసెసింగ్తో ఇప్పటికే ఉన్న సేవలను తీసివేయడం. మేము ఇప్పటికే ఉన్న మాడ్యూల్లను తీసివేసినప్పుడు, ఫలితం ఎల్లప్పుడూ డెవలపర్ల ఇష్టానికి అనుగుణంగా ఉండదు మరియు కార్యాచరణ సృష్టించబడినప్పటి నుండి వ్యాపార ప్రక్రియ పాతది అయి ఉండవచ్చు. రీఫ్యాక్టరింగ్తో, వ్యాపార అవసరాలు నిరంతరం మారుతున్నందున మేము కొత్త వ్యాపార ప్రక్రియకు మద్దతు ఇవ్వగలము. మేము సోర్స్ కోడ్ని మెరుగుపరచవచ్చు, తెలిసిన లోపాలను తొలగించవచ్చు మరియు మెరుగైన డేటా మోడల్ని సృష్టించవచ్చు. అనేక ప్రయోజనాలు కలుగుతున్నాయి.
ప్రాసెసింగ్ నుండి సేవలను వేరు చేయడం సరిహద్దు సందర్భం అనే భావనతో విడదీయరాని విధంగా ముడిపడి ఉంటుంది. ఇది డొమైన్ నడిచే డిజైన్ నుండి వచ్చిన కాన్సెప్ట్. దీని అర్థం డొమైన్ మోడల్లోని ఒక విభాగం, దీనిలో ఒకే భాష యొక్క అన్ని నిబంధనలు ప్రత్యేకంగా నిర్వచించబడ్డాయి. ఉదాహరణగా బీమా మరియు బిల్లుల సందర్భాన్ని చూద్దాం. మాకు ఏకశిలా అప్లికేషన్ ఉంది మరియు మేము బీమాలో ఖాతాతో పని చేయాలి. డెవలపర్ మరొక అసెంబ్లీలో ఇప్పటికే ఉన్న ఖాతా తరగతిని కనుగొంటారని మేము ఆశిస్తున్నాము, భీమా తరగతి నుండి దానిని సూచిస్తాము మరియు మేము వర్కింగ్ కోడ్ని కలిగి ఉంటాము. DRY సూత్రం గౌరవించబడుతుంది, ఇప్పటికే ఉన్న కోడ్ని ఉపయోగించడం ద్వారా పని వేగంగా చేయబడుతుంది.
ఫలితంగా, ఖాతాలు మరియు భీమా యొక్క సందర్భాలు అనుసంధానించబడి ఉన్నాయని తేలింది. కొత్త అవసరాలు ఉద్భవించినప్పుడు, ఈ కలయిక అభివృద్ధికి ఆటంకం కలిగిస్తుంది, ఇప్పటికే సంక్లిష్ట వ్యాపార తర్కం యొక్క సంక్లిష్టతను పెంచుతుంది. ఈ సమస్యను పరిష్కరించడానికి, మీరు కోడ్లోని సందర్భాల మధ్య సరిహద్దులను కనుగొని, వాటి ఉల్లంఘనలను తీసివేయాలి. ఉదాహరణకు, బీమా సందర్భంలో, 20-అంకెల సెంట్రల్ బ్యాంక్ ఖాతా సంఖ్య మరియు ఖాతాను తెరిచిన తేదీ సరిపోయే అవకాశం ఉంది.
ఈ సరిహద్దు సందర్భాలను ఒకదానికొకటి వేరు చేయడానికి మరియు మైక్రోసర్వీస్లను ఏకశిలా పరిష్కారం నుండి వేరు చేసే ప్రక్రియను ప్రారంభించడానికి, మేము అప్లికేషన్లో బాహ్య APIలను సృష్టించడం వంటి విధానాన్ని ఉపయోగించాము. కొన్ని మాడ్యూల్ మైక్రోసర్వీస్గా మారాలని, ప్రక్రియలో ఏదో ఒకవిధంగా సవరించబడిందని మాకు తెలిస్తే, మేము వెంటనే బాహ్య కాల్ల ద్వారా మరొక పరిమిత సందర్భానికి చెందిన లాజిక్కి కాల్లు చేసాము. ఉదాహరణకు, REST లేదా WCF ద్వారా.
పంపిణీ చేయబడిన లావాదేవీలు అవసరమయ్యే కోడ్ను మేము నివారించకూడదని మేము గట్టిగా నిర్ణయించుకున్నాము. మా విషయంలో, ఈ నియమాన్ని అనుసరించడం చాలా సులభం. కఠినమైన పంపిణీ లావాదేవీలు నిజంగా అవసరమయ్యే పరిస్థితులను మేము ఇంకా ఎదుర్కోలేదు - మాడ్యూళ్ల మధ్య తుది స్థిరత్వం చాలా సరిపోతుంది.
ఒక నిర్దిష్ట ఉదాహరణ చూద్దాం. మేము ఆర్కెస్ట్రేటర్ భావనను కలిగి ఉన్నాము - “అప్లికేషన్” యొక్క ఎంటిటీని ప్రాసెస్ చేసే పైప్లైన్. అతను క్లయింట్, ఖాతా మరియు బ్యాంకు కార్డును సృష్టిస్తాడు. క్లయింట్ మరియు ఖాతా విజయవంతంగా సృష్టించబడినప్పటికీ, కార్డ్ సృష్టి విఫలమైతే, అప్లికేషన్ "విజయవంతమైన" స్థితికి తరలించబడదు మరియు "కార్డ్ సృష్టించబడలేదు" స్థితిలోనే ఉంటుంది. భవిష్యత్తులో, నేపథ్య కార్యాచరణ దానిని ఎంచుకొని పూర్తి చేస్తుంది. ఈ వ్యవస్థ కొంత కాలంగా అస్థిరమైన స్థితిలో ఉంది, కానీ మేము సాధారణంగా దీనితో సంతృప్తి చెందాము.
డేటాలో కొంత భాగాన్ని నిలకడగా సేవ్ చేయాల్సిన అవసరం వచ్చినప్పుడు పరిస్థితి తలెత్తితే, మేము దానిని ఒక ప్రక్రియలో ప్రాసెస్ చేయడానికి సేవ యొక్క ఏకీకరణకు ఎక్కువగా వెళ్తాము.
మైక్రోసర్వీస్ను కేటాయించే ఉదాహరణను చూద్దాం. మీరు దానిని సాపేక్షంగా సురక్షితంగా ఉత్పత్తికి ఎలా తీసుకురాగలరు? ఈ ఉదాహరణలో, మేము సిస్టమ్ యొక్క ప్రత్యేక భాగాన్ని కలిగి ఉన్నాము - పేరోల్ సర్వీస్ మాడ్యూల్, మేము మైక్రోసర్వీస్ చేయాలనుకుంటున్న కోడ్ విభాగాలలో ఒకటి.
అన్నింటిలో మొదటిది, మేము కోడ్ను తిరిగి వ్రాయడం ద్వారా మైక్రోసర్వీస్ను సృష్టిస్తాము. మేము సంతోషంగా లేని కొన్ని అంశాలను మెరుగుపరుస్తున్నాము. మేము కస్టమర్ నుండి కొత్త వ్యాపార అవసరాలను అమలు చేస్తాము. మేము UI మరియు బ్యాకెండ్ మధ్య కనెక్షన్కి API గేట్వేని జోడిస్తాము, ఇది కాల్ ఫార్వార్డింగ్ని అందిస్తుంది.
తరువాత, మేము ఈ కాన్ఫిగరేషన్ను ఆపరేషన్లోకి విడుదల చేస్తాము, కానీ పైలట్ స్థితిలో. మా వినియోగదారులు చాలా మంది ఇప్పటికీ పాత వ్యాపార ప్రక్రియలతో పని చేస్తున్నారు. కొత్త వినియోగదారుల కోసం, మేము ఈ ప్రక్రియను కలిగి ఉండని ఏకశిలా అప్లికేషన్ యొక్క కొత్త వెర్షన్ను అభివృద్ధి చేస్తున్నాము. ముఖ్యంగా, మేము పైలట్గా పనిచేసే ఏకశిలా మరియు మైక్రోసర్వీస్ కలయికను కలిగి ఉన్నాము.
విజయవంతమైన పైలట్తో, కొత్త కాన్ఫిగరేషన్ నిజంగా పని చేయదగినదని మేము అర్థం చేసుకున్నాము, మేము సమీకరణం నుండి పాత ఏకశిలాను తీసివేయవచ్చు మరియు పాత పరిష్కారం స్థానంలో కొత్త కాన్ఫిగరేషన్ను వదిలివేయవచ్చు.
మొత్తంగా, మేము మోనోలిత్ యొక్క సోర్స్ కోడ్ను విభజించడానికి ఇప్పటికే ఉన్న అన్ని పద్ధతులను ఉపయోగిస్తాము. అవన్నీ అప్లికేషన్ యొక్క భాగాల పరిమాణాన్ని తగ్గించడానికి మరియు వాటిని కొత్త లైబ్రరీలకు అనువదించడానికి, మెరుగైన సోర్స్ కోడ్ని చేయడానికి మాకు అనుమతిస్తాయి.
డేటాబేస్తో పని చేస్తోంది
డేటాబేస్ సోర్స్ కోడ్ కంటే అధ్వాన్నంగా విభజించబడింది, ఎందుకంటే ఇది ప్రస్తుత స్కీమాను మాత్రమే కాకుండా, సేకరించిన చారిత్రక డేటాను కూడా కలిగి ఉంటుంది.
మా డేటాబేస్, అనేక ఇతర వంటి, మరొక ముఖ్యమైన లోపం ఉంది - దాని భారీ పరిమాణం. ఈ డేటాబేస్ ఒక ఏకశిలా యొక్క క్లిష్టమైన వ్యాపార తర్కం ప్రకారం రూపొందించబడింది మరియు వివిధ పరిమిత సందర్భాల పట్టికల మధ్య సంచిత సంబంధాలు.
మా విషయంలో, అన్ని సమస్యలను అధిగమించడానికి (పెద్ద డేటాబేస్, అనేక కనెక్షన్లు, కొన్నిసార్లు పట్టికల మధ్య అస్పష్టమైన సరిహద్దులు), అనేక పెద్ద ప్రాజెక్ట్లలో సంభవించే సమస్య తలెత్తింది: భాగస్వామ్య డేటాబేస్ టెంప్లేట్ యొక్క ఉపయోగం. పట్టికల నుండి వీక్షణ ద్వారా, ప్రతిరూపణ ద్వారా డేటా తీసుకోబడింది మరియు ఈ ప్రతిరూపణ అవసరమైన ఇతర సిస్టమ్లకు రవాణా చేయబడింది. ఫలితంగా, మేము పట్టికలను ప్రత్యేక స్కీమాలోకి తరలించలేకపోయాము ఎందుకంటే అవి చురుకుగా ఉపయోగించబడ్డాయి.
కోడ్లోని పరిమిత సందర్భాలలో అదే విభజన మనకు వేరు చేయడంలో సహాయపడుతుంది. డేటాబేస్ స్థాయిలో మేము డేటాను ఎలా విచ్ఛిన్నం చేస్తాము అనే దాని గురించి ఇది సాధారణంగా మాకు మంచి ఆలోచన ఇస్తుంది. ఏ పట్టికలు ఒక పరిమిత సందర్భానికి చెందినవి మరియు మరొకదానికి సంబంధించినవి అని మేము అర్థం చేసుకున్నాము.
మేము డేటాబేస్ విభజన యొక్క రెండు ప్రపంచ పద్ధతులను ఉపయోగించాము: ఇప్పటికే ఉన్న పట్టికల విభజన మరియు ప్రాసెసింగ్తో విభజన.
డేటా నిర్మాణం బాగుంటే, వ్యాపార అవసరాలకు అనుగుణంగా మరియు ప్రతి ఒక్కరూ దానితో సంతోషంగా ఉంటే, ఇప్పటికే ఉన్న పట్టికలను విభజించడం మంచి పద్ధతి. ఈ సందర్భంలో, మేము ఇప్పటికే ఉన్న పట్టికలను ప్రత్యేక స్కీమాగా విభజించవచ్చు.
వ్యాపార నమూనా బాగా మారినప్పుడు ప్రాసెసింగ్తో కూడిన డిపార్ట్మెంట్ అవసరం మరియు పట్టికలు ఇకపై మాకు సంతృప్తిని ఇవ్వవు.
ఇప్పటికే ఉన్న పట్టికలను విభజించడం. మనం దేనిని విడదీస్తామో నిర్ణయించుకోవాలి. ఈ జ్ఞానం లేకుండా, ఏదీ పని చేయదు మరియు ఇక్కడ కోడ్లోని పరిమిత సందర్భాలను వేరు చేయడం మాకు సహాయపడుతుంది. నియమం ప్రకారం, మీరు సోర్స్ కోడ్లోని సందర్భాల సరిహద్దులను అర్థం చేసుకోగలిగితే, డిపార్ట్మెంట్ కోసం జాబితాలో ఏ పట్టికలను చేర్చాలో స్పష్టమవుతుంది.
రెండు మోనోలిత్ మాడ్యూల్స్ ఒక డేటాబేస్తో పరస్పర చర్య చేసే పరిష్కారాన్ని కలిగి ఉన్నారని ఊహించుకుందాం. వేరు చేయబడిన పట్టికల విభాగంతో ఒక మాడ్యూల్ మాత్రమే సంకర్షణ చెందుతుందని మేము నిర్ధారించుకోవాలి మరియు మరొకటి API ద్వారా దానితో పరస్పర చర్య చేయడం ప్రారంభిస్తుంది. ప్రారంభించడానికి, API ద్వారా రికార్డింగ్ మాత్రమే నిర్వహిస్తే సరిపోతుంది. మైక్రోసర్వీస్ యొక్క స్వతంత్రత గురించి మాట్లాడటానికి ఇది మాకు అవసరమైన షరతు. పెద్ద సమస్య లేనంత వరకు రీడింగ్ కనెక్షన్లు అలాగే ఉంటాయి.
తదుపరి దశ ఏమిటంటే, మేము వేరు చేయబడిన పట్టికలతో పనిచేసే కోడ్ విభాగాన్ని, ప్రాసెసింగ్తో లేదా లేకుండా, ప్రత్యేక మైక్రోసర్వీస్గా వేరు చేయవచ్చు మరియు దానిని ప్రత్యేక ప్రక్రియలో, కంటైనర్లో అమలు చేయవచ్చు. ఇది మోనోలిత్ డేటాబేస్ మరియు దానికి నేరుగా సంబంధం లేని పట్టికలకు కనెక్షన్తో ప్రత్యేక సేవ అవుతుంది. ఏకశిలా ఇప్పటికీ వేరు చేయగలిగిన భాగంతో చదవడానికి సంకర్షణ చెందుతుంది.
తరువాత మేము ఈ కనెక్షన్ని తీసివేస్తాము, అనగా, వేరు చేయబడిన పట్టికల నుండి ఏకశిలా అప్లికేషన్ నుండి డేటాను చదవడం కూడా APIకి బదిలీ చేయబడుతుంది.
తరువాత, మేము సాధారణ డేటాబేస్ నుండి కొత్త మైక్రోసర్వీస్ మాత్రమే పనిచేసే పట్టికలను ఎంచుకుంటాము. మేము పట్టికలను ప్రత్యేక స్కీమాకు లేదా ప్రత్యేక భౌతిక డేటాబేస్కు కూడా తరలించవచ్చు. మైక్రోసర్వీస్ మరియు మోనోలిత్ డేటాబేస్ మధ్య ఇప్పటికీ రీడింగ్ కనెక్షన్ ఉంది, కానీ ఆందోళన చెందాల్సిన అవసరం లేదు, ఈ కాన్ఫిగరేషన్లో ఇది చాలా కాలం పాటు జీవించగలదు.
అన్ని కనెక్షన్లను పూర్తిగా తీసివేయడం చివరి దశ. ఈ సందర్భంలో, మేము ప్రధాన డేటాబేస్ నుండి డేటాను తరలించాల్సి రావచ్చు. కొన్నిసార్లు మేము అనేక డేటాబేస్లలో బాహ్య సిస్టమ్ల నుండి ప్రతిరూపం చేయబడిన కొన్ని డేటా లేదా డైరెక్టరీలను మళ్లీ ఉపయోగించాలనుకుంటున్నాము. ఇది మనకు క్రమానుగతంగా జరుగుతుంది.
ప్రాసెసింగ్ విభాగం. ఈ పద్ధతి మొదటిదానికి చాలా పోలి ఉంటుంది, రివర్స్ క్రమంలో మాత్రమే. మేము వెంటనే కొత్త డేటాబేస్ మరియు API ద్వారా ఏకశిలాతో పరస్పర చర్య చేసే కొత్త మైక్రోసర్వీస్ను కేటాయిస్తాము. కానీ అదే సమయంలో, భవిష్యత్తులో మనం తొలగించాలనుకుంటున్న డేటాబేస్ పట్టికల సమితి మిగిలి ఉంది. మాకు ఇది అవసరం లేదు; మేము దానిని కొత్త మోడల్లో మార్చాము.
ఈ పథకం పని చేయడానికి, మాకు పరివర్తన కాలం అవసరం కావచ్చు.
అప్పుడు రెండు సాధ్యమైన విధానాలు ఉన్నాయి.
మొదటిది: మేము కొత్త మరియు పాత డేటాబేస్లలో మొత్తం డేటాను నకిలీ చేస్తాము. ఈ సందర్భంలో, మేము డేటా రిడెండెన్సీని కలిగి ఉన్నాము మరియు సమకాలీకరణ సమస్యలు తలెత్తవచ్చు. కానీ మేము రెండు వేర్వేరు క్లయింట్లను తీసుకోవచ్చు. ఒకటి కొత్త వెర్షన్తో, మరొకటి పాత వెర్షన్తో పని చేస్తుంది.
రెండవ: మేము కొన్ని వ్యాపార ప్రమాణాల ప్రకారం డేటాను విభజిస్తాము. ఉదాహరణకు, పాత డేటాబేస్లో నిల్వ చేయబడిన సిస్టమ్లో మేము 5 ఉత్పత్తులను కలిగి ఉన్నాము. మేము కొత్త డేటాబేస్లో కొత్త బిజినెస్ టాస్క్లో ఆరవదాన్ని ఉంచుతాము. కానీ మాకు ఈ డేటాను సమకాలీకరించే మరియు క్లయింట్కు ఎక్కడ మరియు ఏమి పొందాలో చూపే API గేట్వే అవసరం.
రెండు విధానాలు పని చేస్తాయి, పరిస్థితిని బట్టి ఎంచుకోండి.
ప్రతిదీ పని చేస్తుందని మేము నిర్ధారించుకున్న తర్వాత, పాత డేటాబేస్ నిర్మాణాలతో పనిచేసే ఏకశిలా భాగం నిలిపివేయబడుతుంది.
పాత డేటా నిర్మాణాలను తీసివేయడం చివరి దశ.
సంగ్రహంగా చెప్పాలంటే, మనకు డేటాబేస్తో సమస్యలు ఉన్నాయని చెప్పగలం: సోర్స్ కోడ్తో పోలిస్తే దానితో పని చేయడం కష్టం, భాగస్వామ్యం చేయడం చాలా కష్టం, కానీ అది చేయగలదు మరియు చేయాలి. మేము దీన్ని చాలా సురక్షితంగా చేయడానికి అనుమతించే కొన్ని మార్గాలను కనుగొన్నాము, అయితే సోర్స్ కోడ్తో కంటే డేటాతో తప్పులు చేయడం ఇప్పటికీ సులభం.
సోర్స్ కోడ్తో పని చేస్తోంది
మేము ఏకశిలా ప్రాజెక్ట్ను విశ్లేషించడం ప్రారంభించినప్పుడు సోర్స్ కోడ్ రేఖాచిత్రం ఇలా ఉంది.
దీనిని స్థూలంగా మూడు పొరలుగా విభజించవచ్చు. ఇది ప్రారంభించబడిన మాడ్యూల్స్, ప్లగిన్లు, సేవలు మరియు వ్యక్తిగత కార్యకలాపాల యొక్క పొర. వాస్తవానికి, ఇవి ఏకశిలా పరిష్కారంలో ప్రవేశ బిందువులు. అవన్నీ కామన్ లేయర్తో గట్టిగా మూసివేయబడ్డాయి. ఇది సేవలు పంచుకున్న వ్యాపార లాజిక్ మరియు చాలా కనెక్షన్లను కలిగి ఉంది. ప్రతి సేవ మరియు ప్లగ్ఇన్ వాటి పరిమాణం మరియు డెవలపర్ల మనస్సాక్షిని బట్టి 10 లేదా అంతకంటే ఎక్కువ సాధారణ సమావేశాలను ఉపయోగిస్తాయి.
విడివిడిగా ఉపయోగించగలిగే మౌలిక సదుపాయాల లైబ్రరీలను కలిగి ఉండటం మా అదృష్టం.
కొన్ని సాధారణ వస్తువులు వాస్తవానికి ఈ పొరకు చెందినవి కానప్పటికీ, అవస్థాపన లైబ్రరీలుగా ఉన్నప్పుడు కొన్నిసార్లు పరిస్థితి ఏర్పడింది. పేరు మార్చడం ద్వారా ఇది పరిష్కరించబడింది.
అతి పెద్ద ఆందోళన పరిమిత సందర్భాలు. ఒక ఉమ్మడి అసెంబ్లీలో 3-4 సందర్భాలు మిళితం చేయబడ్డాయి మరియు అదే వ్యాపార విధుల్లో ఒకదానికొకటి ఉపయోగించబడ్డాయి. దీన్ని ఎక్కడ విభజించవచ్చు మరియు ఏ సరిహద్దుల ద్వారా విభజించవచ్చు మరియు ఈ విభజనను సోర్స్ కోడ్ అసెంబ్లీలుగా మ్యాపింగ్ చేయడం ద్వారా తదుపరి ఏమి చేయాలో అర్థం చేసుకోవడం అవసరం.
కోడ్ విభజన ప్రక్రియ కోసం మేము అనేక నియమాలను రూపొందించాము.
మొదటిది: మేము ఇకపై సేవలు, కార్యకలాపాలు మరియు ప్లగిన్ల మధ్య వ్యాపార లాజిక్ను పంచుకోవాలనుకోము. మేము మైక్రోసర్వీస్లో వ్యాపార తర్కాన్ని స్వతంత్రంగా చేయాలనుకుంటున్నాము. మరోవైపు మైక్రోసర్వీస్లు పూర్తిగా స్వతంత్రంగా ఉన్న సేవలుగా ఆదర్శంగా భావించబడతాయి. ఈ విధానం కొంత వృధా అని నేను నమ్ముతున్నాను మరియు దానిని సాధించడం కష్టం, ఎందుకంటే, ఉదాహరణకు, C#లోని సేవలు ఏ సందర్భంలోనైనా ప్రామాణిక లైబ్రరీ ద్వారా అనుసంధానించబడతాయి. మా సిస్టమ్ C#లో వ్రాయబడింది; మేము ఇంకా ఇతర సాంకేతికతలను ఉపయోగించలేదు. అందువల్ల, మేము సాధారణ సాంకేతిక సమావేశాలను ఉపయోగించగలమని మేము నిర్ణయించుకున్నాము. ప్రధాన విషయం ఏమిటంటే వారు వ్యాపార తర్కం యొక్క శకలాలు కలిగి ఉండరు. మీరు ఉపయోగిస్తున్న ORMపై మీకు అనుకూలమైన రేపర్ ఉంటే, దానిని సేవ నుండి సేవకు కాపీ చేయడం చాలా ఖరీదైనది.
మా బృందం డొమైన్-ఆధారిత డిజైన్కు అభిమాని, కాబట్టి ఉల్లిపాయల నిర్మాణం మాకు బాగా సరిపోతుంది. మా సేవలకు ఆధారం డేటా యాక్సెస్ లేయర్ కాదు, డొమైన్ లాజిక్తో కూడిన అసెంబ్లీ, ఇది వ్యాపార లాజిక్ను మాత్రమే కలిగి ఉంటుంది మరియు ఇన్ఫ్రాస్ట్రక్చర్తో ఎటువంటి కనెక్షన్లను కలిగి ఉండదు. అదే సమయంలో, ఫ్రేమ్వర్క్లకు సంబంధించిన సమస్యలను పరిష్కరించడానికి మేము డొమైన్ అసెంబ్లీని స్వతంత్రంగా సవరించవచ్చు.
ఈ దశలో మేము మా మొదటి తీవ్రమైన సమస్యను ఎదుర్కొన్నాము. సేవ ఒక డొమైన్ అసెంబ్లీని సూచించవలసి ఉంది, మేము లాజిక్ను స్వతంత్రంగా చేయాలనుకుంటున్నాము మరియు DRY సూత్రం మాకు ఇక్కడ చాలా ఆటంకం కలిగించింది. డెవలపర్లు డూప్లికేషన్ను నివారించడానికి పొరుగు అసెంబ్లీల నుండి తరగతులను తిరిగి ఉపయోగించాలని కోరుకున్నారు మరియు ఫలితంగా, డొమైన్లు మళ్లీ ఒకదానితో ఒకటి లింక్ చేయడం ప్రారంభించాయి. మేము ఫలితాలను విశ్లేషించాము మరియు సమస్య సోర్స్ కోడ్ నిల్వ పరికరం యొక్క ప్రాంతంలో కూడా ఉందని నిర్ణయించుకున్నాము. మేము మొత్తం సోర్స్ కోడ్ను కలిగి ఉన్న పెద్ద రిపోజిటరీని కలిగి ఉన్నాము. మొత్తం ప్రాజెక్ట్ కోసం పరిష్కారం స్థానిక యంత్రంలో సమీకరించడం చాలా కష్టం. అందువల్ల, ప్రాజెక్ట్ యొక్క భాగాల కోసం ప్రత్యేక చిన్న పరిష్కారాలు సృష్టించబడ్డాయి మరియు వాటికి కొన్ని సాధారణ లేదా డొమైన్ అసెంబ్లీని జోడించడాన్ని మరియు వాటిని తిరిగి ఉపయోగించడాన్ని ఎవరూ నిషేధించలేదు. దీన్ని చేయడానికి మమ్మల్ని అనుమతించని ఏకైక సాధనం కోడ్ సమీక్ష. కానీ కొన్నిసార్లు అది కూడా విఫలమైంది.
అప్పుడు మేము ప్రత్యేక రిపోజిటరీలతో మోడల్కు వెళ్లడం ప్రారంభించాము. వ్యాపార తర్కం సేవ నుండి సేవకు ప్రవహించదు, డొమైన్లు నిజంగా స్వతంత్రంగా మారాయి. సరిహద్దు సందర్భాలు మరింత స్పష్టంగా మద్దతిస్తాయి. మేము మౌలిక సదుపాయాల లైబ్రరీలను ఎలా తిరిగి ఉపయోగిస్తాము? మేము వాటిని ప్రత్యేక రిపోజిటరీగా వేరు చేసాము, ఆపై వాటిని నూగెట్ ప్యాకేజీలలో ఉంచాము, దానిని మేము ఆర్టిఫ్యాక్టరీలో ఉంచాము. ఏదైనా మార్పుతో, అసెంబ్లీ మరియు ప్రచురణ స్వయంచాలకంగా జరుగుతుంది.
మా సేవలు బాహ్యమైన వాటిలాగే అంతర్గత మౌలిక సదుపాయాల ప్యాకేజీలను సూచించడం ప్రారంభించాయి. మేము నుగెట్ నుండి బాహ్య లైబ్రరీలను డౌన్లోడ్ చేస్తాము. మేము ఈ ప్యాకేజీలను ఉంచిన ఆర్టిఫ్యాక్టరీతో పని చేయడానికి, మేము రెండు ప్యాకేజీ నిర్వాహకులను ఉపయోగించాము. చిన్న రిపోజిటరీలలో మేము నూగెట్ను కూడా ఉపయోగించాము. బహుళ సేవలతో ఉన్న రిపోజిటరీలలో, మేము ప్యాకెట్ని ఉపయోగించాము, ఇది మాడ్యూళ్ల మధ్య మరింత సంస్కరణ అనుగుణ్యతను అందిస్తుంది.
అందువల్ల, సోర్స్ కోడ్పై పని చేయడం ద్వారా, ఆర్కిటెక్చర్ను కొద్దిగా మార్చడం మరియు రిపోజిటరీలను వేరు చేయడం ద్వారా, మేము మా సేవలను మరింత స్వతంత్రంగా చేస్తాము.
మౌలిక సదుపాయాల సమస్యలు
మైక్రోసర్వీస్లకు వెళ్లడానికి చాలా ప్రతికూలతలు మౌలిక సదుపాయాలకు సంబంధించినవి. మీకు స్వయంచాలక విస్తరణ అవసరం, మౌలిక సదుపాయాలను అమలు చేయడానికి మీకు కొత్త లైబ్రరీలు అవసరం.
పరిసరాలలో మాన్యువల్ సంస్థాపన
ప్రారంభంలో, మేము పర్యావరణాల కోసం పరిష్కారాన్ని మాన్యువల్గా ఇన్స్టాల్ చేసాము. ఈ ప్రక్రియను ఆటోమేట్ చేయడానికి, మేము CI/CD పైప్లైన్ని సృష్టించాము. వ్యాపార ప్రక్రియల కోణం నుండి నిరంతర విస్తరణ మాకు ఇంకా ఆమోదయోగ్యం కానందున మేము నిరంతర డెలివరీ ప్రక్రియను ఎంచుకున్నాము. అందువలన, ఆపరేషన్ కోసం పంపడం బటన్ను ఉపయోగించి నిర్వహించబడుతుంది మరియు పరీక్ష కోసం - స్వయంచాలకంగా.
మేము సోర్స్ కోడ్ నిల్వ కోసం Atlassian, Bitbucket మరియు భవనం కోసం వెదురు ఉపయోగిస్తాము. మేము కేక్లో బిల్డ్ స్క్రిప్ట్లను వ్రాయాలనుకుంటున్నాము ఎందుకంటే ఇది C# వలె ఉంటుంది. రెడీమేడ్ ప్యాకేజీలు ఆర్టిఫ్యాక్టరీకి వస్తాయి మరియు అన్సిబుల్ స్వయంచాలకంగా పరీక్ష సర్వర్లకు చేరుకుంటుంది, ఆ తర్వాత వాటిని వెంటనే పరీక్షించవచ్చు.
ప్రత్యేక లాగింగ్
ఒక సమయంలో, ఏకశిలా యొక్క ఆలోచనలలో ఒకటి భాగస్వామ్య లాగింగ్ను అందించడం. డిస్క్లలో ఉన్న వ్యక్తిగత లాగ్లతో ఏమి చేయాలో కూడా మనం అర్థం చేసుకోవాలి. మా లాగ్లు టెక్స్ట్ ఫైల్లకు వ్రాయబడ్డాయి. మేము ప్రామాణిక ELK స్టాక్ని ఉపయోగించాలని నిర్ణయించుకున్నాము. మేము నేరుగా ప్రొవైడర్ల ద్వారా ELKకి వ్రాయలేదు, కానీ మేము టెక్స్ట్ లాగ్లను ఖరారు చేసి, సేవ పేరును జోడించి, వాటిలో ట్రేస్ IDని ఐడెంటిఫైయర్గా వ్రాయాలని నిర్ణయించుకున్నాము, తద్వారా ఈ లాగ్లను తర్వాత అన్వయించవచ్చు.
ఫైల్బీట్తో మనం మన లాగ్లను సేకరించగలుగుతాము సర్వర్లు, ఆపై వాటిని రూపాంతరం చెందించి, UIలో ప్రశ్నలను నిర్మించడానికి కిబానాను ఉపయోగించండి మరియు సేవల మధ్య కాల్ ఎలా మళ్లించబడిందో చూడండి. ట్రేస్ IDలు దీనికి చాలా సహాయపడతాయి.
సంబంధిత సేవలను పరీక్షించడం మరియు డీబగ్గింగ్ చేయడం
ప్రారంభంలో, డెవలప్ అవుతున్న సేవలను ఎలా డీబగ్ చేయాలో మాకు పూర్తిగా అర్థం కాలేదు. మోనోలిత్తో ప్రతిదీ సరళమైనది; మేము దానిని స్థానిక యంత్రంలో నడిపించాము. మొదట వారు మైక్రోసర్వీస్తో అదే విధంగా చేయడానికి ప్రయత్నించారు, కానీ కొన్నిసార్లు ఒక మైక్రోసర్వీస్ను పూర్తిగా ప్రారంభించడానికి మీరు అనేక ఇతరాలను ప్రారంభించాలి మరియు ఇది అసౌకర్యంగా ఉంటుంది. మేము డీబగ్ చేయాలనుకుంటున్న సేవ లేదా సేవలను మాత్రమే లోకల్ మెషీన్లో వదిలివేసే మోడల్కు వెళ్లాలని మేము గ్రహించాము. ఉత్పత్తి వలె అదే కాన్ఫిగరేషన్ ఉన్న సర్వర్ల నుండి మిగిలిన సేవలు ఉపయోగించబడతాయి. డీబగ్గింగ్ చేసిన తర్వాత, పరీక్ష సమయంలో, ప్రతి పని కోసం, పరీక్ష సర్వర్కు మార్చబడిన సేవలు మాత్రమే జారీ చేయబడతాయి. అందువలన, పరిష్కారం భవిష్యత్తులో ఉత్పత్తిలో కనిపించే రూపంలో పరీక్షించబడుతుంది.
సేవల ఉత్పత్తి సంస్కరణలను మాత్రమే అమలు చేసే సర్వర్లు ఉన్నాయి. ఈ సర్వర్లు సంఘటనల విషయంలో, విస్తరణకు ముందు డెలివరీని తనిఖీ చేయడానికి మరియు అంతర్గత శిక్షణ కోసం అవసరం.
మేము ప్రముఖ స్పెక్ఫ్లో లైబ్రరీని ఉపయోగించి ఆటోమేటెడ్ టెస్టింగ్ ప్రాసెస్ని జోడించాము. Ansible నుండి అమలు చేయబడిన వెంటనే NUnit ఉపయోగించి పరీక్షలు స్వయంచాలకంగా అమలు చేయబడతాయి. టాస్క్ కవరేజ్ పూర్తిగా ఆటోమేటిక్ అయితే, మాన్యువల్ టెస్టింగ్ అవసరం లేదు. కొన్నిసార్లు అదనపు మాన్యువల్ పరీక్ష ఇప్పటికీ అవసరం అయినప్పటికీ. నిర్దిష్ట సమస్య కోసం ఏ పరీక్షలు నిర్వహించాలో నిర్ణయించడానికి మేము జిరాలో ట్యాగ్లను ఉపయోగిస్తాము.
అదనంగా, లోడ్ పరీక్ష అవసరం గతంలో అరుదైన సందర్భాల్లో మాత్రమే నిర్వహించబడింది; మేము పరీక్షలను అమలు చేయడానికి JMeterని, వాటిని నిల్వ చేయడానికి InfluxDBని మరియు ప్రాసెస్ గ్రాఫ్లను రూపొందించడానికి Grafanaని ఉపయోగిస్తాము.
మనం ఏం సాధించాం?
మొదట, మేము "విడుదల" అనే భావనను వదిలించుకున్నాము. వ్యాపార ప్రక్రియలకు తాత్కాలికంగా అంతరాయం కలిగిస్తూ, ఉత్పత్తి వాతావరణంలో ఈ కోలోసస్ని మోహరించినప్పుడు రెండు నెలల భయంకరమైన విడుదలలు అయిపోయాయి. ఇప్పుడు మేము సగటున ప్రతి 1,5 రోజులకు సేవలను అమలు చేస్తాము, ఆమోదం పొందిన తర్వాత అవి అమలులోకి వస్తాయి కాబట్టి వాటిని సమూహపరుస్తాము.
మన వ్యవస్థలో ఘోరమైన వైఫల్యాలు లేవు. మేము బగ్తో మైక్రోసర్వీస్ను విడుదల చేస్తే, దానితో అనుబంధించబడిన కార్యాచరణ విచ్ఛిన్నమవుతుంది మరియు అన్ని ఇతర కార్యాచరణలు ప్రభావితం కావు. ఇది వినియోగదారు అనుభవాన్ని బాగా మెరుగుపరుస్తుంది.
మేము విస్తరణ నమూనాను నియంత్రించగలము. అవసరమైతే, మీరు మిగిలిన పరిష్కారాల నుండి విడిగా సేవల సమూహాలను ఎంచుకోవచ్చు.
అదనంగా, మేము మెరుగుదలల పెద్ద క్యూతో సమస్యను గణనీయంగా తగ్గించాము. మేము ఇప్పుడు కొన్ని సేవలతో స్వతంత్రంగా పని చేసే ప్రత్యేక ఉత్పత్తి బృందాలను కలిగి ఉన్నాము. స్క్రమ్ ప్రక్రియ ఇప్పటికే ఇక్కడ బాగా సరిపోతుంది. నిర్దిష్ట బృందానికి టాస్క్లను కేటాయించే ప్రత్యేక ఉత్పత్తి యజమాని ఉండవచ్చు.
సారాంశం
- సంక్లిష్ట వ్యవస్థలను కుళ్ళిపోవడానికి మైక్రోసర్వీస్లు బాగా సరిపోతాయి. ఈ ప్రక్రియలో, మన సిస్టమ్లో ఏమి ఉంది, పరిమిత సందర్భాలు ఏవి ఉన్నాయి, వాటి సరిహద్దులు ఎక్కడ ఉన్నాయో అర్థం చేసుకోవడం ప్రారంభిస్తాము. ఇది మాడ్యూల్ల మధ్య మెరుగుదలలను సరిగ్గా పంపిణీ చేయడానికి మరియు కోడ్ గందరగోళాన్ని నిరోధించడానికి మిమ్మల్ని అనుమతిస్తుంది.
- మైక్రో సర్వీసెస్ సంస్థాగత ప్రయోజనాలను అందిస్తాయి. వారు తరచుగా ఆర్కిటెక్చర్ గురించి మాత్రమే మాట్లాడతారు, అయితే ఏదైనా వాస్తు అనేది వ్యాపార అవసరాలను పరిష్కరించడానికి అవసరం, మరియు దాని స్వంతంగా కాదు. అందువల్ల, చిన్న జట్లలో సమస్యలను పరిష్కరించడానికి మైక్రోసర్వీస్లు బాగా సరిపోతాయని మేము చెప్పగలం, స్క్రమ్ ఇప్పుడు బాగా ప్రాచుర్యం పొందింది.
- విభజన అనేది ఒక పునరావృత ప్రక్రియ. మీరు అప్లికేషన్ను తీసుకోలేరు మరియు దానిని మైక్రోసర్వీస్లుగా విభజించలేరు. ఫలితంగా ఉత్పత్తి పని చేసే అవకాశం లేదు. మైక్రోసర్వీస్లను అంకితం చేస్తున్నప్పుడు, ఇప్పటికే ఉన్న లెగసీని తిరిగి వ్రాయడం ప్రయోజనకరం, అంటే, దానిని మనకు నచ్చిన కోడ్గా మార్చడం మరియు కార్యాచరణ మరియు వేగం పరంగా వ్యాపార అవసరాలను బాగా తీర్చడం.
ఒక చిన్న హెచ్చరిక: మైక్రోసర్వీస్లకు వెళ్లడానికి అయ్యే ఖర్చులు చాలా ముఖ్యమైనవి. ఒక్క ఇన్ఫ్రాస్ట్రక్చర్ సమస్యను పరిష్కరించడానికే చాలా సమయం పట్టింది. కాబట్టి మీరు నిర్దిష్ట స్కేలింగ్ అవసరం లేని చిన్న అప్లికేషన్ను కలిగి ఉంటే, మీ బృందం యొక్క శ్రద్ధ మరియు సమయం కోసం పోటీ పడే కస్టమర్లు పెద్ద సంఖ్యలో ఉంటే తప్ప, మైక్రోసర్వీస్లు మీకు ఈరోజు అవసరం కాకపోవచ్చు. ఇది చాలా ఖరీదైనది. మీరు మైక్రోసర్వీస్తో ప్రక్రియను ప్రారంభిస్తే, మీరు ఏకశిలా అభివృద్ధితో అదే ప్రాజెక్ట్ను ప్రారంభించినట్లయితే ఖర్చులు మొదట్లో ఎక్కువగా ఉంటాయి.
PS మరింత భావోద్వేగ కథనం (మరియు వ్యక్తిగతంగా మీ కోసం) - ప్రకారం .
నివేదిక యొక్క పూర్తి వెర్షన్ ఇక్కడ ఉంది.
మూలం: www.habr.com
