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

ஹப்ர் உலகை மாற்றுகிறது. நாங்கள் இப்போது ஒரு வருடத்திற்கும் மேலாக வலைப்பதிவு செய்கிறோம். சுமார் ஆறு மாதங்களுக்கு முன்பு, கப்ரோவைட்டுகளிடமிருந்து முற்றிலும் தர்க்கரீதியான கருத்தைப் பெற்றோம்: “டோடோ, உங்களுக்கான சொந்த அமைப்பு இருப்பதாக எல்லா இடங்களிலும் சொல்கிறீர்கள். மற்றும் இந்த அமைப்பு என்ன? பீஸ்ஸா சங்கிலிக்கு அது ஏன் தேவைப்படுகிறது?

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

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

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

1. டோடோ IS இல் ஆரம்பகால மோனோலித் (2011-2015). (செயல்படுகிறது...)
2. பின் அலுவலக பாதை: தனி தளங்கள் மற்றும் பேருந்து. (நீ இங்கே இருக்கிறாய்)
3. கிளையன்ட் பக்க பாதை: அடித்தளத்தின் மீது முகப்பு (2016-2017). (செயல்படுகிறது...)
4. உண்மையான மைக்ரோ சர்வீஸின் வரலாறு. (2018-2019). (செயல்படுகிறது...)
5. கட்டிடக்கலையின் ஒற்றைப்பாதை மற்றும் உறுதிப்படுத்தல் முடிக்கப்பட்டது. (செயல்படுகிறது...)

நீங்கள் வேறு ஏதாவது தெரிந்து கொள்ள ஆர்வமாக இருந்தால் - கருத்துகளில் எழுதுங்கள்.

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

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

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

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

2020 வாக்கில், இது இன்னும் கொஞ்சம் சிக்கலானதாகி, இப்படி ஆனது:

இந்த பரிணாமம் எப்படி நடந்தது? அமைப்பின் வெவ்வேறு பகுதிகள் ஏன் தேவைப்படுகின்றன? என்ன கட்டடக்கலை முடிவுகள் எடுக்கப்பட்டன, ஏன்? என்பதை இந்தக் கட்டுரைத் தொடரில் பார்ப்போம்.

2016 இன் முதல் சிக்கல்கள்: சேவைகள் ஏன் ஒற்றைக்கல்லை விட்டு வெளியேற வேண்டும்

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

ஒரு ஒற்றை MySql தரவுத்தளமானது, அந்த நேரத்தில் Dodo IS இல் இருந்த அனைத்து பயன்பாடுகளும் தங்கள் பதிவுகளை எழுதின. பின்விளைவுகள்:

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

மோனோலித் இருப்பதுதான் பிரச்சனை. பின்விளைவுகள்:

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

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

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

அத்தியாயம் வழிசெலுத்தல்

1. மோனோலித் திட்டம் 2016
2. மோனோலித்தை இறக்கத் தொடங்குதல்: அங்கீகாரம் மற்றும் டிராக்கர் பிரிப்பு
   
3. அங்கீகாரம் என்ன செய்கிறது?
4. சுமைகள் எங்கிருந்து வருகின்றன?
5. அங்கீகாரத்தை இறக்குகிறது
6. டிராக்கர் என்ன செய்கிறது?
7. சுமைகள் எங்கிருந்து வருகின்றன?
8. டிராக்கரை இறக்குகிறது

மோனோலித் திட்டம் 2016

Dodo IS 2016 மோனோலித்தின் முக்கிய தொகுதிகள் இங்கே உள்ளன, மேலும் அவற்றின் முக்கிய பணிகளின் டிரான்ஸ்கிரிப்ட் கீழே உள்ளது.

கேஷியர் டெலிவரி. கூரியர்களுக்கான கணக்கு, கூரியர்களுக்கு உத்தரவுகளை வழங்குதல்.
தொடர்பு மையம். ஆபரேட்டர் மூலம் ஆர்டர்களை ஏற்றுக்கொள்வது.
தள. எங்கள் வலைத்தளங்கள் (dodopizza.ru, dodopizza.co.uk, dodopizza.by, முதலியன).
அங்கீகார. பின் அலுவலகத்திற்கான அங்கீகாரம் மற்றும் அங்கீகார சேவை.
டிராக்கர். சமையலறையில் டிராக்கரை ஆர்டர் செய்யுங்கள். ஆர்டரைத் தயாரிக்கும் போது தயார்நிலை நிலைகளைக் குறிக்கும் சேவை.
உணவகத்தின் பண மேசை. ஒரு உணவகத்தில் ஆர்டர்களை எடுத்து, காசாளர் இடைமுகங்கள்.
ஏற்றுமதி. கணக்கியலுக்காக 1C இல் அறிக்கைகளைப் பதிவேற்றுகிறது.
அறிவிப்புகள் மற்றும் விலைப்பட்டியல். சமையலறையில் குரல் கட்டளைகள் (உதாரணமாக, "புதிய பீஸ்ஸா வந்துவிட்டது") + கூரியர்களுக்கான விலைப்பட்டியல் அச்சிடுதல்.
பணிநேர மேலாளர். ஷிப்ட் மேலாளரின் பணிக்கான இடைமுகங்கள்: ஆர்டர்களின் பட்டியல், செயல்திறன் வரைபடங்கள், பணியாளர்களை மாற்றத்திற்கு மாற்றுதல்.
அலுவலக மேலாளர். உரிமையாளர் மற்றும் மேலாளரின் பணிக்கான இடைமுகங்கள்: ஊழியர்களின் வரவேற்பு, பிஸ்ஸேரியாவின் வேலை பற்றிய அறிக்கைகள்.
உணவகம் ஸ்கோர்போர்டு. பிஸ்ஸேரியாக்களில் உள்ள டிவிகளில் மெனு காட்சி.
நிர்வாகம். குறிப்பிட்ட பிஸ்ஸேரியாவில் உள்ள அமைப்புகள்: மெனு, விலைகள், கணக்கியல், விளம்பரக் குறியீடுகள், விளம்பரங்கள், இணையதள பேனர்கள் போன்றவை.
பணியாளரின் தனிப்பட்ட கணக்கு. ஊழியர்களின் பணி அட்டவணைகள், பணியாளர்கள் பற்றிய தகவல்கள்.
சமையலறை உந்துதல் வாரியம். சமையலறையில் தொங்கி, பீட்சா தயாரிப்பாளர்களின் வேகத்தைக் காட்டும் தனித் திரை.
தொடர்பாடல். எஸ்எம்எஸ் மற்றும் மின்னஞ்சல் அனுப்புகிறது.
கோப்பு சேமிப்பு. நிலையான கோப்புகளைப் பெறுவதற்கும் வழங்குவதற்கும் சொந்த சேவை.

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

மோனோலித்தை இறக்கத் தொடங்குதல்: அங்கீகாரம் மற்றும் டிராக்கர் பிரிப்பு

பிறவற்றை விட தரவுத்தளத்திலிருந்து பதிவுசெய்து படிக்கும் முக்கிய சேவைகள்:

1. அங்கீகாரம். பின் அலுவலகத்திற்கான அங்கீகாரம் மற்றும் அங்கீகார சேவை.
2. டிராக்கர். சமையலறையில் டிராக்கரை ஆர்டர் செய்யுங்கள். ஆர்டரைத் தயாரிக்கும் போது தயார்நிலை நிலைகளைக் குறிக்கும் சேவை.

அங்கீகாரம் என்ன செய்கிறது?

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

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

சுமைகள் எங்கிருந்து வருகின்றன?

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

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

அங்கீகாரத்தை இறக்குகிறது

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

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

இது எவ்வாறு வேலை செய்கிறது என்பதை நான் கொஞ்சம் விளக்க விரும்புகிறேன்:

1. வெளியில் இருந்து ஒரு கோரிக்கை பின்தளத்திற்கு வருகிறது (Asp.Net MVC உள்ளது), அதனுடன் ஒரு அமர்வு குக்கீயைக் கொண்டுவருகிறது, இது Redis(1) இலிருந்து அமர்வுத் தரவைப் பெறப் பயன்படுகிறது. இது அணுகல் பற்றிய தகவல்களைக் கொண்டுள்ளது, பின்னர் கட்டுப்படுத்திக்கான அணுகல் திறந்திருக்கும் (3,4) அல்லது இல்லை.
2. அணுகல் இல்லை என்றால், நீங்கள் அங்கீகார நடைமுறைக்கு செல்ல வேண்டும். இங்கே, எளிமைக்காக, இது உள்நுழைவு பக்கத்திற்கு மாறினாலும், அதே பண்புக்கூறில் பாதையின் ஒரு பகுதியாகக் காட்டப்படுகிறது. நேர்மறையான சூழ்நிலையில், நாங்கள் சரியாக முடிக்கப்பட்ட அமர்வைப் பெற்று, பேக் ஆபீஸ் கன்ட்ரோலருக்குச் செல்வோம்.
3. தரவு இருந்தால், பயனர் தளத்தில் பொருத்தத்திற்காக அதைச் சரிபார்க்க வேண்டும். அவருடைய பங்கு மாறிவிட்டதா, இப்போது அவரைப் பக்கத்தில் அனுமதிக்கக் கூடாதா? இந்த வழக்கில், அமர்வு (1) ஐப் பெற்ற பிறகு, நீங்கள் நேரடியாக தரவுத்தளத்திற்குச் சென்று, அங்கீகார லாஜிக் லேயரை (2) பயன்படுத்தி பயனரின் அணுகலைச் சரிபார்க்க வேண்டும். அடுத்து, உள்நுழைவுப் பக்கத்திற்குச் செல்லவும் அல்லது கட்டுப்படுத்திக்குச் செல்லவும். அத்தகைய எளிய அமைப்பு, ஆனால் மிகவும் நிலையானது அல்ல.
4. அனைத்து நடைமுறைகளும் நிறைவேற்றப்பட்டால், கட்டுப்படுத்திகள் மற்றும் முறைகளில் உள்ள தர்க்கத்தில் மேலும் தவிர்க்கிறோம்.

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

ஆக. எனவே அவர்கள் செய்தார்கள்:

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

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

பிரிவினை ஏன் நீண்டது?
வழியில் பல சிக்கல்கள் இருந்தன, அது எங்களை மெதுவாக்கியது:

1. நாடு சார்ந்த தரவுத்தளங்களிலிருந்து பயனர், சாதனம் மற்றும் அங்கீகாரத் தரவை ஒன்றிற்கு நகர்த்த விரும்புகிறோம். இதைச் செய்ய, அனைத்து அட்டவணைகளையும் பயன்பாட்டையும் முழு அடையாளங்காட்டியிலிருந்து உலகளாவிய UUId அடையாளங்காட்டிக்கு மொழிபெயர்க்க வேண்டும் (சமீபத்தில் இந்தக் குறியீட்டை மறுவேலை செய்தோம் ரோமன் புக்கின் "Uuid - ஒரு சிறிய கட்டமைப்பின் பெரிய கதை" மற்றும் திறந்த மூல திட்டம் ஆதிகாலங்கள்) பயனர் தரவைச் சேமிப்பது (தனிப்பட்ட தகவல் என்பதால்) அதன் வரம்புகளைக் கொண்டுள்ளது மற்றும் சில நாடுகளில் அவற்றைத் தனித்தனியாகச் சேமிப்பது அவசியம். ஆனால் பயனரின் உலகளாவிய ஐடி இருக்க வேண்டும்.
2. தரவுத்தளத்தில் உள்ள பல அட்டவணைகள் செயல்பாட்டைச் செய்த பயனரைப் பற்றிய தணிக்கைத் தகவலைக் கொண்டுள்ளன. இதற்கு நிலைத்தன்மைக்கான கூடுதல் வழிமுறை தேவை.
3. Api-சேவைகள் உருவாக்கப்பட்ட பிறகு, மற்றொரு அமைப்புக்கு மாறுவதற்கான நீண்ட மற்றும் படிப்படியான காலம் இருந்தது. மாறுதல் பயனர்களுக்கு தடையின்றி இருக்க வேண்டும் மற்றும் கைமுறையாக வேலை செய்ய வேண்டும்.

பிஸ்ஸேரியாவில் சாதன பதிவு திட்டம்:

அங்கீகாரம் மற்றும் சாதனங்கள் சேவையைப் பிரித்தெடுத்த பிறகு பொதுவான கட்டமைப்பு:

கருத்து. 2020 ஆம் ஆண்டில், OAuth 2.0 அங்கீகாரத் தரநிலையின் அடிப்படையில், அங்கீகாரத்தின் புதிய பதிப்பை உருவாக்கி வருகிறோம். இந்த தரநிலை மிகவும் சிக்கலானது, ஆனால் பாஸ்-த்ரூ அங்கீகார சேவையை உருவாக்க இது பயனுள்ளதாக இருக்கும். கட்டுரையில் "அங்கீகாரத்தின் நுணுக்கங்கள்: OAuth 2.0 தொழில்நுட்பத்தின் மேலோட்டம்» அலெக்ஸி செர்னியாவ் தரநிலையைப் பற்றி முடிந்தவரை எளிமையாகவும் தெளிவாகவும் சொல்ல முயற்சித்தோம், இதனால் நீங்கள் அதைப் படிப்பதில் நேரத்தை மிச்சப்படுத்துவீர்கள்.

டிராக்கர் என்ன செய்கிறது?

இப்போது ஏற்றப்பட்ட சேவைகளில் இரண்டாவது பற்றி. டிராக்கர் இரட்டை வேடத்தை செய்கிறார்:

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

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

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

"ரஸ்கட்கா" டிராக்கரின் நிலையத்தில் டேப்லெட்டின் திரை இப்படித்தான் இருக்கும்

சுமைகள் எங்கிருந்து வருகின்றன?

ஒவ்வொரு பிஸ்ஸேரியாவிலும் ஒரு டிராக்கருடன் சுமார் ஐந்து மாத்திரைகள் உள்ளன. 2016 இல், எங்களிடம் 100 க்கும் மேற்பட்ட பிஸ்ஸேரியாக்கள் இருந்தன (இப்போது 600 க்கும் அதிகமானவை). ஒவ்வொரு டேப்லெட்டுகளும் 10 வினாடிகளுக்கு ஒருமுறை பின்தளத்தில் கோரிக்கை வைக்கின்றன மற்றும் ஆர்டர் டேபிள் (கிளையன்ட் மற்றும் முகவரியுடன் இணைப்பு), ஆர்டர் கலவை (தயாரிப்பு மற்றும் அளவின் குறிப்பீடு), ஊக்கக் கணக்கியல் அட்டவணை (தி. அழுத்தும் நேரம் அதில் கண்காணிக்கப்படுகிறது). ஒரு பீஸ்ஸா தயாரிப்பாளர் டிராக்கரில் உள்ள தயாரிப்பைக் கிளிக் செய்யும் போது, ​​இந்த அட்டவணைகள் அனைத்திலும் உள்ள பதிவுகள் புதுப்பிக்கப்படும். ஆர்டர் அட்டவணை பொதுவானது, இது ஒரு ஆர்டரை ஏற்கும்போது செருகல்கள், கணினியின் பிற பகுதிகளிலிருந்து புதுப்பிப்புகள் மற்றும் ஏராளமான வாசிப்புகளைக் கொண்டுள்ளது, எடுத்துக்காட்டாக, பிஸ்ஸேரியாவில் தொங்கி வாடிக்கையாளர்களுக்கு முடிக்கப்பட்ட ஆர்டர்களைக் காட்டும் டிவியில்.

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

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

இருந்தது. அசல் கட்டிடக்கலை:

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

டிராக்கரை இறக்குகிறது

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

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

ஆர்டர் நிலைகளை மாற்றுவதற்கான திட்டம் இதுபோல் தெரிகிறது:

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

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

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

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

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

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

மோனோலிதிக் டேபிள் ஆர்டர்களில் இருந்து யாருக்காவது ஆர்டர் தேவைப்பட்டால், நீங்கள் அதை அங்கிருந்தும் படிக்கலாம். எடுத்துக்காட்டாக, ஷிப்ட் மேலாளரில் உள்ள ஆர்டர்கள் இடைமுகத்திற்கு இது தேவை:

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

சிறிது நேரத்திற்குப் பிறகு ஆர்டர் செயல்பாட்டிற்கு வந்தால், அதன் நிலை முதலில் அதன் தரவுத்தளத்தில் (டிராக்கர் தரவுத்தளத்தில்) மாறுகிறது, பின்னர் "OrderIn Progress" நிகழ்வு உடனடியாக உருவாக்கப்படும். இது RMQ க்குள் நுழைகிறது, அங்கிருந்து இது ஒரு ஒற்றைத் தரவுத்தளத்தில் ஒத்திசைக்கப்பட்டு பிற சேவைகளுக்கு வழங்கப்படுகிறது. வழியில் பல்வேறு சிக்கல்கள் இருக்கலாம், அவற்றைப் பற்றிய கூடுதல் விவரங்களை ஷென்யா பெஷ்கோவின் அறிக்கையில் காணலாம் டிராக்கரில் இறுதி நிலைத்தன்மையின் செயல்படுத்தல் விவரங்கள் பற்றி.

அங்கீகாரம் மற்றும் டிராக்கரில் மாற்றங்களுக்குப் பிறகு இறுதி கட்டமைப்பு

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

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

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

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

டோடோவின் எந்தப் பகுதியைப் பற்றி அடுத்த கட்டுரையில் தெரிந்துகொள்ள விரும்புகிறீர்கள்?

• 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