உங்கள் மோனோலித்தை மைக்ரோ சர்வீஸாக மாற்றியமைப்பதில் பல மாதங்கள் செலவழித்துள்ளீர்கள், இறுதியாக அனைவரும் ஒன்றுசேர்ந்து சுவிட்சைப் புரட்டுகிறார்கள். நீங்கள் முதல் இணையப் பக்கத்திற்குச் செல்லுங்கள்... எதுவும் நடக்காது. நீங்கள் அதை மீண்டும் ஏற்றவும் - மீண்டும் எதுவும் நன்றாக இல்லை, தளம் மிகவும் மெதுவாக உள்ளது, அது பல நிமிடங்களுக்கு பதிலளிக்காது. என்ன நடந்தது?
அவரது உரையில், ஜிம்மி போகார்ட் நிஜ வாழ்க்கை மைக்ரோ சர்வீஸ் பேரழிவைப் பற்றி "பிரேத பரிசோதனை" நடத்துவார். அவர் கண்டுபிடித்த மாடலிங், மேம்பாடு மற்றும் உற்பத்தி சிக்கல்கள் மற்றும் அவரது குழு எவ்வாறு புதிய விநியோகிக்கப்பட்ட மோனோலித்தை நல்லறிவின் இறுதிப் படமாக மாற்றியது என்பதைக் காண்பிப்பார். வடிவமைப்புப் பிழைகளை முற்றிலுமாகத் தடுப்பது சாத்தியமில்லை என்றாலும், இறுதித் தயாரிப்பு நம்பகமான விநியோகிக்கப்பட்ட அமைப்பாக மாறுவதை உறுதிசெய்ய, வடிவமைப்புச் செயல்பாட்டின் ஆரம்பத்திலேயே நீங்கள் சிக்கலைக் கண்டறியலாம்.
அனைவருக்கும் வணக்கம், நான் ஜிம்மி மற்றும் மைக்ரோ சர்வீஸ்களை உருவாக்கும்போது மெகா பேரழிவுகளை எவ்வாறு தவிர்க்கலாம் என்பதை இன்று நீங்கள் கேட்கப் போகிறீர்கள். சுமார் ஒன்றரை வருடங்கள் நான் பணிபுரிந்த ஒரு நிறுவனத்தின் கப்பல் பனிப்பாறையில் மோதாமல் இருக்க உதவும் கதை இது. இந்தக் கதையைச் சரியாகச் சொல்ல, நாம் காலப்போக்கில் பின்னோக்கிச் சென்று, இந்த நிறுவனம் எங்கிருந்து தொடங்கியது மற்றும் காலப்போக்கில் அதன் ஐடி உள்கட்டமைப்பு எவ்வாறு வளர்ந்தது என்பதைப் பற்றி பேச வேண்டும். இந்த பேரிடரில் அப்பாவிகளின் பெயர்களை பாதுகாக்க, இந்த நிறுவனத்தின் பெயரை பெல் கம்ப்யூட்டர்ஸ் என மாற்றியுள்ளேன். 90களின் நடுப்பகுதியில் இத்தகைய நிறுவனங்களின் தகவல் தொழில்நுட்ப உள்கட்டமைப்பு எப்படி இருந்தது என்பதை அடுத்த ஸ்லைடு காட்டுகிறது. இது கம்ப்யூட்டர் ஹார்டுவேர் ஸ்டோரை இயக்குவதற்கான ஒரு பெரிய யுனிவர்சல் ஃபால்ட்-டாலரண்ட் ஹெச்பி டேன்டெம் மெயின்பிரேம் சர்வரின் பொதுவான கட்டமைப்பாகும்.
அவர்கள் அனைத்து ஆர்டர்கள், விற்பனை, வருமானம், தயாரிப்பு பட்டியல்கள் மற்றும் வாடிக்கையாளர் தளத்தை நிர்வகிக்க ஒரு அமைப்பை உருவாக்க வேண்டும், எனவே அவர்கள் அந்த நேரத்தில் மிகவும் பொதுவான மெயின்பிரேம் தீர்வைத் தேர்ந்தெடுத்தனர். இந்த மாபெரும் அமைப்பானது நிறுவனத்தைப் பற்றிய ஒவ்வொரு பிட் தகவல்களையும், சாத்தியமான அனைத்தையும் கொண்டுள்ளது, மேலும் ஒவ்வொரு பரிவர்த்தனையும் இந்த மெயின்பிரேம் மூலம் மேற்கொள்ளப்பட்டது. அவர்கள் தங்கள் அனைத்து முட்டைகளையும் ஒரே கூடையில் வைத்து, அது சாதாரணமானது என்று நினைத்தார்கள். இங்கே சேர்க்கப்படாத ஒரே விஷயம் அஞ்சல் ஆர்டர் பட்டியல்கள் மற்றும் தொலைபேசி மூலம் ஆர்டர்களை வைப்பது.
காலப்போக்கில், அமைப்பு பெரியதாகவும் பெரியதாகவும் மாறியது, மேலும் அதில் ஒரு பெரிய அளவு குப்பை குவிந்தது. மேலும், COBOL என்பது உலகில் மிகவும் வெளிப்படையான மொழி அல்ல, எனவே இந்த அமைப்பு ஒரு பெரிய, ஒரே மாதிரியான குப்பைத் துண்டுகளாக முடிந்தது. 2000 ஆம் ஆண்டு வாக்கில், பல நிறுவனங்கள் இணையதளங்களைக் கொண்டிருப்பதைக் கண்டனர், அதன் மூலம் அவர்கள் தங்கள் வணிகத்தை முழுவதுமாக நடத்தினார்கள், மேலும் அவர்களின் முதல் வணிக டாட்-காம் வலைத்தளத்தை உருவாக்க முடிவு செய்தனர்.
ஆரம்ப வடிவமைப்பு மிகவும் அழகாக இருந்தது மற்றும் உயர்மட்ட தளமான bell.com மற்றும் தனிப்பட்ட பயன்பாடுகளுக்கான பல துணை டொமைன்களைக் கொண்டிருந்தது: catalog.bell.com, accounts.bell.com, orders.bell.com, தயாரிப்பு தேடல் search.bell. com. ஒவ்வொரு துணை டொமைனும் ASP.Net 1.0 கட்டமைப்பையும் அதன் சொந்த தரவுத்தளங்களையும் பயன்படுத்தியது, மேலும் அவை அனைத்தும் கணினி பின்தளத்தில் பேசப்பட்டன. இருப்பினும், அனைத்து ஆர்டர்களும் ஒரு பெரிய மெயின்பிரேமுக்குள் தொடர்ந்து செயலாக்கப்பட்டு செயல்படுத்தப்பட்டன, அதில் அனைத்து குப்பைகளும் இருந்தன, ஆனால் முன் இறுதியில் தனிப்பட்ட பயன்பாடுகள் மற்றும் தனி தரவுத்தளங்களுடன் தனி வலைத்தளங்கள் இருந்தன.
எனவே கணினியின் வடிவமைப்பு ஒழுங்காகவும் தர்க்கரீதியாகவும் இருந்தது, ஆனால் உண்மையான அமைப்பு அடுத்த ஸ்லைடில் காட்டப்பட்டுள்ளது.
அனைத்து கூறுகளும் ஒன்றுக்கொன்று அழைப்புகள், அணுகப்பட்ட APIகள், உட்பொதிக்கப்பட்ட மூன்றாம் தரப்பு dllகள் மற்றும் பல. பதிப்பு கட்டுப்பாட்டு அமைப்புகள் வேறொருவரின் குறியீட்டைப் பிடுங்கி, அதை திட்டத்திற்குள் தள்ளும், பின்னர் எல்லாம் உடைந்துவிடும். MS SQL Server 2005 இணைப்பு சேவையகங்களின் கருத்தைப் பயன்படுத்தியது, மேலும் ஸ்லைடில் நான் அம்புக்குறிகளைக் காட்டவில்லை என்றாலும், ஒவ்வொரு தரவுத்தளங்களும் ஒருவருக்கொருவர் பேசிக்கொண்டன, ஏனெனில் பல தரவுத்தளங்களிலிருந்து பெறப்பட்ட தரவுகளின் அடிப்படையில் அட்டவணைகளை உருவாக்குவதில் எந்த தவறும் இல்லை.
கணினியின் வெவ்வேறு தர்க்கரீதியான பகுதிகளுக்கு இடையே அவை இப்போது சில பிரிவினைகளைக் கொண்டிருப்பதால், இது விநியோகிக்கப்பட்ட அழுக்குப் பகுதிகளாக மாறியது, மிகப்பெரிய குப்பைத் துண்டு இன்னும் மெயின்பிரேம் பின்தளத்தில் உள்ளது.
வேடிக்கையான விஷயம் என்னவென்றால், இந்த மெயின்பிரேம் பெல் கம்ப்யூட்டர்களின் போட்டியாளர்களால் கட்டப்பட்டது மற்றும் அவர்களின் தொழில்நுட்ப ஆலோசகர்களால் இன்னும் பராமரிக்கப்படுகிறது. அதன் பயன்பாடுகளின் திருப்தியற்ற செயல்திறனை நம்பிய நிறுவனம், அவற்றை அகற்றி கணினியை மறுவடிவமைப்பு செய்ய முடிவு செய்தது.
தற்போதுள்ள பயன்பாடு 15 ஆண்டுகளாக தயாரிப்பில் உள்ளது, இது ASP.Net அடிப்படையிலான பயன்பாடுகளுக்கான சாதனையாகும். சேவை உலகம் முழுவதிலுமிருந்து ஆர்டர்களை ஏற்றுக்கொண்டது, மேலும் இந்த ஒற்றை பயன்பாட்டிலிருந்து ஆண்டு வருமானம் பில்லியன் டாலர்களை எட்டியது. லாபத்தின் கணிசமான பகுதியை bell.com இணையதளம் உருவாக்கியது. கருப்பு வெள்ளிக்கிழமைகளில், தளத்தின் மூலம் செய்யப்பட்ட ஆர்டர்களின் எண்ணிக்கை பல மில்லியனை எட்டியது. இருப்பினும், தற்போதுள்ள கட்டிடக்கலை எந்த வளர்ச்சியையும் அனுமதிக்கவில்லை, ஏனெனில் கணினி உறுப்புகளின் கடினமான ஒன்றோடொன்று நடைமுறையில் சேவையில் எந்த மாற்றத்தையும் செய்ய அனுமதிக்கவில்லை.
உலகளாவிய நிறுவனங்களில் இதுபோன்ற வர்த்தகத் திட்டம் மிகவும் பொதுவானது என்ற போதிலும், ஒரு நாட்டிலிருந்து ஒரு ஆர்டரை வைக்க இயலாமை, மற்றொரு நாட்டிற்கு பணம் செலுத்தி மூன்றில் ஒரு பகுதிக்கு அனுப்ப இயலாமை மிகவும் கடுமையான பிரச்சனை. தற்போதுள்ள இணையதளம் இது போன்ற எதையும் அனுமதிக்கவில்லை, எனவே அவர்கள் தொலைபேசியில் இந்த ஆர்டர்களை ஏற்று செய்ய வேண்டியிருந்தது. இது கட்டமைப்பை மாற்றுவது பற்றி, குறிப்பாக மைக்ரோ சர்வீஸுக்கு மாறுவது பற்றி நிறுவனம் அதிகளவில் சிந்திக்க வழிவகுத்தது.
இதேபோன்ற சிக்கலை அவர்கள் எவ்வாறு தீர்த்தார்கள் என்பதைப் பார்க்க மற்ற நிறுவனங்களைப் பார்த்து அவர்கள் புத்திசாலித்தனமான காரியத்தைச் செய்தனர். இந்த தீர்வுகளில் ஒன்று நெட்ஃபிக்ஸ் சேவை கட்டமைப்பாகும், இது ஏபிஐ மற்றும் வெளிப்புற தரவுத்தளத்தின் வழியாக இணைக்கப்பட்ட மைக்ரோ சர்வீஸ்களைக் கொண்டுள்ளது.
பெல் கம்ப்யூட்டர்ஸ் நிர்வாகம் சில அடிப்படைக் கொள்கைகளைப் பின்பற்றி, அத்தகைய கட்டிடக்கலையை உருவாக்க முடிவு செய்தது. முதலில், அவர்கள் பகிரப்பட்ட தரவுத்தள அணுகுமுறையைப் பயன்படுத்தி தரவு நகலெடுப்பை அகற்றினர். தரவு எதுவும் அனுப்பப்படவில்லை; மாறாக, தேவைப்படும் அனைவரும் மையப்படுத்தப்பட்ட மூலத்திற்குச் செல்ல வேண்டும். இதைத் தொடர்ந்து தனிமைப்படுத்தல் மற்றும் சுயாட்சி - ஒவ்வொரு சேவையும் மற்றவற்றிலிருந்து சுயாதீனமாக இருந்தது. முற்றிலும் எல்லாவற்றிற்கும் Web API ஐப் பயன்படுத்த அவர்கள் முடிவு செய்தனர் - நீங்கள் தரவைப் பெற விரும்பினால் அல்லது மற்றொரு கணினியில் மாற்றங்களைச் செய்ய விரும்பினால், அனைத்தும் Web API மூலம் செய்யப்பட்டது. போட்டியாளர்களின் வன்பொருளை அடிப்படையாகக் கொண்ட "பெல்" மெயின்பிரேமுக்கு மாறாக "பெல் ஆன் பெல்" என்ற புதிய மெயின்பிரேம்தான் கடைசி பெரிய விஷயம்.
எனவே, 18 மாத காலப்பகுதியில், அவர்கள் இந்த அடிப்படைக் கொள்கைகளைச் சுற்றி அமைப்பை உருவாக்கி அதை முன் தயாரிப்புக்குக் கொண்டு வந்தனர். வார இறுதிக்குப் பிறகு வேலைக்குத் திரும்பியதும், டெவலப்பர்கள் ஒன்றுசேர்ந்து, புதிய அமைப்பு இணைக்கப்பட்ட அனைத்து சேவையகங்களையும் இயக்கினர். 18 மாத வேலை, நூற்றுக்கணக்கான டெவலப்பர்கள், அதி நவீன பெல் ஹார்டுவேர் - மற்றும் நேர்மறையான முடிவு இல்லை! இது பலருக்கு ஏமாற்றத்தை அளித்துள்ளது, ஏனெனில் அவர்கள் இந்த அமைப்பை தங்கள் மடிக்கணினிகளில் பல முறை இயக்கி எல்லாம் நன்றாக இருந்தது.
இந்தப் பிரச்சனையைத் தீர்ப்பதற்குத் தங்கள் பணத்தைச் செலவழிக்க அவர்கள் புத்திசாலித்தனமாக இருந்தனர். அவர்கள் சுவிட்சுகள் கொண்ட மிக நவீன சர்வர் ரேக்குகளை நிறுவினர், ஜிகாபிட் ஆப்டிகல் ஃபைபர், பைத்தியம் இல்லாத அளவு ரேம் கொண்ட மிக சக்திவாய்ந்த சர்வர் வன்பொருள், அனைத்தையும் இணைத்து, கட்டமைத்தார்கள் - மீண்டும், எதுவும் இல்லை! பின்னர் அவர்கள் காரணம் காலாவதியாக இருக்கலாம் என்று சந்தேகிக்கத் தொடங்கினர், எனவே அவர்கள் அனைத்து வலை அமைப்புகளுக்கும், அனைத்து API அமைப்புகளுக்கும் சென்று, முழு நேரமுடிவு உள்ளமைவையும் அதிகபட்ச மதிப்புகளுக்குப் புதுப்பித்தனர், இதனால் அவர்கள் செய்யக்கூடியதெல்லாம் உட்கார்ந்து ஏதாவது நடக்கும் வரை காத்திருக்க வேண்டும். தளத்திற்கு. கடைசியில் இணையதளம் ஏற்றப்படும் வரை 9. அரை நிமிடம் காத்திருந்து காத்திருந்தனர்.
அதன்பிறகு, தற்போதைய சூழ்நிலையை முழுமையாகப் பகுப்பாய்வு செய்ய வேண்டும் என்று அவர்களுக்குப் புரிந்தது, அவர்கள் எங்களை அழைத்தார்கள். நாங்கள் கண்டுபிடித்த முதல் விஷயம் என்னவென்றால், 18 மாத வளர்ச்சியின் போது, ஒரு உண்மையான "மைக்ரோ" கூட உருவாக்கப்படவில்லை - எல்லாம் பெரிதாகிவிட்டது. இதற்குப் பிறகு, பேரழிவுக்கான காரணத்தைப் புரிந்துகொள்வதற்காக, "மூளைப் புயல்" போன்ற "குற்றச்சாட்டு புயல்" என்றும் அழைக்கப்படும் "வருத்தம்" அல்லது "சோகமான பின்னோக்கி" என்றும் அழைக்கப்படும் போஸ்ட் மார்ட்டம் எழுதத் தொடங்கினோம்.
எங்களிடம் பல தடயங்கள் இருந்தன, அவற்றில் ஒன்று API அழைப்பின் போது முழுமையான ட்ராஃபிக் செறிவூட்டலாக இருந்தது. நீங்கள் ஒரு மோனோலிதிக் சேவை கட்டமைப்பைப் பயன்படுத்தும்போது, தோல்விக்குக் காரணமான அனைத்தையும் தெரிவிக்கும் ஒற்றை அடுக்கு ட்ரேஸ் உங்களிடம் இருப்பதால், சரியாக என்ன தவறு நடந்தது என்பதை நீங்கள் உடனடியாகப் புரிந்து கொள்ளலாம். ஒரே நேரத்தில் பல சேவைகள் ஒரே ஏபிஐயை அணுகினால், வயர்ஷார்க் போன்ற கூடுதல் நெட்வொர்க் கண்காணிப்பு கருவிகளைப் பயன்படுத்துவதைத் தவிர, ட்ரேஸைக் கண்காணிக்க எந்த வழியும் இல்லை, இதற்கு நன்றி, நீங்கள் ஒரு கோரிக்கையை ஆராய்ந்து அதன் செயல்பாட்டின் போது என்ன நடந்தது என்பதைக் கண்டறியலாம். எனவே நாங்கள் ஒரு வலைப்பக்கத்தை எடுத்து கிட்டத்தட்ட 2 வாரங்கள் புதிரின் பகுதிகளை ஒன்றாக இணைத்து, அதற்கு பலவிதமான அழைப்புகளைச் செய்து அவை ஒவ்வொன்றும் என்ன வழிவகுத்தது என்பதை பகுப்பாய்வு செய்தோம்.
இந்தப் படத்தைப் பாருங்கள். ஒரு வெளிப்புற கோரிக்கையானது திரும்ப திரும்ப பல உள் அழைப்புகளைச் செய்ய சேவையைத் தூண்டுகிறது என்பதை இது காட்டுகிறது. இந்த கோரிக்கையை சுயாதீனமாகச் செய்ய ஒவ்வொரு உள் அழைப்பும் கூடுதல் ஹாப்களை உருவாக்குகிறது, ஏனெனில் தேவையான தகவல்களைப் பெற வேறு எங்கும் திரும்ப முடியாது. வெளிப்புறக் கோரிக்கையானது, மற்ற கூடுதல் சேவைகளை அழைக்கும் கூடுதல் சேவைகளை அழைப்பதால், இந்த படம் அர்த்தமற்ற அழைப்புகள் போல் தெரிகிறது.
இந்த வரைபடத்தில் உள்ள பச்சை நிறம் ஒரு அரை வட்டத்தைக் காட்டுகிறது, அதில் சேவைகள் ஒன்றையொன்று அழைக்கின்றன - சேவை A சேவையை B ஐ அழைக்கிறது, சேவை B சேவையை C அழைக்கிறது, மேலும் அது சேவை A ஐ மீண்டும் அழைக்கிறது. இதன் விளைவாக, "விநியோகம் செய்யப்பட்ட முட்டுக்கட்டை" பெறுவோம். ஒரு கோரிக்கை ஆயிரம் நெட்வொர்க் ஏபிஐ அழைப்புகளை உருவாக்கியது, மேலும் கணினியில் உள்ளமைந்த தவறு சகிப்புத்தன்மை மற்றும் லூப் பாதுகாப்பு இல்லாததால், இந்த ஏபிஐ அழைப்புகளில் ஒன்று கூட தோல்வியுற்றால் கோரிக்கை தோல்வியடையும்.
நாங்கள் கொஞ்சம் கணிதம் செய்தோம். ஒவ்வொரு API அழைப்பிலும் SLA 150 msக்கு மேல் இல்லை மற்றும் 99,9% இயக்க நேரம் உள்ளது. ஒரு கோரிக்கை 200 வெவ்வேறு அழைப்புகளை ஏற்படுத்தியது, மேலும் சிறந்த நிலையில், பக்கம் 200 x 150 ms = 30 வினாடிகளில் காட்டப்படும். இயற்கையாகவே, இது நல்லதல்ல. 99,9% இயக்க நேரத்தை 200 ஆல் பெருக்கினால், 0% கிடைக்கும். இந்த கட்டிடக்கலை ஆரம்பத்தில் இருந்தே தோல்விக்கு ஆளானது என்று மாறிவிடும்.
18 மாத வேலைக்குப் பிறகு டெவலப்பர்கள் இந்தச் சிக்கலை எவ்வாறு அடையாளம் காணவில்லை என்று நாங்கள் கேட்டோம்? அவர்கள் இயக்கிய குறியீட்டிற்கு SLA ஐ மட்டுமே கணக்கிட்டனர், ஆனால் அவர்களின் சேவை மற்றொரு சேவையை அழைத்தால், அவர்கள் அந்த நேரத்தை SLA இல் கணக்கிடவில்லை. ஒரு செயல்பாட்டிற்குள் தொடங்கப்பட்ட அனைத்தும் 150 எம்எஸ் மதிப்பைக் கடைப்பிடித்தன, ஆனால் பிற சேவை செயல்முறைகளுக்கான அணுகல் மொத்த தாமதத்தை பல மடங்கு அதிகரித்தது. கற்றுக்கொண்ட முதல் பாடம்: "உங்கள் SLA இன் கட்டுப்பாட்டில் உள்ளீர்களா அல்லது SLA உங்கள் கட்டுப்பாட்டில் உள்ளதா?" எங்கள் விஷயத்தில், அது பிந்தையது.
நாங்கள் கண்டுபிடித்த அடுத்த விஷயம் என்னவென்றால், பீட்டர் டெய்ச் மற்றும் ஜேம்ஸ் கோஸ்லிங் ஆகியோரால் உருவாக்கப்பட்ட விநியோகிக்கப்பட்ட கணினி தவறான கருத்துக்கள் பற்றிய கருத்தை அவர்கள் அறிந்திருந்தனர், ஆனால் அவர்கள் அதன் முதல் பகுதியை புறக்கணித்தனர். "நெட்வொர்க் நம்பகமானது," "பூஜ்ஜிய தாமதம்" மற்றும் "எல்லையற்ற செயல்திறன்" என்ற அறிக்கைகள் தவறான கருத்துக்கள் என்று அது கூறுகிறது. மற்ற தவறான கருத்துக்களில் "நெட்வொர்க் பாதுகாப்பானது", "டோபாலஜி மாறவே மாறாது", "எப்போதும் ஒரே ஒரு நிர்வாகி இருப்பார்," "தரவு பரிமாற்றத்தின் விலை பூஜ்ஜியம்" மற்றும் "நெட்வொர்க் ஒரே மாதிரியானது" போன்ற அறிக்கைகள் அடங்கும்.
உள்ளூர் இயந்திரங்களில் தங்கள் சேவையைச் சோதித்ததாலும், வெளிப்புறச் சேவைகளுடன் ஒருபோதும் இணையாததாலும் அவர்கள் தவறு செய்தார்கள். உள்நாட்டில் வளரும்போது மற்றும் உள்ளூர் தற்காலிக சேமிப்பைப் பயன்படுத்தும் போது, அவர்கள் நெட்வொர்க் ஹாப்களை சந்தித்ததில்லை. அனைத்து 18 மாத வளர்ச்சியிலும், வெளிப்புற சேவைகள் பாதிக்கப்பட்டால் என்ன நடக்கும் என்று அவர்கள் ஒருபோதும் யோசித்ததில்லை.
முந்தைய படத்தில் உள்ள சேவை எல்லைகளைப் பார்த்தால், அவை அனைத்தும் தவறாக இருப்பதைக் காணலாம். சேவை எல்லைகளை எவ்வாறு வரையறுப்பது என்பது குறித்து ஆலோசனை வழங்கும் ஆதாரங்கள் ஏராளமாக உள்ளன, மேலும் அடுத்த ஸ்லைடில் மைக்ரோசாப்ட் போல பெரும்பாலானவை தவறு செய்கின்றன.
இந்த படம் "மைக்ரோ சர்வீஸ்களை எவ்வாறு உருவாக்குவது" என்ற தலைப்பில் MS வலைப்பதிவில் இருந்து எடுக்கப்பட்டது. இது ஒரு எளிய வலை பயன்பாடு, வணிக தர்க்கத்தின் தொகுதி மற்றும் தரவுத்தளத்தைக் காட்டுகிறது. கோரிக்கை நேரடியாக வருகிறது, இணையத்திற்கு ஒரு சேவையகம், வணிகத்திற்கு ஒரு சேவையகம் மற்றும் தரவுத்தளத்திற்கு ஒன்று இருக்கலாம். ட்ராஃபிக்கை அதிகப்படுத்தினால் படம் கொஞ்சம் மாறும்.
இரண்டு இணைய சேவையகங்களுக்கிடையில் போக்குவரத்தை விநியோகிக்க ஒரு சுமை சமநிலை, இணைய சேவைக்கும் வணிக தர்க்கத்திற்கும் இடையில் அமைந்துள்ள ஒரு தற்காலிக சேமிப்பு மற்றும் வணிக தர்க்கத்திற்கும் தரவுத்தளத்திற்கும் இடையில் மற்றொரு தற்காலிக சேமிப்பு உள்ளது. 2000 களின் நடுப்பகுதியில் பெல் அதன் சுமை சமநிலை மற்றும் நீலம்/பச்சை வரிசைப்படுத்தல் பயன்பாட்டிற்குப் பயன்படுத்தப்பட்ட கட்டிடக்கலை இதுதான். இந்த திட்டம் ஒரு ஒற்றைக் கட்டமைப்பிற்காக வடிவமைக்கப்பட்டதால், சிறிது நேரம் வரை எல்லாம் நன்றாக வேலை செய்தது.
ஒரு ஒற்றைப்பாதையில் இருந்து மைக்ரோ சர்வீஸுக்கு மாற MS எவ்வாறு பரிந்துரைக்கிறது என்பதை பின்வரும் படம் காட்டுகிறது - ஒவ்வொரு முக்கிய சேவையையும் தனித்தனி மைக்ரோ சர்வீஸ்களாகப் பிரிப்பது. இந்தத் திட்டத்தைச் செயல்படுத்தும்போதுதான் பெல் ஒரு தவறு செய்தார்.
அவர்கள் தங்கள் அனைத்து சேவைகளையும் வெவ்வேறு அடுக்குகளாகப் பிரித்தனர், அவை ஒவ்வொன்றும் பல தனிப்பட்ட சேவைகளைக் கொண்டிருந்தன. எடுத்துக்காட்டாக, வலைச் சேவையானது உள்ளடக்கம் வழங்குதல் மற்றும் அங்கீகாரத்திற்கான மைக்ரோ சர்வீஸ்களை உள்ளடக்கியது, வணிக லாஜிக் சேவையானது ஆர்டர்கள் மற்றும் கணக்குத் தகவலைச் செயலாக்குவதற்கான மைக்ரோ சர்வீஸ்களைக் கொண்டிருந்தது, தரவுத்தளமானது சிறப்புத் தரவுகளுடன் மைக்ரோ சர்வீஸ்களின் தொகுப்பாகப் பிரிக்கப்பட்டது. இணையம், வணிக தர்க்கம் மற்றும் தரவுத்தளம் ஆகிய இரண்டும் நிலையற்ற சேவைகள்.
இருப்பினும், இந்த படம் முற்றிலும் தவறானது, ஏனெனில் இது நிறுவனத்தின் ஐடி கிளஸ்டருக்கு வெளியே எந்த வணிக அலகுகளையும் வரைபடமாக்கவில்லை. இந்தத் திட்டம் வெளி உலகத்துடனான எந்தவொரு தொடர்பையும் கணக்கில் எடுத்துக் கொள்ளவில்லை, எனவே மூன்றாம் தரப்பு வணிக பகுப்பாய்வுகளை எவ்வாறு பெறுவது என்பது தெளிவாகத் தெரியவில்லை. அதிகப் பணத்தைப் பெறுவதற்காக முடிந்தவரை பலரை நிர்வகிக்க முற்படும் தனிப்பட்ட ஊழியர்களின் வாழ்க்கையை மேம்படுத்துவதற்காக அவர்கள் பல சேவைகளை கண்டுபிடித்துள்ளனர் என்பதை நான் கவனிக்கிறேன்.
மைக்ரோ சர்வீஸுக்கு நகர்வது அவர்களின் உள் N-அடுக்கு இயற்பியல் அடுக்கு உள்கட்டமைப்பை எடுத்து அதில் டோக்கரை ஒட்டுவது போல் எளிதானது என்று அவர்கள் நம்பினர். பாரம்பரிய என்-அடுக்கு கட்டிடக்கலை எப்படி இருக்கும் என்று பார்க்கலாம்.
இது 4 நிலைகளைக் கொண்டுள்ளது: UI பயனர் இடைமுக நிலை, வணிக தர்க்க நிலை, தரவு அணுகல் நிலை மற்றும் தரவுத்தளம். மிகவும் முற்போக்கானது DDD (டொமைன்-டிரைவன் டிசைன்) அல்லது மென்பொருள் சார்ந்த கட்டமைப்பு ஆகும், இதில் இரண்டு நடுத்தர நிலைகள் டொமைன் பொருள்கள் மற்றும் களஞ்சியமாகும்.
இந்த கட்டிடக்கலையில் மாற்றத்தின் வெவ்வேறு பகுதிகள், பொறுப்பின் வெவ்வேறு பகுதிகளைப் பார்க்க முயற்சித்தேன். ஒரு பொதுவான N-அடுக்கு பயன்பாட்டில், மேலிருந்து கீழாக செங்குத்தாக கட்டமைப்பை ஊடுருவக்கூடிய மாற்றத்தின் வெவ்வேறு பகுதிகள் வகைப்படுத்தப்படுகின்றன. இவை பட்டியல், தனிப்பட்ட கணினிகளில் செய்யப்படும் கட்டமைப்பு அமைப்புகள் மற்றும் எனது குழுவால் கையாளப்பட்ட Checkout காசோலைகள்.
இந்தத் திட்டத்தின் தனித்தன்மை என்னவென்றால், இந்த மாற்றங்களின் எல்லைகள் வணிக தர்க்க மட்டத்தை மட்டுமல்ல, தரவுத்தளத்திற்கும் நீட்டிக்கப்படுகின்றன.
ஒரு சேவை என்றால் என்ன என்று பார்ப்போம். ஒரு சேவை வரையறையின் 6 சிறப்பியல்பு பண்புகள் உள்ளன - இது மென்பொருள்:
- ஒரு குறிப்பிட்ட நிறுவனத்தால் உருவாக்கப்பட்டு பயன்படுத்தப்படுகிறது;
- கணினியில் ஒரு குறிப்பிட்ட வகை தகவலை உள்ளடக்கம், செயலாக்கம் மற்றும்/அல்லது வழங்குதல் ஆகியவற்றிற்கு பொறுப்பாகும்;
- குறிப்பிட்ட செயல்பாட்டுத் தேவைகளைப் பூர்த்தி செய்ய கட்டமைக்கப்படலாம், வரிசைப்படுத்தலாம் மற்றும் சுயாதீனமாக இயக்கலாம்;
- நுகர்வோர் மற்றும் பிற சேவைகளுடன் தொடர்புகொள்வது, ஒப்பந்தங்கள் அல்லது ஒப்பந்த உத்தரவாதங்களின் அடிப்படையில் தகவல்களை வழங்குதல்;
- அங்கீகரிக்கப்படாத அணுகலில் இருந்து தன்னைப் பாதுகாத்துக் கொள்கிறது, மற்றும் அதன் தகவல் இழப்பிலிருந்து;
- தகவல் சேதத்திற்கு வழிவகுக்காத வகையில் தோல்விகளைக் கையாளுகிறது.
இந்த பண்புகள் அனைத்தையும் "தன்னாட்சி" என்ற ஒரு வார்த்தையில் வெளிப்படுத்தலாம். சேவைகள் ஒருவருக்கொருவர் சுயாதீனமாக இயங்குகின்றன, சில கட்டுப்பாடுகளை பூர்த்தி செய்கின்றன, மேலும் மக்கள் தங்களுக்குத் தேவையான தகவல்களைப் பெறக்கூடிய அடிப்படையில் ஒப்பந்தங்களை வரையறுக்கின்றன. குறிப்பிட்ட தொழில்நுட்பங்களைப் பற்றி நான் குறிப்பிடவில்லை, அதன் பயன்பாடு சுயமாகத் தெரியும்.
இப்போது மைக்ரோ சர்வீஸின் வரையறையைப் பார்ப்போம்:
- ஒரு மைக்ரோ சர்வீஸ் அளவு சிறியது மற்றும் ஒரு குறிப்பிட்ட சிக்கலை தீர்க்க வடிவமைக்கப்பட்டுள்ளது;
- மைக்ரோ சர்வீஸ் தன்னாட்சி கொண்டது;
- மைக்ரோ சர்வீஸ் கட்டமைப்பை உருவாக்கும் போது, நகர திட்டமிடல் உருவகம் பயன்படுத்தப்படுகிறது. சாம் நியூமனின் பில்டிங் மைக்ரோ சர்வீசஸ் புத்தகத்தில் இருந்து இது வரைவிலக்கணம்.
எல்லைக்குட்பட்ட சூழலின் வரையறை எரிக் எவன்ஸின் டொமைன்-டிரைவன் டிசைன் புத்தகத்திலிருந்து எடுக்கப்பட்டது. இது டிடிடியின் ஒரு முக்கிய வடிவமாகும், இது வால்யூமெட்ரிக் கட்டடக்கலை மாதிரிகளுடன் வேலை செய்யும் ஒரு கட்டிடக்கலை வடிவமைப்பு மையமாகும், அவற்றை வெவ்வேறு எல்லைக்குட்பட்ட சூழல்களாகப் பிரித்து அவற்றுக்கிடையேயான தொடர்புகளை வெளிப்படையாக வரையறுக்கிறது.
எளிமையாகச் சொன்னால், ஒரு குறிப்பிட்ட தொகுதியைப் பயன்படுத்தக்கூடிய நோக்கத்தை ஒரு எல்லைக்குட்பட்ட சூழல் குறிக்கிறது. இந்த சூழலில் தர்க்கரீதியாக ஒருங்கிணைக்கப்பட்ட மாதிரி உள்ளது, எடுத்துக்காட்டாக, உங்கள் வணிக டொமைனில். ஆர்டர்களில் ஈடுபட்டுள்ள பணியாளர்களிடம் “வாடிக்கையாளர் யார்” என்று கேட்டால், உங்களுக்கு ஒரு வரையறையும், விற்பனையில் ஈடுபடுபவர்களிடம் கேட்டால், இன்னொன்றும், கலைஞர்கள் மூன்றாவது வரையறையையும் தருவார்கள்.
எனவே, எல்லைக்குட்பட்ட சூழல் கூறுகிறது, எங்கள் சேவைகளின் நுகர்வோர் என்ன என்பதற்கு தெளிவான வரையறையை வழங்க முடியாவிட்டால், இந்த வார்த்தையின் அர்த்தத்தைப் பற்றி பேசக்கூடிய எல்லைகளை வரையறுப்போம், பின்னர் இந்த வெவ்வேறு வரையறைகளுக்கு இடையில் மாறுதல் புள்ளிகளை வரையறுப்போம். அதாவது, ஆர்டர்களை வைக்கும் பார்வையில் ஒரு வாடிக்கையாளரைப் பற்றி நாங்கள் பேசுகிறோம் என்றால், இது இது மற்றும் அது, மற்றும் விற்பனையின் பார்வையில் இருந்தால், இது இது மற்றும் அது என்று பொருள்.
மைக்ரோ சர்வீஸின் அடுத்த வரையறையானது, எந்த விதமான உள் செயல்பாடுகளையும் இணைத்து, சுற்றுச்சூழலில் பணிச் செயல்பாட்டின் கூறுகளின் "கசிவை" தடுக்கிறது. அடுத்ததாக "வெளிப்புற தொடர்புகள் அல்லது வெளிப்புற தகவல்தொடர்புகளுக்கான வெளிப்படையான ஒப்பந்தங்களின் வரையறை" வருகிறது, இது SLA களில் இருந்து திரும்பும் ஒப்பந்தங்களின் யோசனையால் குறிப்பிடப்படுகிறது. கடைசி வரையறை என்பது ஒரு செல் அல்லது கலத்தின் உருவகம் ஆகும், அதாவது ஒரு மைக்ரோ சர்வீஸில் உள்ள செயல்பாடுகளின் முழுமையான தொகுப்பு மற்றும் வெளி உலகத்துடன் தொடர்புகொள்வதற்கான ஏற்பிகளின் இருப்பு.
எனவே நாங்கள் பெல் கம்ப்யூட்டர்ஸில் உள்ள தோழர்களிடம், “நீங்கள் உருவாக்கிய எந்த குழப்பத்தையும் எங்களால் சரிசெய்ய முடியாது, ஏனென்றால் அதைச் செய்ய உங்களிடம் பணம் இல்லை, ஆனால் எல்லாவற்றையும் செய்ய நாங்கள் ஒரு சேவையை மட்டுமே சரிசெய்வோம். உணர்வு." இந்த கட்டத்தில், எங்கள் ஒரே சேவையை நாங்கள் எவ்வாறு சரிசெய்தோம் என்பதைச் சொல்வதன் மூலம் தொடங்குகிறேன், இதனால் கோரிக்கைகளுக்கு 9 மற்றும் ஒன்றரை நிமிடங்களுக்கு மேல் விரைவாகப் பதிலளிக்கிறது.
22:30 நிமிடம்
மிக விரைவில் தொடரும்...
கொஞ்சம் விளம்பரம்
எங்களுடன் தங்கியதற்கு நன்றி. எங்கள் கட்டுரைகளை விரும்புகிறீர்களா? மேலும் சுவாரஸ்யமான உள்ளடக்கத்தைப் பார்க்க வேண்டுமா? ஒரு ஆர்டரை வைப்பதன் மூலம் அல்லது நண்பர்களுக்கு பரிந்துரை செய்வதன் மூலம் எங்களை ஆதரிக்கவும், , நுழைவு-நிலை சேவையகங்களின் தனித்துவமான அனலாக், இது உங்களுக்காக எங்களால் கண்டுபிடிக்கப்பட்டது: (RAID1 மற்றும் RAID10 உடன் கிடைக்கும், 24 கோர்கள் வரை மற்றும் 40GB DDR4 வரை).
ஆம்ஸ்டர்டாமில் உள்ள Equinix Tier IV தரவு மையத்தில் Dell R730xd 2 மடங்கு மலிவானதா? இங்கே மட்டும் நெதர்லாந்தில்! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 முதல்! பற்றி படிக்கவும்
ஆதாரம்: www.habr.com