டோடோ IS கட்டிடக்கலை வரலாறு: ஒரு ஆரம்ப மோனோலித்

அல்லது ஒரு ஒற்றைக்கல் கொண்ட ஒவ்வொரு மகிழ்ச்சியற்ற நிறுவனமும் அதன் சொந்த வழியில் மகிழ்ச்சியற்றது.

டோடோ பிஸ்ஸா வணிகத்தைப் போலவே டோடோ ஐஎஸ் அமைப்பின் வளர்ச்சி உடனடியாகத் தொடங்கியது - 2011 இல். இது வணிக செயல்முறைகளின் முழுமையான மற்றும் மொத்த டிஜிட்டல் மயமாக்கல் யோசனையின் அடிப்படையில் அமைந்தது தங்கள் சொந்த மீது, இது 2011 இல் கூட பல கேள்விகளையும் சந்தேகங்களையும் எழுப்பியது. ஆனால் இப்போது 9 ஆண்டுகளாக நாங்கள் இந்த பாதையை பின்பற்றி வருகிறோம் - எங்கள் சொந்த வளர்ச்சியுடன், இது ஒரு ஒற்றைக்கல்லில் தொடங்கியது.

“கட்டிடக்கலையை ஏன் மாற்றி எழுத வேண்டும், இவ்வளவு பெரிய மற்றும் நீண்ட கால மாற்றங்களைச் செய்ய வேண்டும்?” என்ற கேள்விகளுக்கான “பதில்” இந்தக் கட்டுரை. முந்தைய கட்டுரைக்கு "டோடோ IS கட்டிடக்கலையின் வரலாறு: பின் அலுவலகத்தின் பாதை". டோடோ IS இன் வளர்ச்சி எவ்வாறு தொடங்கியது, ஆரம்ப கட்டிடக்கலை எப்படி இருந்தது, புதிய தொகுதிகள் எவ்வாறு தோன்றின, மற்றும் பெரிய அளவிலான மாற்றங்களைச் செய்ய வேண்டிய சிக்கல்களால் நான் தொடங்குவேன்.

தொடர் கட்டுரைகள் "டோடோ ஐஎஸ் என்றால் என்ன?" பற்றி கூறுகிறது:

1. டோடோ IS இல் ஆரம்பகால மோனோலித் (2011-2015). (நீ இங்கே இருக்கிறாய்)

2. பின் அலுவலக பாதை: தனி தளங்கள் மற்றும் பேருந்து.

3. கிளையன்ட் பக்க பாதை: அடித்தளத்தின் மீது முகப்பு (2016-2017). (செயல்படுகிறது...)

4. உண்மையான மைக்ரோ சர்வீஸின் வரலாறு. (2018-2019). (செயல்படுகிறது...)

5. கட்டிடக்கலையின் ஒற்றைப்பாதை மற்றும் உறுதிப்படுத்தல் முடிக்கப்பட்டது. (செயல்படுகிறது...)

ஆதிகால கட்டிடக்கலை

2011 இல், டோடோ IS கட்டிடக்கலை இப்படி இருந்தது:

கட்டிடக்கலையின் முதல் தொகுதி ஆர்டர் ஏற்பு ஆகும். வணிக செயல்முறை இப்படி இருந்தது:

• ஒரு வாடிக்கையாளர் பிஸ்ஸேரியாவை அழைக்கிறார்;

• மேலாளர் தொலைபேசியை எடுக்கிறார்;

• தொலைபேசியில் ஆர்டர்களை எடுக்கிறது;

• அதே நேரத்தில், ஆர்டர் ஏற்றுக்கொள்ளும் இடைமுகத்தில் அதை நிரப்புகிறது: கிளையன்ட் பற்றிய தகவல்கள், ஆர்டர் விவரங்கள் மற்றும் விநியோக முகவரி ஆகியவை கணக்கில் எடுத்துக்கொள்ளப்படுகின்றன. 

தகவல் அமைப்பு இடைமுகம் இப்படி இருந்தது...

அக்டோபர் 2011 முதல் பதிப்பு:

2012 ஜனவரியில் சற்று மேம்பட்டது

தகவல் அமைப்பு டோடோ பிஸ்ஸா டெலிவரி பீஸ்ஸா உணவகம்

முதல் ஆர்டர் எடுக்கும் தொகுதியை உருவாக்குவதற்கான ஆதாரங்கள் குறைவாகவே இருந்தன. விரைவாகவும் சிறிய குழுவாகவும் நிறைய செய்ய வேண்டியது அவசியம். சிறிய குழுவில் 2 டெவலப்பர்கள் உள்ளனர், அவர்கள் முழு எதிர்கால அமைப்புக்கும் அடித்தளம் அமைத்தனர்.

அவர்களின் முதல் முடிவு தொழில்நுட்ப அடுக்கின் எதிர்கால விதியை தீர்மானித்தது:

• ASP.NET MVC, C# மொழியில் பின்தளம். டெவலப்பர்கள் டாட்னெட்டர்கள்; இந்த ஸ்டேக் அவர்களுக்கு நன்கு தெரிந்திருந்தது மற்றும் இனிமையானது.

• பூட்ஸ்டார்ப் மற்றும் jQuery இல் முன்பக்கம்: தனிப்பயன் பாணிகள் மற்றும் ஸ்கிரிப்ட்களின் அடிப்படையில் பயனர் இடைமுகங்கள். 

• MySQL தரவுத்தளம்: உரிம செலவுகள் இல்லை, பயன்படுத்த எளிதானது.

• விண்டோஸ் சர்வரில் உள்ள சர்வர்கள், ஏனெனில் .நெட் விண்டோஸில் மட்டுமே இருக்க முடியும் (நாங்கள் மோனோவைப் பற்றி விவாதிக்க மாட்டோம்).

உடல் ரீதியாக, இது அனைத்தும் "ஹோஸ்டரின் மேசையில்" வெளிப்படுத்தப்பட்டது. 

ஆர்டர் ஏற்றுக்கொள்ளும் விண்ணப்பத்தின் கட்டமைப்பு

அந்த நேரத்தில், எல்லோரும் ஏற்கனவே மைக்ரோ சர்வீஸ்களைப் பற்றி பேசிக் கொண்டிருந்தனர், மேலும் SOA சுமார் 5 ஆண்டுகளாக பெரிய திட்டங்களில் பயன்படுத்தப்பட்டது, எடுத்துக்காட்டாக, WCF 2006 இல் வெளியிடப்பட்டது. ஆனால் பின்னர் அவர்கள் நம்பகமான மற்றும் நிரூபிக்கப்பட்ட தீர்வைத் தேர்ந்தெடுத்தனர்.

அது இங்கே உள்ளது.

Asp.Net MVC என்பது ரேஸர் ஆகும், இது ஒரு படிவம் அல்லது கிளையண்டின் கோரிக்கையின் பேரில், சர்வரில் ரெண்டரிங் செய்து ஒரு HTML பக்கத்தை உருவாக்குகிறது. கிளையண்டில், CSS மற்றும் JS ஸ்கிரிப்ட்கள் ஏற்கனவே தகவலைக் காண்பிக்கும் மற்றும் தேவைப்பட்டால், JQuery வழியாக AJAX கோரிக்கைகளைச் செய்யவும்.

சர்வரில் உள்ள கோரிக்கைகள் *கண்ட்ரோலர் வகுப்புகளுக்குள் அடங்கும், அங்கு முறையானது இறுதி HTML பக்கத்தை செயலாக்குகிறது மற்றும் உருவாக்குகிறது. * சேவைகள் எனப்படும் தர்க்கத்தின் அடுக்குக்கு கட்டுப்பாட்டாளர்கள் கோரிக்கைகளை வைக்கின்றனர். ஒவ்வொரு சேவையும் வணிகத்தின் சில அம்சங்களுடன் ஒத்துப்போகிறது:

• எடுத்துக்காட்டாக, டிபார்ட்மென்ட் ஸ்ட்ரக்சர் சர்வீஸ் பிஸ்ஸேரியாக்கள் மற்றும் துறைகள் பற்றிய தகவல்களை வழங்கியது. ஒரு துறை என்பது ஒரு உரிமையாளரால் நிர்வகிக்கப்படும் பிஸ்ஸேரியாக்களின் குழுவாகும்.

• ஆர்டரின் உள்ளடக்கத்தைப் பெறுதல் மற்றும் கணக்கிட்டது.

• மற்றும் எஸ்எம்எஸ் அனுப்புவதற்காக ஏபிஐ சேவைகளை அழைப்பதன் மூலம் எஸ்எம்எஸ் சேவை எஸ்எம்எஸ் அனுப்பியது.

சேவைகள் தரவுத்தளத்திலிருந்து தரவைச் செயலாக்கி வணிக தர்க்கத்தைச் சேமிக்கின்றன. ஒவ்வொரு சேவையும் ஒன்று அல்லது அதற்கு மேற்பட்ட *பொருத்தமான பெயருடன் களஞ்சியங்களைக் கொண்டிருந்தது. அவை ஏற்கனவே தரவுத்தளத்தில் சேமிக்கப்பட்ட செயல்முறைகளுக்கான வினவல்கள் மற்றும் மேப்பர்களின் அடுக்கைக் கொண்டிருந்தன. களஞ்சியங்கள் வணிக தர்க்கத்தைக் கொண்டிருந்தன, குறிப்பாக அவற்றில் பல அறிக்கையிடல் தரவை உருவாக்கின. ORM பயன்படுத்தப்படவில்லை, எல்லோரும் கையால் எழுதப்பட்ட sql ஐ நம்பியுள்ளனர். 

டொமைன் மாதிரி மற்றும் பொது உதவி வகுப்புகளின் ஒரு அடுக்கு இருந்தது, எடுத்துக்காட்டாக, ஆர்டரைச் சேமித்த ஆர்டர் வகுப்பு. அங்கு, லேயரில், தேர்ந்தெடுக்கப்பட்ட நாணயத்தின் படி காட்சி உரையை மாற்றுவதற்கு ஒரு உதவியாளர் இருந்தார்.

இவை அனைத்தையும் இந்த மாதிரியால் குறிப்பிடலாம்:

ஆர்டர் வழி

அத்தகைய வரிசையை உருவாக்க எளிய ஆரம்ப வழியைக் கருத்தில் கொள்வோம்.

ஆரம்பத்தில் தளம் நிலையானதாக இருந்தது. அதில் விலைகள் இருந்தன, மேலே ஒரு தொலைபேசி எண் மற்றும் "உங்களுக்கு பீட்சா தேவைப்பட்டால், எண்ணை அழைத்து ஆர்டர் செய்யுங்கள்" என்ற கல்வெட்டு இருந்தது. ஆர்டர் செய்ய, நாங்கள் ஒரு எளிய ஓட்டத்தை செயல்படுத்த வேண்டும்: 

• வாடிக்கையாளர் விலைகளுடன் நிலையான வலைத்தளத்திற்குச் சென்று, தயாரிப்புகளைத் தேர்ந்தெடுத்து, இணையதளத்தில் பட்டியலிடப்பட்டுள்ள எண்ணை அழைக்கிறார்.

• வாடிக்கையாளர் ஆர்டரில் சேர்க்க விரும்பும் தயாரிப்புகளுக்கு பெயரிடுகிறார்.

• அவரது முகவரியையும் பெயரையும் தருகிறது.

• ஆபரேட்டர் ஆர்டரை ஏற்றுக்கொள்கிறார்.

• ஆர்டர் ஏற்றுக்கொள்ளப்பட்ட ஆர்டர்கள் இடைமுகத்தில் காட்டப்படும்.

இது அனைத்தும் மெனு காட்சியுடன் தொடங்குகிறது. உள்நுழைந்துள்ள ஆபரேட்டர் பயனர் ஒரு நேரத்தில் ஒரு ஆர்டரை மட்டுமே ஏற்றுக்கொள்கிறார். எனவே, வரைவு வண்டியை அதன் அமர்வில் சேமிக்க முடியும் (பயனர் அமர்வு நினைவகத்தில் சேமிக்கப்படுகிறது). தயாரிப்புகள் மற்றும் வாடிக்கையாளர் தகவல்களைக் கொண்ட கார்ட் பொருள் உள்ளது.

வாடிக்கையாளர் தயாரிப்புக்கு பெயரிடுகிறார், ஆபரேட்டர் கிளிக் செய்கிறார் + தயாரிப்புக்கு அடுத்ததாக, ஒரு கோரிக்கை சேவையகத்திற்கு அனுப்பப்படும். தயாரிப்பு பற்றிய தகவல்கள் தரவுத்தளத்திலிருந்து வெளியேற்றப்பட்டு, தயாரிப்பு பற்றிய தகவல்கள் வண்டியில் சேர்க்கப்படும்.

கருத்து. ஆம், இங்கே நீங்கள் தரவுத்தளத்திலிருந்து தயாரிப்பை வெளியே இழுக்க வேண்டியதில்லை, ஆனால் அதை முன் இறுதியில் இருந்து மாற்றவும். ஆனால் தெளிவுக்காக, நான் அடித்தளத்திலிருந்து பாதையை சரியாகக் காட்டினேன். 

அடுத்து, வாடிக்கையாளரின் முகவரியையும் பெயரையும் உள்ளிடவும். 

"ஆர்டரை உருவாக்கு" என்பதைக் கிளிக் செய்யும் போது:

• நாங்கள் கோரிக்கையை OrderController.SaveOrder() க்கு அனுப்புகிறோம்.

• அமர்விலிருந்து வண்டியைப் பெறுகிறோம், நமக்குத் தேவையான அளவு தயாரிப்புகள் உள்ளன.

• நாங்கள் கார்ட்டை கிளையண்ட் பற்றிய தகவலைச் சேர்த்து, அதை ரிசீவிங்ஆர்டர் சர்வீஸ் வகுப்பின் AddOrder முறைக்கு அனுப்புகிறோம், அங்கு அது தரவுத்தளத்தில் சேமிக்கப்படும். 

• தரவுத்தளத்தில் ஆர்டர், ஆர்டரின் உள்ளடக்கங்கள், கிளையன்ட் ஆகியவற்றுடன் அட்டவணைகள் உள்ளன, மேலும் அவை அனைத்தும் இணைக்கப்பட்டுள்ளன.

• ஆர்டர் காட்சி இடைமுகம் சென்று சமீபத்திய ஆர்டர்களை வெளியே இழுத்து அவற்றைக் காண்பிக்கும்.

புதிய தொகுதிகள்

ஆர்டரைப் பெறுவது முக்கியமானது மற்றும் அவசியமானது. உங்களிடம் விற்க ஆர்டர் இல்லையென்றால் பீட்சா வியாபாரத்தை நடத்த முடியாது. எனவே, கணினி செயல்பாட்டைப் பெறத் தொடங்கியது - தோராயமாக 2012 முதல் 2015 வரை. இந்த நேரத்தில், கணினியின் பல்வேறு தொகுதிகள் தோன்றின, அதை நான் அழைப்பேன் தொகுதிகள், சேவை அல்லது தயாரிப்பு கருத்துக்கு எதிராக. 

ஒரு தொகுதி என்பது சில பொதுவான வணிக இலக்குகளால் ஒன்றிணைக்கப்பட்ட செயல்பாடுகளின் தொகுப்பாகும். மேலும், அவை உடல் ரீதியாக ஒரே பயன்பாட்டில் அமைந்துள்ளன.

தொகுதிகளை கணினி தொகுதிகள் என்று அழைக்கலாம். எடுத்துக்காட்டாக, இது ஒரு அறிக்கையிடல் தொகுதி, நிர்வாக இடைமுகங்கள், சமையலறை தயாரிப்பு கண்காணிப்பு, அங்கீகாரம். இவை அனைத்தும் வெவ்வேறு பயனர் இடைமுகங்கள், சில வேறுபட்ட காட்சி பாணிகளைக் கொண்டுள்ளன. மேலும், அனைத்தும் ஒரு பயன்பாட்டிற்குள் உள்ளது, ஒரு இயங்கும் செயல்முறை. 

தொழில்நுட்ப ரீதியாக, தொகுதிகள் ஒரு பகுதியாக வடிவமைக்கப்பட்டுள்ளன (இந்த யோசனை கூட இருந்தது asp.net கோர்) முன்பக்கம், மாதிரிகள் மற்றும் அவற்றின் சொந்த கட்டுப்பாட்டு வகுப்புகளுக்கு தனி கோப்புகள் இருந்தன. இதன் விளைவாக, இந்த அமைப்பு மாற்றப்பட்டது ...

...இந்த:

சில தொகுதிகள் தனித்தனி தளங்களால் (செயல்படுத்தக்கூடிய திட்டம்) செயல்படுத்தப்படுகின்றன, இது முற்றிலும் தனித்தனி செயல்பாடு மற்றும் ஓரளவு தனித்தனி, அதிக கவனம் செலுத்தப்பட்ட வளர்ச்சியின் காரணமாகும். இது:

• தள - முதல் பதிப்பு dodopizza.ru இணையதளம்.

• ஏற்றுமதி: Dodo IS இலிருந்து 1Cக்கான அறிக்கைகளைப் பதிவிறக்குகிறது. 

• தனிப்பட்ட - பணியாளரின் தனிப்பட்ட கணக்கு. இது தனித்தனியாக உருவாக்கப்பட்டது மற்றும் அதன் சொந்த நுழைவு புள்ளி மற்றும் தனி வடிவமைப்பு உள்ளது.

• fs - நிலையான ஹோஸ்டிங்கிற்கான திட்டம். பின்னர் நாங்கள் அதிலிருந்து விலகி, அனைத்து நிலையான உள்ளடக்கத்தையும் Akamai CDN க்கு நகர்த்தினோம். 

மீதமுள்ள தொகுதிகள் BackOffice பயன்பாட்டில் உள்ளன. 

பெயர்களின் விளக்கம்:

• காசாளர் - உணவக பணப் பதிவு.

• ShiftManager - "Shift Manager" பாத்திரத்திற்கான இடைமுகங்கள்: பிஸ்ஸேரியா விற்பனையில் செயல்பாட்டு புள்ளிவிவரங்கள், தயாரிப்புகளை நிறுத்தப்பட்டியலில் வைக்கும் திறன், ஒரு வரிசையை மாற்றுதல்.

• OfficeManager - "பிஸ்ஸேரியா மேலாளர்" மற்றும் "உரிமையாளர்" பாத்திரங்களுக்கான இடைமுகங்கள். பிஸ்ஸேரியாவை அமைப்பதற்கான செயல்பாடுகள், அதன் போனஸ் விளம்பரங்கள், பணியாளர்களைப் பெறுதல் மற்றும் பணிபுரிதல் மற்றும் அறிக்கைகள் ஆகியவற்றை இங்கே காணலாம்.

• பொதுத் திரைகள் - பிஸ்ஸேரியாக்களில் தொங்கும் டிவி மற்றும் டேப்லெட்டுகளுக்கான இடைமுகங்கள். டிவிகள் மெனு, விளம்பரத் தகவல் மற்றும் ஆர்டர் நிலையை டெலிவரி செய்யும் போது காண்பிக்கும். 

அவர்கள் ஒரு பொதுவான சேவை அடுக்கு, Dodo.Core டொமைன் வகுப்புகளின் பொதுவான தொகுதி மற்றும் பொதுவான தளத்தைப் பயன்படுத்தினர். சில நேரங்களில் அவர்கள் இன்னும் ஒருவருக்கொருவர் பத்திகளின் வழியாக வழிநடத்தலாம். கூடுதலாக, dodopizza.ru அல்லது personal.dodopizza.ru போன்ற தனிப்பட்ட தளங்களும் பொதுவான சேவைகளை அணுகின.

புதிய தொகுதிகள் தோன்றியபோது, ​​தரவுத்தளத்தில் சேவைகள், சேமிக்கப்பட்ட நடைமுறைகள் மற்றும் அட்டவணைகளுக்கு ஏற்கனவே உருவாக்கப்பட்ட குறியீட்டை முடிந்தவரை மீண்டும் பயன்படுத்த முயற்சித்தோம். 

கணினியில் செய்யப்பட்ட தொகுதிகளின் அளவைப் பற்றி நன்றாகப் புரிந்து கொள்ள, 2012 இல் இருந்து மேம்பாட்டுத் திட்டங்களுடன் ஒரு வரைபடம் உள்ளது:

2015 வாக்கில், எல்லாமே பாதையில் இருந்தன, இன்னும் அதிகமானவை உற்பத்தியில் இருந்தன.

• ஆர்டரை ஏற்றுக்கொள்வது தொடர்பு மையத்தின் தனித் தொகுதியாக வளர்ந்துள்ளது, அங்கு ஆபரேட்டரால் ஆர்டர் ஏற்றுக்கொள்ளப்படுகிறது.

• மெனுக்கள் மற்றும் தகவல்களுடன் கூடிய பொதுத் திரைகள் பிஸ்ஸேரியாக்களில் தோன்றியுள்ளன.

• சமையலறையில் ஒரு தொகுதி உள்ளது, இது புதிய ஆர்டர் வரும்போது "புதிய பிஸ்ஸா" என்ற குரல் செய்தியை தானாகவே இயக்கும், மேலும் கூரியருக்கான விலைப்பட்டியலை அச்சிடுகிறது. இது சமையலறையில் செயல்முறைகளை பெரிதும் எளிதாக்குகிறது மற்றும் பணியாளர்கள் அதிக எண்ணிக்கையிலான எளிய செயல்பாடுகளால் திசைதிருப்பப்படாமல் இருக்க அனுமதிக்கிறது.

• டெலிவரி பிளாக் ஒரு தனி டெலிவரி கேஷியராக மாறியது, அங்கு தனது ஷிப்ட் எடுத்த கூரியருக்கு ஆர்டர் வழங்கப்பட்டது. அவரது சம்பளத்தை கணக்கிடுவதற்கு அவரது வேலை நேரம் கணக்கில் எடுத்துக்கொள்ளப்பட்டது. 

இதற்கு இணையாக, 2012 முதல் 2015 வரை, 10 க்கும் மேற்பட்ட டெவலப்பர்கள் தோன்றினர், 35 பிஸ்ஸேரியாக்கள் திறக்கப்பட்டன, இந்த அமைப்பு ருமேனியாவுக்கு அனுப்பப்பட்டது மற்றும் அமெரிக்காவில் புள்ளிகளைத் திறக்கத் தயாரிக்கப்பட்டது. டெவலப்பர்கள் இனி அனைத்து பணிகளிலும் ஈடுபடவில்லை, ஆனால் குழுக்களாக பிரிக்கப்பட்டனர். ஒவ்வொன்றும் அதன் சொந்த அமைப்பில் நிபுணத்துவம் பெற்றது. 

பிரச்சினைகள்

கட்டிடக்கலை காரணமாக (ஆனால் மட்டும் அல்ல) உட்பட.

அடிவாரத்தில் குழப்பம்

ஒரு அடிப்படை வசதியானது. இது நிலைத்தன்மையை அடைய முடியும், மற்றும் தொடர்புடைய தரவுத்தளங்களில் கட்டமைக்கப்பட்ட கருவிகளின் இழப்பில். அதனுடன் பணிபுரிவது பழக்கமானது மற்றும் வசதியானது, குறிப்பாக சில அட்டவணைகள் மற்றும் சிறிய தரவு இருந்தால்.

ஆனால் 4 வருட வளர்ச்சியில், தரவுத்தளத்தில் சுமார் 600 அட்டவணைகள், 1500 சேமிக்கப்பட்ட நடைமுறைகள் உள்ளன, அவற்றில் பல தர்க்கத்தையும் கொண்டிருந்தன. துரதிர்ஷ்டவசமாக, MySQL உடன் பணிபுரியும் போது சேமிக்கப்பட்ட நடைமுறைகள் அதிக பலனை அளிக்காது. அவை தரவுத்தளத்தால் தற்காலிகமாக சேமிக்கப்படவில்லை, மேலும் அவற்றில் தர்க்கத்தை சேமிப்பது வளர்ச்சி மற்றும் பிழைத்திருத்தத்தை சிக்கலாக்குகிறது. குறியீட்டை மீண்டும் பயன்படுத்துவதும் கடினம்.

பல அட்டவணைகளில் பொருத்தமான குறியீடுகள் இல்லை, எங்காவது, மாறாக, நிறைய குறியீடுகள் இருந்தன, இது செருகுவதை கடினமாக்கியது. சுமார் 20 அட்டவணைகள் மாற்றியமைக்கப்பட வேண்டும் - ஆர்டரை உருவாக்க பரிவர்த்தனை 3-5 வினாடிகள் ஆகலாம். 

அட்டவணையில் உள்ள தரவு எப்போதும் மிகவும் பொருத்தமான வடிவத்தில் இல்லை. எங்காவது டிநார்மலைசேஷன் செய்ய வேண்டியிருந்தது. வழக்கமாக பெறப்பட்ட தரவுகளில் சில எக்ஸ்எம்எல் கட்டமைப்பின் வடிவத்தில் ஒரு நெடுவரிசையில் இருந்தன, இது செயல்படுத்தும் நேரத்தை அதிகரித்தது, வினவல்கள் மற்றும் சிக்கலான வளர்ச்சியை அதிகரித்தது.

அதே அட்டவணைகள் மிகவும் உட்பட்டவை பன்முக கோரிக்கைகள். மேலே குறிப்பிட்டுள்ள அட்டவணை போன்ற பிரபலமான அட்டவணைகள் குறிப்பாக பாதிக்கப்பட்டன உத்தரவுகளை அல்லது அட்டவணைகள் பிஸ்ஸாரியா. அவை சமையலறை மற்றும் பகுப்பாய்வுகளில் செயல்பாட்டு இடைமுகங்களைக் காட்டப் பயன்படுத்தப்பட்டன. தளம் அவர்களையும் தொடர்பு கொண்டது (dodopizza.ru), எந்த நேரத்திலும் ஏராளமான கோரிக்கைகள் திடீரென வரலாம். 

தரவு ஒருங்கிணைக்கப்படவில்லை மற்றும் பல கணக்கீடுகள் தளத்தை பயன்படுத்தி பறந்து நடந்தன. இது தேவையற்ற கணக்கீடுகள் மற்றும் கூடுதல் சுமையை உருவாக்கியது. 

அவ்வாறு செய்ய முடியாதபோது பெரும்பாலும் குறியீடு தரவுத்தளத்திற்குள் சென்றது. எங்காவது மொத்த செயல்பாடுகளின் பற்றாக்குறை இருந்தது, எங்காவது ஒரு கோரிக்கையை விரைவுபடுத்துவதற்கும் நம்பகத்தன்மையை அதிகரிப்பதற்கும் குறியீட்டின் மூலம் பல பகுதிகளாகப் பிரிக்க வேண்டியிருக்கும். 

குறியீட்டில் ஒருங்கிணைப்பு மற்றும் குழப்பம்

வணிகத்தின் தங்கள் பகுதிக்கு பொறுப்பாக இருக்க வேண்டிய தொகுதிகள் அதை நேர்மையாக செய்யவில்லை. அவற்றில் சில பாத்திரங்களுக்கான செயல்பாடுகளின் நகல்களைக் கொண்டிருந்தன. எடுத்துக்காட்டாக, தனது நகரத்தில் ஒரு நெட்வொர்க்கின் சந்தைப்படுத்தல் நடவடிக்கைக்கு பொறுப்பான உள்ளூர் சந்தைப்படுத்துபவர் "நிர்வாகி" இடைமுகம் (விளம்பரங்களை அமைக்க) மற்றும் "அலுவலக மேலாளர்" இடைமுகம் (விளம்பரங்களின் தாக்கத்தைப் பார்க்க வணிக). நிச்சயமாக, இரண்டு தொகுதிகளிலும் ஒரே சேவையைப் பயன்படுத்தியது, இது போனஸ் விளம்பரங்களுடன் வேலை செய்தது.

சேவைகள் (ஒரு ஒற்றைப் பெரிய திட்டத்தில் உள்ள வகுப்புகள்) தங்கள் தரவை வளப்படுத்த ஒருவருக்கொருவர் அழைக்கலாம்.

தரவைச் சேமிக்கும் மாதிரி வகுப்புகளுடன், குறியீட்டில் வேலை வித்தியாசமாக மேற்கொள்ளப்பட்டது. எங்காவது கன்ஸ்ட்ரக்டர்கள் இருந்ததால், தேவையான புலங்களைக் குறிப்பிடலாம். சில இடங்களில் இது பொதுச் சொத்துகள் மூலம் செய்யப்பட்டது. நிச்சயமாக, தரவுத்தளத்திலிருந்து தரவைப் பெறுவது மற்றும் மாற்றுவது வேறுபட்டது. 

தர்க்கம் கட்டுப்படுத்திகள் அல்லது சேவை வகுப்புகளில் இருந்தது. 

இவை சிறிய பிரச்சனைகளாகத் தோன்றினாலும், அவை வளர்ச்சியை வெகுவாகக் குறைத்து, தரத்தைக் குறைத்து, உறுதியற்ற தன்மை மற்றும் பிழைகளுக்கு வழிவகுத்தன. 

பெரிய வளர்ச்சியின் சிக்கலானது

வளர்ச்சியிலேயே சிரமங்கள் எழுந்தன. கணினியின் வெவ்வேறு தொகுதிகளை உருவாக்குவது அவசியம், மற்றும் இணையாக. ஒவ்வொரு கூறுகளின் தேவைகளையும் ஒரே குறியீட்டில் பொருத்துவது கடினமாகிவிட்டது. அனைத்து கூறுகளையும் ஒரே நேரத்தில் ஒப்புக்கொள்வது மற்றும் மகிழ்விப்பது எளிதானது அல்ல. இதனுடன் தொழில்நுட்பத்தில் வரம்புகள் சேர்க்கப்பட்டன, குறிப்பாக அடித்தளம் மற்றும் முன் இறுதியில். உயர்மட்ட கட்டமைப்புகளுக்கு ஆதரவாக, குறிப்பாக கிளையன்ட் சேவைகள் (இணையதளம்) அடிப்படையில் JQuery ஐ கைவிடுவது அவசியம்.

கணினியின் சில பகுதிகள் இதற்கு மிகவும் பொருத்தமான தரவுத்தளங்களைப் பயன்படுத்தலாம். எடுத்துக்காட்டாக, ஆர்டர் கார்ட்டைச் சேமிப்பதற்காக ரெடிஸிலிருந்து காஸ்மோஸ்டிபிக்கு மாறுவதற்கான முன்னோடியைப் பெற்றோம். 

தங்கள் பகுதியில் பணிபுரியும் குழுக்கள் மற்றும் டெவலப்பர்கள் தங்கள் சேவைகளுக்கு மேம்பாடு மற்றும் வெளியீட்டின் அடிப்படையில் அதிக சுதந்திரத்தை விரும்பினர். இணைப்பின் போது ஏற்படும் முரண்பாடுகள், வெளியீடுகளின் போது ஏற்படும் சிக்கல்கள். 5 டெவலப்பர்களுக்கு இந்த சிக்கல் முக்கியமற்றதாக இருந்தால், 10 உடன், மேலும் திட்டமிடப்பட்ட வளர்ச்சியுடன், எல்லாம் மிகவும் தீவிரமாகிவிடும். மேலும் வரவிருப்பது ஒரு மொபைல் பயன்பாட்டின் உருவாக்கம் (இது 2017 இல் தொடங்கியது, 2018 இல் இருந்தது. பெரிய வீழ்ச்சி). 

கணினியின் வெவ்வேறு பகுதிகளுக்கு வெவ்வேறு நிலைத்தன்மை குறிகாட்டிகள் தேவை, ஆனால் கணினியின் வலுவான இணைப்பு காரணமாக, இதை எங்களால் வழங்க முடியவில்லை. நிர்வாகி குழுவில் ஒரு புதிய செயல்பாட்டை உருவாக்கும் போது ஏற்பட்ட பிழையானது, தளத்தில் ஆர்டர் ஏற்றுக்கொள்ளப்படுவதற்கு வழிவகுத்திருக்கலாம், ஏனெனில் குறியீடு பொதுவானது மற்றும் மீண்டும் பயன்படுத்தக்கூடியது, தரவுத்தளமும் தரவுகளும் ஒரே மாதிரியானவை.

அத்தகைய ஒற்றைக்கல்-மட்டு கட்டமைப்பின் கட்டமைப்பிற்குள் இந்த பிழைகள் மற்றும் சிக்கல்களைத் தவிர்ப்பது சாத்தியமாகும்: பொறுப்புகளைப் பிரித்தல், குறியீடு மற்றும் தரவுத்தளம் இரண்டையும் மறுசீரமைத்தல், ஒருவருக்கொருவர் தெளிவாக தனித்தனி அடுக்குகள் மற்றும் ஒவ்வொரு நாளும் தரத்தை கண்காணிக்கவும். ஆனால் தேர்ந்தெடுக்கப்பட்ட கட்டடக்கலை தீர்வுகள் மற்றும் அமைப்பின் செயல்பாட்டை விரைவாக விரிவுபடுத்துவதில் கவனம் செலுத்துவது நிலைத்தன்மையின் விஷயங்களில் சிக்கல்களுக்கு வழிவகுத்தது.

பவர் ஆஃப் மைண்ட் வலைப்பதிவு எப்படி உணவகங்களில் பணப் பதிவேடுகளை வைக்கிறது

பிஸ்ஸேரியா நெட்வொர்க்கின் வளர்ச்சி (மற்றும் சுமை) அதே வேகத்தில் தொடர்ந்தால், சிறிது நேரத்திற்குப் பிறகு சொட்டுகள் கணினியை மீட்டெடுக்காது. 2015ல் நாம் சந்திக்கத் தொடங்கிய பிரச்சனைகளை பின்வரும் கதை நன்கு விளக்குகிறது. 

வலைப்பதிவில் "மன சக்தி"ஒட்டுமொத்த நெட்வொர்க்கிற்கும் ஆண்டுக்கான வருவாய்த் தரவைக் காட்டும் விட்ஜெட் இருந்தது. இந்தத் தரவை வழங்கும் பொது Dodo API ஐ விட்ஜெட் அணுகியது. இந்த புள்ளிவிவரங்கள் இப்போது கிடைக்கின்றன http://dodopizzastory.com/. விட்ஜெட் ஒவ்வொரு பக்கத்திலும் காட்டப்பட்டது மற்றும் ஒவ்வொரு 20 வினாடிகளுக்கும் ஒரு டைமரில் கோரிக்கைகள் செய்யப்பட்டது. கோரிக்கை api.dodopizza.ru க்குச் சென்று கேட்கப்பட்டது:

• நெட்வொர்க்கில் உள்ள பிஸ்ஸேரியாக்களின் எண்ணிக்கை;

• ஆண்டின் தொடக்கத்தில் இருந்து மொத்த நெட்வொர்க் வருவாய்;

• இன்றைய வருவாய்.

வருவாய் புள்ளிவிவரங்களுக்கான கோரிக்கை நேராக தரவுத்தளத்திற்குச் சென்று ஆர்டர்கள் குறித்த தரவைக் கோரத் தொடங்கியது, பறக்கும்போது நேரடியாகத் தரவை ஒருங்கிணைத்துத் தொகையை வெளியிடுகிறது. 

உணவகங்களில் உள்ள பணப் பதிவேடுகள் அதே ஆர்டர்களின் அட்டவணைக்குச் சென்று, இன்று ஏற்றுக்கொள்ளப்பட்ட ஆர்டர்களின் பட்டியலைப் பதிவேற்றி, அதில் புதிய ஆர்டர்கள் சேர்க்கப்பட்டன. ரொக்கப் பதிவேடுகள் ஒவ்வொரு 5 வினாடிகளுக்கும் அல்லது பக்கத்தைப் புதுப்பிக்கும் போது தங்கள் கோரிக்கைகளைச் செய்தன.

வரைபடம் இப்படி இருந்தது:

இலையுதிர் காலத்தில் ஒரு நாள், ஃபியோடர் ஓவ்சினிகோவ் தனது வலைப்பதிவில் ஒரு நீண்ட மற்றும் பிரபலமான கட்டுரையை எழுதினார். நிறைய பேர் வலைப்பதிவுக்கு வந்து எல்லாவற்றையும் கவனமாக படிக்க ஆரம்பித்தார்கள். வந்தவர்கள் ஒவ்வொருவரும் கட்டுரையைப் படிக்கும்போது, ​​வருவாய் விட்ஜெட் சரியாக வேலைசெய்து, ஒவ்வொரு 20 வினாடிக்கும் ஒருமுறை APIஐக் கோரியது.

நெட்வொர்க்கில் உள்ள அனைத்து பிஸ்ஸேரியாக்களுக்கும் ஆண்டின் தொடக்கத்தில் இருந்து அனைத்து ஆர்டர்களின் அளவைக் கணக்கிடுவதற்கு API சேமிக்கப்பட்ட செயல்முறையை அழைத்தது. ஆர்டர்கள் அட்டவணையின் அடிப்படையில் திரட்டப்பட்டது, இது மிகவும் பிரபலமானது. அந்த நேரத்தில் அனைத்து திறந்த உணவகங்களின் அனைத்து பணப் பதிவேடுகளும் அதற்குச் செல்கின்றன. பணப் பதிவேடுகள் பதிலளிப்பதை நிறுத்திவிட்டன மற்றும் ஆர்டர்கள் ஏற்றுக்கொள்ளப்படவில்லை. அவை தளத்திலிருந்து ஏற்றுக்கொள்ளப்படவில்லை, டிராக்கரில் தோன்றவில்லை, மேலும் ஷிப்ட் மேலாளரால் அவற்றை அவரது இடைமுகத்தில் பார்க்க முடியவில்லை. 

இது மட்டும் கதையல்ல. 2015 இலையுதிர்காலத்தில், ஒவ்வொரு வெள்ளிக்கிழமையும் கணினியில் சுமை முக்கியமானது. பொது ஏபிஐயை பலமுறை முடக்கிவிட்டோம், ஒன்றும் உதவாததால் ஒருமுறை தளத்தை முடக்க வேண்டியிருந்தது. அதிக சுமைகளின் கீழ் பணிநிறுத்தம் வரிசையுடன் சேவைகளின் பட்டியல் கூட இருந்தது.

இந்த நேரத்திலிருந்து, சுமைகள் மற்றும் கணினி உறுதிப்படுத்தலுக்கான எங்கள் போராட்டம் தொடங்குகிறது (இலையுதிர் காலம் 2015 முதல் இலையுதிர் காலம் 2018 வரை). அப்போதுதான் நடந்தது"பெரும் வீழ்ச்சி" மேலும், சில நேரங்களில் தோல்விகளும் இருந்தன, அவற்றில் சில மிகவும் உணர்திறன் கொண்டவை, ஆனால் உறுதியற்ற தன்மையின் பொதுவான காலம் இப்போது முடிந்துவிட்டது என்று கருதலாம்.

விரைவான வணிக வளர்ச்சி

அதை ஏன் "உடனடியாக" செய்ய முடியவில்லை? பின்வரும் வரைபடங்களைப் பாருங்கள்.

2014-2015 இல் ருமேனியாவில் ஒரு திறப்பு இருந்தது மற்றும் அமெரிக்காவில் ஒரு திறப்பு தயாராகி வருகிறது.

சங்கிலி மிக விரைவாக வளர்ந்தது, புதிய நாடுகள் திறக்கப்பட்டன, பிஸ்ஸேரியாக்களின் புதிய வடிவங்கள் தோன்றின, எடுத்துக்காட்டாக, உணவு நீதிமன்றத்தில் ஒரு பிஸ்ஸேரியா திறக்கப்பட்டது. இவை அனைத்திற்கும் குறிப்பாக Dodo IS இன் செயல்பாடுகளை விரிவுபடுத்துவதில் குறிப்பிடத்தக்க கவனம் தேவைப்பட்டது. இந்த செயல்பாடுகள் அனைத்தும் இல்லாமல், சமையலறையில் கண்காணிக்காமல், கணினியில் உள்ள தயாரிப்புகள் மற்றும் இழப்புகளைக் கணக்கிடாமல், உணவு நீதிமன்ற மண்டபத்தில் ஆர்டர்களை வழங்குவதைக் காட்டாமல், இப்போது நாம் "சரியான" கட்டிடக்கலை மற்றும் "சரியான" பற்றி பேசுவது சாத்தியமில்லை. "வளர்ச்சிக்கான அணுகுமுறை.

கட்டிடக்கலையை சரியான நேரத்தில் திருத்துவதற்கு மற்றொரு தடையாக இருந்தது மற்றும் தொழில்நுட்ப சிக்கல்களுக்கு பொதுவான கவனம் 2014 நெருக்கடி ஆகும். இது போன்ற விஷயங்கள் அணிகளின் வளர்ச்சி வாய்ப்புகளைப் பாதிக்கின்றன, குறிப்பாக டோடோ பிஸ்ஸா போன்ற இளம் வணிகத்திற்கு.

விரைவான தீர்வுகள் உதவியது

பிரச்சனைகளுக்கு தீர்வுகள் தேவை. வழக்கமாக, தீர்வுகளை 2 குழுக்களாகப் பிரிக்கலாம்:

• வேகமானவை தீயை அணைத்து, சிறிய அளவிலான பாதுகாப்பைக் கொடுத்து, மாற்றுவதற்கு நமக்கு நேரத்தை வாங்கித் தரும்.

• அமைப்பு மற்றும், எனவே, நீண்ட. பல தொகுதிகளை மறுசீரமைத்தல், தனித்தனி சேவைகளாக ஒற்றைக்கல் கட்டமைப்பைப் பிரித்தல் (அவற்றில் பெரும்பாலானவை மைக்ரோ அல்ல, மாறாக மேக்ரோ சேவைகள், மேலும் இதைப் பற்றி மேலும் உள்ளன Andrey Morevsky அறிக்கை). 

விரைவான மாற்றங்களின் உலர்ந்த பட்டியல்:

அடிப்படை மாஸ்டரை அளவிடவும்

நிச்சயமாக, சுமைகளை எதிர்த்துப் போராடுவதற்கு முதலில் செய்ய வேண்டியது சர்வர் சக்தியை அதிகரிப்பதாகும். முதன்மை தரவுத்தளம் மற்றும் இணைய சேவையகங்களுக்காக இது செய்யப்பட்டது. ஐயோ, இது ஒரு குறிப்பிட்ட வரம்பு வரை மட்டுமே சாத்தியம்; அதைத் தாண்டி அது மிகவும் விலை உயர்ந்ததாகிறது.

2014 முதல், நாங்கள் அஸூருக்குச் சென்றோம்; இந்த தலைப்பைப் பற்றியும் நாங்கள் கட்டுரையில் எழுதினோம்.மைக்ரோசாஃப்ட் அஸூர் கிளவுட்டைப் பயன்படுத்தி டோடோ பிஸ்ஸா எப்படி பீட்சாவை வழங்குகிறது" ஆனால் தொடர்ச்சியான சேவையக அதிகரிப்புக்குப் பிறகு, தளத்தின் விலை வரம்பை எட்டியது. 

படிப்பதற்கான தரவுத்தள பிரதிகள்

அடித்தளத்திற்கான இரண்டு பிரதிகளை நாங்கள் செய்தோம்:

ReadReplica அடைவு கோரிக்கைகளுக்கு. நகரம், தெரு, பிஸ்ஸேரியா, தயாரிப்புகள் (மெதுவாக மாற்றப்பட்ட டொமைன்) போன்ற அடைவுகளைப் படிக்கவும், சிறிய தாமதம் ஏற்றுக்கொள்ளக்கூடிய இடைமுகங்களிலும் இது பயன்படுத்தப்படுகிறது. இவற்றில் 2 பிரதிகள் இருந்தன, மாஸ்டரைப் போலவே அவற்றின் கிடைக்கும் தன்மையை நாங்கள் உறுதி செய்தோம்.

அறிக்கை கோரிக்கைகளுக்கான ரெப்லிகாவைப் படிக்கவும். இந்த தரவுத்தளமானது குறைவான கிடைக்கும் தன்மையைக் கொண்டிருந்தது, ஆனால் எல்லா அறிக்கைகளும் அதற்குச் சென்றன. பெரிய தரவு மறுகணக்கீடுகளுக்கு அவர்கள் அதிக கோரிக்கைகளைக் கொண்டிருக்கலாம், ஆனால் அவை முக்கிய தரவுத்தளத்தையும் செயல்பாட்டு இடைமுகங்களையும் பாதிக்காது. 

குறியீட்டில் தற்காலிக சேமிப்புகள்

குறியீட்டில் எங்கும் தற்காலிக சேமிப்புகள் இல்லை (அனைத்தும்). இது ஏற்றப்பட்ட தரவுத்தளத்திற்கு கூடுதல், எப்போதும் தேவையில்லாத கோரிக்கைகளுக்கு வழிவகுத்தது. முதலில், தற்காலிக சேமிப்புகள் நினைவகத்திலும் வெளிப்புற கேச் சேவையிலும் இருந்தன, அது ரெடிஸ் ஆகும். எல்லாம் நேரம் செல்லாதது, அமைப்புகள் குறியீட்டில் குறிப்பிடப்பட்டுள்ளன.

பின்தளத்திற்கான பல சேவையகங்கள்

அதிகரித்த சுமைகளைத் தாங்கும் வகையில் பயன்பாட்டின் பின்தளமும் அளவிடப்பட வேண்டும். ஒரு IIS சேவையகத்திலிருந்து ஒரு கிளஸ்டரை உருவாக்குவது அவசியம். நாங்கள் இடம் மாறிவிட்டோம் விண்ணப்ப அமர்வு RedisCache இல் உள்ள நினைவகத்திலிருந்து, இது ரவுண்ட் ராபினுடன் ஒரு எளிய சுமை சமநிலைக்கு பின்னால் பல சேவையகங்களை உருவாக்குவதை சாத்தியமாக்கியது. முதலில், அதே ரெடிஸ் கேச்களுக்குப் பயன்படுத்தப்பட்டது, பின்னர் அவை பல பகுதிகளாகப் பிரிக்கப்பட்டன. 

இதன் விளைவாக, கட்டிடக்கலை மிகவும் சிக்கலானது.

...ஆனால் கொஞ்சம் பதற்றம் தணிந்தது.

பின்னர் ஏற்றப்பட்ட கூறுகளை மீண்டும் செய்வது அவசியம், அதைத்தான் நாங்கள் எடுத்தோம். இதைப் பற்றி அடுத்த பகுதியில் பேசுவோம்.

ஆதாரம்: www.habr.com