"என் காலணிகளில் நடப்பது" - காத்திருங்கள், அவை குறிக்கப்பட்டுள்ளதா?

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

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

உண்மையான ஹைலோட்

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

அணி எம்

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

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

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

தொலைதூர குழு கூட்டம்

தொலைதூர வேலையின் போது சந்திப்புகள்

தீர்வுக்கான தொழில்நுட்ப அடுக்கு

X5 க்கான நிலையான களஞ்சியம் மற்றும் CI/CD கருவி GitLab ஆகும். குறியீட்டு சேமிப்பு, தொடர்ச்சியான சோதனை மற்றும் சோதனை மற்றும் உற்பத்தி சேவையகங்களுக்கு பயன்படுத்துவதற்கு இதைப் பயன்படுத்துகிறோம். குறியீட்டில் டெவலப்பர் செய்த மாற்றங்களை குறைந்தது 2 சக பணியாளர்கள் அங்கீகரிக்க வேண்டியிருக்கும் போது, ​​குறியீடு மதிப்பாய்வு நடைமுறையையும் நாங்கள் பயன்படுத்துகிறோம். நிலையான குறியீடு பகுப்பாய்விகளான SonarQube மற்றும் JaCoCo ஆகியவை எங்கள் குறியீட்டை சுத்தமாக வைத்திருக்கவும், தேவையான அளவிலான யூனிட் டெஸ்ட் கவரேஜை உறுதி செய்யவும் உதவுகின்றன. குறியீட்டின் அனைத்து மாற்றங்களும் இந்த சோதனைகள் மூலம் செல்ல வேண்டும். கைமுறையாக இயக்கப்படும் அனைத்து சோதனை ஸ்கிரிப்ட்களும் பின்னர் தானியங்கு செய்யப்படுகின்றன.

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

பணி 1. அமைப்பின் கிடைமட்ட அளவிடுதல் தேவை

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

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

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

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

பணி 2. இயங்குதள சேவைகளுக்கு இடையே அதிக சுமை மற்றும் மிகவும் தீவிரமான தரவு பரிமாற்றத்தை பராமரிக்க வேண்டிய அவசியம்: திட்டத்தின் துவக்க கட்டத்தில் மட்டும், ஒரு வினாடிக்கு சுமார் 600 செயல்பாடுகள் செய்யப்படுகின்றன. சில்லறை விற்பனை நிலையங்கள் எங்கள் தளத்துடன் இணைக்கப்படுவதால், இந்த மதிப்பு 5000 ops/sec ஆக அதிகரிக்கும் என எதிர்பார்க்கிறோம்.

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

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

பணி 3. அதிக அளவிலான தரவைச் சேமிக்க வேண்டிய அவசியம்: புகையிலைக்கு மட்டும் வருடத்திற்கு 1 பில்லியனுக்கும் அதிகமான லேபிள்கள் X5க்கு வருகின்றன. அவர்களுக்கு நிலையான மற்றும் விரைவான அணுகல் தேவை. மொத்தத்தில், இந்த லேபிளிடப்பட்ட பொருட்களின் இயக்க வரலாற்றின் சுமார் 10 பில்லியன் பதிவுகளை கணினி செயலாக்க வேண்டும்.

மூன்றாவது சிக்கலைத் தீர்க்க, NoSQL தரவுத்தளமான MongoDB தேர்ந்தெடுக்கப்பட்டது. நாங்கள் 5 முனைகளின் ஒரு பகுதியை உருவாக்கியுள்ளோம், மேலும் ஒவ்வொரு முனையிலும் 3 சேவையகங்களின் பிரதி தொகுப்பு உள்ளது. இது கணினியை கிடைமட்டமாக அளவிடவும், புதிய சேவையகங்களை கிளஸ்டரில் சேர்க்கவும் மற்றும் அதன் தவறு சகிப்புத்தன்மையை உறுதிப்படுத்தவும் உங்களை அனுமதிக்கிறது. இங்கே நாங்கள் மற்றொரு சிக்கலை எதிர்கொண்டோம் - மோங்கோ கிளஸ்டரில் பரிவர்த்தனையை உறுதி செய்தல், கிடைமட்டமாக அளவிடக்கூடிய மைக்ரோ சர்வீஸ்களின் பயன்பாட்டை கணக்கில் எடுத்துக்கொள்வது. எடுத்துக்காட்டாக, அதே லேபிளிங் குறியீடுகளுடன் தயாரிப்புகளை மீண்டும் விற்பனை செய்வதற்கான முயற்சிகளை அடையாளம் காண்பது எங்கள் அமைப்பின் பணிகளில் ஒன்றாகும். இங்கே, மேலடுக்குகள் தவறான ஸ்கேன் அல்லது காசாளர்களின் தவறான செயல்பாடுகளுடன் தோன்றும். ஒரு காஃப்கா பேட்ச் செயலாக்கப்படுவதற்குள்ளும், இரண்டு தொகுதிகளுக்கு இணையாக செயலாக்கப்படுவதற்குள்ளும் இத்தகைய நகல்கள் நிகழலாம் என்பதைக் கண்டறிந்தோம். இதனால், தரவுத்தளத்தை வினவுவதன் மூலம் நகல்களை சரிபார்ப்பது எதையும் கொடுக்கவில்லை. ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும், இந்தச் சேவையின் வணிக தர்க்கத்தின் அடிப்படையில் சிக்கலைத் தனித்தனியாகத் தீர்த்தோம். எடுத்துக்காட்டாக, காசோலைகளுக்கு, தொகுதிக்குள் ஒரு காசோலையைச் சேர்த்துள்ளோம் மற்றும் செருகும் போது நகல்களின் தோற்றத்திற்கான தனிச் செயலாக்கத்தைச் சேர்த்துள்ளோம்.

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

பணி 4: வரிசை மறு செயலாக்கம் மற்றும் கண்காணிப்பு:

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

அத்தகைய திட்டத்தை செயல்படுத்த, எங்களுக்கு பின்வருபவை தேவைப்படுகின்றன: இந்த தீர்வை ஸ்பிரிங் உடன் ஒருங்கிணைக்கவும் மற்றும் குறியீடு நகலெடுப்பதைத் தவிர்க்கவும். இணையத்தில் உலாவும்போது, ​​Spring BeanPostProccessor அடிப்படையிலான இதேபோன்ற தீர்வை நாங்கள் கண்டோம், ஆனால் அது தேவையில்லாமல் எங்களுக்கு சிரமமாகத் தோன்றியது. எங்கள் குழு ஒரு எளிய தீர்வை உருவாக்கியுள்ளது, இது நுகர்வோரை உருவாக்குவதற்காக வசந்த சுழற்சியில் ஒருங்கிணைக்க அனுமதிக்கிறது மற்றும் கூடுதலாக நுகர்வோரை மீண்டும் முயற்சிக்கவும். ஸ்பிரிங் குழுவிற்கு எங்கள் தீர்வின் முன்மாதிரியை நாங்கள் வழங்கினோம், அதை நீங்கள் பார்க்கலாம் இங்கே. மீண்டும் முயற்சி செய்யும் நுகர்வோரின் எண்ணிக்கை மற்றும் ஒவ்வொரு நுகர்வோருக்கான முயற்சிகளின் எண்ணிக்கையும் வணிகச் செயல்முறையின் தேவைகளைப் பொறுத்து அளவுருக்கள் மூலம் கட்டமைக்கப்படுகின்றன, மேலும் அனைத்தும் செயல்பட, org.springframework.kafka.annotation.KafkaListener என்ற சிறுகுறிப்பைச் சேர்ப்பது மட்டுமே எஞ்சியுள்ளது. , இது அனைத்து ஸ்பிரிங் டெவலப்பர்களுக்கும் தெரிந்திருக்கும்.

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

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

பிளாட்ஃபார்ம் ஆபரேஷன்

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

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

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

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

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