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

அது என்ன?

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

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

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

குறுக்கு வெட்டு கவலை என்றால் என்ன?

நாம் விக்கிபீடியாவைக் கவனித்தால், பின்வரும் வரையறையைக் காணலாம்

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

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

குறுக்கு வெட்டு கவலை என்பது அமைப்பு/நிறுவனத்தின் ஒரு கருத்து அல்லது கூறு ஆகும், இது பல பகுதிகளை பாதிக்கிறது (அல்லது 'குறுக்கு வெட்டுகிறது').

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

குறியீடு மட்டத்தில், குறுக்கு வெட்டுக் கவலைகள் பெரும்பாலும் Aspect-Oriented Programming (AOP) போன்ற நுட்பங்களைப் பயன்படுத்தி செயல்படுத்தப்படுகின்றன, இந்த கவலைகள் தனித்தனி கூறுகளாக மட்டுப்படுத்தப்படுகின்றன, அவை பயன்பாடு முழுவதும் பயன்படுத்தப்படுகின்றன. இது வணிக தர்க்கத்தை இந்தக் கவலைகளிலிருந்து தனிமைப்படுத்தி, குறியீட்டை மேலும் படிக்கக்கூடியதாகவும் பராமரிக்கக்கூடியதாகவும் ஆக்குகிறது.

அம்சங்களின் வகைப்பாடு

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

எனவே, நான் அம்சங்களை மேக்ரோ மற்றும் மைக்ரோ என பிரிக்கப் போகிறேன்.

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

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

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

இந்த கட்டுரையில், எனது முதன்மை கவனம் மேக்ரோ அம்சங்களில் இருக்கும்.

மேக்ரோ அம்சங்கள்

அமைப்பின் கட்டமைப்பு

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

ஒரு அமைப்பை வடிவமைக்கும் எந்தவொரு நிறுவனமும் (பரந்த அளவில் வரையறுக்கப்பட்ட) ஒரு வடிவமைப்பை உருவாக்கும், அதன் கட்டமைப்பு நிறுவனத்தின் தகவல் தொடர்பு கட்டமைப்பின் நகலாகும்.

இந்த கருத்து உண்மையில் மிகவும் உலகளாவியது மற்றும் தங்க விதியை பிரதிபலிக்கிறது என்று நான் எப்போதும் நம்புகிறேன்.

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

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

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

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

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

பெரிய மண் பந்து

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

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

கணினி கட்டமைப்பு

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

மென்பொருள் கட்டமைப்பு என்பது ஒவ்வொரு நாளும் நீங்கள் எடுக்கும் முடிவுகள் மற்றும் தேர்வுகள் கட்டமைக்கப்பட்ட அமைப்பை பாதிக்கும்.

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

மென்பொருள் கட்டிடக்கலை பாணி என்பது மென்பொருளை எவ்வாறு உருவாக்குவது என்பதைக் குறிக்கும் கொள்கைகள் மற்றும் வடிவங்களின் தொகுப்பாகும்.

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

உதாரணமாக, போன்றவை:

1. ஒற்றைக்கல் கட்டிடக்கலை

2. டொமைன் சார்ந்த வடிவமைப்பு

3. கூறு அடிப்படையிலானது

4. நுண் சேவைகள்

5. குழாய் மற்றும் வடிகட்டிகள்

6. நிகழ்வு உந்துதல்

7. மைக்ரோகர்னல்

8. சேவை சார்ந்த

   
   

மற்றும் பல…

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

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

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

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

DAU (தினசரி செயலில் உள்ள பயனர்கள்), MAU (மாதாந்திர செயலில் உள்ள பயனர்கள்), RPC (வினாடிக்கான கோரிக்கை), மற்றும் TPC (வினாடிக்கு பரிவர்த்தனை) போன்ற எண்கள் மற்றும் அளவீடுகளைப் புரிந்துகொள்வதும் இன்றியமையாதது. 100 செயலில் உள்ள பயனர்களும் 100 மில்லியன் செயலில் உள்ள பயனர்களும் வேறுபட்டவர்கள்.

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

தொழில்நுட்ப அடுக்கு தேர்வு

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

தொழில்நுட்ப அடுக்கைத் தேர்ந்தெடுப்பதற்கான அடிப்படைக் கருத்தாய்வுகளின் பட்டியல் இது:

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

பல தொழில்நுட்ப அடுக்குகளை வைத்திருப்பது வணிக வளர்ச்சியை எவ்வாறு பாதிக்கும்?

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

ஆனால் ஒரு குறிப்பிட்ட சிக்கலுக்கு சிறந்த கருவியைத் தேர்ந்தெடுக்கும் கொள்கை என்ன?

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

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

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

தோல்வியின் ஒற்றை புள்ளி (SPOF)

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

தோல்வியின் ஒற்றை புள்ளிகளை அகற்ற பல அடிப்படை நுட்பங்கள் உள்ளன:

1. பணிநீக்கம். முக்கியமான கூறுகளுக்கு பணிநீக்கத்தை செயல்படுத்தவும். இதன் பொருள், முதன்மைக் கூறு தோல்வியுற்றால், காப்புப் பிரதிக் கூறுகளைக் கொண்டிருப்பதைக் குறிக்கிறது. வன்பொருள் (சேவையகங்கள், வட்டுகள்), நெட்வொர்க்கிங் (இணைப்புகள், சுவிட்சுகள்) மற்றும் மென்பொருள் (தரவுத்தளங்கள், பயன்பாட்டு சேவையகங்கள்) உட்பட கணினியின் பல்வேறு அடுக்குகளில் பணிநீக்கம் பயன்படுத்தப்படலாம். நீங்கள் எல்லாவற்றையும் ஒரு கிளவுட் வழங்குநரில் ஹோஸ்ட் செய்து, காப்புப்பிரதிகளை வைத்திருந்தாலும், பேரழிவின் போது உங்கள் இழந்த செலவைக் குறைக்க, மற்றொன்றில் வழக்கமான கூடுதல் காப்புப்பிரதியை உருவாக்கவும்.
2. தரவு மையங்கள். தரவு மையங்கள் அல்லது கிளவுட் பகுதிகள் போன்ற பல இயற்பியல் இருப்பிடங்களில் உங்கள் கணினியை விநியோகிக்கவும். இந்த அணுகுமுறை மின்வெட்டு அல்லது இயற்கை பேரழிவுகள் போன்ற இருப்பிட-குறிப்பிட்ட தோல்விகளுக்கு எதிராக உங்கள் கணினியைப் பாதுகாக்கிறது.
3. தோல்வி. உங்களின் அனைத்து கூறுகளுக்கும் (DNS, CDN, Load balancers, Kubernetes, API நுழைவாயில்கள் மற்றும் தரவுத்தளங்கள்) தோல்வி அணுகுமுறையைப் பயன்படுத்தவும். சிக்கல்கள் எதிர்பாராதவிதமாக எழலாம் என்பதால், எந்த ஒரு கூறுகளையும் அதன் குளோன் மூலம் விரைவாகத் தேவைக்கேற்ப மாற்றுவதற்கான காப்புப் பிரதித் திட்டத்தை வைத்திருப்பது முக்கியம்.
4. உயர் கிடைக்கும் சேவைகள். பின்வரும் கொள்கைகளை கடைபிடிப்பதன் மூலம் உங்கள் சேவைகள் கிடைமட்டமாக அளவிடக்கூடியதாகவும், தொடக்கத்திலிருந்தே அதிக அளவில் கிடைக்கக்கூடியதாகவும் கட்டமைக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்:
   • சேவை நிலையற்ற தன்மையைப் பயிற்சி செய்து, நினைவகத்தில் உள்ள கேச்களில் பயனர் அமர்வுகளைச் சேமிப்பதைத் தவிர்க்கவும். அதற்கு பதிலாக, ரெடிஸ் போன்ற விநியோகிக்கப்பட்ட கேச் சிஸ்டத்தைப் பயன்படுத்தவும்.
   • தர்க்கத்தை உருவாக்கும் போது செய்தி நுகர்வு காலவரிசைப்படி நம்பியிருப்பதைத் தவிர்க்கவும்.
   • API நுகர்வோருக்கு இடையூறு ஏற்படுவதைத் தடுக்க, மாற்றங்களை உடைப்பதைக் குறைக்கவும். முடிந்தால், பின்னோக்கி இணக்கமான மாற்றங்களைத் தேர்ந்தெடுக்கவும். மேலும், சில சமயங்களில் செலவைக் கருத்தில் கொள்ளுங்கள், ஒரு பிரேக்கிங் மாற்றத்தை செயல்படுத்துவது மிகவும் செலவு குறைந்ததாக இருக்கலாம்.
   • வரிசைப்படுத்தல் பைப்லைனில் இடம்பெயர்வு செயல்படுத்தலை இணைக்கவும்.
   • ஒரே நேரத்தில் கோரிக்கைகளை கையாள்வதற்கான உத்தியை உருவாக்கவும்.
   • நம்பகத்தன்மை மற்றும் கவனிப்புத் திறனை மேம்படுத்த, சேவை கண்டுபிடிப்பு, கண்காணிப்பு மற்றும் பதிவு செய்தல் ஆகியவற்றைச் செயல்படுத்தவும்.
   • நெட்வொர்க் தோல்விகள் தவிர்க்க முடியாதவை என்பதை ஒப்புக்கொண்டு, திறமையற்றதாக வணிக தர்க்கத்தை உருவாக்குங்கள்.
5. சார்பு மதிப்பாய்வு. வெளிப்புற சார்புகளை தவறாமல் மதிப்பாய்வு செய்து குறைக்கவும். ஒவ்வொரு வெளிப்புற சார்புநிலையும் சாத்தியமான SPOFகளை அறிமுகப்படுத்தலாம், எனவே இந்த அபாயங்களைப் புரிந்துகொள்வதும் குறைப்பதும் அவசியம்.
6. வழக்கமான அறிவுப் பகிர்வு. உங்கள் நிறுவனத்தில் அறிவைப் பரப்புவதன் முக்கியத்துவத்தை ஒருபோதும் மறந்துவிடாதீர்கள். மக்கள் கணிக்க முடியாதவர்களாக இருக்கலாம், மேலும் ஒரு தனி நபரை நம்புவது ஆபத்தானது. குழு உறுப்பினர்களை ஆவணப்படுத்தல் மூலம் தங்கள் அறிவை டிஜிட்டல் மயமாக்க ஊக்குவிக்கவும். இருப்பினும், அதிகமாக ஆவணப்படுத்துவதை கவனத்தில் கொள்ளுங்கள். இந்த செயல்முறையை எளிதாக்க பல்வேறு AI கருவிகளைப் பயன்படுத்தவும்.

முடிவுரை

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

படித்ததற்கு நன்றி! அடுத்த முறை சந்திப்போம்!