செப்டம்பர் 19 மாஸ்கோவில் முதல் கருப்பொருள் சந்திப்பு HUG (ஹைலோடு++ பயனர் குழு), இது மைக்ரோ சர்வீஸுக்கு அர்ப்பணிக்கப்பட்டது. “ஆப்பரேட்டிங் மைக்ரோ சர்வீசஸ்: சைஸ் மேட்டர்ஸ், குபர்னெட்ஸ் இருந்தாலும்” என்ற விளக்கக்காட்சி இருந்தது, அதில் மைக்ரோ சர்வீஸ் ஆர்கிடெக்சருடன் ப்ராஜெக்ட்களை இயக்குவதில் ஃப்ளான்ட்டின் விரிவான அனுபவத்தைப் பகிர்ந்து கொண்டோம். முதலாவதாக, தங்கள் தற்போதைய அல்லது எதிர்கால திட்டத்தில் இந்த அணுகுமுறையைப் பயன்படுத்துவதைப் பற்றி சிந்திக்கும் அனைத்து டெவலப்பர்களுக்கும் இது பயனுள்ளதாக இருக்கும்.
அறிமுகப்படுத்துகிறது (50 நிமிடங்கள், கட்டுரையை விட அதிக தகவல்), அத்துடன் உரை வடிவத்தில் அதிலிருந்து முக்கிய சாறு.
குறிப்பு: இந்த இடுகையின் முடிவில் வீடியோ மற்றும் விளக்கக்காட்சியும் உள்ளது.
அறிமுகம்
பொதுவாக ஒரு நல்ல கதைக்கு ஆரம்பம், முக்கிய சதி மற்றும் தீர்மானம் இருக்கும். இந்த அறிக்கை ஒரு முன்னுரை போன்றது, மேலும் அது ஒரு சோகமானது. மைக்ரோ சர்வீஸ்கள் பற்றிய வெளியாரின் பார்வையை இது வழங்குகிறது என்பதையும் கவனத்தில் கொள்ள வேண்டும். சுரண்டல்.
நான் இந்த வரைபடத்துடன் தொடங்குகிறேன், அதன் ஆசிரியர் (2015 இல்) மார்ட்டின் ஃபோலர்:
ஒரு குறிப்பிட்ட மதிப்பை அடையும் ஒற்றைக்கல் பயன்பாட்டின் விஷயத்தில், உற்பத்தித்திறன் எவ்வாறு குறையத் தொடங்குகிறது என்பதை இது காட்டுகிறது. மைக்ரோ சர்வீஸ்கள் வேறுபட்டவை, அவற்றுடன் ஆரம்ப உற்பத்தித்திறன் குறைவாக உள்ளது, ஆனால் சிக்கலானது அதிகரிக்கும் போது, செயல்திறனில் ஏற்படும் சிதைவு அவர்களுக்கு அவ்வளவு கவனிக்கப்படாது.
குபெர்னெட்ஸைப் பயன்படுத்துவதற்கு இந்த வரைபடத்தில் சேர்க்கிறேன்:
மைக்ரோ சர்வீசஸ் கொண்ட பயன்பாடு ஏன் சிறந்தது? ஏனெனில் அத்தகைய கட்டிடக்கலை கட்டிடக்கலைக்கான தீவிர தேவைகளை முன்வைக்கிறது, இது குபெர்னெட்டஸின் திறன்களால் முழுமையாக மூடப்பட்டுள்ளது. மறுபுறம், இந்த செயல்பாடுகளில் சில ஒரு ஒற்றைப்பாதைக்கு பயனுள்ளதாக இருக்கும், குறிப்பாக இன்று வழக்கமான ஒற்றைக்கல் சரியாக ஒரு ஒற்றைக்கல் அல்ல (விவரங்கள் பின்னர் அறிக்கையில் இருக்கும்).
நீங்கள் பார்க்க முடியும் என, இறுதி வரைபடம் (குபெர்னெட்ஸுடன் உள்ள உள்கட்டமைப்பில் மோனோலிதிக் மற்றும் மைக்ரோ சர்வீஸ் பயன்பாடுகள் இரண்டும் இருக்கும்போது) அசல் ஒன்றிலிருந்து மிகவும் வித்தியாசமாக இல்லை. அடுத்து Kubernetes ஐப் பயன்படுத்தி இயக்கப்படும் பயன்பாடுகளைப் பற்றி பேசுவோம்.
பயனுள்ள மற்றும் தீங்கு விளைவிக்கும் மைக்ரோ சர்வீஸ்கள்
இங்கே முக்கிய யோசனை:
என்ன சாதாரண மைக்ரோ சர்வீஸ் கட்டிடக்கலை? இது உங்களுக்கு உண்மையான பலன்களைக் கொண்டு வர வேண்டும், உங்கள் வேலை திறனை அதிகரிக்கும். நாம் மீண்டும் வரைபடத்திற்குச் சென்றால், அது இங்கே:
அவளை அழைத்தால் பயனுள்ள, பின்னர் வரைபடத்தின் மறுபுறம் இருக்கும் தீங்கு விளைவிக்கும் மைக்ரோ சர்வீஸ் (வேலையில் தலையிடுகிறது):
"முக்கிய யோசனைக்கு" திரும்புகிறேன்: எனது அனுபவத்தை நான் நம்ப வேண்டுமா? இந்த வருடத்தின் தொடக்கத்தில் இருந்து நான் பார்த்தேன் 85 திட்டங்கள். அவை அனைத்தும் மைக்ரோ சர்வீஸ்கள் அல்ல (அவற்றில் மூன்றில் ஒரு பங்கு முதல் பாதி வரை அத்தகைய கட்டிடக்கலை இருந்தது), ஆனால் இது இன்னும் பெரிய எண்ணிக்கையில் உள்ளது. அவுட்சோர்ஸர்களாகிய நாங்கள் (Flant நிறுவனம்) சிறிய நிறுவனங்கள் (5 டெவலப்பர்களுடன்) மற்றும் பெரிய நிறுவனங்களில் (~500 டெவலப்பர்கள்) பல்வேறு வகையான பயன்பாடுகளை உருவாக்குவதைக் காண முடிகிறது. ஒரு கூடுதல் நன்மை என்னவென்றால், இந்த பயன்பாடுகள் பல ஆண்டுகளாக வாழ்கின்றன மற்றும் உருவாகின்றன.
மைக்ரோ சர்வீஸ் ஏன்?
மைக்ரோ சர்வீஸின் நன்மைகள் பற்றிய கேள்விக்கு உள்ளது ஏற்கனவே குறிப்பிட்டுள்ள மார்ட்டின் ஃபோலரிடமிருந்து:
- மட்டுப்படுத்தலின் தெளிவான எல்லைகள்;
- சுயாதீன வரிசைப்படுத்தல்;
- தொழில்நுட்பங்களைத் தேர்ந்தெடுக்கும் சுதந்திரம்.
நான் மென்பொருள் கட்டிடக்கலை நிபுணர்கள் மற்றும் டெவலப்பர்களிடம் நிறைய பேசினேன், அவர்களுக்கு ஏன் மைக்ரோ சர்வீஸ்கள் தேவை என்று கேட்டேன். நான் அவர்களின் எதிர்பார்ப்புகளின் பட்டியலை உருவாக்கினேன். என்ன நடந்தது என்பது இங்கே:
"உணர்வுகளில்" சில புள்ளிகளை விவரித்தால்:
- தொகுதிகளின் தெளிவான எல்லைகள்: இங்கே எங்களிடம் ஒரு பயங்கரமான மோனோலித் உள்ளது, இப்போது எல்லாமே Git களஞ்சியங்களில் அழகாக ஏற்பாடு செய்யப்படும், அதில் எல்லாம் "அலமாரிகளில்" உள்ளது, சூடான மற்றும் மென்மையானது கலக்கப்படவில்லை;
- வரிசைப்படுத்தல் சுதந்திரம்: நாங்கள் சுயாதீனமாக சேவைகளை உருவாக்க முடியும், இதனால் வளர்ச்சி வேகமாகச் செல்லும் (புதிய அம்சங்களை இணையாக வெளியிடவும்);
- வளர்ச்சியின் சுதந்திரம்: இந்த மைக்ரோ சர்வீஸை ஒரு குழு/டெவலப்பருக்கு வழங்கலாம், மற்றொன்றுக்கு, நாம் வேகமாக உருவாக்க முடியும்;
- боஅதிக நம்பகத்தன்மை: பகுதியளவு சிதைவு ஏற்பட்டால் (20 வீழ்ச்சிகளில் ஒரு மைக்ரோ சர்வீஸ்), ஒரே ஒரு பொத்தான் வேலை செய்வதை நிறுத்தும், மேலும் ஒட்டுமொத்த அமைப்பும் தொடர்ந்து செயல்படும்.
வழக்கமான (தீங்கு விளைவிக்கும்) மைக்ரோ சர்வீஸ் கட்டமைப்பு
யதார்த்தம் ஏன் நாம் எதிர்பார்ப்பது அல்ல என்பதை விளக்க, நான் முன்வைக்கிறேன் கூட்டு பல்வேறு திட்டங்களின் அனுபவத்தின் அடிப்படையில் மைக்ரோ சர்வீஸ் கட்டமைப்பின் படம்.
அமேசான் அல்லது குறைந்தபட்சம் OZON உடன் போட்டியிடும் ஒரு சுருக்கமான ஆன்லைன் ஸ்டோர் ஒரு எடுத்துக்காட்டு. அதன் மைக்ரோ சர்வீஸ் கட்டமைப்பு இதுபோல் தெரிகிறது:
பல காரணங்களுக்காக, இந்த மைக்ரோ சர்வீஸ்கள் வெவ்வேறு தளங்களில் எழுதப்பட்டுள்ளன:
ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும் தன்னாட்சி இருக்க வேண்டும் என்பதால், அவர்களில் பலருக்கு அவற்றின் சொந்த தரவுத்தளம் மற்றும் தற்காலிக சேமிப்பு தேவை. இறுதி கட்டிடக்கலை பின்வருமாறு:
அதன் விளைவுகள் என்ன?
ஃபோலருக்கும் இது உண்டு - மைக்ரோ சர்வீஸ்களைப் பயன்படுத்துவதற்கான "கட்டணம்" பற்றி:
எங்கள் எதிர்பார்ப்புகள் நிறைவேறுமா என்று பார்ப்போம்.
தொகுதிகளின் எல்லைகளை அழிக்கவும்...
ஆயினும் எத்தனை மைக்ரோ சர்வீஸ்களை நாம் சரி செய்ய வேண்டும்?மாற்றத்தை வெளியிடவா? விநியோகிக்கப்பட்ட ட்ரேசர் இல்லாமல் அனைத்தும் எவ்வாறு செயல்படுகின்றன என்பதை நாம் கண்டுபிடிக்க முடியுமா (எல்லாவற்றிற்கும் மேலாக, எந்தவொரு கோரிக்கையும் மைக்ரோ சர்வீஸில் பாதியால் செயலாக்கப்படுகிறது)?
ஒரு மாதிரி இருக்கிறது"", இங்கே அது ஒரு விநியோகிக்கப்பட்ட அழுக்கு கட்டியாக மாறியது. இதை உறுதிப்படுத்த, கோரிக்கைகள் எவ்வாறு செல்கின்றன என்பதற்கான தோராயமான எடுத்துக்காட்டு:
வரிசைப்படுத்தல் சுதந்திரம்...
தொழில்நுட்ப ரீதியாக, இது அடையப்பட்டது: நாம் ஒவ்வொரு மைக்ரோ சர்வீஸையும் தனித்தனியாக வெளியிடலாம். ஆனால் நடைமுறையில் அது எப்போதும் உருளும் என்பதை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும் பல மைக்ரோ சர்வீஸ்கள், மற்றும் நாம் கணக்கில் எடுத்துக்கொள்ள வேண்டும் அவற்றின் வெளியீட்டின் வரிசை. ஒரு நல்ல வழியில், நாம் பொதுவாக சரியான வரிசையில் வெளியீட்டை வெளியிடுகிறோமா என்பதை ஒரு தனி வட்டத்தில் சோதிக்க வேண்டும்.
தொழில்நுட்பத்தை தேர்ந்தெடுக்கும் சுதந்திரம்...
அவள். சுதந்திரம் பெரும்பாலும் சட்டவிரோதத்தின் எல்லையில் உள்ளது என்பதை நினைவில் கொள்ளுங்கள். அவர்களுடன் "விளையாட" தொழில்நுட்பங்களைத் தேர்வு செய்யாதது இங்கே மிகவும் முக்கியமானது.
வளர்ச்சியின் சுதந்திரம்...
முழு பயன்பாட்டிற்கும் (பல கூறுகளுடன்) சோதனை வளையத்தை உருவாக்குவது எப்படி? ஆனால் நீங்கள் அதை இன்னும் புதுப்பித்த நிலையில் வைத்திருக்க வேண்டும். இவை அனைத்தும் உண்மைக்கு வழிவகுக்கிறது சோதனை சுற்றுகளின் உண்மையான எண்ணிக்கை, கொள்கையளவில் நாம் கொண்டிருக்கும், குறைந்தபட்சமாக மாறிவிடும்.
இதையெல்லாம் உள்நாட்டில் பயன்படுத்துவது எப்படி?
தனி அளவீடு...
ஆம், ஆனால் இது பயன்படுத்தப்படும் DBMS பகுதியில் வரையறுக்கப்பட்டுள்ளது. கொடுக்கப்பட்ட கட்டிடக்கலை எடுத்துக்காட்டில், கசாண்ட்ராவுக்கு சிக்கல்கள் இருக்காது, ஆனால் MySQL மற்றும் PostgreSQL ஆகியவை இருக்கும்.
Боஅதிக நம்பகத்தன்மை...
உண்மையில் ஒரு மைக்ரோ சர்வீஸின் தோல்வி முழு அமைப்பின் சரியான செயல்பாட்டை அடிக்கடி உடைப்பது மட்டுமல்லாமல், ஒரு புதிய சிக்கலும் உள்ளது: ஒவ்வொரு மைக்ரோ சர்வீஸ் தவறு-சகிப்புத்தன்மையை உருவாக்குவது மிகவும் கடினம். மைக்ரோ சர்வீஸ்கள் வெவ்வேறு தொழில்நுட்பங்களைப் பயன்படுத்துவதால் (மெம்கேச், ரெடிஸ், முதலியன), ஒவ்வொன்றிற்கும் நீங்கள் எல்லாவற்றையும் சிந்தித்து செயல்படுத்த வேண்டும், இது நிச்சயமாக சாத்தியம், ஆனால் பெரிய ஆதாரங்கள் தேவை.
சுமை அளவிடக்கூடியது...
இது மிகவும் நல்லது.
மைக்ரோ சர்வீஸின் "லேசான தன்மை"...
எங்களிடம் பெரியது மட்டுமல்ல நெட்வொர்க் மேல்நிலை (DNS க்கான கோரிக்கைகள் பெருகும், முதலியன), ஆனால் நாங்கள் தொடங்கிய பல துணை வினவல்கள் காரணமாகவும் தரவு பிரதி (ஸ்டோர் கேச்), இது குறிப்பிடத்தக்க அளவு சேமிப்பிற்கு வழிவகுத்தது.
எங்கள் எதிர்பார்ப்புகளை பூர்த்தி செய்ததன் விளைவு இங்கே:
ஆனால் அதெல்லாம் இல்லை!
ஏனெனில்:
- பெரும்பாலும் எங்களுக்கு ஒரு செய்தி பஸ் தேவைப்படும்.
- சரியான நேரத்தில் ஒரு நிலையான காப்புப்பிரதியை எவ்வாறு உருவாக்குவது? ஒன்றே ஒன்று உண்மையான இதற்கான போக்குவரத்தை முடக்குவதே விருப்பம். ஆனால் தயாரிப்பில் இதை எப்படி செய்வது?
- நாங்கள் பல பிராந்தியங்களை ஆதரிப்பது பற்றி பேசுகிறோம் என்றால், அவை ஒவ்வொன்றிலும் நிலைத்தன்மையை ஒழுங்கமைப்பது மிகவும் உழைப்பு மிகுந்த பணியாகும்.
- மையப்படுத்தப்பட்ட மாற்றங்களைச் செய்வதில் சிக்கல் எழுகிறது. எடுத்துக்காட்டாக, நாம் PHP பதிப்பைப் புதுப்பிக்க வேண்டும் என்றால், ஒவ்வொரு களஞ்சியத்திலும் நாம் ஈடுபட வேண்டும் (மற்றும் அவற்றில் டஜன் கணக்கானவை உள்ளன).
- செயல்பாட்டின் சிக்கலான வளர்ச்சியானது, செயலற்றது, அதிவேகமானது.
இதையெல்லாம் என்ன செய்வது?
ஒரு மோனோலிதிக் பயன்பாட்டுடன் தொடங்கவும். ஃபோலரின் அனுபவம் ஏறக்குறைய அனைத்து வெற்றிகரமான மைக்ரோ சர்வீஸ் அப்ளிகேஷன்களும் ஒரு மோனோலித் ஆகத் தொடங்கி மிகப் பெரியதாகி பின்னர் உடைந்தன. அதே நேரத்தில், ஆரம்பத்திலிருந்தே மைக்ரோ சர்வீஸாக கட்டமைக்கப்பட்ட அனைத்து அமைப்புகளும் விரைவில் அல்லது பின்னர் கடுமையான சிக்கல்களை சந்தித்தன.
மற்றொரு மதிப்புமிக்க சிந்தனை என்னவென்றால், மைக்ரோ சர்வீஸ் கட்டமைப்பைக் கொண்ட திட்டம் வெற்றிகரமாக இருக்க, நீங்கள் நன்றாக அறிந்திருக்க வேண்டும் மற்றும் பொருள் பகுதி மற்றும் மைக்ரோ சர்வீஸ்களை எவ்வாறு உருவாக்குவது. ஒரு பாடப் பகுதியைக் கற்றுக்கொள்வதற்கான சிறந்த வழி ஒரு ஒற்றைக்கல்லை உருவாக்குவதாகும்.
ஆனால் நாம் ஏற்கனவே இந்த நிலையில் இருந்தால் என்ன செய்வது?
எந்தவொரு பிரச்சினையையும் தீர்ப்பதற்கான முதல் படி, அதை ஏற்றுக்கொள்வதும், அது ஒரு பிரச்சனை என்பதை புரிந்துகொள்வதும், நாம் இனி கஷ்டப்பட விரும்பவில்லை.
வளர்ந்த மோனோலித்தின் விஷயத்தில் (அதற்கான கூடுதல் ஆதாரங்களை வாங்குவதற்கான வாய்ப்பை நாங்கள் இழந்துவிட்டால்), நாங்கள் அதை வெட்டுகிறோம், இந்த விஷயத்தில் எதிர் கதை மாறிவிடும்: அதிகப்படியான மைக்ரோ சர்வீஸ்கள் இனி உதவாது, ஆனால் தடையாக இருக்கும்போது - அதிகப்படியானவற்றை வெட்டி பெரிதாக்கவும்!
எடுத்துக்காட்டாக, மேலே விவாதிக்கப்பட்ட கூட்டுப் படத்திற்கு...
மிகவும் சந்தேகத்திற்குரிய மைக்ரோ சர்வீஸ்களை அகற்றவும்:
முன்னோக்கி உருவாக்கத்திற்கு பொறுப்பான அனைத்து மைக்ரோ சர்வீஸ்களையும் இணைக்கவும்:
... ஒரு மைக்ரோ சர்வீஸ், ஒன்றில் எழுதப்பட்ட (நவீன மற்றும் இயல்பான, நீங்களே நினைப்பது போல்) மொழி/கட்டமைப்பு:
இது ஒரு ORM (ஒரு DBMS) மற்றும் முதலில் இரண்டு பயன்பாடுகளைக் கொண்டிருக்கும்:
... ஆனால் பொதுவாக நீங்கள் பலவற்றை அங்கு மாற்றலாம், பின்வரும் முடிவைப் பெறலாம்:
மேலும், குபெர்னெட்டஸில் இவை அனைத்தையும் தனித்தனி நிகழ்வுகளில் இயக்குகிறோம், அதாவது சுமைகளை அளவிடலாம் மற்றும் அவற்றை தனித்தனியாக அளவிடலாம்.
சுருக்க
பெரிய படத்தைப் பாருங்கள். பெரும்பாலும், மைக்ரோ சர்வீஸில் உள்ள இந்த சிக்கல்கள் அனைத்தும் யாரோ ஒருவர் தங்கள் பணியை எடுத்ததால் எழுகின்றன, ஆனால் "மைக்ரோ சர்வீஸுடன் விளையாட" விரும்பினர்.
"மைக்ரோ சர்வீசஸ்" என்ற வார்த்தையில் "மைக்ரோ" பகுதி தேவையற்றது.. அவை ஒரு பெரிய ஒற்றைப்பாதையை விட சிறியதாக இருப்பதால் மட்டுமே அவை "மைக்ரோ" ஆகும். ஆனால் அவற்றை சிறியதாக நினைக்க வேண்டாம்.
இறுதிச் சிந்தனைக்கு, அசல் விளக்கப்படத்திற்குத் திரும்புவோம்:
அதில் எழுதப்பட்ட குறிப்பு (மேல் வலது) என்று கொதிக்கிறது உங்கள் திட்டத்தை உருவாக்கும் குழுவின் திறன்கள் எப்போதும் முதன்மையானவை — மைக்ரோ சர்வீஸ் மற்றும் மோனோலித் ஆகியவற்றுக்கு இடையே உங்கள் விருப்பத்தில் அவை முக்கிய பங்கு வகிக்கும். அணிக்கு போதுமான திறன்கள் இல்லை, ஆனால் அது மைக்ரோ சர்வீஸ் செய்யத் தொடங்கினால், கதை நிச்சயமாக ஆபத்தானது.
வீடியோக்கள் மற்றும் ஸ்லைடுகள்
பேச்சின் வீடியோ (~ 50 நிமிடங்கள்; துரதிர்ஷ்டவசமாக, இது பார்வையாளர்களின் எண்ணற்ற உணர்ச்சிகளை வெளிப்படுத்தவில்லை, இது அறிக்கையின் மனநிலையை பெரும்பாலும் தீர்மானித்தது, ஆனால் அது அப்படித்தான்):
அறிக்கையின் விளக்கக்காட்சி:
சோசலிஸ்ட் கட்சி
எங்கள் வலைப்பதிவில் உள்ள மற்ற அறிக்கைகள்:
- «» (Dmitry Stolyarov; மே 28, 2018 RootConf இல்);
- «» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 7, 2017 ஹைலோட்++ இல்);
- «» (Dmitry Stolyarov; ஜூன் 6, 2017 RootConf இல்);
- «» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 8, 2016 ஹைலோட்++ இல்);
- «» (Dmitry Stolyarov; மே 31, 2016 RootConf இல்).
பின்வரும் வெளியீடுகளிலும் நீங்கள் ஆர்வமாக இருக்கலாம்:
- «";
- «";
- «".
ஆதாரம்: www.habr.com