హిస్టరీ ఆఫ్ ది డోడో IS ఆర్కిటెక్చర్: ది బ్యాక్ ఆఫీస్ పాత్

హబ్ర్ ప్రపంచాన్ని మారుస్తోంది. మేము ఒక సంవత్సరానికి పైగా బ్లాగింగ్ చేస్తున్నాము. సుమారు ఆరు నెలల క్రితం మేము ఖబ్రోవ్స్క్ నివాసితుల నుండి చాలా తార్కిక అభిప్రాయాన్ని అందుకున్నాము: “డోడో, మీకు మీ స్వంత సిస్టమ్ ఉందని మీరు ప్రతిచోటా చెబుతారు. ఇది ఎలాంటి వ్యవస్థ? మరియు పిజ్జేరియా చైన్‌కి ఇది ఎందుకు అవసరం?"

మేము కూర్చుని ఆలోచించాము మరియు మీరు చెప్పింది నిజమని గ్రహించాము. మేము మా వేళ్ళతో ప్రతిదీ వివరించడానికి ప్రయత్నిస్తున్నాము, కానీ అది చిరిగిపోయిన ముక్కలుగా వస్తుంది మరియు ఎక్కడా సిస్టమ్ గురించి పూర్తి వివరణ లేదు. ఆ విధంగా సమాచారాన్ని సేకరించడం, రచయితల కోసం శోధించడం మరియు డోడో IS గురించి వరుస కథనాలు రాయడం వంటి సుదీర్ఘ ప్రయాణం ప్రారంభమైంది. వెళ్దాం!

కృతజ్ఞతలు: మీ అభిప్రాయాన్ని మాతో పంచుకున్నందుకు ధన్యవాదాలు. అతనికి ధన్యవాదాలు, మేము చివరకు సిస్టమ్‌ను వివరించాము, టెక్నోరాడార్‌ను కంపైల్ చేసాము మరియు త్వరలో మా ప్రక్రియల యొక్క పెద్ద వివరణను విడుదల చేస్తాము. నువ్వు లేకుంటే మరో ఐదేళ్లు ఇలాగే కూర్చుంటాం.

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

1. డోడో IS (2011-2015)లో ప్రారంభ ఏకశిలా. (పురోగతిలో ఉంది...)
2. బ్యాక్ ఆఫీస్ మార్గం: ప్రత్యేక స్థావరాలు మరియు బస్సు. (నువ్వు ఇక్కడ ఉన్నావు)
3. క్లయింట్ వైపు మార్గం: బేస్ మీద ముఖభాగం (2016-2017). (పురోగతిలో ఉంది...)
4. నిజమైన మైక్రోసర్వీస్‌ల చరిత్ర. (2018-2019) (పురోగతిలో ఉంది...)
5. ఏకశిలా యొక్క కత్తిరింపు మరియు నిర్మాణం యొక్క స్థిరీకరణ పూర్తయింది. (పురోగతిలో ఉంది...)

మీకు ఇంకేదైనా నేర్చుకోవాలని ఆసక్తి ఉంటే, వ్యాఖ్యలలో వ్రాయండి.

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

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

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

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

2020 నాటికి, ఇది కొంచెం క్లిష్టంగా మారింది మరియు ఇలా మారింది:

ఈ పరిణామం ఎలా జరిగింది? సిస్టమ్ యొక్క వివిధ భాగాలు ఎందుకు అవసరం? ఏ నిర్మాణ నిర్ణయాలు తీసుకున్నారు మరియు ఎందుకు? అనే విషయాలను ఈ కథనాల పరంపరలో తెలుసుకుందాం.

2016 యొక్క మొదటి సమస్యలు: సేవలు ఏకశిలాను ఎందుకు వదిలివేయాలి?

సిరీస్‌లోని మొదటి కథనాలు ఏకశిలా నుండి వేరు చేయబడిన సేవల గురించి ఉంటాయి. మిమ్మల్ని సందర్భోచితంగా చెప్పాలంటే, 2016 ప్రారంభంలో సిస్టమ్‌లో మాకు ఏ సమస్యలు ఉన్నాయో, మేము సేవల విభజనతో వ్యవహరించాల్సి వచ్చిందని నేను మీకు చెప్తాను.

ఒకే MySql డేటాబేస్‌లో ఆ సమయంలో డోడో ISలో ఉన్న అన్ని అప్లికేషన్‌లు వాటి రికార్డులను వ్రాసాయి. పరిణామాలు:

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

సమస్య ఏకశిలా యొక్క ఉనికి. పరిణామాలు:

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

బేస్ మరియు ఏకశిలాతో సమస్యలు చాలాసార్లు వివరించబడ్డాయి, ఉదాహరణకు, 2018 ప్రారంభంలో క్రాష్‌ల సందర్భంలో (మంచ్ లాగా ఉండండి లేదా సాంకేతిక రుణం గురించి కొన్ని పదాలు, డోడో IS ఆగిపోయిన రోజు. అసమకాలిక స్క్రిప్ట్ и ఫీనిక్స్ కుటుంబానికి చెందిన డోడో పక్షి కథ. డోడో యొక్క గొప్ప పతనం IS), కాబట్టి నేను ఎక్కువగా నివసించను. సేవలను అభివృద్ధి చేస్తున్నప్పుడు మేము మరింత సౌలభ్యాన్ని అందించాలనుకుంటున్నామని నేను చెప్పాను. అన్నింటిలో మొదటిది, ఇది మొత్తం సిస్టమ్‌లో అత్యంత లోడ్ చేయబడిన మరియు రూట్ అయిన వాటికి సంబంధించినది - Auth మరియు Tracker.

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

చాప్టర్ నావిగేషన్

1. ఏకశిలా పథకం 2016
2. మేము మోనోలిత్‌ను అన్‌లోడ్ చేయడం ప్రారంభిస్తాము: ప్రామాణీకరణ మరియు ట్రాకర్ వేరు
   
3. Auth ఏమి చేస్తుంది?
4. లోడ్లు ఎక్కడ నుండి వస్తాయి?
5. ప్రమాణీకరణను అన్‌లోడ్ చేస్తోంది
6. ట్రాకర్ ఏమి చేస్తుంది?
7. లోడ్లు ఎక్కడ నుండి వస్తాయి?
8. ట్రాకర్‌ను అన్‌లోడ్ చేస్తోంది

ఏకశిలా పథకం 2016

2016 డోడో IS మోనోలిత్ యొక్క ప్రధాన బ్లాక్‌లు ఇక్కడ ఉన్నాయి మరియు వాటి ప్రధాన పనుల విచ్ఛిన్నం క్రింద ఉంది.

డెలివరీ నగదు డెస్క్. కొరియర్‌లకు అకౌంటింగ్, కొరియర్‌లకు ఆదేశాలు జారీ చేయడం.
సంప్రదించవలసిన కేంద్రం. ఆపరేటర్ ద్వారా ఆర్డర్‌లను అంగీకరించడం.
సైట్. మా వెబ్‌సైట్‌లు (dodopizza.ru, dodopizza.co.uk, dodopizza.by, మొదలైనవి).
ప్రామాణీకరణ. బ్యాక్ ఆఫీస్ కోసం ఆథరైజేషన్ మరియు అథెంటికేషన్ సర్వీస్.
ట్రాకర్. కిచెన్ ఆర్డర్ ట్రాకర్. ఆర్డర్‌ను సిద్ధం చేసేటప్పుడు సంసిద్ధత స్థితిని గుర్తించడం కోసం సేవ.
రెస్టారెంట్ నగదు డెస్క్. రెస్టారెంట్, క్యాషియర్ ఇంటర్‌ఫేస్‌లలో ఆర్డర్లు తీసుకోవడం.
ఎగుమతి. అకౌంటింగ్ కోసం 1Cలో నివేదికలను అప్‌లోడ్ చేస్తోంది.
హెచ్చరికలు మరియు ఇన్‌వాయిస్‌లు. వంటగదిలో వాయిస్ ఆదేశాలు (ఉదాహరణకు, "కొత్త పిజ్జా వచ్చింది") + కొరియర్‌ల కోసం ఇన్‌వాయిస్‌ల ముద్రణ.
షిఫ్ట్ మేనేజర్. షిఫ్ట్ మేనేజర్ యొక్క పని కోసం ఇంటర్‌ఫేస్‌లు: ఆర్డర్‌ల జాబితా, ఉత్పాదకత పటాలు, ఉద్యోగులను షిఫ్ట్‌లకు తీసుకురావడం.
ఆఫీసు మేనేజర్. ఫ్రాంఛైజీలు మరియు నిర్వాహకుల పని కోసం ఇంటర్‌ఫేస్‌లు: ఉద్యోగుల స్వీకరణ, పిజ్జేరియా పనిపై నివేదికలు.
రెస్టారెంట్ బోర్డు. పిజ్జేరియాలలో టీవీలలో మెనులను ప్రదర్శిస్తోంది.
అడ్మిన్. నిర్దిష్ట పిజ్జేరియా కోసం సెట్టింగ్‌లు: మెను, ధరలు, అకౌంటింగ్, ప్రచార కోడ్‌లు, ప్రమోషన్‌లు, సైట్ కోసం బ్యానర్‌లు మొదలైనవి.
ఉద్యోగి వ్యక్తిగత ఖాతా. ఉద్యోగి పని షెడ్యూల్, ఉద్యోగుల గురించి సమాచారం.
కిచెన్ మోటివేషన్ బోర్డ్. వంటగదిలో వేలాడుతున్న ప్రత్యేక స్క్రీన్ మరియు పిజ్జా తయారీదారుల వేగాన్ని ప్రదర్శిస్తుంది.
కమ్యూనికేషన్. sms మరియు ఇమెయిల్ పంపడం.
ఫైల్ నిల్వ. స్టాటిక్ ఫైల్‌లను స్వీకరించడానికి మరియు జారీ చేయడానికి స్వంత సేవ.

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

మేము మోనోలిత్‌ను అన్‌లోడ్ చేయడం ప్రారంభిస్తాము: ప్రామాణీకరణ మరియు ట్రాకర్ వేరు

డేటాబేస్ నుండి ఇతరుల కంటే ఎక్కువగా వ్రాసిన మరియు చదివే ప్రధాన సేవలు:

1. ప్రమాణీకరణ. బ్యాక్ ఆఫీస్ కోసం ఆథరైజేషన్ మరియు అథెంటికేషన్ సర్వీస్.
2. ట్రాకర్. కిచెన్ ఆర్డర్ ట్రాకర్. ఆర్డర్‌ను సిద్ధం చేసేటప్పుడు సంసిద్ధత స్థితిని గుర్తించడం కోసం సేవ.

Auth ఏమి చేస్తుంది?

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

ఉదాహరణకు, మేము హాల్‌లో వేలాడుతున్న టీవీలో పూర్తయిన ఆర్డర్‌ల స్థితితో కూడిన ప్రదర్శనను తెరవాలనుకుంటున్నాము. అప్పుడు మేము auth.dodopizza.ruని తెరిచి, "పరికరం వలె లాగిన్ చేయి" ఎంచుకోండి, పరికర రకాన్ని (పరికరం) సూచిస్తూ షిఫ్ట్ మేనేజర్ కంప్యూటర్‌లోని ప్రత్యేక పేజీలో నమోదు చేయగల కోడ్ కనిపిస్తుంది. టీవీ తన పిజ్జేరియా యొక్క కావలసిన ఇంటర్‌ఫేస్‌కి వెళ్లి, ఆర్డర్‌లు సిద్ధంగా ఉన్న కస్టమర్‌ల పేర్లను అక్కడ ప్రదర్శించడం ప్రారంభిస్తుంది.

లోడ్లు ఎక్కడ నుండి వస్తాయి?

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

ప్రతి పరికరం పరికరం పట్టికతో మాత్రమే అదే పని చేస్తుంది, దాని పాత్ర మరియు దాని యాక్సెస్‌లను తనిఖీ చేస్తుంది. మాస్టర్ డేటాబేస్కు పెద్ద సంఖ్యలో అభ్యర్థనలు ఈ కార్యకలాపాలపై సాధారణ డేటాబేస్ వనరులను లోడ్ చేయడానికి మరియు వృధా చేయడానికి దారితీస్తాయి.

ప్రమాణీకరణను అన్‌లోడ్ చేస్తోంది

Auth ఒక వివిక్త డొమైన్‌ను కలిగి ఉంది, అంటే వినియోగదారులు, లాగిన్‌లు లేదా పరికరాల గురించిన డేటా సేవలోకి ప్రవేశించి (ప్రస్తుతం భవిష్యత్తులో) అలాగే ఉంటుంది. ఎవరికైనా అవసరమైతే, అతను డేటా కోసం ఈ సేవకు వెళ్తాడు.

ఉంది. పని విధానం మొదట్లో ఇలా ఉంది:

ఇది ఎలా పని చేస్తుందో నేను కొద్దిగా వివరించాలనుకుంటున్నాను:

1. ఒక బాహ్య అభ్యర్థన బ్యాకెండ్‌కు వస్తుంది (అక్కడ Asp.Net MVC), దానితో పాటు ఒక సెషన్ కుక్కీని తీసుకువస్తుంది, ఇది Redis(1) నుండి సెషన్ డేటాను పొందేందుకు ఉపయోగించబడుతుంది. ఇది యాక్సెస్‌ల గురించి సమాచారాన్ని కలిగి ఉంటుంది, ఆపై కంట్రోలర్‌కు యాక్సెస్ తెరవబడి ఉంటుంది (3,4), లేదా కాదు.
2. యాక్సెస్ లేనట్లయితే, మీరు అధికార విధానాన్ని అనుసరించాలి. ఇక్కడ, సరళత కోసం, ఇది అదే లక్షణంలో మార్గంలో భాగంగా చూపబడుతుంది, అయితే ఇది లాగిన్ పేజీకి మార్పు. సానుకూల దృష్టాంతంలో, మేము సరిగ్గా పూరించిన సెషన్‌ని అందుకుంటాము మరియు బ్యాక్‌ఆఫీస్ కంట్రోలర్‌కి వెళ్తాము.
3. డేటా ఉంటే, మీరు వినియోగదారు డేటాబేస్‌లో ఔచిత్యం కోసం దాన్ని తనిఖీ చేయాలి. అతని పాత్ర మారిపోయింది, ఇప్పుడు అతన్ని పేజీలో అనుమతించకూడదా? ఈ సందర్భంలో, సెషన్ (1)ని స్వీకరించిన తర్వాత, మీరు నేరుగా డేటాబేస్కు వెళ్లి, ప్రామాణీకరణ లాజిక్ లేయర్ (2) ఉపయోగించి వినియోగదారు యాక్సెస్‌ను తనిఖీ చేయాలి. తర్వాత, లాగిన్ పేజీకి వెళ్లండి లేదా కంట్రోలర్‌కి వెళ్లండి. ఇది సాధారణ వ్యవస్థ, కానీ పూర్తిగా ప్రామాణికం కాదు.
4. అన్ని విధానాలు పూర్తయితే, మేము కంట్రోలర్‌లు మరియు పద్ధతులలో లాజిక్‌లో మరింత దాటవేస్తాము.

వినియోగదారు డేటా అన్ని ఇతర డేటా నుండి వేరు చేయబడింది, ఇది ప్రత్యేక సభ్యత్వ పట్టికలో నిల్వ చేయబడుతుంది, AuthService లాజిక్ లేయర్ నుండి విధులు API పద్ధతులుగా మారవచ్చు. డొమైన్ యొక్క సరిహద్దులు చాలా స్పష్టంగా నిర్వచించబడ్డాయి: వినియోగదారులు, వారి పాత్రలు, యాక్సెస్ డేటా, జారీ మరియు యాక్సెస్ రద్దు. ప్రతిదీ ఒక ప్రత్యేక సేవకు తరలించబడినట్లు కనిపిస్తోంది.

అయింది. వారు చేసింది అదే:

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

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

విడిపోవడానికి ఇంత సమయం ఎందుకు పట్టింది?
దారిలో చాలా సమస్యలు ఉన్నాయి, అది మమ్మల్ని నెమ్మదించింది:

1. మేము దేశ డేటాబేస్‌ల నుండి వినియోగదారులు, పరికరాలు మరియు ప్రమాణీకరణకు సంబంధించిన డేటాను ఒకదానికి బదిలీ చేయాలనుకుంటున్నాము. దీన్ని చేయడానికి, మేము అన్ని పట్టికలు మరియు వినియోగాన్ని పూర్ణాంక ఐడెంటిఫైయర్ నుండి గ్లోబల్ UUId ఐడెంటిఫైయర్‌కి బదిలీ చేయాలి (మేము ఇటీవల ఈ కోడ్‌ని మళ్లీ పని చేసాము రోమన్ బుకిన్ “Uuid - ఒక చిన్న నిర్మాణం యొక్క పెద్ద కథ” మరియు ఓపెన్ సోర్స్ ప్రాజెక్ట్ ఆదిమానవులు) వినియోగదారు డేటాను నిల్వ చేయడం (ఇది వ్యక్తిగత సమాచారం కాబట్టి) దాని పరిమితులను కలిగి ఉంది మరియు కొన్ని దేశాలలో దానిని విడిగా నిల్వ చేయడం అవసరం. కానీ గ్లోబల్ యూజర్ ఐడి తప్పనిసరిగా ఉండాలి.
2. డేటాబేస్‌లోని అనేక పట్టికలు ఆపరేషన్ చేసిన వినియోగదారు గురించి ఆడిట్ సమాచారాన్ని కలిగి ఉంటాయి. ఇది స్థిరత్వాన్ని నిర్ధారించడానికి అదనపు యంత్రాంగం అవసరం.
3. API సేవలను సృష్టించిన తర్వాత, మరొక సిస్టమ్‌కు బదిలీ చేయడానికి సుదీర్ఘమైన మరియు క్రమంగా కాలం ఉంది. వినియోగదారుల కోసం స్విచ్‌లు సజావుగా జరగాలి మరియు మాన్యువల్ పని అవసరం.

పిజ్జేరియాలో పరికరాన్ని నమోదు చేసే పథకం:

ప్రామాణీకరణ మరియు పరికరాల సేవను వేరు చేసిన తర్వాత సాధారణ నిర్మాణం:

వ్యాఖ్య. 2020 కోసం, మేము OAuth 2.0 ప్రమాణీకరణ ప్రమాణం ఆధారంగా Auth యొక్క కొత్త వెర్షన్‌పై పని చేస్తున్నాము. ఈ ప్రమాణం చాలా క్లిష్టమైనది, కానీ ఎండ్-టు-ఎండ్ ప్రమాణీకరణ సేవను అభివృద్ధి చేయడానికి ఉపయోగపడుతుంది. వ్యాసంలో "అధికారం యొక్క సూక్ష్మబేధాలు: OAuth 2.0 సాంకేతికత యొక్క అవలోకనం» మేము అలెక్సీ చెర్న్యావ్ ప్రమాణం గురించి వీలైనంత సరళంగా మరియు స్పష్టంగా మాట్లాడటానికి ప్రయత్నించాము, తద్వారా మీరు దానిని అధ్యయనం చేయడానికి సమయాన్ని ఆదా చేస్తారు.

ట్రాకర్ ఏమి చేస్తుంది?

ఇప్పుడు లోడ్ చేయబడిన సేవలలో రెండవది గురించి. ట్రాకర్ ద్వంద్వ పాత్రను నిర్వహిస్తుంది:

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

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

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

రస్కట్కా ట్రాకర్ స్టేషన్‌లో టాబ్లెట్ స్క్రీన్ ఇలా కనిపిస్తుంది.

లోడ్లు ఎక్కడ నుండి వస్తాయి?

ప్రతి పిజ్జేరియాలో ట్రాకర్‌తో దాదాపు ఐదు టాబ్లెట్‌లు ఉంటాయి. 2016లో మేము 100 కంటే ఎక్కువ పిజ్జేరియాలను కలిగి ఉన్నాము (ఇప్పుడు 600 కంటే ఎక్కువ ఉన్నాయి). ప్రతి టాబ్లెట్ ప్రతి 10 సెకన్లకు బ్యాకెండ్‌కు అభ్యర్థన చేస్తుంది మరియు ఆర్డర్ టేబుల్ (క్లయింట్ మరియు చిరునామాతో లింక్), ఆర్డర్ కూర్పు (ఉత్పత్తి మరియు పరిమాణం యొక్క సూచనతో లింక్) మరియు ప్రేరణ పట్టిక (ఇది ట్రాక్ చేస్తుంది) నుండి డేటాను సేకరిస్తుంది. నొక్కే సమయం). పిజ్జా తయారీదారు ట్రాకర్‌లోని ఉత్పత్తిపై క్లిక్ చేసినప్పుడు, ఈ అన్ని పట్టికలలోని రికార్డులు నవీకరించబడతాయి. ఆర్డర్ టేబుల్ సాధారణమైనది; ఇది ఏకకాలంలో ఆర్డర్‌ను ఆమోదించేటప్పుడు ఇన్‌సర్షన్‌లు, సిస్టమ్‌లోని ఇతర భాగాల నుండి అప్‌డేట్‌లు మరియు అనేక రీడింగ్‌లను కలిగి ఉంటుంది, ఉదాహరణకు, పిజ్జేరియాలో వేలాడదీసిన మరియు కస్టమర్‌లకు రెడీమేడ్ ఆర్డర్‌లను చూపే టీవీలో.

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

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

ఉంది. ప్రారంభంలో వాస్తుశిల్పం ఇలా ఉండేది:

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

ట్రాకర్‌ను అన్‌లోడ్ చేస్తోంది

ట్రాకర్‌తో ఉన్న ప్రధాన సమస్య ఏమిటంటే, డేటా తప్పనిసరిగా వేర్వేరు డేటాబేస్‌ల మధ్య సమకాలీకరించబడాలి. ఇది ప్రామాణీకరణ సేవ యొక్క విభజన నుండి దాని ప్రధాన వ్యత్యాసం; ఆర్డర్ మరియు దాని స్థితి మారవచ్చు మరియు వివిధ సేవల్లో ప్రదర్శించబడాలి.

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

ఆర్డర్ స్థితి మార్పు పథకం ఇలా కనిపిస్తుంది:

వివిధ వ్యవస్థల మధ్య స్థితిగతులు మారుతాయి. మరియు ఇక్కడ ట్రాకర్ అనేది డేటా లాక్ చేయబడిన చివరి సిస్టమ్ కాదు. అటువంటి సందర్భంలో విభజన కోసం మేము అనేక సాధ్యమైన విధానాలను చూశాము:

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

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

ఆ సమయానికి, మేము ఇప్పటికే స్టాక్‌లో RabbitMQని కలిగి ఉన్నాము, కాబట్టి దానిని సందేశ బ్రోకర్‌గా ఉపయోగించాలనే తుది నిర్ణయం. రేఖాచిత్రం రెస్టారెంట్ క్యాషియర్ నుండి ట్రాకర్ ద్వారా ఆర్డర్ యొక్క పరివర్తనను చూపుతుంది, ఇక్కడ అది దాని స్థితిని మరియు మేనేజర్ ఆర్డర్స్ ఇంటర్‌ఫేస్‌లో దాని ప్రదర్శనను మారుస్తుంది. అయింది:

మార్గాన్ని దశలవారీగా ఆర్డర్ చేయండి
ఆర్డర్ సోర్స్ సర్వీస్‌లలో ఒకదానిలో ఆర్డర్ మార్గం ప్రారంభమవుతుంది. ఇక్కడ రెస్టారెంట్ క్యాషియర్ ఉంది:

1. చెక్అవుట్ వద్ద ఆర్డర్ పూర్తిగా సిద్ధంగా ఉంది మరియు దానిని ట్రాకర్‌కు పంపాల్సిన సమయం ఆసన్నమైంది. ట్రాకర్ సభ్యత్వం పొందిన ఈవెంట్ విసిరివేయబడింది.
2. ట్రాకర్, ఆర్డర్‌ను అంగీకరించి, దానిని దాని స్వంత డేటాబేస్‌లో సేవ్ చేస్తుంది, “ఆర్డర్ అంగీకరించబడిన ట్రాకర్” ఈవెంట్‌ను తయారు చేసి RMQకి పంపుతుంది.
3. కస్టమ్ ఈవెంట్ బస్‌కు ఇప్పటికే అనేక మంది హ్యాండ్లర్లు సబ్‌స్క్రయిబ్ చేసుకున్నారు. మాకు, మోనోలిథిక్ డేటాబేస్‌తో సింక్రొనైజ్ చేసేది ముఖ్యమైనది.
4. హ్యాండ్లర్ ఈవెంట్‌ను స్వీకరిస్తుంది, దాని నుండి ముఖ్యమైన డేటాను ఎంచుకుంటుంది: మా విషయంలో, ఇది "ట్రాకర్ ద్వారా ఆమోదించబడినది" ఆర్డర్ స్థితి మరియు ప్రధాన డేటాబేస్లో దాని ఆర్డర్ ఎంటిటీని నవీకరిస్తుంది.

మోనోలిథిక్ ఆర్డర్స్ టేబుల్ నుండి ఎవరికైనా ప్రత్యేకంగా ఆర్డర్ అవసరమైతే, వారు దానిని అక్కడ నుండి కూడా చదవగలరు. ఉదాహరణకు, Shift మేనేజర్‌లోని ఆర్డర్స్ ఇంటర్‌ఫేస్‌కి ఇది అవసరం:

అన్ని ఇతర సేవలు తమ కోసం వాటిని ఉపయోగించుకోవడానికి ట్రాకర్ నుండి ఆర్డర్ ఈవెంట్‌లకు కూడా సభ్యత్వాన్ని పొందవచ్చు.

కొంత సమయం తర్వాత ఆర్డర్‌ను ఉత్పత్తిలోకి తీసుకుంటే, దాని స్థితి మొదట దాని డేటాబేస్ (ట్రాకర్ డేటాబేస్)లో మారుతుంది, ఆపై “OrderInWork” ఈవెంట్ వెంటనే రూపొందించబడుతుంది. ఇది RMQలోకి కూడా వస్తుంది, అక్కడ నుండి ఇది ఏకశిలా డేటాబేస్‌లో సమకాలీకరించబడుతుంది మరియు ఇతర సేవలకు పంపిణీ చేయబడుతుంది. ఈ మార్గంలో వివిధ సమస్యలు ఉండవచ్చు; వాటి గురించి మరిన్ని వివరాలను జెన్యా పెష్కోవ్ నివేదికలో చూడవచ్చు ట్రాకర్‌లో ఆఖరి స్థిరత్వం యొక్క అమలు వివరాల గురించి.

ప్రామాణీకరణ మరియు ట్రాకర్‌లో మార్పుల తర్వాత తుది నిర్మాణం

సంగ్రహించేందుకు: ప్రారంభంలో, డోడో IS వ్యవస్థ యొక్క తొమ్మిదేళ్ల చరిత్రను ఒక కథనంలో ప్యాక్ చేయాలనే ఆలోచన నాకు ఉంది. నేను పరిణామ దశల గురించి త్వరగా మరియు సరళంగా మాట్లాడాలనుకుంటున్నాను. అయినప్పటికీ, పదార్థాన్ని అధ్యయనం చేయడానికి కూర్చున్న తరువాత, ప్రతిదీ కనిపించే దానికంటే చాలా క్లిష్టంగా మరియు ఆసక్తికరంగా ఉందని నేను గ్రహించాను.

అటువంటి పదార్థం యొక్క ప్రయోజనాలను (లేదా దాని లేకపోవడం) గురించి ఆలోచిస్తూ, సంఘటనల యొక్క పూర్తి స్థాయి చరిత్రలు, వివరణాత్మక పునరాలోచనలు మరియు ఒకరి గత నిర్ణయాల విశ్లేషణ లేకుండా నిరంతర అభివృద్ధి అసాధ్యమని నేను నిర్ణయానికి వచ్చాను.

మా ప్రయాణం గురించి తెలుసుకోవడం మీకు ఉపయోగకరంగా మరియు ఆసక్తికరంగా ఉందని నేను ఆశిస్తున్నాను. ఇప్పుడు నేను తదుపరి కథనంలో డోడో IS సిస్టమ్‌లోని ఏ భాగాన్ని వివరించాలనే ఎంపికను ఎదుర్కొంటున్నాను: వ్యాఖ్యలలో వ్రాయండి లేదా ఓటు వేయండి.

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

మీరు తదుపరి కథనంలో డోడో ISలో ఏ భాగం గురించి తెలుసుకోవాలనుకుంటున్నారు?

• 24,1%డోడో ISలో ప్రారంభ ఏకశిలా (2011-2015)14

• 24,1%మొదటి సమస్యలు మరియు వాటి పరిష్కారాలు (2015-2016)14

• 20,7%క్లయింట్ భాగం యొక్క మార్గం: బేస్ పైన ముఖభాగం (2016-2017)12

• 36,2%నిజమైన మైక్రోసర్వీస్‌ల చరిత్ర (2018-2019)21

• 44,8%ఏకశిలా కత్తిరించడం మరియు నిర్మాణం యొక్క స్థిరీకరణ 26

• 29,3%సిస్టమ్ అభివృద్ధి కోసం తదుపరి ప్రణాళికల గురించి 17

• 19,0%నేను Dodo IS11 గురించి ఏమీ తెలుసుకోవాలనుకోవడం లేదు

58 మంది వినియోగదారులు ఓటు వేశారు. 6 మంది వినియోగదారులు దూరంగా ఉన్నారు.

మూలం: www.habr.com