வணக்கம், ஹாப்ர். OTUS இல் புதிய பாடத் தொடருக்கான பதிவு இப்போது திறக்கப்பட்டுள்ளது . பாடத்திட்டத்தின் தொடக்கத்தில், எனது அசல் கட்டுரையை உங்களுடன் பகிர்ந்து கொள்ள விரும்புகிறேன்.
அறிமுகம்
ஒரு தகவல் அமைப்பை உருவாக்கும்போது கட்டடக்கலை பாணியின் தேர்வு அடிப்படை தொழில்நுட்ப முடிவுகளில் ஒன்றாகும். இந்த கட்டுரைத் தொடரில், பயன்பாடுகளை உருவாக்குவதற்கான மிகவும் பிரபலமான கட்டிடக்கலை பாணிகளை பகுப்பாய்வு செய்ய நான் முன்மொழிகிறேன் மற்றும் எந்த கட்டிடக்கலை பாணி எப்போது மிகவும் விரும்பத்தக்கது என்ற கேள்விக்கு பதிலளிக்கிறேன். விளக்கக்காட்சியின் செயல்பாட்டில், மோனோலித்கள் முதல் மைக்ரோ சர்வீஸ்கள் வரை கட்டடக்கலை பாணிகளின் வளர்ச்சியை விளக்கும் தருக்க சங்கிலியை வரைய முயற்சிப்பேன்.
வரலாற்றின் ஒரு பிட்
நீங்கள் டெவலப்பர்களிடம் கேட்க முயற்சித்தால்: "எங்களுக்கு மைக்ரோ சர்வீஸ்கள் ஏன் தேவை?", நீங்கள் பலவிதமான பதில்களைப் பெறுவீர்கள். மைக்ரோ சர்வீஸ்கள் அளவிடக்கூடிய தன்மையை மேம்படுத்துகின்றன, குறியீட்டை எளிதாகப் புரிந்துகொள்கின்றன, தவறு சகிப்புத்தன்மையை மேம்படுத்துகின்றன, மேலும் சில சமயங்களில் அவை "உங்கள் குறியீட்டை சுத்தம் செய்ய" அனுமதிக்கின்றன என்பதை நீங்கள் கேள்விப்படுவீர்கள். மைக்ரோ சர்வீஸ்கள் தோன்றியதன் நோக்கத்தைப் புரிந்துகொள்ள வரலாற்றைப் பார்ப்போம்.
சுருக்கமாக, எங்கள் தற்போதைய புரிதலில் மைக்ரோ சர்வீஸ்கள் பின்வருமாறு எழுந்தன: 2011 ஆம் ஆண்டில், ஜேம்ஸ் லூயிஸ், பல்வேறு நிறுவனங்களின் பணியை பகுப்பாய்வு செய்து, ஒரு புதிய "மைக்ரோ-ஆப்" வடிவத்தின் தோற்றத்திற்கு கவனத்தை ஈர்த்தார், இது SOA ஐ மேம்படுத்துவதை துரிதப்படுத்தும் சேவைகள். சிறிது நேரம் கழித்து, 2012 இல், ஒரு கட்டிடக்கலை உச்சிமாநாட்டில், இந்த முறை மைக்ரோ சர்வீஸ் என மறுபெயரிடப்பட்டது. எனவே, மைக்ரோ சர்வீஸ்களை அறிமுகம் செய்வதன் ஆரம்ப இலக்கு, மோசமானவர்களை மேம்படுத்துவதாகும் சந்தைக்கான நேரம்.
மைக்ரோ சர்வீஸ்கள் 2015 இல் ஹைப் அலையில் இருந்தன. சில ஆய்வுகளின்படி, மைக்ரோ சர்வீஸ் என்ற தலைப்பில் ஒரு அறிக்கை இல்லாமல் ஒரு மாநாடு கூட நிறைவடையவில்லை. மேலும், சில மாநாடுகள் மைக்ரோ சர்வீஸுக்கு பிரத்தியேகமாக அர்ப்பணிக்கப்பட்டன. இப்போதெல்லாம், பல திட்டங்கள் இந்த கட்டிடக்கலை பாணியைப் பயன்படுத்தத் தொடங்குகின்றன, மேலும் திட்டத்தில் டன் மரபுக் குறியீடுகள் இருந்தால், மைக்ரோ சர்வீஸுக்கு இடம்பெயர்வது தீவிரமாக மேற்கொள்ளப்படுகிறது.
மேலே உள்ள அனைத்தையும் மீறி, ஒரு சிறிய எண்ணிக்கையிலான டெவலப்பர்கள் "மைக்ரோ சர்வீஸ்" என்ற கருத்தை இன்னும் வரையறுக்க முடியும். ஆனால் இதைப் பற்றி சிறிது நேரம் கழித்து பேசுவோம் ...
ஒற்றைக்கல்
மைக்ரோ சர்வீஸ்களை வேறுபடுத்தும் கட்டிடக்கலை பாணி மோனோலித் (அல்லது ஆல் இன் ஒன்) ஆகும். மோனோலித் என்றால் என்ன என்று சொல்வதில் அர்த்தமில்லை, எனவே இந்த கட்டடக்கலை பாணியின் தீமைகளை நான் உடனடியாக பட்டியலிடுவேன், இது கட்டடக்கலை பாணிகளின் மேலும் வளர்ச்சியைத் தொடங்கியது: அளவு, இணைப்பு, வரிசைப்படுத்தல், அளவிடுதல், நம்பகத்தன்மை மற்றும் விறைப்பு. ஒவ்வொரு குறைபாடுகளையும் தனித்தனியாகப் பார்க்க கீழே நான் முன்மொழிகிறேன்.
அளவு
ஒற்றைக்கல் மிகப் பெரியது. மேலும் இது பொதுவாக மிகப் பெரிய தரவுத்தளத்துடன் தொடர்பு கொள்கிறது. ஒரு டெவலப்பர் புரிந்து கொள்ள முடியாத அளவுக்கு பயன்பாடு பெரிதாகிறது. இந்த குறியீட்டில் வேலை செய்வதில் அதிக நேரம் செலவழித்தவர்கள் மட்டுமே மோனோலித்துடன் நன்றாக வேலை செய்ய முடியும், அதே நேரத்தில் ஆரம்பநிலையாளர்கள் மோனோலித்தை கண்டுபிடிக்க நிறைய நேரம் செலவிடுவார்கள், மேலும் அவர்கள் அதைக் கண்டுபிடிப்பார்கள் என்பதற்கு எந்த உத்தரவாதமும் இல்லை. வழக்கமாக, ஒரு மோனோலித்துடன் பணிபுரியும் போது, சில "நிபந்தனை" மூத்தவர்கள் எப்போதும் இருக்கிறார்கள், அவர் மோனோலித்தை அதிகமாகவோ அல்லது குறைவாகவோ நன்கு அறிந்தவர் மற்றும் ஒன்றரை ஆண்டுகளுக்குள் மற்ற புதிய டெவலப்பர்களின் கைகளை அடிப்பார். இயற்கையாகவே, அத்தகைய நிபந்தனை மூத்தவர் தோல்வியின் ஒற்றை புள்ளியாகும், மேலும் அவரது புறப்பாடு மோனோலித்தின் மரணத்திற்கு வழிவகுக்கும்.
இணைப்பு
மோனோலித் என்பது "மண்ணின் பெரிய பந்து", இதில் ஏற்படும் மாற்றங்கள் கணிக்க முடியாத விளைவுகளுக்கு வழிவகுக்கும். ஒரு இடத்தில் மாற்றங்களைச் செய்வதன் மூலம், நீங்கள் மற்றொரு இடத்தில் மோனோலித்தை சேதப்படுத்தலாம் (அதே "நீங்கள் உங்கள் காதை சொறிந்தீர்கள், *@ விழுந்தது"). மோனோலித்தில் உள்ள கூறுகள் மிகவும் சிக்கலான மற்றும், மிக முக்கியமாக, வெளிப்படையான உறவுகளைக் கொண்டிருப்பதே இதற்குக் காரணம்.
வரிசைப்படுத்தல்
ஒரு ஒற்றைப்பாதையை வரிசைப்படுத்துவது, அதன் கூறுகளுக்கு இடையே உள்ள சிக்கலான உறவுகளின் காரணமாக, அதன் சொந்த சடங்குடன் ஒரு நீண்ட செயல்முறை ஆகும். இத்தகைய சடங்கு பொதுவாக முற்றிலும் தரப்படுத்தப்படவில்லை மற்றும் "வாய்வழியாக" அனுப்பப்படுகிறது.
அளவீடல்
மோனோலித் தொகுதிகள் முரண்பட்ட ஆதாரத் தேவைகளைக் கொண்டிருக்கலாம், வன்பொருளின் அடிப்படையில் சமரசம் செய்யப்பட வேண்டும். நீங்கள் A மற்றும் B சேவைகளைக் கொண்ட ஒரு மோனோலித் என்று கற்பனை செய்து பாருங்கள். சேவை A ஆனது ஹார்ட் டிரைவின் அளவைக் கோருகிறது, மேலும் சேவை B RAM இல் கோருகிறது. இந்த வழக்கில், மோனோலித் நிறுவப்பட்ட இயந்திரம் இரண்டு சேவைகளின் தேவைகளையும் ஆதரிக்க வேண்டும், அல்லது நீங்கள் கைமுறையாக, செயற்கையாக சேவைகளில் ஒன்றை முடக்க வேண்டும்.
மற்றொரு உதாரணம் (மிகவும் உன்னதமானது): சேவை B சேவையை விட, சேவை A மிகவும் பிரபலமானது, எனவே 100 சேவைகள் A மற்றும் 10 சேவைகள் B இருக்க வேண்டும். மீண்டும், இரண்டு விருப்பங்கள்: ஒன்று 100 முழு அளவிலான மோனோலித்களை பயன்படுத்துவோம், அல்லது சிலவற்றில் சேவைகள் B கைமுறையாக முடக்கப்பட வேண்டும்.
நம்பகத்தன்மை
அனைத்து சேவைகளும் ஒன்றாக அமைந்துள்ளதால், மோனோலித் விழுந்தால், அனைத்து சேவைகளும் ஒரே நேரத்தில் விழும். உண்மையில், இது மிகவும் மோசமாக இருக்காது, குறைந்தபட்சம் விநியோகிக்கப்பட்ட அமைப்பில் பகுதியளவு தோல்விகள் இருக்காது, ஆனால் மறுபுறம், 0.001% பயனர்கள் பயன்படுத்தும் செயல்பாட்டில் உள்ள பிழை காரணமாக, நீங்கள் அனைத்து பயனர்களையும் இழக்க நேரிடும். உங்கள் அமைப்பின்.
மந்தநிலை
மோனோலித்தின் அளவு காரணமாக, புதிய தொழில்நுட்பங்களுக்கு மாறுவது கடினம். இதன் விளைவாக, அதே மூத்தவரைத் தக்கவைத்துக்கொள்வது ஒரு தனி பணியாகும். ஒரு திட்டத்தின் தொடக்கத்தில் தேர்ந்தெடுக்கப்பட்ட தொழில்நுட்ப அடுக்கு தயாரிப்பின் வளர்ச்சியைத் தடுக்கும் ஒரு தொகுதியாக மாறும்.
முடிவுக்கு
அடுத்த முறை, கூறுகள் மற்றும் SOA க்கு நகர்த்துவதன் மூலம் மக்கள் இந்த சிக்கல்களை எவ்வாறு தீர்க்க முயற்சித்தார்கள் என்பதைப் பற்றி பேசுவோம்.
மேலும் படிக்க:
ஆதாரம்: www.habr.com