குறிப்பு. மொழிபெயர்: சர்வீஸ் மெஷ் என்பது ரஷ்ய மொழியில் இன்னும் நிலையான மொழிபெயர்ப்பு இல்லாத ஒரு நிகழ்வு (2 ஆண்டுகளுக்கு முன்பு நாங்கள் “சேவைகளுக்கான மெஷ்” விருப்பத்தை முன்மொழிந்தோம், சிறிது நேரம் கழித்து சில சக ஊழியர்கள் “சேவை சல்லடை” கலவையை தீவிரமாக ஊக்குவிக்கத் தொடங்கினர்). இந்த தொழில்நுட்பத்தைப் பற்றிய தொடர்ச்சியான பேச்சு, சந்தைப்படுத்தல் மற்றும் தொழில்நுட்ப கூறுகள் மிகவும் நெருக்கமாக பின்னிப்பிணைந்த சூழ்நிலைக்கு வழிவகுத்தது. அசல் காலத்தின் ஆசிரியர்களில் ஒருவரிடமிருந்து இந்த அற்புதமான பொருள் பொறியாளர்கள் மற்றும் பிறருக்கு தெளிவுபடுத்தும் நோக்கம் கொண்டது.
இருந்து நகைச்சுவை
அறிமுகம்
நீங்கள் ஒரு மென்பொருள் பொறியியலாளராக இருந்தால், பின்தள அமைப்புகளில் எங்காவது பணிபுரிந்தால், "சர்வீஸ் மெஷ்" என்ற சொல் கடந்த இரண்டு வருடங்களாக உங்கள் மனதில் உறுதியாக பதிந்திருக்கும். ஒரு விசித்திரமான தற்செயல் நிகழ்வுக்கு நன்றி, இந்த சொற்றொடர் தொழில்துறையை மேலும் மேலும் ஆக்கிரமித்து வருகிறது, மேலும் அதனுடன் தொடர்புடைய மிகைப்படுத்தல் மற்றும் விளம்பர சலுகைகள் பனிப்பந்து கீழ்நோக்கி பறக்கிறது மற்றும் வேகம் குறைவதற்கான அறிகுறிகளைக் காட்டவில்லை.
சேவை கண்ணி கிளவுட் நேட்டிவ் சுற்றுச்சூழல் அமைப்பின் இருண்ட, பாரபட்சமான நீரில் பிறந்தது. துரதிர்ஷ்டவசமாக, இதைச் சுற்றியுள்ள பெரும்பாலான சர்ச்சைகள் "குறைந்த கலோரி பேச்சு" முதல் ஒரு தொழில்நுட்பச் சொல்லைப் பயன்படுத்துவது - முற்றிலும் முட்டாள்தனமானவை. ஆனால் நீங்கள் அனைத்து இரைச்சலையும் வெட்டினால், சேவை மெஷ் மிகவும் உண்மையான, வரையறுக்கப்பட்ட மற்றும் முக்கியமான செயல்பாட்டைக் கொண்டிருப்பதைக் காண்பீர்கள்.
இந்த இடுகையில், நான் அதைச் செய்ய முயற்சிப்பேன்: சேவை கண்ணிக்கு நேர்மையான, ஆழமான, பொறியாளரை மையமாகக் கொண்ட வழிகாட்டியை வழங்கவும். நான் கேள்விக்கு மட்டும் பதில் சொல்லப் போவதில்லை: "அது என்ன?", - ஆனால் "ஏன்?"மேலும் "ஏன் இப்போ?". இறுதியாக, இந்தக் குறிப்பிட்ட தொழில்நுட்பம் ஏன் இப்படி ஒரு பைத்தியக்காரத்தனமான பரபரப்பை ஏற்படுத்தியது என்பதை (என் கருத்துப்படி) கோடிட்டுக் காட்ட முயற்சிப்பேன், இதுவே ஒரு சுவாரஸ்யமான கதை.
?
அனைவருக்கும் வணக்கம்! என் பெயர் . படைப்பாளிகளில் நானும் ஒருவன் - முதல் சேவை மெஷ் திட்டம் மற்றும் இந்த வார்த்தையின் தோற்றத்திற்கு காரணம் சேவை கண்ணி அப்படியே (மன்னிக்கவும் தோழர்களே!). (குறிப்பு மொழிபெயர்ப்பு.: மூலம், இந்த வார்த்தையின் தோற்றத்தின் விடியலில், 2,5 ஆண்டுகளுக்கு முன்பு, "" என்ற தலைப்பில் அதே ஆசிரியரின் ஆரம்பகால உள்ளடக்கத்தை நாங்கள் ஏற்கனவே மொழிபெயர்த்துள்ளோம்.".) நானும் தலைவன் லிங்கர்ட் போன்ற சிறந்த சேவை மெஷ் விஷயங்களை உருவாக்கும் தொடக்கமாகும் .
இந்தப் பிரச்சினையில் எனக்கு மிகவும் பக்கச்சார்பான மற்றும் அகநிலைக் கருத்து இருப்பதாக நீங்கள் ஒருவேளை யூகிக்கலாம். இருப்பினும், சார்புநிலையை குறைந்தபட்சமாக வைக்க முயற்சிப்பேன் (ஒரு பிரிவைத் தவிர: "சேவை மெஷ் பற்றி ஏன் இவ்வளவு பேச்சு?", - இதில் நான் இன்னும் எனது முன்கூட்டிய கருத்துக்களை பகிர்ந்து கொள்கிறேன்). இந்த வழிகாட்டியை முடிந்தவரை குறிக்கோளாக மாற்ற என்னால் முடிந்த அனைத்தையும் செய்வேன். குறிப்பிட்ட எடுத்துக்காட்டுகளுக்கு, பிற சேவை மெஷ் வகைகளைச் செயல்படுத்துவதில் எனக்குத் தெரிந்த வேறுபாடுகளை (ஏதேனும் இருந்தால்) சுட்டிக்காட்டும்போது, நான் முதன்மையாக லிங்கர்டின் அனுபவத்தை நம்பியிருப்பேன்.
சரி, இனிய விஷயங்களுக்கு செல்ல வேண்டிய நேரம் இது.
சேவை மெஷ் என்றால் என்ன?
அனைத்து மிகைப்படுத்தல்கள் இருந்தபோதிலும், சேவை கண்ணி அமைப்பு மிகவும் எளிமையானது. இது சேவைகளுக்கு "அடுத்ததாக" அமைந்துள்ள பயனர்வெளி ப்ராக்ஸிகளின் தொகுப்பாகும் ("அடுத்து" என்ன என்பதைப் பற்றி சிறிது பேசுவோம்), மேலும் கட்டுப்பாட்டு செயல்முறைகளின் தொகுப்பு. ப்ராக்ஸிகள் கூட்டாக அழைக்கப்படுகின்றன தரவு விமானம், மற்றும் கட்டுப்பாட்டு செயல்முறைகள் அழைக்கப்படுகின்றன கட்டுப்பாட்டு விமானம். டேட்டா பிளேன், சேவைகளுக்கு இடையே உள்ள அழைப்புகளை இடைமறித்து, அவற்றுடன் "அனைத்து விதமான விஷயங்களையும்" செய்கிறது; கட்டுப்பாட்டு விமானம், அதன்படி, ப்ராக்ஸியின் நடத்தையை ஒருங்கிணைத்து, உங்களுக்கான அணுகலை வழங்குகிறது, அதாவது. ஆபரேட்டர், ஏபிஐக்கு, நெட்வொர்க்கைக் கையாளவும், ஒட்டுமொத்தமாக அளவிடவும் அனுமதிக்கிறது.
இது என்ன வகையான ப்ராக்ஸி? இது லேயர் 7-அவேர் டிசிபி ப்ராக்ஸி. (அதாவது OSI மாதிரியின் "கணக்கில் எடுத்துக்கொள்வது" அடுக்கு 7) HAProxy மற்றும் NGINX போன்றவை. உங்கள் விருப்பப்படி ப்ராக்ஸியை நீங்கள் தேர்வு செய்யலாம்; Linkerd ஒரு ரஸ்ட் ப்ராக்ஸியைப் பயன்படுத்துகிறது, வெறுமனே பெயரிடப்பட்டது . சர்வீஸ் மெஷிற்காக பிரத்யேகமாக அதை ஒன்றாக இணைத்துள்ளோம். மற்ற மெஷ்கள் மற்ற ப்ராக்ஸிகளை விரும்புகின்றன (தூதுவர் ஒரு பொதுவான தேர்வு). இருப்பினும், ஒரு ப்ராக்ஸியைத் தேர்ந்தெடுப்பது செயல்படுத்துவதற்கான ஒரு விஷயம்.
இந்த ப்ராக்ஸி சர்வர்கள் என்ன செய்கின்றன? வெளிப்படையாக, அவர்கள் சேவைகளுக்கான அழைப்புகளை ப்ராக்ஸி செய்கிறார்கள் (கண்டிப்பாகச் சொன்னால், அவை ப்ராக்ஸிகளாகவும் தலைகீழ் ப்ராக்ஸிகளாகவும் செயல்படுகின்றன, உள்வரும் மற்றும் வெளிச்செல்லும் அழைப்புகளைக் கையாளுகின்றன). மேலும் அவை அழைப்புகளில் கவனம் செலுத்தும் அம்சத் தொகுப்பை செயல்படுத்துகின்றன இடையில் சேவைகள். சேவைகளுக்கு இடையேயான போக்குவரத்தின் மீதான இந்த கவனம், சேவை மெஷ் ப்ராக்ஸியை ஏபிஐ கேட்வேகள் அல்லது இன்க்ரஸ் ப்ராக்ஸிகளிலிருந்து வேறுபடுத்துகிறது (பிந்தைய கவனம் வெளி உலகத்திலிருந்து கிளஸ்டருக்கு வரும் அழைப்புகள்). (குறிப்பு. மொழிபெயர்குபெர்னெட்டஸுக்கு ஏற்கனவே உள்ள இங்க்ரஸ் கன்ட்ரோலர்களை ஒப்பிடுவதற்கு, அவற்றில் பல ஏற்கனவே குறிப்பிட்டுள்ள தூதுவரைப் பயன்படுத்துகின்றன, பார்க்கவும் .)
எனவே, நாங்கள் தரவு விமானத்தை வரிசைப்படுத்தியுள்ளோம். கட்டுப்பாட்டு விமானம் எளிமையானது: இது சேவைக் கண்டறிதல், TLS சான்றிதழ்களை வழங்குதல், மெட்ரிக் திரட்டுதல் போன்றவை உட்பட தரவு விமானம் ஒருங்கிணைக்கப்பட்ட முறையில் செயல்பட வேண்டிய அனைத்து இயக்கவியல்களையும் வழங்கும் கூறுகளின் தொகுப்பாகும். அதன் நடத்தை; இதையொட்டி, கட்டுப்பாட்டு விமானம் ஒரு API ஐ வழங்குகிறது, இது தரவு விமானத்தின் ஒட்டுமொத்த நடத்தையை மாற்றவும் கண்காணிக்கவும் உங்களை அனுமதிக்கிறது.
Linkerd இல் உள்ள கட்டுப்பாட்டு விமானம் மற்றும் தரவு விமானத்தின் வரைபடம் கீழே உள்ளது. நீங்கள் பார்க்க முடியும் என, கட்டுப்பாட்டு விமானம் ப்ராக்ஸி சேவையகங்களிலிருந்து அளவீடுகளை சேகரிக்கும் ப்ரோமிதியஸ் நிகழ்வு உட்பட பல்வேறு கூறுகளை உள்ளடக்கியது. destination (சேவை கண்டுபிடிப்பு), identity (சான்றிதழ் அதிகாரம், CA) மற்றும் public-api (இணையம் மற்றும் CLI க்கான இறுதிப்புள்ளிகள்). இதற்கு நேர்மாறாக, டேட்டா பிளேன் என்பது பயன்பாட்டு நிகழ்விற்கு அடுத்துள்ள ஒரு எளிய லிங்க்கர்ட்-ப்ராக்ஸி ஆகும். இது ஒரு தர்க்க வரைபடம் மட்டுமே; நிஜ-உலகப் வரிசைப்படுத்தலில், ஒவ்வொரு கட்டுப்பாட்டு விமானக் கூறுகளின் மூன்று பிரதிகள் மற்றும் தரவுத் தளத்தில் நூற்றுக்கணக்கான அல்லது ஆயிரக்கணக்கான ப்ராக்ஸிகள் உங்களிடம் இருக்கலாம்.
(இந்த வரைபடத்தில் உள்ள நீல செவ்வகங்கள் குபெர்னெட்டஸ் காய்களின் எல்லைகளை அடையாளப்படுத்துகின்றன. லிங்கர்ட்-ப்ராக்ஸி கொண்ட கொள்கலன்கள் பயன்பாட்டுக் கொள்கலன்களின் அதே பாடில் இருப்பதை நீங்கள் காணலாம். இந்தத் திட்டம் பக்கவாட்டு கொள்கலன்.)
சர்வீஸ் மெஷ் கட்டிடக்கலை பல முக்கியமான தாக்கங்களைக் கொண்டுள்ளது. முதலாவதாக, ப்ராக்ஸியின் பணியானது, சேவைகளுக்கிடையேயான அழைப்புகளை இடைமறிப்பதால், ஒரு குறிப்பிட்ட சேவைகளுக்காக உங்கள் விண்ணப்பம் உருவாக்கப்பட்டிருந்தால் மட்டுமே ஒரு சேவை மெஷ் அர்த்தமுள்ளதாக இருக்கும். கண்ணி முடியும் மோனோலித்களுடன் பயன்படுத்தவும், ஆனால் இது ஒரு ஒற்றை ப்ராக்ஸிக்காக தெளிவாக தேவையற்றது, மேலும் அதன் செயல்பாடு தேவையில் இருக்க வாய்ப்பில்லை.
மற்றொரு முக்கியமான விளைவு என்னவென்றால், சேவை மெஷ் தேவைப்படுகிறது பெரிய ப்ராக்ஸிகளின் எண்ணிக்கை. உண்மையில், லிங்கர்ட் ஒவ்வொரு சேவையின் ஒவ்வொரு நிகழ்விற்கும் ஒரு லிங்கர்ட்-ப்ராக்ஸியை இணைக்கிறது (மற்ற செயலாக்கங்கள் ஒவ்வொரு முனை/ஹோஸ்ட்/மெய்நிகர் இயந்திரத்திற்கும் ஒரு ப்ராக்ஸியைச் சேர்க்கின்றன. அது எப்படியும் அதிகம்). ப்ராக்ஸிகளின் இத்தகைய செயலில் பயன்பாடு பல கூடுதல் சிக்கல்களைக் கொண்டுள்ளது:
- தரவுத் தளத்தில் ப்ராக்ஸிகள் இருக்க வேண்டும் வேகமாக, ஒவ்வொரு அழைப்பிற்கும் ப்ராக்ஸிக்கு இரண்டு அழைப்புகள் உள்ளன: ஒன்று கிளையன்ட் பக்கத்தில், ஒன்று சர்வர் பக்கத்தில்.
- ப்ராக்ஸிகளும் இருக்க வேண்டும் சிறிய и இலகுரக. ஒவ்வொன்றும் நினைவகம் மற்றும் CPU வளங்களை உட்கொள்ளும், மேலும் இந்த நுகர்வு பயன்பாட்டிற்கு நேர்கோட்டில் வளரும்.
- அதிக எண்ணிக்கையிலான ப்ராக்ஸிகளை வரிசைப்படுத்தவும் புதுப்பிக்கவும் உங்களுக்கு ஒரு பொறிமுறை தேவைப்படும். கைமுறையாகச் செய்வது ஒரு விருப்பமல்ல.
பொதுவாக, ஒரு சர்வீஸ் மெஷ் இப்படி இருக்கும் (குறைந்தபட்சம் ஒரு பறவையின் பார்வையில் இருந்து): உள், சேவைகளுக்கு இடையேயான போக்குவரத்தில் "ஏதாவது செய்யும்" பயனர் ஸ்பேஸ் ப்ராக்ஸிகளை நீங்கள் பயன்படுத்துகிறீர்கள், மேலும் அவற்றைக் கண்காணிக்கவும் நிர்வகிக்கவும் கட்டுப்பாட்டு விமானத்தைப் பயன்படுத்தவும்.
இப்போது "ஏன்?" என்ற கேள்வியைக் கேட்க வேண்டிய நேரம் இது.
சேவை மெஷ் எதற்காக?
ஒரு சேவை கண்ணி யோசனையை முதலில் சந்தித்தவர்கள் கொஞ்சம் பயமாக உணர்ந்ததற்காக மன்னிக்கப்படலாம். சேவை மெஷ் வடிவமைப்பு என்பது பயன்பாட்டில் உள்ள தாமதத்தை அதிகரிப்பது மட்டுமல்லாமல், அதுவும் செய்யும் நுகரும் வளங்கள் மற்றும் சேர்ப்பார்கள் உள்கட்டமைப்பில் ஒரு புதிய வழிமுறைகள். முதலில் நீங்கள் ஒரு சேவை வலையை அமைத்தீர்கள், பின்னர் திடீரென்று நீங்கள் நூற்றுக்கணக்கான (ஆயிரக்கணக்கில் இல்லாவிட்டாலும்) ப்ராக்ஸிகளுக்கு சேவை செய்ய வேண்டும். யார் தானாக முன்வந்து இதைச் செய்வார்கள் என்பதுதான் கேள்வி.
இந்த கேள்விக்கான பதில் இரண்டு பகுதிகளைக் கொண்டுள்ளது. முதலாவதாக, சுற்றுச்சூழலில் நிகழும் சில மாற்றங்களால் இந்த ப்ராக்ஸிகளை வரிசைப்படுத்துவதோடு தொடர்புடைய பரிவர்த்தனை செலவுகள் கணிசமாகக் குறைக்கப்படலாம் (இதைப் பற்றி மேலும்).
இரண்டாவதாக, இது போன்ற ஒரு சாதனம் உண்மையில் கணினியில் கூடுதல் தர்க்கத்தை அறிமுகப்படுத்த ஒரு சிறந்த வழியாகும். ஒரு சர்வீஸ் மெஷ் நிறைய புதிய செயல்பாடுகளைச் சேர்க்க முடியும் என்பதால் மட்டுமல்ல, சுற்றுச்சூழல் அமைப்பில் குறுக்கிடாமல் செய்ய முடியும் என்பதால். உண்மையில், முழு சேவை மெஷ் மாதிரியும் இந்த அடிப்படையை அடிப்படையாகக் கொண்டது: பல சேவை அமைப்பில், எதுவாக இருந்தாலும் சரி செய்கிறார்கள் தனிப்பட்ட சேவைகள், போக்குவரத்து அவர்களுக்கு மத்தியில் செயல்பாட்டைச் சேர்க்க சிறந்த புள்ளி.
எடுத்துக்காட்டாக, Linkerd இல் (பெரும்பாலான மெஷ்களைப் போலவே) செயல்பாடு முதன்மையாக HTTP அழைப்புகளில் கவனம் செலுத்துகிறது, இதில் HTTP/2 மற்றும் gRPC* ஆகியவை அடங்கும். செயல்பாடு மிகவும் பணக்காரமானது - இது மூன்று வகுப்புகளாக பிரிக்கலாம்:
- தொடர்பான அம்சங்கள் நம்பகத்தன்மை. மீண்டும் மீண்டும் கோரிக்கைகள், காலக்கெடு, கேனரி அணுகுமுறை (போக்குவரத்தை பிரித்தல்/திருப்புதல்) போன்றவை.
- தொடர்பான அம்சங்கள் கண்காணிப்பு. ஒவ்வொரு சேவை அல்லது தனிப்பட்ட திசைகளுக்கான வெற்றி விகிதங்கள், தாமதங்கள் மற்றும் கோரிக்கை தொகுதிகளின் தொகுப்பு; சேவைகளின் இடவியல் வரைபடங்களை உருவாக்குதல், முதலியன
- தொடர்பான அம்சங்கள் பாதுகாப்பு. பரஸ்பர TLS, அணுகல் கட்டுப்பாடு போன்றவை.
* லிங்கர்டின் பார்வையில், gRPC நடைமுறையில் HTTP/2 இலிருந்து வேறுபட்டதல்ல: இது பேலோடில் புரோட்டோபஃப் பயன்படுத்துகிறது. ஒரு டெவலப்பரின் பார்வையில், இரண்டு விஷயங்களும் வேறுபட்டவை.
இவற்றில் பல வழிமுறைகள் கோரிக்கை மட்டத்தில் இயங்குகின்றன (எனவே "L7 ப்ராக்ஸி"). எடுத்துக்காட்டாக, Foo சேவையானது பார் சேவைக்கு HTTP அழைப்பை மேற்கொண்டால், Foo பக்கத்திலுள்ள linkerd-proxy ஆனது, கவனிக்கப்பட்ட தாமதத்தின் அடிப்படையில், Foo இலிருந்து Bar நிகழ்வுகளுக்கு அறிவார்ந்த சுமை சமநிலை மற்றும் வழி அழைப்புகளைச் செய்ய முடியும்; தேவைப்பட்டால் அது கோரிக்கையை மீண்டும் செய்யலாம் (மற்றும் அது பலவீனமாக இருந்தால்); இது மறுமொழி குறியீடு மற்றும் காலக்கெடு போன்றவற்றை பதிவு செய்யலாம். இதேபோல், பார் பக்கத்தில் உள்ள linkerd-proxy கோரிக்கையை அனுமதிக்கவில்லை அல்லது கோரிக்கை வரம்பை மீறினால் அதை நிராகரிக்கலாம்; அதன் பங்கில் தாமதம் போன்றவை பதிவு செய்யலாம்.
ப்ராக்ஸிகள் இணைப்பு மட்டத்திலும் "ஏதாவது செய்ய" முடியும். எடுத்துக்காட்டாக, Foo பக்கத்திலுள்ள linkerd-proxy ஆனது TLS இணைப்பைத் தொடங்கலாம், மேலும் Bar பக்கத்தில் உள்ள linkerd-proxy அதை நிறுத்தலாம், மேலும் இரு தரப்பும் TLS சான்றிதழ்களைச் சரிபார்க்கலாம்*. இது சேவைகளுக்கு இடையே உள்ள குறியாக்கத்தை மட்டுமல்ல, சேவைகளை அடையாளம் காண்பதற்கான கிரிப்டோகிராஃபிகலாக பாதுகாப்பான வழியையும் வழங்குகிறது: ஃபூ மற்றும் பார் அவர்கள் யார் என்று "நிரூபிக்க" முடியும்.
* "ஒரு நண்பரின் பரஸ்பரம்" என்பது கிளையன்ட் சான்றிதழையும் சரிபார்க்கிறது (பரஸ்பர TLS). "கிளாசிக்" TLS இல், எடுத்துக்காட்டாக, உலாவி மற்றும் சேவையகத்திற்கு இடையில், ஒரு பக்கத்தின் (சர்வர்) சான்றிதழ் பொதுவாக சரிபார்க்கப்படும்.
அவை கோரிக்கை அல்லது இணைப்பு மட்டத்தில் செயல்படுகின்றனவா என்பதைப் பொருட்படுத்தாமல், அனைத்து சேவை மெஷ் செயல்பாடுகளும் உள்ளன என்பதை வலியுறுத்துவது முக்கியம் செயல்பாட்டு பாத்திரம். Linkerd ஆனது பேலோடின் சொற்பொருளை மாற்ற முடியாது - எடுத்துக்காட்டாக, JSON துண்டுக்கு புலங்களைச் சேர்ப்பது அல்லது புரோட்டோபஃப் இல் மாற்றங்களைச் செய்வது. ESB மற்றும் மிடில்வேர் பற்றி பேசும்போது இந்த முக்கியமான அம்சத்தைப் பற்றி பின்னர் பேசுவோம்.
இது சேவை மெஷ் வழங்கும் அம்சங்களின் தொகுப்பாகும். கேள்வி எழுகிறது: அவற்றை ஏன் நேரடியாக விண்ணப்பத்தில் செயல்படுத்தக்கூடாது? ஒரு ப்ராக்ஸியுடன் ஏன் கவலைப்பட வேண்டும்?
சேவை மெஷ் ஏன் ஒரு நல்ல யோசனை
சேவை மெஷின் திறன்கள் உற்சாகமாக இருந்தாலும், அதன் முக்கிய மதிப்பு உண்மையில் அதன் அம்சங்களில் இல்லை. இறுதியில் நாம் முடியும் அவற்றை நேரடியாக பயன்பாட்டில் செயல்படுத்தவும் (இதுதான் சேவை மெஷின் தோற்றம் என்பதை பின்னர் பார்ப்போம்). ஒரு வாக்கியத்தில் சுருக்கமாக முயற்சி செய்ய, சேவை மெஷின் மதிப்பு: இது நவீன சேவையக மென்பொருளை முழு ஸ்டாக் முழுவதும் சீரான முறையில் இயக்குவதற்கு முக்கியமான அம்சங்களை வழங்குகிறது மற்றும் பயன்பாட்டுக் குறியீட்டிலிருந்து சுயாதீனமாக உள்ளது.
இந்த முன்மொழிவை பகுப்பாய்வு செய்வோம்.
«நவீன சர்வர் மென்பொருளை இயக்குவதற்கு முக்கியமான அம்சங்கள்" நீங்கள் பொது இணையத்துடன் இணைக்கப்பட்ட பரிவர்த்தனை சேவையக பயன்பாட்டை உருவாக்குகிறீர்கள் என்றால், வெளி உலகத்திலிருந்து வரும் கோரிக்கைகளை ஏற்று, குறுகிய காலத்திற்குள் அவற்றிற்கு பதிலளிப்பீர்கள் - எடுத்துக்காட்டாக, ஒரு வலை பயன்பாடு, ஒரு API சேவையகம் மற்றும் பிற நவீன பயன்பாடுகளில் பெரும்பாலானவை - மற்றும் நீங்கள் அதை ஒன்றுக்கொன்று ஒத்திசைந்து செயல்படும் சேவைகளின் தொகுப்பாகச் செயல்படுத்தினால், நீங்கள் தொடர்ந்து இந்த மென்பொருளை மேம்படுத்தி, புதிய அம்சங்களைச் சேர்த்தால், மாற்றியமைக்கும் செயல்பாட்டின் போது இந்த அமைப்பைப் பராமரிக்க வேண்டிய கட்டாயத்தில் இருந்தால் - இதில் வழக்கு, வாழ்த்துக்கள், நீங்கள் நவீன சர்வர் மென்பொருளை உருவாக்குகிறீர்கள். மேலே பட்டியலிடப்பட்டுள்ள இந்த சிறந்த அம்சங்கள் அனைத்தும் உங்களுக்கு முக்கியமானதாக மாறும். பயன்பாடு நம்பகமானதாகவும், பாதுகாப்பாகவும் இருக்க வேண்டும், மேலும் அது என்ன செய்கிறது என்பதை நீங்கள் கவனிக்க முடியும். சர்வீஸ் மெஷ் தீர்க்க உதவும் கேள்விகள் இவைதான்.
(சரி, முந்தைய பத்தியில் இந்த அணுகுமுறையே சர்வர் மென்பொருளை உருவாக்குவதற்கான நவீன வழி என்ற எனது நம்பிக்கையை உள்ளடக்கியது. மற்றவர்கள் மோனோலித்கள், “ரியாக்டிவ் மைக்ரோ சர்வீஸ்கள்” மற்றும் மேலே கொடுக்கப்பட்டுள்ள வரையறையின் கீழ் வராத பிற விஷயங்களை உருவாக்க விரும்புகிறார்கள். இந்த நபர்கள் தங்கள் எனது கருத்து வேறுபட்டது. இதையொட்டி, அவை "தவறு" என்று நான் நினைக்கிறேன் - எந்தவொரு சந்தர்ப்பத்திலும் சேவை மெஷ் அவர்களுக்கு மிகவும் பயனுள்ளதாக இல்லை).
«முழு அடுக்கிற்குமான சீருடை" ஒரு சேவை மெஷ் மூலம் வழங்கப்படும் செயல்பாடு வெறும் பணி முக்கியத்துவம் வாய்ந்தது அல்ல. அவர்கள் எந்த மொழியில் எழுதப்பட்டிருக்கிறார்கள், எந்த கட்டமைப்பைப் பயன்படுத்துகிறார்கள், யார் எழுதினார்கள், எப்படிப் பயன்படுத்தினார்கள், அவற்றின் வளர்ச்சி மற்றும் பயன்பாட்டின் பிற நுணுக்கங்களைப் பொருட்படுத்தாமல், பயன்பாட்டில் உள்ள அனைத்து சேவைகளுக்கும் அவை பொருந்தும்.
«பயன்பாட்டுக் குறியீட்டைச் சார்ந்தது" இறுதியாக, ஒரு சர்வீஸ் மெஷ், ஸ்டாக் முழுவதும் சீரான செயல்பாட்டை வழங்குவது மட்டுமல்லாமல், பயன்பாட்டைத் திருத்த வேண்டிய அவசியமில்லாத வகையில் செய்கிறது. உள்ளமைவு, புதுப்பித்தல், செயல்பாடு, பராமரிப்பு போன்றவற்றுக்கான பணிகள் உட்பட சேவை மெஷ் செயல்பாட்டின் அடிப்படை அடிப்படையானது முற்றிலும் இயங்குதள மட்டத்தில் உள்ளது மற்றும் பயன்பாட்டிலிருந்து சுயாதீனமாக உள்ளது. சேவை மெஷைப் பாதிக்காமல் பயன்பாடு மாறலாம். இதையொட்டி, பயன்பாட்டிலிருந்து எந்தப் பங்கேற்பும் இல்லாமல் சேவை மெஷ் மாறலாம்.
சுருக்கமாக, ஒரு சேவை மெஷ் முக்கிய செயல்பாட்டை வழங்குவது மட்டுமல்லாமல், உலகளாவிய, சீரான மற்றும் பயன்பாட்டு-சுயாதீனமான முறையில் செய்கிறது. எனவே, சேவை மெஷ் செயல்பாட்டை சேவைக் குறியீட்டில் செயல்படுத்த முடியும் என்றாலும் (உதாரணமாக, ஒவ்வொரு சேவையிலும் ஒரு நூலகமாக சேர்க்கப்பட்டுள்ளது), இந்த அணுகுமுறை ஒரு சேவை கண்ணி விஷயத்தில் மிகவும் மதிப்புமிக்க சீரான மற்றும் சுதந்திரத்தை வழங்காது.
நீங்கள் செய்ய வேண்டியது எல்லாம் ஒரு சில ப்ராக்ஸிகளைச் சேர்ப்பதுதான்! இந்த ப்ராக்ஸிகளைச் சேர்ப்பது தொடர்பான செயல்பாட்டுச் செலவுகளை விரைவில் பார்ப்போம் என்று உறுதியளிக்கிறேன். ஆனால் முதலில் இந்த சுதந்திர யோசனையை வெவ்வேறு கண்ணோட்டங்களில் நிறுத்தி பார்ப்போம். மக்கள்.
சர்வீஸ் மெஷ் யாருக்கு உதவுகிறது?
ஒரு தொழில்நுட்பம் சுற்றுச்சூழலின் முக்கிய அங்கமாக மாற, அது சிரமமாக இருந்தாலும், அது மக்களால் ஏற்றுக்கொள்ளப்பட வேண்டும். சேவை வலையில் யார் ஆர்வம் காட்டுகிறார்கள்? அதன் பயன்பாட்டால் யார் பயனடைகிறார்கள்?
நீங்கள் நவீன சேவையக மென்பொருளை உருவாக்குகிறீர்கள் என்றால், உங்கள் குழுவை ஒரு குழுவாக நீங்கள் நினைக்கலாம் சேவை உரிமையாளர்கள்வணிக தர்க்கத்தை உருவாக்கி செயல்படுத்துபவர்கள், மற்றும் மேடை உரிமையாளர்கள், இந்த சேவைகள் செயல்படும் உள் தளத்தை உருவாக்குதல். சிறிய நிறுவனங்களில், இவை ஒரே நபர்களாக இருக்கலாம், ஆனால் நிறுவனம் வளரும்போது, இந்த பாத்திரங்கள் மிகவும் உச்சரிக்கப்படுகின்றன மற்றும் துணை வேடங்களாகப் பிரிக்கப்படுகின்றன... (டெவொப்களின் மாறும் தன்மையைப் பற்றி இங்கு நிறைய சொல்ல வேண்டும் மைக்ரோ சர்வீஸ்கள், முதலியவற்றின் நிறுவன தாக்கம்) n. ஆனால் தற்போது இந்த விளக்கங்களை கொடுக்கப்பட்டுள்ளபடியே எடுத்துக்கொள்வோம்).
இந்தக் கண்ணோட்டத்தில், சேவை மெஷின் தெளிவான பயனாளிகள் பிளாட்ஃபார்ம் உரிமையாளர்கள். எல்லாவற்றிற்கும் மேலாக, பிளாட்ஃபார்ம் குழுவின் குறிக்கோள், சேவை உரிமையாளர்கள் வணிக தர்க்கத்தை செயல்படுத்தக்கூடிய ஒரு உள் தளத்தை உருவாக்குவதும், அதன் செயல்பாட்டின் இருண்ட விவரங்களிலிருந்து முடிந்தவரை சுதந்திரமாக இருப்பதை உறுதிசெய்யும் வகையில் செய்வதும் ஆகும். ஒரு சேவை மெஷ் இந்த இலக்கை அடைவதற்கு முக்கியமான திறன்களை வழங்குவது மட்டுமல்லாமல், சேவை உரிமையாளர்கள் மீது சார்புகளை சுமத்தாத வகையில் அது செய்கிறது.
இன்னும் மறைமுகமாக இருந்தாலும் சேவை உரிமையாளர்களும் பயனடைகிறார்கள். சேவை உரிமையாளரின் குறிக்கோள், வணிக செயல்முறையின் தர்க்கத்தை செயல்படுத்துவதில் முடிந்தவரை உற்பத்தி செய்ய வேண்டும், மேலும் அவர் செயல்பாட்டு சிக்கல்களைப் பற்றி எவ்வளவு குறைவாக கவலைப்படுகிறாரோ, அவ்வளவு சிறந்தது. கொள்கைகள் அல்லது TLSஐ நடைமுறைப்படுத்துதல், சொல்லுதல், மறுமுயற்சி செய்தல் போன்றவற்றைச் சமாளிப்பதற்குப் பதிலாக, அவர்கள் வணிக நோக்கங்களில் மட்டுமே கவனம் செலுத்த முடியும் மற்றும் மீதமுள்ளவற்றை தளம் கவனித்துக்கொள்ளும் என்று நம்புகிறார்கள். இது அவர்களுக்கு ஒரு பெரிய நன்மை.
தளங்கள் மற்றும் சேவைகளின் உரிமையாளர்களுக்கு இடையிலான அத்தகைய பிரிவின் நிறுவன மதிப்பை மிகைப்படுத்த முடியாது. அவள் பங்களிப்பாள் என்று நினைக்கிறேன் பிரதான சேவை கண்ணி மதிப்புக்கு பங்களிப்பு.
அவர்கள் ஏன் சர்வீஸ் மெஷைத் தேர்ந்தெடுத்தார்கள் என்று ஆரம்பகால லிங்கர்ட் ரசிகர் ஒருவர் எங்களிடம் கூறியபோது இந்தப் பாடத்தைக் கற்றுக்கொண்டோம்: ஏனெனில் அது அவர்களை "பேசும் கடையை குறைந்தபட்சமாக வைத்திருக்க" அனுமதித்தது. இங்கே சில விவரங்கள் உள்ளன: ஒரு பெரிய நிறுவனத்தைச் சேர்ந்த தோழர்கள் தங்கள் தளத்தை குபெர்னெட்டஸுக்கு மாற்றினர். பயன்பாடு முக்கியமான தகவல்களைக் கையாள்வதால், கிளஸ்டர்கள் முழுவதும் அனைத்து தகவல்தொடர்புகளையும் குறியாக்கம் செய்ய அவர்கள் விரும்பினர். இருப்பினும், நூற்றுக்கணக்கான சேவைகள் மற்றும் நூற்றுக்கணக்கான மேம்பாட்டுக் குழுக்கள் இருப்பதால் நிலைமை சிக்கலானது. எல்லோரையும் தொடர்புகொண்டு, அவர்களின் திட்டங்களில் TLS ஆதரவைச் சேர்க்கும்படி அவர்களை நம்பவைக்கும் வாய்ப்பு அவர்களுக்கு மகிழ்ச்சியைத் தரவில்லை. Linkerd ஐ நிறுவிய பிறகு, அவர்கள் மாற்றப்பட்டனர் பொறுப்பு டெவலப்பர்கள் (இது தேவையற்ற பிரச்சனை என்ற பார்வையில் இருந்து) பிளாட்ஃபார்மர்கள் வரை, யாருக்கு இது ஒரு உயர்மட்ட முன்னுரிமையாக இருந்தது. வேறு வார்த்தைகளில் கூறுவதானால், லிங்கர்ட் அவர்களுக்கு ஒரு நிறுவன ரீதியாக தொழில்நுட்ப சிக்கலை தீர்க்கவில்லை.
சுருக்கமாக, ஒரு சேவை கண்ணி என்பது ஒரு தீர்வாகும், தொழில்நுட்பம் அல்ல, ஆனால் சமூக-தொழில்நுட்ப பிரச்சனைகள். (நன்றி இந்த வார்த்தையை அறிமுகப்படுத்தியதற்காக.)
ஒரு சேவை மெஷ் எனது எல்லா பிரச்சனைகளையும் தீர்க்குமா?
ஆம். அதாவது, இல்லை!
மேலே குறிப்பிட்டுள்ள மூன்று வகை அம்சங்களைப் பார்த்தால்-நம்பகத்தன்மை, பாதுகாப்பு மற்றும் கவனிப்பு-இந்தப் பிரச்சனைகள் எதற்கும் ஒரு சர்வீஸ் மெஷ் ஒரு முழுமையான தீர்வு அல்ல என்பது தெளிவாகிறது. லிங்கர்டு கோரிக்கைகளை மீண்டும் வெளியிட முடியும் (அவை வலிமையற்றவை என்று தெரிந்தால்), சேவை நிரந்தரமாக தோல்வியுற்றால், பயனருக்கு எதைத் திருப்பித் தருவது என்பது குறித்த முடிவுகளை எடுக்க முடியாது-அந்த முடிவுகள் பயன்பாட்டினால் எடுக்கப்பட வேண்டும். வெற்றிகரமான கோரிக்கைகளின் புள்ளிவிவரங்களை Linkerd வைத்திருக்க முடியும், ஆனால் அது சேவையைப் பார்த்து அதன் உள் அளவீடுகளை வழங்க முடியாது - பயன்பாட்டில் அத்தகைய கருவிகள் இருக்க வேண்டும். லிங்கர்டு mTLS ஐ ஒழுங்கமைக்கும் திறன் கொண்டதாக இருந்தாலும், முழு அளவிலான பாதுகாப்பு தீர்வுகளுக்கு இன்னும் அதிகம் தேவைப்படுகிறது.
சேவை மெஷ் வழங்கும் இந்தப் பகுதிகளில் உள்ள அம்சங்களின் துணைக்குழு தொடர்புடையது மேடை அம்சங்கள். இதன் மூலம் நான் செயல்பாடுகளை சொல்கிறேன்:
- வணிக தர்க்கத்திலிருந்து சாராதது. ஃபூ மற்றும் பார் இடையே உள்ள கால் ஹிஸ்டோகிராம்கள் கட்டமைக்கப்பட்ட விதம் முற்றிலும் சுயாதீனமானது ஏன் ஃபூ பட்டியை அழைக்கிறார்.
- சரியாக செயல்படுத்துவது கடினம். லிங்கர்டில், மறுமுயற்சிகள், மறுமுயற்சி பட்ஜெட்கள் போன்ற அனைத்து விதமான ஆடம்பரமான விஷயங்களுடனும் அளவுருவாக இருக்கும் (பட்ஜெட்களை மீண்டும் முயற்சிக்கவும்), இதுபோன்ற விஷயங்களைச் செயல்படுத்துவதில் ஒரு நுட்பமற்ற, தலைகீழ் அணுகுமுறை நிச்சயமாக "கோரிக்கைகளின் பனிச்சரிவு" என்று அழைக்கப்படுவதற்கு வழிவகுக்கும். (புயல் மீண்டும் முயற்சிக்கவும்) விநியோகிக்கப்பட்ட அமைப்புகளின் சிறப்பியல்பு மற்றும் பிற சிக்கல்கள்.
- ஒரே மாதிரியாகப் பயன்படுத்தும்போது மிகவும் பயனுள்ளதாக இருக்கும். TLS பொறிமுறையானது எல்லா இடங்களிலும் பயன்படுத்தப்பட்டால் மட்டுமே அர்த்தமுள்ளதாக இருக்கும்.
இந்த செயல்பாடுகள் ப்ராக்ஸி மட்டத்தில் செயல்படுத்தப்படுவதால் (பயன்பாட்டு மட்டத்தில் அல்ல), சேவை மெஷ் அவற்றை வழங்குகிறது платформы, பயன்பாடுகள் அல்ல. எனவே, சேவைகள் எந்த மொழியில் எழுதப்பட்டுள்ளன, எந்த கட்டமைப்பைப் பயன்படுத்துகின்றன, யார் அவற்றை எழுதினார்கள், ஏன் எழுதுகிறார்கள் என்பது முக்கியமல்ல. இந்த விவரங்கள் அனைத்திற்கும் வெளியே ப்ராக்ஸிகள் செயல்படுகின்றன, மேலும் இந்த செயல்பாட்டின் அடிப்படை அடிப்படையானது, உள்ளமைவு, புதுப்பித்தல், செயல்பாடு, பராமரிப்பு போன்றவற்றுக்கான பணிகள் உட்பட, இயங்குதள மட்டத்தில் மட்டுமே உள்ளது.
சேவை மெஷ் திறன்களின் எடுத்துக்காட்டுகள்
சுருக்கமாகச் சொல்வதானால், நம்பகத்தன்மை, கவனிப்பு அல்லது பாதுகாப்பிற்கான ஒரு சேவை மெஷ் ஒரு முழுமையான தீர்வு அல்ல. இந்த பகுதிகளின் நோக்கத்திற்கு சேவை உரிமையாளர்கள், Ops/SRE குழுக்கள் மற்றும் பிற நிறுவனங்களின் பங்கு தேவை. சேவை மெஷ் இந்த ஒவ்வொரு பகுதிக்கும் இயங்குதள அளவிலான “ஸ்லைஸை” மட்டுமே வழங்குகிறது.
சேவை மெஷ் ஏன் இப்போது பிரபலமாகிவிட்டது?
இப்போது நீங்கள் ஒருவேளை யோசித்துக்கொண்டிருக்கலாம்: சரி, சர்வீஸ் மெஷ் மிகவும் நன்றாக இருந்தால், பத்து வருடங்களுக்கு முன்பு நாம் ஏன் மில்லியன் கணக்கான ப்ராக்ஸிகளை அடுக்கி வைக்கவில்லை?
இந்த கேள்விக்கு ஒரு சாதாரணமான பதில் உள்ளது: பத்து ஆண்டுகளுக்கு முன்பு எல்லோரும் மோனோலித்களைக் கட்டினார்கள், யாருக்கும் சேவை கண்ணி தேவையில்லை. இது உண்மைதான், ஆனால் என் கருத்துப்படி இந்த பதில் புள்ளியை இழக்கிறது. பத்து ஆண்டுகளுக்கு முன்பு கூட, பெரிய அளவிலான அமைப்புகளை உருவாக்குவதற்கான ஒரு நம்பிக்கைக்குரிய வழியாக மைக்ரோ சர்வீஸ் கருத்து பரவலாக விவாதிக்கப்பட்டது மற்றும் Twitter, Facebook, Google மற்றும் Netflix போன்ற நிறுவனங்களில் பயன்படுத்தப்பட்டது. பொதுவான பார்வை-குறைந்தபட்சம் நான் தொடர்பு கொண்ட தொழில்துறையின் பகுதிகள்-அது கடினமானதாக இருந்தாலும் கூட, பெரிய அமைப்புகளை உருவாக்க மைக்ரோ சர்வீஸ்கள் "சரியான வழி".
நிச்சயமாக, பத்து ஆண்டுகளுக்கு முன்பு மைக்ரோ சர்வீஸ்களை இயக்கும் நிறுவனங்கள் இருந்தபோதிலும், அவை சேவை வலையை உருவாக்க எல்லா இடங்களிலும் ப்ராக்ஸிகளை ஒட்டவில்லை. இருப்பினும், நீங்கள் நெருக்கமாகப் பார்த்தால், அவர்கள் இதேபோன்ற ஒன்றைச் செய்தார்கள்: இந்த நிறுவனங்களில் பல நெட்வொர்க் தகவல்தொடர்புக்கு ஒரு சிறப்பு உள் நூலகத்தைப் பயன்படுத்த வேண்டும் (சில நேரங்களில் தடிமனான கிளையன்ட் நூலகம் என்று அழைக்கப்படுகிறது, கொழுப்பு வாடிக்கையாளர் நூலகம்).
Netflix இல் Hysterix இருந்தது, Google இல் Stubby இருந்தது, Twitter இல் Finagle நூலகம் இருந்தது. எடுத்துக்காட்டாக, ட்விட்டரில் ஒவ்வொரு புதிய சேவைக்கும் Finagle கட்டாயமாக இருந்தது. இது இணைப்புகளின் கிளையன்ட் மற்றும் சர்வர் இரண்டையும் கையாண்டது, மீண்டும் மீண்டும் கோரிக்கைகள், ஆதரவு கோரிக்கை ரூட்டிங், சுமை சமநிலை மற்றும் அளவீடு ஆகியவற்றிற்கு அனுமதித்தது. சேவை என்ன செய்தாலும், முழு ட்விட்டர் ஸ்டேக் முழுவதும் நம்பகத்தன்மை மற்றும் கவனிப்பு ஆகியவற்றின் நிலையான அடுக்கை இது வழங்கியது. நிச்சயமாக, இது JVM மொழிகளுக்கு மட்டுமே வேலை செய்தது மற்றும் முழு பயன்பாட்டிற்கும் பயன்படுத்த வேண்டிய நிரலாக்க மாதிரியை அடிப்படையாகக் கொண்டது. இருப்பினும், அதன் செயல்பாடு சேவை கண்ணியைப் போலவே இருந்தது. (உண்மையில், Linkerd இன் முதல் பதிப்பு ப்ராக்ஸி வடிவத்தில் வெறுமனே Finagle மூடப்பட்டிருந்தது.)
இவ்வாறு, பத்து ஆண்டுகளுக்கு முன்பு மைக்ரோ சர்வீஸ்கள் மட்டுமல்ல, சிறப்பு புரோட்டோ-சர்வீஸ்-மெஷ் நூலகங்களும் இருந்தன, அவை இன்று சேவை மெஷ் தீர்க்கும் அதே சிக்கல்களைத் தீர்க்கின்றன. இருப்பினும், சேவை மெஷ் அப்போது இல்லை. அவள் தோன்றுவதற்கு முன்பு இன்னும் ஒரு ஷிப்ட் இருக்க வேண்டும்.
கடந்த 10 ஆண்டுகளில் நடந்த மற்றொரு மாற்றத்தில் மறைந்திருக்கும் ஆழமான பதில் இங்குதான் உள்ளது: மைக்ரோ சர்வீஸ்களைப் பயன்படுத்துவதற்கான செலவு வியத்தகு அளவில் குறைந்துள்ளது. பத்து ஆண்டுகளுக்கு முன்பு மைக்ரோ சர்வீஸைப் பயன்படுத்திய மேலே குறிப்பிடப்பட்ட நிறுவனங்கள் - ட்விட்டர், நெட்ஃபிக்ஸ், ஃபேஸ்புக், கூகுள் - மிகப்பெரிய அளவிலான மற்றும் மகத்தான வளங்களைக் கொண்ட நிறுவனங்கள். அவை தேவை மட்டுமல்ல, பெரிய மைக்ரோ சர்வீஸ் அடிப்படையிலான பயன்பாடுகளை உருவாக்க, வரிசைப்படுத்த மற்றும் இயக்கும் திறனையும் கொண்டிருந்தன. ட்விட்டர் பொறியியலாளர்கள் ஒரு ஒற்றைப்பாதையில் இருந்து மைக்ரோ சர்வீஸ் அணுகுமுறைக்கு நகர்த்த ஆற்றலும் முயற்சியும் அற்புதமானது. (நியாயமாக இருக்க, அது வெற்றி பெற்றது.) இந்த வகையான உள்கட்டமைப்பு சூழ்ச்சிகள் சிறிய நிறுவனங்களுக்கு பின்னர் சாத்தியமற்றது.
நிகழ்காலத்திற்கு வேகமாக முன்னேறுங்கள். மைக்ரோ சர்வீஸ் மற்றும் டெவலப்பர்களின் விகிதம் 5:1 (அல்லது கூட ), மேலும் என்ன, அவர்கள் அவற்றை வெற்றிகரமாக சமாளிக்கிறார்கள்! 5 பேர் கொண்ட ஸ்டார்ட்அப் மூலம் 50 மைக்ரோ சர்வீஸ்களை எளிதாக இயக்க முடியும் என்றால், அதைச் செயல்படுத்துவதற்கான செலவை ஏதோ தெளிவாகக் குறைத்துள்ளது.
மோன்சோவில் 1500 மைக்ரோ சர்வீஸ்கள்; ஒவ்வொரு வரியும் டிராஃபிக்கை அனுமதிக்கும் பரிந்துரைக்கப்பட்ட பிணைய விதி
மைக்ரோ சர்வீஸ்களை இயக்குவதற்கான செலவில் வியத்தகு குறைப்பு ஒரு செயல்முறையின் விளைவாகும்: கொள்கலன்களின் வளர்ந்து வரும் புகழ் и இசைக்கலைஞர்கள். சேவை மெஷ் தோன்றுவதற்கு என்ன பங்களித்தது என்ற கேள்விக்கு இது துல்லியமாக ஆழமான பதில். அதே தொழில்நுட்பம் சேவை மெஷ்கள் மற்றும் மைக்ரோ சர்வீஸ்கள் இரண்டையும் கவர்ச்சிகரமானதாக ஆக்கியது: குபெர்னெட்ஸ் மற்றும் டோக்கர்.
ஏன்? சரி, டோக்கர் ஒரு பெரிய சிக்கலை தீர்க்கிறார் - பேக்கேஜிங் பிரச்சனை. ஒரு பயன்பாடு மற்றும் அதன் (நெட்வொர்க் அல்லாத) இயக்க நேர சார்புகளை ஒரு கொள்கலனில் பேக்கேஜிங் செய்வதன் மூலம், டோக்கர் பயன்பாட்டை ஒரு பரிமாற்றக்கூடிய யூனிட்டாக மாற்றுகிறது, இது எங்கும் ஹோஸ்ட் செய்து இயக்க முடியும். அதே நேரத்தில், இது செயல்பாட்டை பெரிதும் எளிதாக்குகிறது பன்மொழி ஸ்டேக்: ஒரு கொள்கலன் ஒரு அணு அலகு என்பதால், வரிசைப்படுத்தல் மற்றும் செயல்பாட்டு நோக்கங்களுக்காக, அது JVM, Node, Go, Python அல்லது Ruby பயன்பாடாக இருந்தாலும், உள்ளே என்ன இருக்கிறது என்பது முக்கியமல்ல. நீங்கள் அதைத் தொடங்குங்கள், அவ்வளவுதான்.
குபெர்னெட்ஸ் எல்லாவற்றையும் அடுத்த கட்டத்திற்கு கொண்டு செல்கிறார். இப்போது "இயக்க வேண்டிய விஷயங்கள்" டன்கள் மற்றும் அவற்றை இயக்க டன் இயந்திரங்கள் இருப்பதால், அவற்றை ஒன்றுடன் ஒன்று தொடர்புபடுத்தக்கூடிய ஒரு கருவி தேவை. ஒரு பரந்த பொருளில், நீங்கள் குபெர்னெட்டஸுக்கு நிறைய கொள்கலன்களையும் நிறைய இயந்திரங்களையும் கொடுக்கிறீர்கள், மேலும் அது அவற்றை ஒன்றுக்கொன்று எதிராக வரைபடமாக்குகிறது (நிச்சயமாக, இது ஒரு மாறும் மற்றும் எப்போதும் மாறும் செயல்முறை: புதிய கொள்கலன்கள் கணினியைச் சுற்றி நகரும், இயந்திரங்கள் தொடங்கி நிறுத்தப்படும். , போன்றவை. இருப்பினும், குபெர்னெட்டஸ் இவை அனைத்தையும் கணக்கில் எடுத்துக்கொள்கிறார் ).
Kubernetes கட்டமைக்கப்பட்டவுடன், ஒரு சேவையை வரிசைப்படுத்துவதற்கும் இயக்குவதற்கும் ஆகும் செலவானது பத்து சேவைகளை வரிசைப்படுத்துவதற்கும் இயக்குவதற்கும் ஆகும் செலவில் இருந்து சிறிது வித்தியாசமாக இருக்கும் (உண்மையில், இது 100 சேவைகளுக்கு கிட்டத்தட்ட ஒரே மாதிரியாக இருக்கும்). பன்மொழி செயலாக்கத்தை ஊக்குவிக்கும் பேக்கேஜிங் பொறிமுறையாக இந்தக் கொள்கலன்களைச் சேர்க்கவும், மேலும் பல்வேறு மொழிகளில் எழுதப்பட்ட மைக்ரோ சர்வீஸ் வடிவில் செயல்படுத்தப்பட்ட புதிய பயன்பாடுகள் உங்களிடம் உள்ளன - ஒரு சேவை மெஷ் மிகவும் பொருத்தமான சூழல்.
எனவே, ஒரு சேவை மெஷ் பற்றிய யோசனை இப்போது ஏன் பிரபலமாகிவிட்டது என்ற கேள்விக்கான பதிலுக்கு நாங்கள் வருகிறோம்: சேவைகளுக்கு குபெர்னெட்டஸ் வழங்கும் ஒருமைப்பாடு, சேவை மெஷ் எதிர்கொள்ளும் செயல்பாட்டு சவால்களுக்கு நேரடியாகப் பொருந்தும். நீங்கள் ப்ராக்ஸிகளை கொள்கலன்களில் அடைத்து, குபெர்னெட்டஸுக்கு அவற்றை எங்கு வேண்டுமானாலும் ஒட்டும் பணியை வழங்குகிறீர்கள், மேலும் வோய்லா! இதன் விளைவாக, நீங்கள் ஒரு சேவை வலையைப் பெறுவீர்கள், அதே நேரத்தில் அதன் வரிசைப்படுத்தலின் அனைத்து இயக்கவியல்களும் குபெர்னெட்டஸால் நிர்வகிக்கப்படுகின்றன. (குறைந்தது ஒரு பறவையின் பார்வையில் இருந்து. நிச்சயமாக, இந்த செயல்முறைக்கு பல நுணுக்கங்கள் உள்ளன.)
சுருக்கமாகச் சொல்வதானால்: சேவை மெஷ்கள் இப்போது பிரபலமாகிவிட்டன, பத்து ஆண்டுகளுக்கு முன்பு அல்ல, குபெர்னெட்டஸ் மற்றும் டோக்கர் கணிசமாக அதிகரிக்கவில்லை. தேவை அதில், பன்மொழி மைக்ரோ சர்வீஸ்களின் தொகுப்பாக பயன்பாடுகளை செயல்படுத்துவதை எளிதாக்கியது, ஆனால் கணிசமாக குறைக்கப்பட்டது செலவுகள் அதன் செயல்பாட்டிற்காக, சைட்கார் ப்ராக்ஸி கடற்படைகளை வரிசைப்படுத்துவதற்கும் ஆதரிப்பதற்கும் வழிமுறைகளை வழங்குகிறது.
சர்வீஸ் மெஷ் பற்றி ஏன் இவ்வளவு பேச்சு?
தடுப்பு: இந்த பிரிவில் நான் அனைத்து வகையான அனுமானங்கள், அனுமானங்கள், கட்டுக்கதைகள் மற்றும் உள் தகவல்களைப் பயன்படுத்துகிறேன்.
"சர்வீஸ் மெஷ்" என்பதைத் தேடுங்கள், மறுசுழற்சி செய்யப்பட்ட குறைந்த கலோரி உள்ளடக்கம், வித்தியாசமான திட்டங்கள் மற்றும் எக்கோ சேம்பருக்குத் தகுதியான சிதைவின் கெலிடோஸ்கோப் ஆகியவற்றைக் காண்பீர்கள். எந்தவொரு ஆடம்பரமான புதிய தொழில்நுட்பமும் இதைச் செய்கிறது, ஆனால் ஒரு சேவை கண்ணி விஷயத்தில் சிக்கல் குறிப்பாக கடுமையானது. ஏன்?
சரி, அதில் ஒரு பகுதி என் தவறு. இது போன்ற எண்ணற்ற வலைப்பதிவு இடுகைகள் மற்றும் கட்டுரைகள் மூலம் எனக்குக் கிடைக்கும் ஒவ்வொரு வாய்ப்பும் லிங்கர்டு மற்றும் சேவை மெஷ் ஆகியவற்றை விளம்பரப்படுத்த நான் கடுமையாக உழைத்து வருகிறேன். ஆனால் நான் அவ்வளவு சக்தி வாய்ந்தவன் அல்ல. இந்த கேள்விக்கு உண்மையில் பதிலளிக்க, ஒட்டுமொத்த சூழ்நிலையைப் பற்றி நாம் கொஞ்சம் பேச வேண்டும். ஒரு திட்டத்தைக் குறிப்பிடாமல் அதைப் பற்றி பேச முடியாது: கூகுள், ஐபிஎம் மற்றும் லிஃப்ட் இணைந்து உருவாக்கிய திறந்த மூல சேவை மெஷ் ஆகும்.
(மூன்று நிறுவனங்களும் மிகவும் வேறுபட்ட பாத்திரங்களைக் கொண்டுள்ளன: லிஃப்ட்டின் ஈடுபாடு பெயரளவில் மட்டுமே உள்ளது; அவர்கள் தூதரின் ஆசிரியர்கள், ஆனால் இஸ்டியோவின் வளர்ச்சியைப் பயன்படுத்தவோ அல்லது பங்கேற்கவோ இல்லை. IBM இஸ்டியோவின் வளர்ச்சியில் ஈடுபட்டுள்ளது மற்றும் பயன்படுத்துகிறது. கூகிள் இஸ்டியோவில் தீவிரமாக ஈடுபட்டுள்ளது வளர்ச்சி , ஆனால் நான் சொல்லும் வரை உண்மையில் அதைப் பயன்படுத்தவில்லை.)
இஸ்டியோ திட்டம் இரண்டு விஷயங்களுக்கு குறிப்பிடத்தக்கது. முதலாவதாக, கூகிள், குறிப்பாக, அதை விளம்பரப்படுத்துவதில் மகத்தான சந்தைப்படுத்தல் முயற்சி உள்ளது. இன்று சர்வீஸ் மெஷ் கான்செப்ட்டைப் பற்றி அறிந்த பெரும்பாலான மக்கள் முதலில் இஸ்டியோ மூலம் அதைப் பற்றி அறிந்து கொண்டதாக நான் மதிப்பிடுவேன். இரண்டாவது விஷயம் என்னவென்றால், இஸ்டியோவுக்கு எவ்வளவு மோசமான வரவேற்பு கிடைத்தது. இந்த விஷயத்தில், நான் வெளிப்படையாக ஆர்வமுள்ள தரப்பினர், ஆனால் முடிந்தவரை புறநிலையாக இருக்க முயற்சிக்கிறேன், என்னால் இன்னும் உதவ முடியாது , மிகவும் தனித்துவமானது அல்ல (தனித்துவம் இல்லை என்றாலும்: systemd நினைவுக்கு வருகிறது, ...) திறந்த மூல திட்டத்திற்கு.
(நடைமுறையில், Istio சிக்கலானது மற்றும் UX இல் மட்டும் சிக்கல்கள் இருப்பதாகத் தெரிகிறது, ஆனால் செயல்திறனிலும். எடுத்துக்காட்டாக, போது மூன்றாம் தரப்பு ஆய்வில், இஸ்டியோவின் வால் தாமதமானது லிங்கெர்டை விட 100 மடங்கு அதிகமாக இருந்த சூழ்நிலைகளையும், இஸ்டியோ முழுமையாக வேலை செய்வதை நிறுத்தும் போது லிங்கர்ட் தொடர்ந்து வெற்றிகரமாகச் செயல்படும் வள-பட்டினிச் சூழ்நிலைகளையும் ஆராய்ச்சியாளர்கள் கண்டறிந்தனர்.)
இது ஏன் நடந்தது என்பது பற்றிய எனது கோட்பாடுகளை ஒதுக்கி வைத்துவிட்டு, கூகுளின் பங்கேற்பால் சர்வீஸ் மெஷைச் சுற்றியுள்ள பெரும் உற்சாகம் விளக்கப்படுகிறது என்று நான் நம்புகிறேன். அதாவது, பின்வரும் மூன்று காரணிகளின் கலவை:
- இஸ்டியோவின் கூகுளின் ஊடுருவும் விளம்பரம்;
- திட்டத்திற்கு தொடர்புடைய மறுப்பு, விமர்சன அணுகுமுறை;
- குபெர்னெட்டஸின் பிரபலத்தின் சமீபத்திய விண்கல் உயர்வு, அதன் நினைவுகள் இன்னும் புதியவை.
இந்தக் காரணிகள் ஒன்றிணைந்து, ஒரு மயக்கமான, ஆக்ஸிஜன் இல்லாத சூழலை உருவாக்குகின்றன, இதில் பகுத்தறிவுத் தீர்ப்புக்கான திறன் பலவீனமடைகிறது, மேலும் வித்தியாசமான வகை மட்டுமே உள்ளது. .
லிங்கர்டின் பார்வையில், இது... நான் ஒரு கலவையான ஆசீர்வாதமாக விவரிக்கிறேன். அதாவது, 2016 இல் லிங்கர்ட் முதன்முதலில் தொடங்கியபோது இல்லாத வகையில் சர்வீஸ் மெஷ் பிரதான நீரோட்டத்தில் நுழைந்திருப்பது மிகவும் மகிழ்ச்சி அளிக்கிறது மற்றும் திட்டத்தில் மக்கள் கவனம் செலுத்துவது மிகவும் கடினமாக இருந்தது. இப்போது அந்த பிரச்சனை இல்லை! ஆனால் மோசமான செய்தி என்னவென்றால், சேவை மெஷ் நிலப்பரப்பு இன்று மிகவும் குழப்பமாக உள்ளது, உண்மையில் எந்தத் திட்டங்கள் சேவை மெஷ் வகையைச் சேர்ந்தவை என்பதைப் புரிந்துகொள்வது கிட்டத்தட்ட சாத்தியமற்றது (குறிப்பிட்ட பயன்பாட்டு வழக்குக்கு எது மிகவும் பொருத்தமானது என்பதைப் புரிந்து கொள்ளட்டும்). இது நிச்சயமாக அனைவருக்கும் ஒரு டீல் பிரேக்கராகும் (மற்றும் லிங்கர்டை விட இஸ்டியோ அல்லது வேறு திட்டம் மிகவும் பொருத்தமானதாக இருக்கும் சில சந்தர்ப்பங்கள் உள்ளன, ஏனெனில் பிந்தையது இன்னும் உலகளாவிய தீர்வாக இல்லை).
லிங்கர்டின் தரப்பில், சத்தத்தை புறக்கணிப்பது, உண்மையான சமூகப் பிரச்சனைகளைத் தீர்ப்பதில் தொடர்ந்து கவனம் செலுத்துவது, மற்றும் மிகைப்படுத்தல் குறையும் வரை காத்திருப்பதே எங்கள் உத்தி. இறுதியில், பரபரப்பானது தணிந்து, நிதானமாகத் தொடரலாம்.
இதற்கிடையில், நாம் அனைவரும் கொஞ்சம் பொறுமையாக இருக்க வேண்டும்.
ஒரு பணிவான மென்பொருள் பொறியாளரான எனக்கு சேவை மெஷ் பயனுள்ளதாக இருக்குமா?
இந்த கேள்விக்கு பதிலளிக்க பின்வரும் கேள்வித்தாள் உங்களுக்கு உதவும்:
நீங்கள் வணிக தர்க்கத்தை செயல்படுத்துவதில் மட்டுமே ஈடுபட்டுள்ளீர்களா? இந்த வழக்கில், சேவை மெஷ் உங்களுக்கு பயனுள்ளதாக இருக்காது. அதாவது, நிச்சயமாக, நீங்கள் அதில் ஆர்வமாக இருக்கலாம், ஆனால் சேவை கண்ணி உங்கள் சூழலில் நேரடியாக எதையும் பாதிக்கக்கூடாது. நீங்கள் செய்ய வேண்டிய ஊதியத்தில் தொடர்ந்து பணியாற்றுங்கள்.
Kubernetes ஐப் பயன்படுத்தும் நிறுவனத்தில் இயங்குதளத்தை ஆதரிக்கிறீர்களா? ஆம், இந்த விஷயத்தில் உங்களுக்கு ஒரு சேவை மெஷ் தேவை (நிச்சயமாக, நீங்கள் ஒரு மோனோலித் அல்லது பேட்ச் செயலாக்கத்தை இயக்க K8s ஐப் பயன்படுத்தினால் தவிர - ஆனால் உங்களுக்கு ஏன் K8s தேவை என்று நான் கேட்க விரும்புகிறேன்). வெவ்வேறு நபர்களால் எழுதப்பட்ட பல மைக்ரோ சர்வீஸ்களுடன் நீங்கள் முடிவடையும். அவை அனைத்தும் ஒன்றோடொன்று தொடர்பு கொள்கின்றன மற்றும் இயக்க நேர சார்புகளின் சிக்கலுடன் பிணைக்கப்பட்டுள்ளன, மேலும் அனைத்தையும் சமாளிக்க நீங்கள் ஒரு வழியைக் கண்டுபிடிக்க வேண்டும். குபெர்னெட்ஸைப் பயன்படுத்துவது "உனக்காக" ஒரு சேவை வலையைத் தேர்வுசெய்ய உங்களை அனுமதிக்கிறது. இதைச் செய்ய, அவர்களின் திறன்கள் மற்றும் அம்சங்களைப் பற்றி உங்களைப் பழக்கப்படுத்திக் கொள்ளுங்கள் மற்றும் கிடைக்கக்கூடிய திட்டங்கள் ஏதேனும் உங்களுக்கு ஏற்றதா என்ற கேள்விக்கு பதிலளிக்கவும் (உங்கள் ஆராய்ச்சியை லிங்கர்டுடன் தொடங்க பரிந்துரைக்கிறேன்).
நீங்கள் Kubernetes ஐப் பயன்படுத்தாத ஆனால் மைக்ரோ சர்வீஸ்களைப் பயன்படுத்தும் ஒரு நிறுவனத்தில் இயங்குதள நிறுவனமா? இந்த வழக்கில், ஒரு சேவை மெஷ் உங்களுக்கு பயனுள்ளதாக இருக்கும், ஆனால் அதன் பயன்பாடு அற்பமானது அல்ல. ஆம் உன்னால் முடியும் பின்பற்று ஒரு சில ப்ராக்ஸிகளை வைப்பதன் மூலம் பணி சேவை மெஷ், ஆனால் குபெர்னெட்ஸின் முக்கிய நன்மை வரிசைப்படுத்தல் மாதிரி: இந்த ப்ராக்ஸிகளை கைமுறையாக பராமரிக்க அதிக நேரம், முயற்சி மற்றும் செலவு தேவைப்படும்.
மோனோலித்களுடன் பணிபுரியும் நிறுவனத்தில் இயங்குதளத்திற்கு நீங்கள் பொறுப்பா? இந்த வழக்கில், உங்களுக்கு சேவை மெஷ் தேவையில்லை. நீங்கள் நன்கு வரையறுக்கப்பட்ட மற்றும் அரிதாகவே மாறிவரும் தொடர்பு முறைகளைக் கொண்ட மோனோலித்களுடன் (அல்லது மோனோலித்களின் சேகரிப்புகள் கூட) பணிபுரிந்தால், சேவை மெஷ் உங்களுக்கு வழங்குவதற்குச் சிறிதும் இல்லை. எனவே நீங்கள் அதை புறக்கணித்து, கெட்ட கனவு போல் மறைந்துவிடும் என்று நம்பலாம்...
முடிவுக்கு
அநேகமாக, சேவை மெஷ் இன்னும் "உலகின் மிகவும் விளம்பரப்படுத்தப்பட்ட தொழில்நுட்பம்" என்று அழைக்கப்படக்கூடாது - இந்த சந்தேகத்திற்குரிய மரியாதை ஒருவேளை பிட்காயின் அல்லது AI க்கு சொந்தமானது. அவள் அநேகமாக முதல் ஐந்து இடங்களில் இருக்கலாம். ஆனால் சத்தத்தின் அடுக்குகளை நீங்கள் வெட்டினால், குபெர்னெட்டஸில் பயன்பாடுகளை உருவாக்குபவர்களுக்கு சேவை மெஷ் உண்மையான நன்மைகளைத் தருகிறது என்பது தெளிவாகிறது.
நீங்கள் Linkerd -ஐ Kubernetes க்ளஸ்டரில் (அல்லது மடிக்கணினியில் Minikube) நிறுவி முயற்சி செய்ய விரும்புகிறேன். , மற்றும் நான் என்ன பேசுகிறேன் என்பதை நீங்களே பார்க்கலாம்.
FAQ
— சேவை கண்ணியை நான் புறக்கணித்தால், அது மறைந்துவிடுமா?
- நான் உங்களை ஏமாற்ற வேண்டும்: சேவை மெஷ் நீண்ட காலமாக எங்களுடன் உள்ளது.
- ஆனால் நான் சேவை மெஷ் பயன்படுத்த விரும்பவில்லை!
- சரி, அது தேவையில்லை! குறைந்தபட்சம் அதன் அடிப்படைகளை நீங்கள் அறிந்து கொள்ள வேண்டுமா என்பதைப் புரிந்துகொள்ள மேலே உள்ள எனது கேள்வித்தாளைப் படிக்கவும்.
— இது புதிய சாஸுடன் கூடிய நல்ல பழைய ESB/மிடில்வேர் இல்லையா?
- சர்வீஸ் மெஷ் செயல்பாட்டு தர்க்கத்தை கையாள்கிறது, சொற்பொருள் அல்ல. நிறுவன சேவை பேருந்து () இந்த பிரிவை பராமரிப்பது, சேவை மெஷ் அதே விதியை தவிர்க்க உதவுகிறது.
— API நுழைவாயில்களிலிருந்து ஒரு சேவை மெஷ் எவ்வாறு வேறுபடுகிறது?
- இந்த தலைப்பில் ஒரு மில்லியன் கட்டுரைகள் உள்ளன. கூகுள் செய்து பாருங்கள்.
— தூதுவர் ஒரு சேவை கண்ணி?
- இல்லை, என்வாய் ஒரு சேவை மெஷ் அல்ல, இது ஒரு ப்ராக்ஸி சர்வர். ஒரு சேவை கண்ணியை ஒழுங்கமைக்க இது பயன்படுத்தப்படலாம் (மேலும் பல - இது ஒரு பொது நோக்கத்திற்கான ப்ராக்ஸி ஆகும்). ஆனால் அது ஒரு சேவை கண்ணி அல்ல.
— Network Service Mesh என்பது சேவை வலையா?
- இல்லை. பெயர் இருந்தாலும், இது ஒரு சேவை மெஷ் அல்ல (மார்கெட்டிங் அற்புதங்களை நீங்கள் எப்படி விரும்புகிறீர்கள்?).
— எனது செய்தி வரிசை அடிப்படையிலான எதிர்வினை ஒத்திசைவற்ற அமைப்பிற்கு சேவை மெஷ் உதவுமா?
- இல்லை, சேவை மெஷ் உங்களுக்கு உதவாது.
— நான் எந்த சேவை மெஷ் பயன்படுத்த வேண்டும்?
- , மூளை இல்லை.
- கட்டுரை சலிக்கிறது! / ஆசிரியர் வரவேற்கப்படுகிறார்!
— தயவு செய்து அதற்கான இணைப்பை உங்கள் நண்பர்கள் அனைவருடனும் பகிர்ந்து கொள்ளுங்கள், அதனால் அவர்கள் அதைப் பார்க்க முடியும்!
ஒப்புதல்கள்
தலைப்பிலிருந்து நீங்கள் யூகித்திருப்பதைப் போல, இந்த கட்டுரை ஜே கிரெப்ஸின் அற்புதமான கட்டுரையால் ஈர்க்கப்பட்டது "" பத்து வருடங்களுக்கு முன்பு நான் ஜெய்யை லிங்க்ட் இன்ல் பேட்டி எடுத்தபோது சந்தித்தேன், அன்றிலிருந்து அவர் எனக்கு ஒரு உத்வேகமாக இருந்து வருகிறார்.
நான் என்னை ஒரு "Linkerd டெவலப்பர்" என்று அழைக்க விரும்புகிறேன், உண்மையில் நான் ஒரு திட்டத்தில் README.md கோப்பைப் பராமரிப்பவன். Linkerd இன்று வேலை செய்கிறது , , மக்கள், மற்றும் இந்த திட்டம் ஒரு அற்புதமான பங்களிப்பாளர்கள் மற்றும் பயனர்களின் பங்கேற்பு இல்லாமல் நடந்திருக்காது.
இறுதியாக, லிங்கர்டை உருவாக்கியவருக்கு ஒரு சிறப்பு நன்றி, (பிரைமஸ் இன்டர் பரேஸ்), பல வருடங்களுக்கு முன்பு என்னுடன் சேர்ந்து, சர்வீஸ் மெஷ் மூலம் இந்த வம்புகளில் தலைகுனிந்தார்.
மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «";
- «";
- «".
ஆதாரம்: www.habr.com