హిస్టరీ ఆఫ్ ది డోడో IS ఆర్కిటెక్చర్: యాన్ ఎర్లీ మోనోలిత్

లేదా ఒక ఏకశిలాతో ప్రతి సంతోషంగా లేని సంస్థ దాని స్వంత మార్గంలో సంతోషంగా లేదు.

డోడో పిజ్జా వ్యాపారం వలె డోడో IS వ్యవస్థ అభివృద్ధి వెంటనే ప్రారంభమైంది - 2011లో. ఇది వ్యాపార ప్రక్రియల పూర్తి మరియు పూర్తి డిజిటలైజేషన్ ఆలోచనపై ఆధారపడింది మరియు నీ సొంతంగా, ఇది 2011లో కూడా అనేక ప్రశ్నలు మరియు సందేహాలను లేవనెత్తింది. కానీ ఇప్పుడు 9 సంవత్సరాలుగా మేము ఈ మార్గాన్ని అనుసరిస్తున్నాము - మా స్వంత అభివృద్ధితో, ఇది ఏకశిలాతో ప్రారంభమైంది.

ఈ కథనం “వాస్తుశిల్పాన్ని తిరిగి వ్రాయడం మరియు ఇంత పెద్ద ఎత్తున మరియు దీర్ఘకాలిక మార్పులు ఎందుకు చేయాలి?” అనే ప్రశ్నలకు “సమాధానం”. మునుపటి కథనానికి "ది హిస్టరీ ఆఫ్ డోడో IS ఆర్కిటెక్చర్: ది పాత్ ఆఫ్ ది బ్యాక్ ఆఫీస్". డోడో IS అభివృద్ధి ఎలా ప్రారంభమైంది, ప్రారంభ నిర్మాణం ఎలా ఉంది, కొత్త మాడ్యూల్స్ ఎలా కనిపించాయి మరియు ఏ సమస్యల కారణంగా పెద్ద ఎత్తున మార్పులు చేయవలసి వచ్చింది అనే దానితో నేను ప్రారంభిస్తాను.

వ్యాసాల శ్రేణి "డోడో IS అంటే ఏమిటి?" గురించి చెబుతుంది:

1. డోడో IS (2011-2015)లో ప్రారంభ ఏకశిలా. (నువ్వు ఇక్కడ ఉన్నావు)

2. బ్యాక్ ఆఫీస్ మార్గం: ప్రత్యేక స్థావరాలు మరియు బస్సు.

3. క్లయింట్ వైపు మార్గం: బేస్ మీద ముఖభాగం (2016-2017). (పురోగతిలో ఉంది...)

4. నిజమైన మైక్రోసర్వీస్‌ల చరిత్ర. (2018-2019) (పురోగతిలో ఉంది...)

5. ఏకశిలా యొక్క కత్తిరింపు మరియు నిర్మాణం యొక్క స్థిరీకరణ పూర్తయింది. (పురోగతిలో ఉంది...)

ఆదిమ వాస్తుశిల్పం

2011లో, డోడో IS ఆర్కిటెక్చర్ ఇలా ఉంది:

ఆర్కిటెక్చర్‌లో మొదటి మాడ్యూల్ ఆర్డర్ అంగీకారం. వ్యాపార ప్రక్రియ ఇలా ఉంది:

• ఒక కస్టమర్ పిజ్జేరియాను పిలుస్తాడు;

• మేనేజర్ ఫోన్ తీసుకుంటాడు;

• ఫోన్ ద్వారా ఆర్డర్లు తీసుకుంటుంది;

• అదే సమయంలో, ఇది ఆర్డర్ అంగీకార ఇంటర్‌ఫేస్‌లో నింపుతుంది: క్లయింట్ గురించిన సమాచారం, ఆర్డర్ వివరాలపై డేటా మరియు డెలివరీ చిరునామా పరిగణనలోకి తీసుకోబడతాయి. 

సమాచార వ్యవస్థ ఇంటర్‌ఫేస్ ఇలా ఉంది...

అక్టోబర్ 2011 నుండి మొదటి వెర్షన్:

జనవరి 2012లో కొంచెం మెరుగుపడింది

సమాచార వ్యవస్థ డోడో పిజ్జా డెలివరీ పిజ్జా రెస్టారెంట్

మొదటి ఆర్డర్ తీసుకునే మాడ్యూల్‌ను అభివృద్ధి చేయడానికి వనరులు పరిమితం చేయబడ్డాయి. చాలా త్వరగా మరియు చిన్న బృందంతో చేయవలసి వచ్చింది. చిన్న బృందంలో 2 డెవలపర్లు ఉన్నారు, వారు మొత్తం భవిష్యత్తు వ్యవస్థకు పునాది వేశారు.

వారి మొదటి నిర్ణయం టెక్నాలజీ స్టాక్ యొక్క భవిష్యత్తు విధిని నిర్ణయించింది:

• ASP.NET MVC, C# భాషపై బ్యాకెండ్. డెవలపర్‌లు డాట్‌నెటర్‌లు; ఈ స్టాక్ వారికి సుపరిచితం మరియు ఆహ్లాదకరంగా ఉంది.

• బూట్‌స్ట్రాప్ మరియు J క్వెరీలో ఫ్రంటెండ్: అనుకూల శైలులు మరియు స్క్రిప్ట్‌ల ఆధారంగా వినియోగదారు ఇంటర్‌ఫేస్‌లు. 

• MySQL డేటాబేస్: లైసెన్స్ ఖర్చులు లేవు, ఉపయోగించడానికి సులభమైనది.

• Windows సర్వర్‌లోని సర్వర్‌లు, ఎందుకంటే .NET అప్పుడు Windowsలో మాత్రమే ఉంటుంది (మేము మోనో గురించి చర్చించము).

భౌతికంగా, ఇదంతా "హోస్టర్ డెస్క్"లో వ్యక్తీకరించబడింది. 

ఆర్డర్ అంగీకార అప్లికేషన్ ఆర్కిటెక్చర్

ఆ సమయంలో, ప్రతి ఒక్కరూ ఇప్పటికే మైక్రోసర్వీస్ గురించి మాట్లాడుతున్నారు మరియు SOA సుమారు 5 సంవత్సరాలు పెద్ద ప్రాజెక్టులలో ఉపయోగించబడింది, ఉదాహరణకు, WCF 2006లో విడుదలైంది. కానీ అప్పుడు వారు నమ్మదగిన మరియు నిరూపితమైన పరిష్కారాన్ని ఎంచుకున్నారు.

ఇది ఇక్కడ ఉంది.

Asp.Net MVC అనేది రేజర్, ఇది ఫారమ్ లేదా క్లయింట్ నుండి అభ్యర్థనపై సర్వర్‌లో రెండరింగ్‌తో HTML పేజీని ఉత్పత్తి చేస్తుంది. క్లయింట్‌లో, CSS మరియు JS స్క్రిప్ట్‌లు ఇప్పటికే సమాచారాన్ని ప్రదర్శిస్తాయి మరియు అవసరమైతే, J క్వెరీ ద్వారా AJAX అభ్యర్థనలను నిర్వహిస్తాయి.

సర్వర్‌లోని అభ్యర్థనలు *కంట్రోలర్ తరగతుల్లోకి వస్తాయి, ఇక్కడ పద్ధతి చివరి HTML పేజీని ప్రాసెస్ చేస్తుంది మరియు ఉత్పత్తి చేస్తుంది. కంట్రోలర్‌లు *సర్వీసెస్ అనే లాజిక్ లేయర్‌కి అభ్యర్థనలు చేస్తాయి. ప్రతి సేవలు వ్యాపారంలోని కొన్ని అంశాలకు అనుగుణంగా ఉంటాయి:

• ఉదాహరణకు, డిపార్ట్‌మెంట్‌స్ట్రక్చర్‌సర్వీస్ పిజ్జేరియాలు మరియు డిపార్ట్‌మెంట్‌లపై సమాచారాన్ని అందించింది. డిపార్ట్‌మెంట్ అనేది ఒక ఫ్రాంఛైజీ ద్వారా నిర్వహించబడే పిజ్జేరియాల సమూహం.

• రిసీవింగ్ఆర్డర్స్ సర్వీస్ ఆర్డర్ యొక్క కంటెంట్‌లను స్వీకరించింది మరియు లెక్కించింది.

• మరియు SmsService SMS పంపడం కోసం API సేవలకు కాల్ చేయడం ద్వారా SMS పంపబడింది.

సేవలు డేటాబేస్ నుండి డేటాను ప్రాసెస్ చేస్తాయి మరియు వ్యాపార తర్కాన్ని నిల్వ చేస్తాయి. ప్రతి సేవలో ఒకటి లేదా అంతకంటే ఎక్కువ *రిపోజిటరీలు తగిన పేరుతో ఉంటాయి. వారు ఇప్పటికే డేటాబేస్‌లో నిల్వ చేసిన విధానాలకు సంబంధించిన ప్రశ్నలను మరియు మ్యాపర్‌ల పొరను కలిగి ఉన్నారు. రిపోజిటరీలు వ్యాపార తర్కాన్ని కలిగి ఉన్నాయి, ముఖ్యంగా వాటిలో చాలా రిపోర్టింగ్ డేటాను ఉత్పత్తి చేశాయి. ORM ఉపయోగించబడలేదు, ప్రతి ఒక్కరూ చేతితో వ్రాసిన sqlపై ఆధారపడతారు. 

డొమైన్ మోడల్ మరియు సాధారణ సహాయక తరగతుల పొర కూడా ఉంది, ఉదాహరణకు, ఆర్డర్ క్లాస్, ఇది ఆర్డర్‌ను నిల్వ చేస్తుంది. అక్కడ, లేయర్‌లో, ఎంచుకున్న కరెన్సీకి అనుగుణంగా డిస్‌ప్లే టెక్స్ట్‌ని మార్చడానికి ఒక హెల్పర్ ఉంది.

ఇవన్నీ ఈ మోడల్ ద్వారా సూచించబడతాయి:

ఆర్డర్ మార్గం

అటువంటి ఆర్డర్‌ను రూపొందించడానికి సరళీకృత ప్రారంభ మార్గాన్ని పరిశీలిద్దాం.

ప్రారంభంలో సైట్ స్థిరంగా ఉంది. దానిపై ధరలు ఉన్నాయి మరియు పైభాగంలో ఫోన్ నంబర్ మరియు "మీకు పిజ్జా కావాలంటే, నంబర్‌కు కాల్ చేసి ఆర్డర్ చేయండి" అనే శాసనం ఉంది. ఆర్డర్ చేయడానికి, మేము సరళమైన విధానాన్ని అమలు చేయాలి: 

• క్లయింట్ ధరలతో కూడిన స్టాటిక్ వెబ్‌సైట్‌కి వెళ్లి, ఉత్పత్తులను ఎంచుకుని, వెబ్‌సైట్‌లో జాబితా చేయబడిన నంబర్‌కు కాల్ చేస్తాడు.

• కస్టమర్ అతను ఆర్డర్‌కు జోడించాలనుకుంటున్న ఉత్పత్తులకు పేరు పెడతాడు.

• అతని చిరునామా మరియు పేరును ఇస్తుంది.

• ఆపరేటర్ ఆర్డర్‌ను అంగీకరిస్తారు.

• ఆర్డర్ ఆమోదించబడిన ఆర్డర్‌ల ఇంటర్‌ఫేస్‌లో ప్రదర్శించబడుతుంది.

ఇది అన్ని మెను ప్రదర్శనతో మొదలవుతుంది. లాగిన్ అయిన ఆపరేటర్ వినియోగదారు ఒకేసారి ఒక ఆర్డర్‌ను మాత్రమే అంగీకరిస్తారు. అందువల్ల, డ్రాఫ్ట్ కార్ట్ దాని సెషన్‌లో నిల్వ చేయబడుతుంది (వినియోగదారు యొక్క సెషన్ మెమరీలో నిల్వ చేయబడుతుంది). ఉత్పత్తులు మరియు కస్టమర్ సమాచారాన్ని కలిగి ఉన్న కార్ట్ వస్తువు ఉంది.

క్లయింట్ ఉత్పత్తికి పేరు పెట్టాడు, ఆపరేటర్ క్లిక్ చేస్తాడు + ఉత్పత్తి పక్కన, మరియు ఒక అభ్యర్థన సర్వర్‌కు పంపబడుతుంది. ఉత్పత్తి గురించిన సమాచారం డేటాబేస్ నుండి తీసివేయబడుతుంది మరియు ఉత్పత్తి గురించిన సమాచారం కార్ట్‌కు జోడించబడుతుంది.

వ్యాఖ్య. అవును, ఇక్కడ మీరు డేటాబేస్ నుండి ఉత్పత్తిని తీసివేయవలసిన అవసరం లేదు, కానీ దానిని ఫ్రంట్ ఎండ్ నుండి బదిలీ చేయండి. కానీ స్పష్టత కోసం, నేను బేస్ నుండి సరిగ్గా మార్గాన్ని చూపించాను. 

తరువాత, క్లయింట్ చిరునామా మరియు పేరు నమోదు చేయండి. 

మీరు "ఆర్డర్‌ని సృష్టించు" క్లిక్ చేసినప్పుడు:

• మేము OrderController.SaveOrder()కి అభ్యర్థనను పంపుతాము.

• మేము సెషన్ నుండి కార్ట్ పొందుతాము, మనకు అవసరమైన పరిమాణంలో ఉత్పత్తులు ఉన్నాయి.

• మేము క్లయింట్ గురించిన సమాచారంతో కార్ట్‌ను సప్లిమెంట్ చేస్తాము మరియు దానిని డేటాబేస్‌లో సేవ్ చేసే రిసీవింగ్‌ఆర్డర్ సర్వీస్ క్లాస్ యొక్క యాడ్‌ఆర్డర్ పద్ధతికి పంపుతాము. 

• డేటాబేస్ ఆర్డర్, ఆర్డర్ యొక్క కంటెంట్‌లు, క్లయింట్‌తో పట్టికలను కలిగి ఉంది మరియు అవి అన్నీ కనెక్ట్ చేయబడ్డాయి.

• ఆర్డర్ డిస్‌ప్లే ఇంటర్‌ఫేస్ వెళ్లి తాజా ఆర్డర్‌లను బయటకు తీసి వాటిని ప్రదర్శిస్తుంది.

కొత్త మాడ్యూల్స్

ఆర్డర్‌ను స్వీకరించడం ముఖ్యం మరియు అవసరం. మీకు విక్రయించడానికి ఆర్డర్ లేకపోతే మీరు పిజ్జా వ్యాపారాన్ని నిర్వహించలేరు. అందువల్ల, సిస్టమ్ కార్యాచరణను పొందడం ప్రారంభించింది - సుమారు 2012 నుండి 2015 వరకు. ఈ సమయంలో, సిస్టమ్ యొక్క అనేక విభిన్న బ్లాక్‌లు కనిపించాయి, వీటిని నేను పిలుస్తాను మాడ్యూల్స్, సేవ లేదా ఉత్పత్తి భావనకు విరుద్ధంగా. 

మాడ్యూల్ అనేది కొన్ని సాధారణ వ్యాపార లక్ష్యంతో ఐక్యమైన ఫంక్షన్ల సమితి. అంతేకాకుండా, అవి భౌతికంగా ఒకే అప్లికేషన్‌లో ఉన్నాయి.

మాడ్యూళ్లను సిస్టమ్ బ్లాక్స్ అని పిలుస్తారు. ఉదాహరణకు, ఇది రిపోర్టింగ్ మాడ్యూల్, అడ్మిన్ ఇంటర్‌ఫేస్‌లు, వంటగది ఉత్పత్తి ట్రాకర్, అధికారం. ఇవన్నీ విభిన్న వినియోగదారు ఇంటర్‌ఫేస్‌లు, కొన్ని విభిన్న దృశ్య శైలులను కలిగి ఉంటాయి. అంతేకాకుండా, ప్రతిదీ ఒక అప్లికేషన్, ఒక రన్నింగ్ ప్రక్రియలో ఉంటుంది. 

సాంకేతికంగా, మాడ్యూల్స్ ఏరియాగా రూపొందించబడ్డాయి (ఈ ఆలోచన కూడా అలాగే ఉంది asp.net కోర్) ఫ్రంటెండ్, మోడల్స్, అలాగే వారి స్వంత కంట్రోలర్ తరగతుల కోసం ప్రత్యేక ఫైల్‌లు ఉన్నాయి. ఫలితంగా, వ్యవస్థ అటువంటి నుండి రూపాంతరం చెందింది ...

...దీనికి:

కొన్ని మాడ్యూల్స్ ప్రత్యేక సైట్లు (ఎక్జిక్యూటబుల్ ప్రాజెక్ట్) ద్వారా అమలు చేయబడతాయి, పూర్తిగా ప్రత్యేక కార్యాచరణ కారణంగా మరియు కొంతవరకు వేరు వేరు, మరింత దృష్టి కేంద్రీకరించబడిన అభివృద్ధి కారణంగా. ఇది:

• సైట్ - మొదటి వెర్షన్ వెబ్సైట్ dodopizza.ru.

• ఎగుమతి: 1C కోసం డోడో IS నుండి నివేదికలను డౌన్‌లోడ్ చేస్తోంది. 

• వ్యక్తిగత - ఉద్యోగి వ్యక్తిగత ఖాతా. ఇది విడిగా అభివృద్ధి చేయబడింది మరియు దాని స్వంత ఎంట్రీ పాయింట్ మరియు ప్రత్యేక డిజైన్‌ను కలిగి ఉంది.

• fs - స్టాటిక్ హోస్టింగ్ కోసం ప్రాజెక్ట్. తర్వాత మేము అకామై CDNకి మొత్తం స్టాటిక్ కంటెంట్‌ని తరలించి, దాని నుండి దూరమయ్యాము. 

మిగిలిన బ్లాక్‌లు బ్యాక్‌ఆఫీస్ అప్లికేషన్‌లో ఉన్నాయి. 

పేర్ల వివరణ:

• క్యాషియర్ - రెస్టారెంట్ క్యాష్ డెస్క్.

• ShiftManager - “Shift Manager” పాత్ర కోసం ఇంటర్‌ఫేస్‌లు: పిజ్జేరియా అమ్మకాలపై కార్యాచరణ గణాంకాలు, ఉత్పత్తులను స్టాప్ లిస్ట్‌లో ఉంచే సామర్థ్యం, ​​ఆర్డర్‌ను మార్చడం.

• OfficeManager - “పిజ్జేరియా మేనేజర్” మరియు “ఫ్రాంచైజీ” పాత్రల కోసం ఇంటర్‌ఫేస్‌లు. ఇక్కడ మీరు పిజ్జేరియాను సెటప్ చేయడం, దాని బోనస్ ప్రమోషన్‌లు, ఉద్యోగులను స్వీకరించడం మరియు పని చేయడం మరియు నివేదికల కోసం ఫంక్షన్‌లను కనుగొనవచ్చు.

• పబ్లిక్‌స్క్రీన్‌లు - పిజ్జేరియాల్లో వేలాడుతున్న టీవీలు మరియు టాబ్లెట్‌ల కోసం ఇంటర్‌ఫేస్‌లు. టీవీలు డెలివరీ అయిన తర్వాత మెను, ప్రకటనల సమాచారం మరియు ఆర్డర్ స్థితిని ప్రదర్శిస్తాయి. 

వారు ఒక సాధారణ సేవా పొరను, Dodo.Core డొమైన్ తరగతుల యొక్క సాధారణ బ్లాక్‌ను మరియు ఒక సాధారణ స్థావరాన్ని ఉపయోగించారు. కొన్నిసార్లు వారు ఇప్పటికీ ఒకరికొకరు మార్గాల ద్వారా దారి తీయవచ్చు. అదనంగా, dodopizza.ru లేదా personal.dodopizza.ru వంటి వ్యక్తిగత సైట్‌లు కూడా సాధారణ సేవలను యాక్సెస్ చేశాయి.

కొత్త మాడ్యూల్‌లు కనిపించినప్పుడు, డేటాబేస్‌లోని సేవలు, నిల్వ చేసిన విధానాలు మరియు పట్టికల కోసం ఇప్పటికే సృష్టించిన కోడ్‌ను వీలైనంత వరకు మళ్లీ ఉపయోగించేందుకు మేము ప్రయత్నించాము. 

సిస్టమ్‌లో తయారు చేయబడిన మాడ్యూల్స్ స్థాయిని బాగా అర్థం చేసుకోవడానికి, అభివృద్ధి ప్రణాళికలతో 2012 నుండి రేఖాచిత్రం ఇక్కడ ఉంది:

2015 నాటికి, ప్రతిదీ ట్రాక్‌లో ఉంది మరియు ఇంకా ఎక్కువ ఉత్పత్తిలో ఉంది.

• ఆర్డర్ అంగీకారం కాంటాక్ట్ సెంటర్ యొక్క ప్రత్యేక బ్లాక్‌గా పెరిగింది, ఇక్కడ ఆర్డర్‌ను ఆపరేటర్ అంగీకరించారు.

• మెనులు మరియు సమాచారంతో కూడిన పబ్లిక్ స్క్రీన్‌లు పిజ్జేరియాలలో కనిపించాయి.

• వంటగది మాడ్యూల్‌ను కలిగి ఉంది, ఇది కొత్త ఆర్డర్ వచ్చినప్పుడు స్వయంచాలకంగా "న్యూ పిజ్జా" వాయిస్ సందేశాన్ని ప్లే చేస్తుంది మరియు కొరియర్ కోసం ఇన్‌వాయిస్‌ను కూడా ప్రింట్ చేస్తుంది. ఇది వంటగదిలో ప్రక్రియలను చాలా సులభతరం చేస్తుంది మరియు ఉద్యోగులు పెద్ద సంఖ్యలో సాధారణ కార్యకలాపాల ద్వారా పరధ్యానంలో ఉండకుండా అనుమతిస్తుంది.

• డెలివరీ బ్లాక్ ప్రత్యేక డెలివరీ క్యాషియర్‌గా మారింది, ఇక్కడ ఆర్డర్ కొరియర్‌కు జారీ చేయబడింది, అతను గతంలో తన షిఫ్ట్ తీసుకున్నాడు. అతని జీతం లెక్కించడానికి అతని పని గంటలను పరిగణనలోకి తీసుకున్నారు. 

సమాంతరంగా, 2012 నుండి 2015 వరకు, 10 కంటే ఎక్కువ డెవలపర్లు కనిపించారు, 35 పిజ్జేరియాలు తెరవబడ్డాయి, సిస్టమ్ రొమేనియాకు పంపబడింది మరియు USA లో పాయింట్ల ప్రారంభానికి సిద్ధం చేయబడింది. డెవలపర్లు ఇకపై అన్ని పనులలో పాల్గొనలేదు, కానీ జట్లుగా విభజించబడ్డారు. ప్రతి ఒక్కటి సిస్టమ్ యొక్క దాని స్వంత భాగంలో ప్రత్యేకించబడింది. 

సమస్యలు

వాస్తుశిల్పం (కానీ మాత్రమే కాదు) కారణంగా సహా.

స్థావరంలో గందరగోళం

ఒక బేస్ సౌకర్యవంతంగా ఉంటుంది. స్థిరత్వాన్ని సాధించడం సాధ్యమవుతుంది మరియు రిలేషనల్ డేటాబేస్‌లలో నిర్మించిన సాధనాల వ్యయంతో. దానితో పని చేయడం సుపరిచితం మరియు అనుకూలమైనది, ప్రత్యేకించి కొన్ని పట్టికలు మరియు తక్కువ డేటా ఉంటే.

కానీ 4 సంవత్సరాల అభివృద్ధిలో, డేటాబేస్ సుమారు 600 పట్టికలు, 1500 నిల్వ చేసిన విధానాలను కలిగి ఉంది, వీటిలో చాలా తర్కం కూడా ఉన్నాయి. దురదృష్టవశాత్తు, MySQLతో పని చేస్తున్నప్పుడు నిల్వ చేయబడిన విధానాలు ఎక్కువ ప్రయోజనాన్ని అందించవు. అవి డేటాబేస్ ద్వారా కాష్ చేయబడవు మరియు వాటిలో లాజిక్ నిల్వ చేయడం అభివృద్ధి మరియు డీబగ్గింగ్‌ను క్లిష్టతరం చేస్తుంది. కోడ్‌ని మళ్లీ ఉపయోగించడం కూడా కష్టం.

చాలా పట్టికలలో తగిన సూచికలు లేవు, ఎక్కడో, దీనికి విరుద్ధంగా, చాలా సూచికలు ఉన్నాయి, ఇది చొప్పించడం కష్టతరం చేసింది. దాదాపు 20 టేబుల్‌లను సవరించాల్సి ఉంది-ఆర్డర్‌ని సృష్టించడానికి లావాదేవీ దాదాపు 3-5 సెకన్లు పట్టవచ్చు. 

పట్టికలలోని డేటా ఎల్లప్పుడూ సరైన రూపంలో ఉండదు. ఎక్కడా డీనార్మలైజేషన్ చేయాల్సిన అవసరం ఏర్పడింది. క్రమం తప్పకుండా స్వీకరించే డేటాలో కొన్ని XML నిర్మాణం రూపంలో కాలమ్‌లో ఉన్నాయి, ఇది అమలు సమయం, సుదీర్ఘమైన ప్రశ్నలు మరియు సంక్లిష్టమైన అభివృద్ధిని పెంచింది.

అదే పట్టికలు చాలా లోబడి ఉన్నాయి భిన్నమైన అభ్యర్థనలు. పైన పేర్కొన్న పట్టిక వంటి జనాదరణ పొందిన పట్టికలు ముఖ్యంగా ప్రభావితమయ్యాయి ఆదేశాలు లేదా పట్టికలు పిజ్జా షాప్. వంటగది మరియు విశ్లేషణలలో కార్యాచరణ ఇంటర్‌ఫేస్‌లను ప్రదర్శించడానికి అవి ఉపయోగించబడ్డాయి. సైట్ వారిని కూడా సంప్రదించింది (dodopizza.ru), ఏ సమయంలోనైనా చాలా అభ్యర్థనలు అకస్మాత్తుగా రావచ్చు. 

డేటా సమగ్రపరచబడలేదు మరియు అనేక లెక్కలు బేస్ ఉపయోగించి ఫ్లైలో జరిగాయి. ఇది అనవసరమైన లెక్కలు మరియు అదనపు భారాన్ని సృష్టించింది. 

తరచుగా కోడ్ అలా చేయలేనప్పుడు డేటాబేస్‌లోకి వెళ్లింది. ఎక్కడా బల్క్ ఆపరేషన్ల కొరత ఉంది, ఎక్కడో ఒక అభ్యర్థనను వేగవంతం చేయడానికి మరియు విశ్వసనీయతను పెంచడానికి కోడ్ ద్వారా అనేక భాగాలుగా విభజించాల్సిన అవసరం ఉంది. 

కోడ్‌లో సమన్వయం మరియు గందరగోళం

వ్యాపారంలో తమ వంతు బాధ్యత వహించాల్సిన మాడ్యూల్స్ నిజాయితీగా చేయలేదు. వాటిలో కొన్ని పాత్రల కోసం డూప్లికేషన్ ఫంక్షన్లు ఉన్నాయి. ఉదాహరణకు, తన నగరంలోని నెట్‌వర్క్ యొక్క మార్కెటింగ్ కార్యకలాపాలకు బాధ్యత వహించే స్థానిక విక్రయదారుడు “అడ్మిన్” ఇంటర్‌ఫేస్ (ప్రమోషన్‌లను సెటప్ చేయడానికి) మరియు “ఆఫీస్ మేనేజర్” ఇంటర్‌ఫేస్ (ప్రమోషన్‌ల ప్రభావాన్ని వీక్షించడానికి) రెండింటినీ ఉపయోగించాల్సి ఉంటుంది వ్యాపారం). వాస్తవానికి, రెండు మాడ్యూల్స్ లోపల బోనస్ ప్రమోషన్‌లతో పనిచేసిన ఒకే సేవను ఉపయోగించారు.

సేవలు (ఒక ఏకశిలా పెద్ద ప్రాజెక్ట్‌లోని తరగతులు) తమ డేటాను మెరుగుపరచుకోవడానికి ఒకదానికొకటి కాల్ చేసుకోవచ్చు.

డేటాను నిల్వ చేసే మోడల్ తరగతులతో, కోడ్‌లోని పని భిన్నంగా జరిగింది. మీరు అవసరమైన ఫీల్డ్‌లను పేర్కొనగలిగే కన్‌స్ట్రక్టర్‌లు ఎక్కడో ఉన్నారు. కొన్నిచోట్ల ఇది పబ్లిక్ ప్రాపర్టీల ద్వారా జరిగింది. వాస్తవానికి, డేటాబేస్ నుండి డేటాను పొందడం మరియు మార్చడం వైవిధ్యంగా ఉంటుంది. 

లాజిక్ కంట్రోలర్‌లు లేదా సర్వీస్ క్లాస్‌లలో ఉంది. 

ఇవి చిన్న సమస్యల వలె కనిపిస్తున్నాయి, కానీ అవి అభివృద్ధిని బాగా తగ్గించాయి మరియు నాణ్యతను తగ్గించాయి, అస్థిరత మరియు దోషాలకు దారితీశాయి. 

పెద్ద అభివృద్ధి యొక్క సంక్లిష్టత

అభివృద్ధిలోనే ఇబ్బందులు తలెత్తాయి. సిస్టమ్ యొక్క వివిధ బ్లాక్‌లను మరియు సమాంతరంగా సృష్టించడం అవసరం. ప్రతి భాగం యొక్క అవసరాలను ఒకే కోడ్‌లో అమర్చడం చాలా కష్టంగా మారింది. ఒకే సమయంలో అన్ని భాగాలను అంగీకరించడం మరియు దయచేసి చేయడం సులభం కాదు. దీనికి సాంకేతికతలో పరిమితులు జోడించబడ్డాయి, ముఖ్యంగా బేస్ మరియు ఫ్రంట్ ఎండ్‌కు సంబంధించి. అధిక-స్థాయి ఫ్రేమ్‌వర్క్‌లకు అనుకూలంగా J క్వెరీని వదిలివేయడం అవసరం, ముఖ్యంగా క్లయింట్ సేవల (వెబ్‌సైట్) పరంగా.

సిస్టమ్‌లోని కొన్ని భాగాలు దీనికి మరింత అనుకూలంగా ఉండే డేటాబేస్‌లను ఉపయోగించవచ్చు. ఉదాహరణకు, ఆర్డర్ కార్ట్‌ను నిల్వ చేయడానికి Redis నుండి CosmosDBకి మారడానికి మేము తర్వాత ఒక ఉదాహరణను కలిగి ఉన్నాము. 

తమ ప్రాంతంలో పని చేస్తున్న బృందాలు మరియు డెవలపర్‌లు తమ సేవలకు అభివృద్ధి పరంగా మరియు రోల్‌అవుట్ పరంగా మరింత స్వాతంత్ర్యం కావాలని స్పష్టంగా కోరుకుంటున్నారు. విలీన సమయంలో విభేదాలు, విడుదల సమయంలో సమస్యలు. 5 మంది డెవలపర్‌లకు ఈ సమస్య చాలా తక్కువగా ఉంటే, 10 మందితో, ఇంకా ఎక్కువగా ప్రణాళికాబద్ధమైన వృద్ధితో, ప్రతిదీ మరింత తీవ్రంగా మారుతుంది. మరియు రాబోయేది మొబైల్ అప్లికేషన్ యొక్క అభివృద్ధి (ఇది 2017 లో ప్రారంభమైంది మరియు 2018 లో ఉంది పెద్ద పతనం). 

సిస్టమ్ యొక్క వివిధ భాగాలకు వేర్వేరు స్థిరత్వ సూచికలు అవసరం, కానీ సిస్టమ్ యొక్క బలమైన కనెక్టివిటీ కారణంగా, మేము దీన్ని అందించలేకపోయాము. అడ్మిన్ ప్యానెల్‌లో కొత్త ఫంక్షన్‌ని డెవలప్ చేస్తున్నప్పుడు ఏర్పడిన లోపం సైట్‌లో ఆర్డర్ అంగీకారానికి దారితీయవచ్చు, ఎందుకంటే కోడ్ సాధారణమైనది మరియు పునర్వినియోగపరచదగినది, డేటాబేస్ మరియు డేటా కూడా ఒకే విధంగా ఉంటాయి.

అటువంటి మోనోలిథిక్-మాడ్యులర్ ఆర్కిటెక్చర్ ఫ్రేమ్‌వర్క్‌లో ఈ లోపాలు మరియు సమస్యలను నివారించడం బహుశా సాధ్యమవుతుంది: బాధ్యతల విభజనను సృష్టించడం, కోడ్ మరియు డేటాబేస్ రెండింటినీ రీఫాక్టర్ చేయడం, ఒకదానికొకటి స్పష్టంగా వేరుచేయడం మరియు ప్రతిరోజు నాణ్యతను పర్యవేక్షించడం. కానీ ఎంచుకున్న నిర్మాణ పరిష్కారాలు మరియు వ్యవస్థ యొక్క కార్యాచరణను త్వరగా విస్తరించడంపై దృష్టి పెట్టడం స్థిరత్వ విషయాలలో సమస్యలకు దారితీసింది.

బ్లాగ్ పవర్ ఆఫ్ మైండ్ రెస్టారెంట్లలో నగదు రిజిస్టర్లను ఎలా ఉంచింది

పిజ్జేరియా నెట్‌వర్క్ (మరియు లోడ్) యొక్క పెరుగుదల అదే వేగంతో కొనసాగితే, కొంతకాలం తర్వాత చుక్కలు సిస్టమ్ కోలుకోలేని విధంగా ఉంటాయి. 2015 నాటికి మనం ఎదుర్కొనే సమస్యలను ఈ క్రింది కథనం చక్కగా వివరిస్తుంది. 

బ్లాగులో"మనస్సు శక్తి"మొత్తం నెట్‌వర్క్ కోసం సంవత్సరానికి ఆదాయ డేటాను చూపించే విడ్జెట్ ఉంది. ఈ డేటాను అందించే పబ్లిక్ డోడో APIని విడ్జెట్ యాక్సెస్ చేసింది. ఈ గణాంకాలు ఇప్పుడు అందుబాటులో ఉన్నాయి http://dodopizzastory.com/. విడ్జెట్ ప్రతి పేజీలో చూపబడుతుంది మరియు ప్రతి 20 సెకన్లకు టైమర్‌లో అభ్యర్థనలు చేయబడింది. అభ్యర్థన api.dodopizza.ruకి వెళ్లి ఇలా అడిగారు:

• నెట్వర్క్లో పిజ్జేరియాల సంఖ్య;

• సంవత్సరం ప్రారంభం నుండి మొత్తం నెట్‌వర్క్ ఆదాయం;

• నేటి ఆదాయం.

ఆదాయ గణాంకాల కోసం ఒక అభ్యర్థన నేరుగా డేటాబేస్‌కు వెళ్లి ఆర్డర్‌లపై డేటాను అభ్యర్థించడం ప్రారంభించింది, ఫ్లైలో నేరుగా డేటాను సమగ్రపరచడం మరియు మొత్తాన్ని జారీ చేయడం. 

రెస్టారెంట్లలోని నగదు రిజిస్టర్‌లు అదే ఆర్డర్‌ల పట్టికకు వెళ్లి, ఈరోజు ఆమోదించబడిన ఆర్డర్‌ల జాబితాను అప్‌లోడ్ చేసి, దానికి కొత్త ఆర్డర్‌లు జోడించబడ్డాయి. నగదు రిజిస్టర్‌లు ప్రతి 5 సెకన్లకు లేదా పేజీని రిఫ్రెష్ చేసినప్పుడు వారి అభ్యర్థనలను చేస్తారు.

రేఖాచిత్రం ఇలా కనిపించింది:

శరదృతువులో ఒక రోజు, ఫ్యోడర్ ఓవ్చిన్నికోవ్ తన బ్లాగులో సుదీర్ఘమైన మరియు ప్రసిద్ధ కథనాన్ని వ్రాసాడు. చాలా మంది బ్లాగ్‌కి వచ్చారు మరియు ప్రతిదీ జాగ్రత్తగా చదవడం ప్రారంభించారు. వచ్చిన ప్రతి ఒక్కరూ కథనాన్ని చదువుతున్నప్పుడు, రెవెన్యూ విడ్జెట్ సరిగ్గా పని చేసి, ప్రతి 20 సెకన్లకు APIని అభ్యర్థించింది.

నెట్‌వర్క్‌లోని అన్ని పిజ్జేరియాల కోసం సంవత్సరం ప్రారంభం నుండి అన్ని ఆర్డర్‌ల మొత్తాన్ని లెక్కించడానికి API నిల్వ చేయబడిన విధానాన్ని పిలిచింది. అగ్రిగేషన్ ఆర్డర్‌ల పట్టికపై ఆధారపడింది, ఇది బాగా ప్రాచుర్యం పొందింది. ఆ సమయంలో అన్ని ఓపెన్ రెస్టారెంట్లలోని అన్ని నగదు రిజిస్టర్లు దీనికి వెళ్తాయి. నగదు రిజిస్టర్‌లు ప్రతిస్పందించడం ఆగిపోయాయి మరియు ఆర్డర్‌లు ఆమోదించబడలేదు. అవి కూడా సైట్ నుండి ఆమోదించబడలేదు, ట్రాకర్‌లో కనిపించలేదు మరియు షిఫ్ట్ మేనేజర్ వాటిని తన ఇంటర్‌ఫేస్‌లో చూడలేకపోయాడు. 

ఇది ఒక్కటే కథ కాదు. 2015 పతనం నాటికి, ప్రతి శుక్రవారం సిస్టమ్‌పై లోడ్ చాలా క్లిష్టమైనది. మేము అనేక సార్లు పబ్లిక్ APIని ఆఫ్ చేసాము మరియు ఒకసారి ఏమీ సహాయం చేయనందున మేము సైట్‌ను కూడా ఆఫ్ చేయాల్సి వచ్చింది. భారీ లోడ్‌ల కింద షట్‌డౌన్ ఆర్డర్‌తో సేవల జాబితా కూడా ఉంది.

ఈ సమయం నుండి, లోడ్‌లతో మరియు సిస్టమ్ స్థిరీకరణ కోసం మా పోరాటం ప్రారంభమవుతుంది (శరదృతువు 2015 నుండి శరదృతువు 2018 వరకు). అప్పుడే జరిగింది"ది గ్రేట్ ఫాల్" ఇంకా, కొన్నిసార్లు వైఫల్యాలు కూడా ఉన్నాయి, వాటిలో కొన్ని చాలా సున్నితమైనవి, అయితే సాధారణ అస్థిరత కాలం ఇప్పుడు ముగిసినట్లు పరిగణించవచ్చు.

వేగవంతమైన వ్యాపార వృద్ధి

"వెంటనే బాగా" ఎందుకు చేయలేకపోయింది? కింది గ్రాఫ్‌లను చూడండి.

అలాగే 2014-2015లో రొమేనియాలో ఓపెనింగ్ జరగగా, USAలో ఓపెనింగ్ సిద్ధమవుతోంది.

గొలుసు చాలా త్వరగా పెరిగింది, కొత్త దేశాలు తెరవబడ్డాయి, పిజ్జేరియాల కొత్త ఫార్మాట్‌లు కనిపించాయి, ఉదాహరణకు, ఫుడ్ కోర్టులో పిజ్జేరియా తెరవబడింది. వీటన్నింటికీ ప్రత్యేకంగా డోడో IS యొక్క విధులను విస్తరించడానికి గణనీయమైన శ్రద్ధ అవసరం. ఈ విధులన్నీ లేకుండా, వంటగదిలో ట్రాక్ చేయకుండా, సిస్టమ్‌లోని ఉత్పత్తులు మరియు నష్టాలను లెక్కించకుండా, ఫుడ్ కోర్టు హాల్‌లో ఆర్డర్‌ల డెలివరీని ప్రదర్శించకుండా, మనం ఇప్పుడు “సరైన” నిర్మాణం మరియు “సరైనది” గురించి మాట్లాడే అవకాశం లేదు. ”అభివృద్ధి విధానం.

వాస్తుశిల్పం యొక్క సకాలంలో పునర్విమర్శకు మరియు సాంకేతిక సమస్యలపై సాధారణ దృష్టికి మరొక అడ్డంకి 2014 సంక్షోభం. ఇటువంటి విషయాలు ముఖ్యంగా డోడో పిజ్జా వంటి యువ వ్యాపారానికి జట్ల వృద్ధి అవకాశాలను దెబ్బతీస్తాయి.

సహాయపడిన శీఘ్ర పరిష్కారాలు

సమస్యలకు పరిష్కారాలు కావాలి. సాంప్రదాయకంగా, పరిష్కారాలను 2 సమూహాలుగా విభజించవచ్చు:

• వేగవంతమైనవి మంటలను ఆర్పివేస్తాయి మరియు మాకు భద్రత యొక్క చిన్న మార్జిన్‌ను ఇస్తాయి మరియు మార్చడానికి మాకు సమయాన్ని కొనుగోలు చేస్తాయి.

• దైహిక మరియు, అందువలన, దీర్ఘ. అనేక మాడ్యూల్‌లను రీఇంజనీరింగ్ చేయడం, ఏకశిలా నిర్మాణాన్ని ప్రత్యేక సేవలుగా విభజించడం (వాటిలో ఎక్కువ భాగం మైక్రో కాదు, స్థూల సేవలు, మరియు దీని గురించి మరిన్ని విషయాలు ఉన్నాయి ఆండ్రీ మోరెవ్స్కీ నివేదిక). 

శీఘ్ర మార్పుల పొడి జాబితా:

స్కేల్ అప్ బేస్ మాస్టర్

వాస్తవానికి, లోడ్‌ను ఎదుర్కోవడానికి చేసే మొదటి విషయం సర్వర్ శక్తిని పెంచడం. ఇది మాస్టర్ డేటాబేస్ మరియు వెబ్ సర్వర్‌ల కోసం జరిగింది. అయ్యో, ఇది ఒక నిర్దిష్ట పరిమితి వరకు మాత్రమే సాధ్యమవుతుంది; అంతకు మించి ఇది చాలా ఖరీదైనది.

2014 నుండి, మేము అజూర్‌కి మారాము; మేము ఈ అంశం గురించి అప్పట్లో వ్యాసంలో కూడా వ్రాసాము "మైక్రోసాఫ్ట్ అజూర్ క్లౌడ్‌ని ఉపయోగించి డోడో పిజ్జా ఎలా పిజ్జాని అందిస్తుంది" కానీ సర్వర్ వరుస పెరుగుదల తర్వాత, బేస్ ధర పరిమితిని చేరుకుంది. 

చదవడానికి డేటాబేస్ ప్రతిరూపాలు

మేము బేస్ కోసం రెండు ప్రతిరూపాలను తయారు చేసాము:

రీడ్ రెప్లికా డైరెక్టరీ అభ్యర్థనల కోసం. ఇది నగరం, వీధి, పిజ్జేరియా, ఉత్పత్తులు (నెమ్మదిగా మారిన డొమైన్) వంటి డైరెక్టరీలను చదవడానికి మరియు చిన్న ఆలస్యం ఆమోదయోగ్యమైన ఇంటర్‌ఫేస్‌లలో ఉపయోగించబడుతుంది. వీటిలో 2 ప్రతిరూపాలు ఉన్నాయి, మేము మాస్టర్ మాదిరిగానే వాటి లభ్యతను నిర్ధారించాము.

రిపోర్ట్ అభ్యర్థనల కోసం రీడ్ రెప్లికా. ఈ డేటాబేస్ తక్కువ లభ్యతను కలిగి ఉంది, కానీ అన్ని నివేదికలు దీనికి వెళ్లాయి. భారీ డేటా రీకాలిక్యులేషన్‌ల కోసం వారు భారీ అభ్యర్థనలను కలిగి ఉండవచ్చు, కానీ అవి ప్రధాన డేటాబేస్ మరియు కార్యాచరణ ఇంటర్‌ఫేస్‌లను ప్రభావితం చేయవు. 

కోడ్‌లో కాష్‌లు

కోడ్‌లో ఎక్కడా కాష్‌లు లేవు (అస్సలు). ఇది లోడ్ చేయబడిన డేటాబేస్కు అదనపు, ఎల్లప్పుడూ అవసరం లేని అభ్యర్థనలకు దారితీసింది. మొదట, కాష్‌లు మెమరీలో మరియు బాహ్య కాష్ సేవలో ఉన్నాయి, ఇది రెడిస్. ప్రతిదీ సమయం చెల్లనిది, సెట్టింగులు కోడ్‌లో పేర్కొనబడ్డాయి.

బ్యాకెండ్ కోసం బహుళ సర్వర్లు

పెరిగిన లోడ్‌లను తట్టుకోవడానికి అప్లికేషన్ యొక్క బ్యాకెండ్ కూడా స్కేల్ చేయబడాలి. ఒక IIS సర్వర్ నుండి క్లస్టర్‌ను తయారు చేయడం అవసరం. మేము తరలించాము అప్లికేషన్ సెషన్ RedisCacheలో మెమరీ నుండి, రౌండ్ రాబిన్‌తో ఒక సాధారణ లోడ్ బ్యాలెన్సర్ వెనుక అనేక సర్వర్‌లను సృష్టించడం సాధ్యమైంది. మొదట, కాష్‌ల కోసం అదే రెడిస్ ఉపయోగించబడింది, తరువాత అవి అనేక భాగాలుగా విభజించబడ్డాయి. 

ఫలితంగా, వాస్తుశిల్పం మరింత క్లిష్టంగా మారింది...

...కానీ కొంత టెన్షన్ రిలీఫ్ అయింది.

ఆపై లోడ్ చేయబడిన భాగాలను మళ్లీ చేయడం అవసరం, ఇది మేము తీసుకున్నాము. మేము దీని గురించి తదుపరి భాగంలో మాట్లాడుతాము.

మూలం: www.habr.com