குறிப்பு. மொழிபெயர்: இந்தக் கட்டுரையின் ஆசிரியர் (Luc Perkins) CNCF அமைப்பில் டெவலப்பர் வக்கீல் ஆவார், இது Linkerd, SMI (Service Mesh Interface) மற்றும் Kuma போன்ற ஓப்பன் சோர்ஸ் ப்ராஜெக்ட்டுகளின் தாயகமாக உள்ளது (இஸ்தியோ ஏன் என்று நீங்கள் யோசித்திருக்கிறீர்களா? இந்த பட்டியலில் இல்லையா? "சர்வீஸ் மெஷ்" எனப்படும் நவநாகரீக ஹைப்பைப் பற்றி DevOps சமூகத்திற்கு ஒரு நல்ல புரிதலைக் கொண்டுவர மீண்டும் முயற்சிக்கிறார், அத்தகைய தீர்வுகள் வழங்கும் 16 சிறப்பியல்பு திறன்களை அவர் பட்டியலிடுகிறார்.
இன்று - மென்பொருள் பொறியியல் துறையில் வெப்பமான தலைப்புகளில் ஒன்று (மற்றும் சரியாக!). இந்த தொழில்நுட்பம் நம்பமுடியாத அளவிற்கு நம்பிக்கைக்குரியது என்று நான் நினைக்கிறேன், மேலும் இது பரவலாக ஏற்றுக்கொள்ளப்படுவதைப் பார்க்க விரும்புகிறேன் (நிச்சயமாக அது அர்த்தமுள்ளதாக இருக்கும் போது). இருப்பினும், இது இன்னும் பெரும்பாலான மக்களுக்கு மர்மத்தின் ஒளியால் சூழப்பட்டுள்ளது. அதே நேரத்தில், யார் கூட நன்கு அறியப்பட்ட அதனுடன், அதன் நன்மைகள் மற்றும் அது சரியாக என்ன (உண்மையில் உங்களுடையது உட்பட) உருவாக்குவது பெரும்பாலும் கடினம். இந்த கட்டுரையில் நான் பல்வேறு பட்டியலிடுவதன் மூலம் நிலைமையை சரிசெய்ய முயற்சிப்பேன் பயன்பாடு வழக்குகள் "சேவை மெஷ்கள்"*.
* குறிப்பு மொழிபெயர்ப்பு
ஆனால் முதலில் நான் சில கருத்துக்களைச் சொல்ல விரும்புகிறேன்:
- எனது சொந்தக் கல்விக்காகத் தொடங்கப்பட்ட திட்டங்களுக்கு வெளியே நான் ஒருபோதும் சேவை மெஷ்களுடன் பணியாற்றவில்லை அல்லது அவற்றைப் பயன்படுத்தவில்லை. மறுபுறம், நான் 2015 இல் ட்விட்டரின் உள் சேவை மெஷிற்காக ஒரு கொத்து ஆவணங்களை எழுதினேன் (அப்போது அது "சேவை மெஷ்" என்று கூட அழைக்கப்படவில்லை) மற்றும் இணையதளம் மற்றும் ஆவணங்களை உருவாக்குவதில் பங்கேற்றேன். , அதனால் ஏதோ அர்த்தம்.
- எனது பட்டியல் தோராயமானது மற்றும் முழுமையற்றது. எனக்குத் தெரியாத பயன்பாட்டு வழக்குகள் இருக்கலாம், மேலும் தொழில்நுட்பம் வளரும் மற்றும் அதன் புகழ் வளரும்போது புதிய விருப்பங்கள் காலப்போக்கில் உருவாகலாம்.
- அதே நேரத்தில், தற்போதுள்ள ஒவ்வொரு சேவை மெஷ் செயல்படுத்தலும் பட்டியலிடப்பட்ட அனைத்து பயன்பாட்டு நிகழ்வுகளையும் ஆதரிக்காது. எனவே, "சர்வீஸ் மெஷ் கேன்..." போன்ற எனது அறிக்கைகள் "தனிநபர் மற்றும் ஒருவேளை அனைத்து பிரபலமான சேவை மெஷ் செயல்படுத்தல்களும்..." என படிக்கப்பட வேண்டும்.
- எடுத்துக்காட்டுகளின் வரிசை எந்த வித்தியாசத்தையும் ஏற்படுத்தாது.
சிறு பட்டியல்:
- சேவை கண்டுபிடிப்பு;
- குறியாக்கம்;
- அங்கீகாரம் மற்றும் அங்கீகாரம்;
- சுமை சமநிலை;
- சுற்று உடைப்பு;
- ஆட்டோஸ்கேலிங்;
- கேனரி வரிசைப்படுத்தல்கள்;
- நீல-பச்சை வரிசைப்படுத்தல்கள்;
- சுகாதார சோதனை;
- சுமை கொட்டுதல்;
- போக்குவரத்து பிரதிபலிப்பு;
- காப்பு;
- கோரிக்கை விகிதம் வரம்பு, மறு முயற்சிகள் மற்றும் காலக்கெடு;
- டெலிமெட்ரி;
- தணிக்கை;
- காட்சிப்படுத்தல்.
1. சேவை கண்டுபிடிப்பு
TL;DR: எளிய பெயர்களைப் பயன்படுத்தி நெட்வொர்க்கில் உள்ள பிற சேவைகளுடன் இணைக்கவும்.
போதுமான பெயர்களைப் பயன்படுத்தி சேவைகள் தானாக "கண்டுபிடிக்க" முடியும் - எடுத்துக்காட்டாக, service.api.production, pets/staging அல்லது cassandra. கிளவுட் சூழல்கள் மீள்தன்மை கொண்டவை, மேலும் ஒரு பெயர் சேவையின் பல நிகழ்வுகளை மறைக்க முடியும். அத்தகைய சூழ்நிலையில் அனைத்து ஐபி முகவரிகளையும் கடின குறியீடு செய்வது உடல் ரீதியாக சாத்தியமற்றது என்பது தெளிவாகிறது.
கூடுதலாக, ஒரு சேவை மற்றொன்றைக் கண்டறியும் போது, அதன் உடைந்த நிகழ்வின் உள்ளீட்டில் அவை முடிவடையும் என்ற அச்சமின்றி அந்த சேவைக்கு கோரிக்கைகளை அனுப்ப முடியும். வேறு வார்த்தைகளில் கூறுவதானால், சேவை மெஷ் அனைத்து சேவை நிகழ்வுகளின் ஆரோக்கியத்தையும் கண்காணிக்க வேண்டும் மற்றும் ஹோஸ்ட்களின் பட்டியலை முடிந்தவரை புதுப்பித்த நிலையில் வைத்திருக்க வேண்டும்.
ஒவ்வொரு சேவை மெஷும் சேவை கண்டுபிடிப்பு பொறிமுறையை வித்தியாசமாக செயல்படுத்துகிறது. இந்த நேரத்தில், குபெர்னெட்டஸ் டிஎன்எஸ் போன்ற வெளிப்புற செயல்முறைகளுக்கு ஒப்படைப்பதே மிகவும் பொதுவான வழி. கடந்த காலத்தில் ட்விட்டரில் இந்த நோக்கத்திற்காக ஒரு பெயரிடும் முறையைப் பயன்படுத்தினோம் . கூடுதலாக, சர்வீஸ் மெஷ் தொழில்நுட்பம் தனிப்பயன் பெயரிடும் வழிமுறைகள் வெளிப்படுவதை சாத்தியமாக்குகிறது (அத்தகைய செயல்பாடுகளுடன் கூடிய SM செயல்படுத்தலை நான் இதுவரை பார்க்கவில்லை என்றாலும்).
2. குறியாக்கம்
TL;DR: சேவைகளுக்கு இடையே உள்ள மறைகுறியாக்கப்படாத போக்குவரத்தை அகற்றி, இந்த செயல்முறையை தானியங்கு மற்றும் அளவிடக்கூடியதாக மாற்றவும்.
உங்கள் உள் நெட்வொர்க்கில் தாக்குபவர்களால் ஊடுருவ முடியாது என்பதை அறிவது மகிழ்ச்சி அளிக்கிறது. ஃபயர்வால்கள் இதற்கு ஒரு சிறந்த வேலையைச் செய்கின்றன. ஆனால் ஒரு ஹேக்கர் உள்ளே நுழைந்தால் என்ன ஆகும்? இன்ட்ரா சர்வீஸ் டிராஃபிக்கில் அவர் என்ன வேண்டுமானாலும் செய்ய முடியுமா? பிறகும் இது நடக்காது என்று நம்புவோம். இந்தச் சூழ்நிலையைத் தடுக்க, சேவைகளுக்கு இடையேயான அனைத்துப் போக்குவரமும் குறியாக்கம் செய்யப்பட்ட ஜீரோ-ட்ரஸ்ட் நெட்வொர்க்கை நீங்கள் செயல்படுத்த வேண்டும். பெரும்பாலான நவீன சேவை மெஷ்கள் பரஸ்பரம் இதை அடைகின்றன (பரஸ்பர TLS, mTLS). சில சந்தர்ப்பங்களில், mTLS முழு மேகங்கள் மற்றும் கிளஸ்டர்களில் வேலை செய்கிறது (கிரகங்களுக்கு இடையேயான தகவல்தொடர்புகள் ஒருநாள் இதேபோல் ஏற்பாடு செய்யப்படும் என்று நான் நினைக்கிறேன்).
நிச்சயமாக, mTLS சேவை கண்ணிக்கு விருப்பமானது. ஒவ்வொரு சேவையும் அதன் சொந்த TLS ஐ கவனித்துக் கொள்ளலாம், ஆனால் இதன் பொருள் நீங்கள் சான்றிதழ்களை உருவாக்க, சேவை ஹோஸ்ட்கள் முழுவதும் விநியோகிக்க மற்றும் கோப்புகளில் இருந்து இந்த சான்றிதழ்களை ஏற்றும் பயன்பாட்டில் குறியீட்டை சேர்க்க ஒரு வழியைக் கண்டறிய வேண்டும். ஆம், இந்த சான்றிதழ்களை சீரான இடைவெளியில் புதுப்பிக்க மறக்காதீர்கள். சேவை மெஷ்கள் mTLS போன்ற அமைப்புகளுடன் தானியங்கும் , இது, சான்றிதழ்களை வழங்கும் மற்றும் சுழலும் செயல்முறையை தானியக்கமாக்குகிறது.
3. அங்கீகாரம் மற்றும் அங்கீகாரம்
TL;DR: கோரிக்கையாளர் யார் என்பதை நிறுவி, கோரிக்கை சேவையை அடைவதற்கு முன்பே அவர்கள் என்ன செய்ய அனுமதிக்கப்படுகிறார்கள் என்பதை வரையறுக்கவும்.
சேவைகள் அடிக்கடி தெரிந்து கொள்ள வேண்டும் யார் கோரிக்கையை (அங்கீகாரம்) செய்கிறது, மேலும் இந்த தகவலைப் பயன்படுத்தி, முடிவு செய்கிறது என்று கொடுக்கப்பட்ட நிறுவனம் (அங்கீகாரம்) செய்ய அனுமதிக்கப்படுகிறது. இந்த வழக்கில், "யார்" என்ற பிரதிபெயர் மறைக்க முடியும்:
- பிற சேவைகள். இது "அங்கீகாரம்" என்று அழைக்கப்படுகிறது. சக" உதாரணமாக, சேவை
webசேவையை அணுக விரும்புகிறார்db. சேவை மெஷ்கள் பொதுவாக mTLS ஐப் பயன்படுத்தி இதுபோன்ற சிக்கல்களைத் தீர்க்கும்: இந்த வழக்கில் சான்றிதழ்கள் தேவையான அடையாளங்காட்டியாக செயல்படுகின்றன. - சில மனித பயனர்கள். இது "அங்கீகாரம்" என்று அழைக்கப்படுகிறது. கோரிக்கை" உதாரணமாக, பயனர்
haxor69புதிய விளக்கு வாங்க வேண்டும். சேவை மெஷ்கள் பல்வேறு வழிமுறைகளை வழங்குகின்றன, எ.கா. .நம்மில் பலர் இதை பயன்பாட்டுக் குறியீட்டில் செய்துள்ளோம். ஒரு கோரிக்கை வருகிறது, நாங்கள் அட்டவணையைப் பார்க்கிறோம்
users, பயனரைக் கண்டுபிடித்து கடவுச்சொல்லை ஒப்பிட்டு, பின்னர் நெடுவரிசையைச் சரிபார்க்கவும்permissionsமுதலியன சேவை மெஷ் விஷயத்தில், கோரிக்கை சேவையை அடைவதற்கு முன்பே இது நடக்கும்.
கோரிக்கை யாரிடமிருந்து வந்தது என்பதை நாங்கள் கண்டறிந்ததும், இந்த நிறுவனம் என்ன செய்ய அனுமதிக்கப்படுகிறது என்பதை நாங்கள் தீர்மானிக்க வேண்டும். சில சேவை மெஷ்கள் YAML கோப்புகளாக அல்லது கட்டளை வரியில் அடிப்படைக் கொள்கைகளை (யார் என்ன செய்ய முடியும் என்பது பற்றி) அமைக்க உங்களை அனுமதிக்கின்றன, மற்றவை போன்ற கட்டமைப்புகளுடன் ஒருங்கிணைப்பை வழங்குகின்றன. . நம்பகமான மூலத்திலிருந்து வந்ததாகக் கருதி, எந்தவொரு கோரிக்கையையும் உங்கள் சேவைகள் ஏற்க வேண்டும் என்பதே இறுதி இலக்கு и இந்த நடவடிக்கை அனுமதிக்கப்படுகிறது.
4. சுமை சமநிலை
TL;DR: ஒரு குறிப்பிட்ட வடிவத்தின்படி சேவை நிகழ்வுகள் முழுவதும் சுமைகளை விநியோகிக்கவும்.
ஒரு சேவைப் பிரிவில் உள்ள ஒரு "சேவை" பெரும்பாலும் ஒரே மாதிரியான பல நிகழ்வுகளைக் கொண்டுள்ளது. உதாரணமாக, இன்று சேவை cache 5 பிரதிகள் உள்ளன, நாளை அவற்றின் எண்ணிக்கை 11 ஆக அதிகரிக்கலாம். கோரிக்கைகள் அனுப்பப்பட்டன cache, ஒரு குறிப்பிட்ட நோக்கத்திற்கு ஏற்ப விநியோகிக்கப்பட வேண்டும். எடுத்துக்காட்டாக, தாமதத்தைக் குறைக்கவும் அல்லது வேலை செய்யும் நிகழ்வைப் பெறுவதற்கான நிகழ்தகவை அதிகரிக்கவும். மிகவும் பொதுவாகப் பயன்படுத்தப்படும் அல்காரிதம் ரவுண்ட்-ராபின் ஆகும், ஆனால் இன்னும் பல உள்ளன - எடுத்துக்காட்டாக, எடையுள்ள முறை (எடையிடப்பட்ட) வினவல்கள் (நீங்கள் விருப்பமான இலக்குகளைத் தேர்ந்தெடுக்கலாம்), ரிங் (மோதிரம்) ஹேஷிங் (அப்ஸ்ட்ரீம் ஹோஸ்ட்கள் முழுவதும் நிலையான ஹேஷிங்கைப் பயன்படுத்துதல்) அல்லது குறைந்தபட்ச கோரிக்கை முறை (குறைந்த கோரிக்கைகள் உள்ள நிகழ்விற்கு முன்னுரிமை அளிக்கப்படும்).
கிளாசிக் பேலன்சர்களுக்கு HTTP கேச்சிங் மற்றும் DDoS பாதுகாப்பு போன்ற பிற செயல்பாடுகள் உள்ளன, ஆனால் அவை கிழக்கு-மேற்கு போக்குவரத்திற்கு மிகவும் பொருத்தமானவை அல்ல (அதாவது, தரவு மையத்திற்குள் பாயும் போக்குவரத்திற்கு - தோராயமாக. ட்ரான்ஸ்ல்.) (சேவை மெஷின் வழக்கமான நோக்கம்). நிச்சயமாக, சுமை சமநிலைக்கு ஒரு சேவை மெஷ் பயன்படுத்த வேண்டிய அவசியமில்லை, ஆனால் ஒவ்வொரு சேவைக்கும் ஒரு மையப்படுத்தப்பட்ட கட்டுப்பாட்டு அடுக்கிலிருந்து சமநிலைப்படுத்தும் கொள்கைகளை அமைக்கவும் கட்டுப்படுத்தவும் இது உங்களை அனுமதிக்கிறது, இதன் மூலம் பிணைய அடுக்கில் தனித்தனி சுமை பேலன்சர்களை இயக்கி உள்ளமைக்க வேண்டிய தேவையை நீக்குகிறது. .
5. சர்க்யூட் பிரேக்கிங்
TL;DR: பிரச்சனைக்குரிய சேவைக்கான போக்குவரத்தை நிறுத்தி, மோசமான சூழ்நிலைகளில் சேதத்தைக் கட்டுப்படுத்தவும்.
சில காரணங்களால் சேவை போக்குவரத்தை சமாளிக்க முடியாவிட்டால், இந்த சிக்கலைத் தீர்ப்பதற்கு சேவை மெஷ் பல விருப்பங்களை வழங்குகிறது (மற்றவை பொருத்தமான பிரிவுகளில் விவாதிக்கப்படும்). ஒரு சேவையை போக்குவரத்திலிருந்து துண்டிக்க சர்க்யூட் பிரேக்கிங் மிகவும் கடுமையான விருப்பமாகும். இருப்பினும், அது அர்த்தமற்றது - ஒரு காப்புத் திட்டம் தேவை. பின் அழுத்தம் வழங்கப்படலாம் () கோரிக்கைகளை வைக்கும் சேவைகளுக்கு (இதற்காக உங்கள் சேவை மெஷை உள்ளமைக்க மறக்காதீர்கள்!), அல்லது, எடுத்துக்காட்டாக, நிலைப் பக்கத்தை சிவப்பு நிறமாக்கி, பயனர்களை "விழும் திமிங்கலம்" ("ட்விட்டர் என்பது கீழ்").
சேவை மெஷ்கள் உங்களை வரையறுக்க மட்டும் அனுமதிக்காது போது பணிநிறுத்தம் தொடரும் மற்றும் என்று இது தொடரும். இந்த வழக்கில், குறிப்பிட்ட அளவுருக்களின் கலவையை "எப்போது" சேர்க்கலாம்: ஒரு குறிப்பிட்ட காலத்திற்கான மொத்த கோரிக்கைகளின் எண்ணிக்கை, இணையான இணைப்புகளின் எண்ணிக்கை, நிலுவையில் உள்ள கோரிக்கைகள், செயலில் உள்ள முயற்சிகள் போன்றவை.
சர்க்யூட் பிரேக்கிங்கை நீங்கள் தவறாகப் பயன்படுத்த விரும்ப மாட்டீர்கள், ஆனால் அவசரகாலத்தில் உங்களிடம் காப்புப் பிரதி திட்டம் உள்ளது என்பதை அறிவது மகிழ்ச்சி அளிக்கிறது.
6. ஆட்டோஸ்கேலிங்
TL;DR: குறிப்பிட்ட அளவுகோல்களைப் பொறுத்து சேவை நிகழ்வுகளின் எண்ணிக்கையை அதிகரிக்கவும் அல்லது குறைக்கவும்.
சேவை மெஷ்கள் திட்டமிடுபவர்கள் அல்ல, எனவே அவை அவ்வாறு செய்யாது செயல்படுத்த உங்களை அளவிடுதல். இருப்பினும், எந்த திட்டமிடுபவர்கள் தங்கள் முடிவுகளை அடிப்படையாகக் கொள்வார்கள் என்ற தகவலை அவர்கள் வழங்க முடியும். சேவை மெஷ்கள் சேவைகளுக்கு இடையேயான அனைத்து போக்குவரத்திற்கும் அணுகலைக் கொண்டிருப்பதால், என்ன நடக்கிறது என்பது பற்றிய விரிவான தகவல்கள் அவர்களிடம் உள்ளன: எந்த சேவைகள் சிக்கல்களை எதிர்கொள்கின்றன, எந்த சேவைகள் மிகவும் லேசாக ஏற்றப்படுகின்றன (அவற்றுக்கு ஒதுக்கப்பட்ட திறன் வீணாகிறது) போன்றவை.
எடுத்துக்காட்டாக, காய்களின் CPU மற்றும் நினைவக பயன்பாட்டின் அடிப்படையில் குபெர்னெட்ஸ் சேவைகளை அளவிடுகிறது (எங்கள் அறிக்கையைப் பார்க்கவும்""- தோராயமாக. மொழிபெயர்ப்பு.), ஆனால் வேறு எந்த அளவீட்டின் அடிப்படையிலும் அளவிட முடிவு செய்தால் (எங்கள் விஷயத்தில், போக்குவரத்து தொடர்பானது), உங்களுக்கு ஒரு சிறப்பு மெட்ரிக் தேவைப்படும். மேலாண்மை இதை எப்படி செய்வது என்று காட்டுகிறது , и , ஆனால் செயல்முறை மிகவும் சிக்கலானது. "சேவை நிகழ்வுகளின் எண்ணிக்கையை அதிகரிக்கவும் auth, நிலுவையில் உள்ள கோரிக்கைகளின் எண்ணிக்கை ஒரு நிமிடத்திற்குள் வரம்பை மீறினால்."
7. கேனரி வரிசைப்படுத்தல்கள்
TL;DR: பயனர்களின் துணைக்குழுவில் புதிய அம்சங்கள் அல்லது சேவை பதிப்புகளை சோதிக்கவும்.
நீங்கள் ஒரு SaaS தயாரிப்பை உருவாக்கி அதன் புதிய பதிப்பை வெளியிட உள்ளீர்கள் என்று வைத்துக்கொள்வோம். நீங்கள் அதை மேடையில் சோதித்தீர்கள், அது நன்றாக வேலை செய்தது. ஆனால் உண்மையான நிலைமைகளில் அவரது நடத்தை குறித்து இன்னும் சில கவலைகள் உள்ளன. வேறு வார்த்தைகளில் கூறுவதானால், பயனர் நம்பிக்கையைப் பணயம் வைக்காமல் உண்மையான சிக்கல்களில் புதிய பதிப்பைச் சோதிக்க வேண்டும். கேனரி வரிசைப்படுத்தல் இதற்கு சிறந்தது. பயனர்களின் துணைக்குழுவிற்கு புதிய அம்சத்தை நிரூபிக்க அவை உங்களை அனுமதிக்கின்றன. இந்த துணைக்குழு மிகவும் விசுவாசமான பயனர்கள் அல்லது தயாரிப்பின் இலவச பதிப்பில் பணிபுரிபவர்கள் அல்லது "கினிப் பன்றிகளாக" இருக்க விருப்பம் தெரிவித்த பயனர்களைக் கொண்டிருக்கலாம்.
பயன்பாட்டின் எந்தப் பதிப்பை யார் பார்ப்பார்கள் என்பதைத் தீர்மானிக்கும் அளவுகோல்களைக் குறிப்பிட உங்களை அனுமதிப்பதன் மூலம் சேவை மெஷ்கள் இதைச் செயல்படுத்துகின்றன, மேலும் அதற்கேற்ப போக்குவரத்தை வழிநடத்துகின்றன. இருப்பினும், சேவைகளுக்கு எதுவும் மாறாது. சேவையின் பதிப்பு 1.0, எல்லா கோரிக்கைகளும் அதைப் பார்க்க வேண்டிய பயனர்களிடமிருந்து வந்ததாக நம்புகிறது, மேலும் பதிப்பு 1.1 அதன் பயனர்களுக்கும் அதையே நம்புகிறது. இதற்கிடையில், பழைய மற்றும் புதிய பதிப்புகளுக்கு இடையிலான போக்குவரத்தின் சதவீதத்தை நீங்கள் மாற்றலாம், இது நிலையானதாகச் செயல்பட்டால், உங்கள் "கினிப் பன்றிகள்" முன்னோக்கிச் சென்றால், வளர்ந்து வரும் பயனர்களின் எண்ணிக்கையை புதியதாக மாற்றலாம்.
8. நீல-பச்சை வரிசைப்படுத்தல்கள்
TL;DR: ஒரு புதிய அம்சத்தை வெளியிடுங்கள், ஆனால் உடனடியாக அனைத்தையும் திரும்பப் பெற தயாராக இருங்கள்.
அதாவது புதிய "நீல" சேவையை வெளியிடுவது, பழைய, "பச்சை" சேவைக்கு இணையாகத் தொடங்குவது. எல்லாம் சீராகச் சென்று புதிய சேவை சிறப்பாகச் செயல்பட்டால், பழைய சேவையை படிப்படியாக முடக்கலாம். (ஐயோ, என்றாவது ஒரு நாள் இந்த புதிய "நீலம்" சேவையானது "பச்சை" ஒன்றின் தலைவிதியை மீண்டும் மீண்டும் செய்து மறைந்துவிடும்...) நீல-பச்சை வரிசைப்படுத்தல்கள் கேனரியில் இருந்து வேறுபடுகின்றன, புதிய செயல்பாடு உள்ளடக்கியது அனைவரும் ஒரே நேரத்தில் பயனர்கள் (பகுதி அல்ல); ஏதாவது தவறு நடந்தால், "பாதுகாப்பான துறைமுகம்" தயாராக இருக்க வேண்டும் என்பதே இங்கு முக்கிய விஷயம்.
சேவை மெஷ்கள் "நீல" சேவையை சோதிக்க மிகவும் வசதியான வழியை வழங்குகின்றன மற்றும் சிக்கல்கள் ஏற்பட்டால் உடனடியாக வேலை செய்யும் "பச்சை" ஒன்றை மாற்றவும். "ப்ளூ" இன் வேலையைப் பற்றி அவர்கள் நிறைய தகவல்களை (கீழே உள்ள "டெலிமெட்ரி" ஐப் பார்க்கவும்) வழியில் வழங்குகிறார்கள் என்ற உண்மையை குறிப்பிட தேவையில்லை, இது முழு செயல்பாட்டிற்கு தயாரா என்பதைப் புரிந்துகொள்ள உதவுகிறது.
குறிப்பு. மொழிபெயர்: குபெர்னெட்டஸில் (குறிப்பிடப்பட்ட கேனரி, நீலம்/பச்சை மற்றும் பிற உட்பட) வெவ்வேறு வரிசைப்படுத்தல் உத்திகள் பற்றி நீங்கள் மேலும் படிக்கலாம் .
9. சுகாதார சோதனை
TL;DR: எந்த சேவை நிகழ்வுகள் செயல்படுகின்றன என்பதைக் கண்காணித்து, இனி செயல்படாதவற்றுக்கு பதிலளிக்கவும்.
சுகாதார சோதனை (சுகாதார சோதனை) போக்குவரத்தை ஏற்கவும் செயலாக்கவும் சேவை நிகழ்வுகள் தயாராக உள்ளதா என்பதை தீர்மானிக்க உதவுகிறது. எடுத்துக்காட்டாக, HTTP சேவைகளின் விஷயத்தில், ஹெல்த் செக் ஒரு GET கோரிக்கையைப் போல் இறுதிப் புள்ளியில் இருக்கும் /health. பதில் 200 OK நிகழ்வு ஆரோக்கியமானது, வேறு ஏதேனும் - அது போக்குவரத்தைப் பெறத் தயாராக இல்லை என்று அர்த்தம். சேவை மெஷ்கள் செயல்பாடு சரிபார்க்கப்படும் முறை மற்றும் இந்த சோதனை மேற்கொள்ளப்படும் அதிர்வெண் ஆகிய இரண்டையும் குறிப்பிட உங்களை அனுமதிக்கிறது. இந்தத் தகவல் பிற நோக்கங்களுக்காகப் பயன்படுத்தப்படலாம் - எடுத்துக்காட்டாக, சுமை சமநிலை மற்றும் சுற்று உடைப்பு.
எனவே, உடல்நலம் சரிபார்ப்பு என்பது ஒரு தனித்த பயன்பாடு அல்ல, ஆனால் பொதுவாக மற்ற இலக்குகளை அடையப் பயன்படுகிறது. மேலும், சுகாதார சோதனைகளின் முடிவுகளைப் பொறுத்து, பிற சேவை மெஷ் இலக்குகளுக்குப் புறம்பான செயல்கள் தேவைப்படலாம்: எடுத்துக்காட்டாக, நிலைப் பக்கத்தைப் புதுப்பித்தல், GitHub இல் சிக்கலை உருவாக்குதல் அல்லது JIRA டிக்கெட்டை நிரப்புதல். சர்வீஸ் மெஷ் இதையெல்லாம் தானியக்கமாக்க ஒரு வசதியான பொறிமுறையை வழங்குகிறது.
10. சுமை கொட்டுதல்
TL;DR: தற்காலிக பயன்பாட்டிற்குப் பதில் போக்குவரத்தைத் திருப்பிவிடவும்.
குறிப்பிட்ட சேவையில் போக்குவரத்து அதிகமாக இருந்தால், இந்த போக்குவரத்தில் சிலவற்றை நீங்கள் தற்காலிகமாக வேறு இடத்திற்குத் திருப்பிவிடலாம் (அதாவது, "டம்ப்", "பரிமாற்றம்" (பந்தல்) அவன் அங்கே). எடுத்துக்காட்டாக, காப்புப்பிரதி சேவை அல்லது தரவு மையத்திற்கு அல்லது நிரந்தரமாக தலைப்பு. இதன் விளைவாக, சேவையானது செயலிழக்கச் செய்வதற்குப் பதிலாக சில கோரிக்கைகளைச் செயல்படுத்தி, எல்லாவற்றையும் முழுவதுமாகச் செயலாக்குவதை நிறுத்தும். சுற்றை உடைப்பதை விட சுமை கொட்டுதல் விரும்பத்தக்கது, ஆனால் அதை தவறாகப் பயன்படுத்துவது இன்னும் நல்லதல்ல. கீழ்நிலை சேவைகளை தோல்வியடையச் செய்யும் கேஸ்கேடிங் தோல்விகளைத் தடுக்க இது உதவுகிறது.
11. போக்குவரத்து இணையாக்கம்/பிரதிபலிப்பு
TL;DR: ஒரே நேரத்தில் பல இடங்களுக்கு ஒரு கோரிக்கையை அனுப்பவும்.
சில நேரங்களில் ஒரே நேரத்தில் பல சேவைகளுக்கு ஒரு கோரிக்கையை (அல்லது ஒரு குறிப்பிட்ட தேர்வு கோரிக்கைகளை) அனுப்ப வேண்டிய அவசியம் உள்ளது. ஒரு பொதுவான உதாரணம் உற்பத்தி போக்குவரத்தின் ஒரு பகுதியை ஸ்டேஜிங் சேவைக்கு அனுப்புவதாகும். பிரதான உற்பத்தி வலை சேவையகம் கீழ்நிலை சேவைக்கு ஒரு கோரிக்கையை அனுப்புகிறது products.production மற்றும் அவருக்கு மட்டுமே. சேவை மெஷ் இந்த கோரிக்கையை புத்திசாலித்தனமாக நகலெடுத்து அதை அனுப்புகிறது products.staging, இது இணைய சேவையகத்திற்கு கூட தெரியாது.
போக்குவரத்து இணைமயமாக்கலுக்கு மேல் செயல்படுத்தக்கூடிய மற்றொரு தொடர்புடைய சேவை மெஷ் பயன்பாட்டு வழக்கு . சேவையின் வெவ்வேறு பதிப்புகளுக்கு ஒரே கோரிக்கைகளை அனுப்புவது மற்றும் அனைத்து பதிப்புகளும் ஒரே மாதிரியாக செயல்படுகின்றனவா என்பதைச் சரிபார்ப்பதும் இதில் அடங்கும். ஒருங்கிணைக்கப்பட்ட பின்னடைவு சோதனை அமைப்புடன் சேவை மெஷ் செயல்படுத்தலை நான் இன்னும் காணவில்லை , ஆனால் யோசனை தன்னை நம்பிக்கைக்குரியதாக தெரிகிறது.
12. காப்பு
TL;DR: உங்கள் சேவை மெஷை மினி-நெட்வொர்க்குகளாக உடைக்கவும்.
எனவும் அறியப்படுகிறது பிரிவுதனிமைப்படுத்தல் என்பது ஒரு சேவை கண்ணியை தர்க்கரீதியாக வேறுபட்ட பிரிவுகளாகப் பிரிக்கும் கலையாகும். தனிமைப்படுத்தல் என்பது மெய்நிகர் தனியார் நெட்வொர்க்குகளை உருவாக்குவது போன்றது. அடிப்படை வேறுபாடு என்னவென்றால், சேவை மெஷின் அனைத்து நன்மைகளையும் (சேவை கண்டுபிடிப்பு போன்றவை) நீங்கள் இன்னமும் அனுபவிக்க முடியும், ஆனால் கூடுதல் பாதுகாப்புடன். எடுத்துக்காட்டாக, தாக்குபவர் சப்நெட்களில் ஒன்றில் சேவையை ஊடுருவச் செய்தால், மற்ற சப்நெட்களில் என்ன சேவைகள் இயங்குகின்றன என்பதை அவரால் பார்க்க முடியாது அல்லது அவற்றின் போக்குவரத்தை இடைமறிக்க முடியாது.
கூடுதலாக, நன்மைகள் நிறுவனமாகவும் இருக்கலாம். உங்கள் நிறுவனத்தின் கட்டமைப்பின் அடிப்படையில் உங்கள் சேவைகளை சப்நெட் செய்ய நீங்கள் விரும்பலாம் மற்றும் முழு சேவை மெஷையும் மனதில் வைத்திருக்க வேண்டிய அறிவாற்றல் சுமையிலிருந்து டெவலப்பர்களை விடுவிக்கலாம்.
13. கோரிக்கை விகித வரம்பு, மறு முயற்சிகள் மற்றும் காலக்கெடு
TL;DR: உங்கள் கோட்பேஸில் இனி நிட்டி-கிரிட்டி கோரிக்கை மேலாண்மை பணிகளைச் சேர்க்க வேண்டியதில்லை.
இவை அனைத்தும் தனித்தனி பயன்பாட்டு நிகழ்வுகளாகக் கருதப்படலாம், ஆனால் ஒரு பொதுவான அம்சத்தின் காரணமாக அவற்றை இணைக்க முடிவு செய்தேன்: பொதுவாக பயன்பாட்டு நூலகங்களால் கையாளப்படும் கோரிக்கை வாழ்க்கைச் சுழற்சி மேலாண்மை பணிகளை அவை எடுத்துக்கொள்கின்றன. நீங்கள் ரூபி ஆன் ரெயில்ஸில் ஒரு இணைய சேவையகத்தை உருவாக்குகிறீர்கள் என்றால் (சேவை மெஷ் உடன் ஒருங்கிணைக்கப்படவில்லை) இது பின்தளத்தில் சேவைகளுக்கு கோரிக்கைகளை செய்கிறது , N கோரிக்கைகள் தோல்வியுற்றால் என்ன செய்வது என்பதை விண்ணப்பம் தீர்மானிக்க வேண்டும். ஒரு சிறப்பு நூலகத்தைப் பயன்படுத்தி இந்த அளவுருக்களை செயலாக்க மற்றும் கடின குறியீடு இந்த சேவைகள் எவ்வளவு ட்ராஃபிக் செய்ய முடியும் என்பதையும் நீங்கள் கண்டுபிடிக்க வேண்டும். கூடுதலாக, விண்ணப்பம் எப்போது கைவிடப்பட வேண்டும் என்பதை முடிவு செய்ய வேண்டும் மற்றும் கோரிக்கையை செயலிழக்க அனுமதிக்க வேண்டும் (காலக்கெடுவின் அடிப்படையில்). மேலே உள்ள எந்த அளவுருக்களையும் மாற்ற, வலை சேவையகத்தை நிறுத்தி, மறுகட்டமைத்து மீண்டும் தொடங்க வேண்டும்.
இந்த பணிகளை சேவை மெஷில் ஏற்றுவது, சேவை உருவாக்குநர்கள் அவற்றைப் பற்றி சிந்திக்க வேண்டிய அவசியமில்லை என்பது மட்டுமல்லாமல், அவை உலகளாவிய முறையில் பார்க்கப்படலாம். ஒரு சிக்கலான சேவைகள் பயன்படுத்தப்பட்டால், A -> B -> C -> D -> E என்று சொல்லுங்கள், கோரிக்கையின் முழு வாழ்க்கைச் சுழற்சியும் கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும். சேவை C இல் காலக்கெடுவை நீட்டிப்பதே பணியாக இருந்தால், இதை ஒரே நேரத்தில் செய்வது தர்க்கரீதியானது, மற்றும் பகுதிகளாக அல்ல: சேவைக் குறியீட்டைப் புதுப்பித்து, இழுக்கும் கோரிக்கை ஏற்கப்படும் வரை மற்றும் CI அமைப்பு புதுப்பிக்கப்பட்ட சேவையைப் பயன்படுத்தும் வரை காத்திருக்கவும்.
14. டெலிமெட்ரி
TL;DR: சேவைகளில் இருந்து தேவையான அனைத்து (மற்றும் இல்லை) தகவல் சேகரிக்கவும்.
டெலிமெட்ரி என்பது அளவீடுகள், விநியோகிக்கப்பட்ட டிரேசிங் மற்றும் பதிவுகளை உள்ளடக்கிய ஒரு பொதுவான சொல். சேவை மெஷ்கள் மூன்று வகையான தரவுகளையும் சேகரித்து செயலாக்குவதற்கான வழிமுறைகளை வழங்குகின்றன. சாத்தியமான விருப்பங்களின் எண்ணிக்கை மிக அதிகமாக இருப்பதால் இங்குதான் விஷயங்கள் கொஞ்சம் மங்கலாகின்றன. அளவீடுகளை சேகரிக்க உள்ளது மற்றும் பதிவுகளை சேகரிக்கப் பயன்படுத்தக்கூடிய பிற கருவிகள் , , மற்றும் பலர். (எடுத்துக்காட்டாக, கிளிக்ஹவுஸ் உடன் எங்களுடையது K8s க்கு - தோராயமாக. மொழிபெயர்ப்பு.), விநியோகிக்கப்பட்ட டிரேசிங்கிற்கு உள்ளது மற்றும் பல. ஒவ்வொரு சேவை மெஷும் சில கருவிகளை ஆதரிக்கலாம், மற்றவை அல்ல. திட்டம் முடியுமா என்பதைப் பார்ப்பது சுவாரஸ்யமாக இருக்கும் சில ஒருங்கிணைப்பை வழங்குகின்றன.
இந்த வழக்கில், சர்வீஸ் மெஷ் தொழில்நுட்பத்தின் நன்மை என்னவென்றால், சைட்கார் கொள்கலன்கள், கொள்கையளவில், மேலே உள்ள எல்லா தரவையும் தங்கள் சேவைகளிலிருந்து சேகரிக்க முடியும். வேறு வார்த்தைகளில் கூறுவதானால், உங்கள் வசம் ஒரு டெலிமெட்ரி சேகரிப்பு அமைப்பு உள்ளது, மேலும் சேவை மெஷ் இந்த தகவலை பல்வேறு வழிகளில் செயல்படுத்த முடியும். உதாரணத்திற்கு:
- CLI இல் ஒரு குறிப்பிட்ட சேவையிலிருந்து வால் பதிவுகள்;
- சேவை மெஷ் டாஷ்போர்டில் இருந்து கோரிக்கைகளின் அளவைக் கண்காணிக்கவும்;
- விநியோகிக்கப்பட்ட தடயங்களை சேகரித்து அவற்றை ஜெகர் போன்ற அமைப்புக்கு அனுப்பவும்.
கவனம், அகநிலை தீர்ப்பு: பொதுவாக, டெலிமெட்ரி என்பது சர்வீஸ் மெஷின் வலுவான குறுக்கீடு விரும்பத்தகாத ஒரு பகுதி. அடிப்படைத் தகவல்களைச் சேகரிப்பதும், கோரிக்கை வெற்றி விகிதம் மற்றும் தாமதம் போன்ற சில கோல்டன் அளவீடுகளைக் கண்காணிப்பதும் நன்றாக இருக்கிறது, ஆனால் சிறப்பு அமைப்புகளை மாற்ற முயற்சிக்கும் ஃபிராங்கண்ஸ்டைன் அடுக்குகள் வெளிவருவதை நாம் காணவில்லை என்று நம்புவோம், அவற்றில் சில ஏற்கனவே தங்களை நிரூபித்து நன்கு ஆய்வு செய்துள்ளன. .
15. தணிக்கை
டி.எல்; டி.ஆர்: வரலாற்றின் படிப்பினைகளை மறப்பவர்கள் அவற்றை மீண்டும் செய்யத் திணறுவார்கள்.
தணிக்கை என்பது ஒரு அமைப்பில் முக்கியமான நிகழ்வுகளைக் கவனிக்கும் கலை. சேவை மெஷ் விஷயத்தில், குறிப்பிட்ட சேவைகளுக்கான குறிப்பிட்ட இறுதிப்புள்ளிகளுக்கு யார் கோரிக்கை வைத்தனர் அல்லது கடந்த மாதத்தில் எத்தனை முறை பாதுகாப்பு தொடர்பான நிகழ்வுகள் நடந்தன என்பதைக் கண்காணிக்கலாம்.
தணிக்கை என்பது டெலிமெட்ரியுடன் மிக நெருங்கிய தொடர்புடையது என்பது தெளிவாகிறது. வித்தியாசம் என்னவென்றால், டெலிமெட்ரி பொதுவாக உற்பத்தித்திறன் மற்றும் தொழில்நுட்ப ஒருமைப்பாடு போன்ற விஷயங்களுடன் தொடர்புடையது, அதே சமயம் தணிக்கை என்பது சட்டப்பூர்வ மற்றும் பிற சிக்கல்களுடன் தொடர்புடையதாக இருக்கும், இது கடுமையான தொழில்நுட்பக் கோளத்திற்கு அப்பாற்பட்டது (உதாரணமாக, GDPR-க்கு இணங்குதல் - தரவுப் பாதுகாப்பிற்கான ஐரோப்பிய ஒன்றிய பொது ஒழுங்குமுறை).
16. காட்சிப்படுத்தல்
TL;DR: Long live React.js - ஆடம்பரமான இடைமுகங்களின் விவரிக்க முடியாத ஆதாரம்.
ஒரு சிறந்த சொல் இருக்கலாம், ஆனால் எனக்கு அது தெரியாது. நான் ஒரு சர்வீஸ் மெஷ் அல்லது அதன் சில கூறுகளின் வரைகலைப் பிரதிநிதித்துவத்தைக் குறிக்கிறேன். இந்த காட்சிப்படுத்தல்களில் சராசரி தாமதங்கள், பக்கவாட்டு உள்ளமைவுத் தகவல், சுகாதார சோதனை முடிவுகள் மற்றும் விழிப்பூட்டல்கள் போன்ற குறிகாட்டிகள் இருக்கலாம்.
ஒரு சேவை சார்ந்த சூழலில் பணிபுரிவது, ஹிஸ் மெஜஸ்டி தி மோனோலித் உடன் ஒப்பிடும்போது அதிக அறிவாற்றல் சுமையை உள்ளடக்கியது. எனவே, அறிவாற்றல் அழுத்தம் எல்லா விலையிலும் குறைக்கப்பட வேண்டும். ஒரு பொத்தானைக் கிளிக் செய்து விரும்பிய முடிவைப் பெறும் திறன் கொண்ட சேவை வலைக்கான எளிய வரைகலை இடைமுகம் இந்த தொழில்நுட்பத்தின் பிரபலத்தின் வளர்ச்சிக்கு தீர்க்கமானதாக இருக்கும்.
பட்டியலில் சேர்க்கப்படவில்லை
நான் முதலில் இன்னும் சில பயன்பாட்டு நிகழ்வுகளை பட்டியலில் சேர்க்க எண்ணினேன், ஆனால் பின்னர் வேண்டாம் என்று முடிவு செய்தேன். எனது முடிவுக்கான காரணங்களுடன் அவை இங்கே:
- பல தரவு மையம். என் கருத்துப்படி, இது சேவை மெஷ்கள் அல்லது சேவை கண்டுபிடிப்பு போன்ற சில செயல்பாடுகளின் குறுகிய மற்றும் குறிப்பிட்ட பகுதியின் பயன்பாடு அல்ல.
- உட்புகுதல் மற்றும் வெளியேறுதல். இது தொடர்புடைய பகுதி, ஆனால் நான் என்னை (ஒருவேளை செயற்கையாக) "கிழக்கு-மேற்கு ட்ராஃபிக்" பயன்பாட்டுக்கு மட்டுப்படுத்தினேன். நுழைவு மற்றும் வெளியேற்றம் ஒரு தனி கட்டுரைக்கு தகுதியானது.
முடிவுக்கு
இப்பொழுது இத்துடன் நிறைவடைகிறது! மீண்டும், இந்த பட்டியல் மிகவும் தன்னிச்சையானது மற்றும் பெரும்பாலும் முழுமையற்றது. நான் எதையாவது தவறவிட்டதாக நீங்கள் நினைத்தால் அல்லது ஏதேனும் தவறு நடந்ததாக நீங்கள் நினைத்தால், தயவுசெய்து என்னை Twitter இல் தொடர்பு கொள்ளவும் () தயவு செய்து ஒழுக்க விதிகளை மதிக்கவும்.
மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்
கட்டுரையின் தலைப்பு விளக்கப்படம் கட்டுரையில் இருந்து ஒரு படத்தை அடிப்படையாகக் கொண்டது."(கிரிகோரி மெக்கின்னனால்). பயன்பாடுகளின் சில செயல்பாடுகள் (பச்சை நிறத்தில்) அவற்றுக்கிடையே (நீல நிறத்தில்) தொடர்புகளை வழங்கும் சேவை மெஷ்ஷிற்கு எவ்வாறு நகர்ந்துள்ளது என்பதை இது காட்டுகிறது.
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «".
ஆதாரம்: www.habr.com
