வணக்கம்! என் பெயர் வாடிம் மேடிசன், நான் Avito சிஸ்டம் பிளாட்ஃபார்ம் வளர்ச்சிக்கு தலைமை தாங்குகிறேன். நிறுவனத்தில் நாங்கள் எப்படி ஒரு ஒற்றைக் கட்டிடக்கலையிலிருந்து மைக்ரோ சர்வீஸ் ஒன்றிற்கு மாறுகிறோம் என்பது ஒன்றுக்கு மேற்பட்ட முறை கூறப்பட்டுள்ளது. மைக்ரோ சர்வீஸ்களில் இருந்து அதிகப் பலனைப் பெறுவதற்கும், அவற்றில் தொலைந்து போவதைத் தடுப்பதற்கும் எங்கள் உள்கட்டமைப்பை எவ்வாறு மாற்றியுள்ளோம் என்பதைப் பகிர்ந்துகொள்ள வேண்டிய நேரம் இது. PaaS நமக்கு இங்கே எவ்வாறு உதவுகிறது, நாங்கள் எவ்வாறு வரிசைப்படுத்தலை எளிதாக்கினோம் மற்றும் மைக்ரோ சர்வீஸ் உருவாக்கத்தை ஒரே கிளிக்கில் குறைத்தோம் - படிக்கவும். நான் கீழே எழுதும் அனைத்தும் Avito இல் முழுமையாக செயல்படுத்தப்படவில்லை, அவற்றில் சில எங்கள் தளத்தை எவ்வாறு உருவாக்குகிறோம்.

(மேலும் இந்தக் கட்டுரையின் முடிவில், மைக்ரோ சர்வீஸ் கட்டிடக்கலை நிபுணர் கிறிஸ் ரிச்சர்ட்சனின் மூன்று நாள் கருத்தரங்கில் கலந்துகொள்ளும் வாய்ப்பைப் பற்றி பேசுகிறேன்).

நாங்கள் மைக்ரோ சர்வீஸுக்கு எப்படி வந்தோம்

Avito உலகின் மிகப்பெரிய வகைப்படுத்தப்பட்ட தளங்களில் ஒன்றாகும்; ஒரு நாளைக்கு 15 மில்லியனுக்கும் அதிகமான புதிய விளம்பரங்கள் வெளியிடப்படுகின்றன. எங்கள் பின்தளத்தில் வினாடிக்கு 20 ஆயிரத்துக்கும் மேற்பட்ட கோரிக்கைகள் ஏற்கப்படுகின்றன. எங்களிடம் தற்போது பல நூறு மைக்ரோ சர்வீஸ்கள் உள்ளன.

நாங்கள் பல ஆண்டுகளாக மைக்ரோ சர்வீஸ் கட்டமைப்பை உருவாக்கி வருகிறோம். எப்படி சரியாக - எங்கள் சகாக்கள் விரிவாக கூறினார் RIT++ 2017 இல் உள்ள எங்கள் பிரிவில். CodeFest 2017 இல் (பார்க்க. видео), செர்ஜி ஓர்லோவ் மற்றும் மிகைல் ப்ரோகோப்சுக் ஆகியோர் மைக்ரோ சர்வீஸுக்கு ஏன் மாற வேண்டும் என்பதையும், குபெர்னெட்டஸ் இங்கு என்ன பங்கு வகித்தார் என்பதையும் விரிவாக விளக்கினர். சரி, இப்போது நாம் அத்தகைய கட்டிடக்கலையில் உள்ளார்ந்த அளவிடுதல் செலவுகளைக் குறைக்க எல்லாவற்றையும் செய்கிறோம்.

ஆரம்பத்தில், மைக்ரோ சர்வீஸ்களை உருவாக்கவும் தொடங்கவும் உதவும் ஒரு சுற்றுச்சூழல் அமைப்பை நாங்கள் உருவாக்கவில்லை. அவர்கள் விவேகமான ஓப்பன் சோர்ஸ் தீர்வுகளைச் சேகரித்து, அவற்றை வீட்டிலேயே அறிமுகப்படுத்தி, அவற்றைச் சமாளிக்க டெவலப்பரை அழைத்தனர். இதன் விளைவாக, அவர் ஒரு டஜன் இடங்களுக்குச் சென்றார் (டாஷ்போர்டுகள், உள் சேவைகள்), அதன் பிறகு, குறியீட்டை பழைய வழியில், ஒரு ஒற்றைப்பாதையில் வெட்டுவதற்கான விருப்பத்தில் அவர் வலுவாகிவிட்டார். கீழே உள்ள வரைபடங்களில் உள்ள பச்சை நிறம் டெவலப்பர் தனது சொந்த கைகளால் ஒரு வழி அல்லது வேறு என்ன செய்கிறார் என்பதைக் குறிக்கிறது, மேலும் மஞ்சள் நிறம் ஆட்டோமேஷனைக் குறிக்கிறது.

இப்போது PaaS CLI பயன்பாட்டில், ஒரு கட்டளையுடன் ஒரு புதிய சேவை உருவாக்கப்பட்டது, மேலும் ஒரு புதிய தரவுத்தளமானது மேலும் இரண்டுடன் சேர்க்கப்பட்டு, ஸ்டேஜில் பயன்படுத்தப்படுகிறது.

"மைக்ரோ சர்வீஸ் துண்டாடுதல்" சகாப்தத்தை எவ்வாறு சமாளிப்பது

ஒரு ஒற்றைக் கட்டிடக்கலை மூலம், தயாரிப்பில் ஏற்படும் மாற்றங்களின் நிலைத்தன்மைக்காக, டெவலப்பர்கள் தங்கள் அண்டை நாடுகளுடன் என்ன நடக்கிறது என்பதைக் கண்டுபிடிக்க வேண்டிய கட்டாயம் ஏற்பட்டது. புதிய கட்டிடக்கலையில் பணிபுரியும் போது, ​​சேவை சூழல்கள் ஒன்றுக்கொன்று சார்ந்திருக்காது.

கூடுதலாக, மைக்ரோ சர்வீஸ் கட்டிடக்கலை பயனுள்ளதாக இருக்க, பல செயல்முறைகள் நிறுவப்பட வேண்டும், அதாவது:

• பதிவு செய்தல்;
• கோரிக்கை டிரேசிங் (ஜெய்கர்);
• பிழை திரட்டல் (சென்ட்ரி);
• நிலைகள், செய்திகள், குபெர்னெட்டஸின் நிகழ்வுகள் (நிகழ்வு ஸ்ட்ரீம் செயலாக்கம்);
• பந்தய வரம்பு / சர்க்யூட் பிரேக்கர் (நீங்கள் Hystrix ஐப் பயன்படுத்தலாம்);
• சேவை இணைப்பு கட்டுப்பாடு (நாங்கள் Netramesh பயன்படுத்துகிறோம்);
• கண்காணிப்பு (கிராஃபனா);
• சட்டசபை (டீம்சிட்டி);
• தொடர்பு மற்றும் அறிவிப்பு (ஸ்லாக், மின்னஞ்சல்);
• பணி கண்காணிப்பு; (ஜிரா)
• ஆவணங்கள் தயாரித்தல்.

சிஸ்டம் அதன் ஒருமைப்பாட்டை இழக்காமல் இருப்பதையும், அது அளவிடப்படும்போது பயனுள்ளதாக இருப்பதையும் உறுதிசெய்ய, Avitoவில் மைக்ரோ சர்வீசஸ் அமைப்பை நாங்கள் மறுபரிசீலனை செய்தோம்.

மைக்ரோ சர்வீஸ்களை நாங்கள் எப்படி நிர்வகிக்கிறோம்

பல Avito மைக்ரோ சர்வீஸ்கள் மத்தியில் ஒரு ஒருங்கிணைந்த "கட்சிக் கொள்கையை" செயல்படுத்த பின்வரும் உதவிக்குறிப்புகள்:

• உள்கட்டமைப்பை அடுக்குகளாகப் பிரித்தல்;
• ஒரு சேவையாக இயங்குதளம் (PaaS) கருத்து;
• மைக்ரோ சர்வீஸ் மூலம் நடக்கும் அனைத்தையும் கண்காணித்தல்.

உள்கட்டமைப்பு சுருக்க அடுக்குகள் மூன்று அடுக்குகளை உள்ளடக்கியது. மேலிருந்து கீழாகச் செல்வோம்.

A. மேல் - சேவை கண்ணி. முதலில் நாங்கள் இஸ்டியோவை முயற்சித்தோம், ஆனால் அது பல ஆதாரங்களைப் பயன்படுத்துகிறது, இது எங்கள் தொகுதிகளுக்கு மிகவும் விலை உயர்ந்தது. எனவே, கட்டிடக்கலை குழுவில் மூத்த பொறியாளர் அலெக்சாண்டர் லுக்யான்சென்கோ தனது சொந்த தீர்வை உருவாக்கினார் - நேத்ரமேஷ் (திறந்த மூலத்தில் கிடைக்கிறது), நாங்கள் தற்போது உற்பத்தியில் பயன்படுத்துகிறோம் மற்றும் இஸ்டியோவை விட பல மடங்கு குறைவான வளங்களைப் பயன்படுத்துகிறோம் (ஆனால் இஸ்டியோ பெருமைப்படக்கூடிய அனைத்தையும் செய்யாது).
பி. நடுத்தர - ​​குபெர்னெட்ஸ். நாங்கள் மைக்ரோ சர்வீஸ்களை வரிசைப்படுத்தி இயக்குகிறோம்.
C. கீழே - வெற்று உலோகம். நாங்கள் மேகங்கள் அல்லது OpenStack போன்றவற்றைப் பயன்படுத்துவதில்லை, ஆனால் முற்றிலும் வெறும் உலோகத்தையே நம்பியுள்ளோம்.

அனைத்து அடுக்குகளும் PaaS ஆல் இணைக்கப்பட்டுள்ளன. இந்த தளம், இதையொட்டி, மூன்று பகுதிகளைக் கொண்டுள்ளது.

I. ஜெனரேட்டர்கள், CLI பயன்பாடு மூலம் கட்டுப்படுத்தப்படுகிறது. மைக்ரோ சர்வீஸை சரியான முறையில் மற்றும் குறைந்தபட்ச முயற்சியுடன் உருவாக்க டெவலப்பருக்கு உதவுவது அவள்தான்.

II. ஒருங்கிணைந்த சேகரிப்பாளர் பொதுவான டாஷ்போர்டு மூலம் அனைத்து கருவிகளின் கட்டுப்பாட்டுடன்.

III. சேமிப்பு. குறிப்பிடத்தக்க செயல்களுக்கான தூண்டுதல்களை தானாகவே அமைக்கும் திட்டமிடுபவர்களுடன் இணைக்கிறது. அத்தகைய அமைப்புக்கு நன்றி, யாரோ ஒருவர் ஜிராவில் ஒரு பணியை அமைக்க மறந்துவிட்டார் என்பதற்காக ஒரு பணி கூட தவறவிடப்படவில்லை. இதற்கு அட்லஸ் என்ற உள் கருவியைப் பயன்படுத்துகிறோம்.

Avito இல் மைக்ரோ சர்வீஸ்களை செயல்படுத்துவதும் ஒரு திட்டத்தின் படி மேற்கொள்ளப்படுகிறது, இது வளர்ச்சி மற்றும் வெளியீட்டின் ஒவ்வொரு கட்டத்திலும் அவற்றின் மீதான கட்டுப்பாட்டை எளிதாக்குகிறது.

ஒரு நிலையான மைக்ரோ சர்வீஸ் மேம்பாட்டு பைப்லைன் எவ்வாறு செயல்படுகிறது?

பொதுவாக, மைக்ரோ சர்வீஸ் உருவாக்கும் சங்கிலி இதுபோல் தெரிகிறது:

CLI-புஷ் → தொடர்ச்சியான ஒருங்கிணைப்பு → பேக் → வரிசைப்படுத்தல் → செயற்கை சோதனைகள் → கேனரி சோதனைகள் → சுருக்க சோதனை → உற்பத்தி → பராமரிப்பு.

இந்த வரிசையில் சரியாகச் செல்லலாம்.

CLI-மிகுதி

• மைக்ரோ சர்வீஸை உருவாக்குதல்.
மைக்ரோ சர்வீஸ் செய்வது எப்படி என்று ஒவ்வொரு டெவலப்பருக்கும் கற்றுக்கொடுக்க நாங்கள் நீண்ட நேரம் போராடினோம். சங்கமத்தில் விரிவான வழிமுறைகளை எழுதுவது இதில் அடங்கும். ஆனால் திட்டங்கள் மாற்றப்பட்டு கூடுதலாக வழங்கப்பட்டன. இதன் விளைவாக, பயணத்தின் தொடக்கத்தில் ஒரு இடையூறு தோன்றியது: மைக்ரோ சர்வீஸைத் தொடங்க அதிக நேரம் எடுத்தது, மேலும் அவை உருவாக்கும் போது அடிக்கடி சிக்கல்கள் எழுந்தன.

முடிவில், மைக்ரோ சர்வீஸை உருவாக்கும் போது அடிப்படை படிகளை தானியங்குபடுத்தும் எளிய CLI பயன்பாட்டை உருவாக்கினோம். உண்மையில், இது முதல் கிட் புஷ் மாற்றுகிறது. அவள் சரியாக என்ன செய்கிறாள் என்பது இங்கே.

- ஒரு டெம்ப்ளேட்டின் படி ஒரு சேவையை உருவாக்குகிறது - படிப்படியாக, "விஜார்ட்" முறையில். Avito பின்தளத்தில் முக்கிய நிரலாக்க மொழிகளுக்கான வார்ப்புருக்கள் எங்களிடம் உள்ளன: PHP, Golang மற்றும் Python.

- ஒரு நேரத்தில் ஒரு கட்டளை ஒரு குறிப்பிட்ட கணினியில் உள்ளூர் மேம்பாட்டிற்கான சூழலை வரிசைப்படுத்துகிறது - மினிகுப் தொடங்கப்பட்டது, ஹெல்ம் விளக்கப்படங்கள் தானாகவே உருவாக்கப்பட்டு உள்ளூர் குபெர்னெட்டுகளில் தொடங்கப்படும்.

- தேவையான தரவுத்தளத்தை இணைக்கிறது. டெவலப்பர் தனக்குத் தேவையான தரவுத்தளத்திற்கான அணுகலைப் பெற ஐபி, உள்நுழைவு மற்றும் கடவுச்சொல்லை அறிந்திருக்க வேண்டிய அவசியமில்லை - அது உள்நாட்டில், ஸ்டேஜில் அல்லது தயாரிப்பில் இருக்கலாம். மேலும், தரவுத்தளமானது தவறு-சகிப்புத்தன்மை உள்ளமைவு மற்றும் சமநிலையுடன் உடனடியாக பயன்படுத்தப்படுகிறது.

- இது நேரடி அசெம்பிளியை தானே செய்கிறது. ஒரு டெவலப்பர் தனது IDE மூலம் மைக்ரோ சர்வீஸில் எதையாவது சரிசெய்தார் என்று வைத்துக்கொள்வோம். பயன்பாடு கோப்பு முறைமையில் மாற்றங்களைக் காண்கிறது மற்றும் அவற்றின் அடிப்படையில், பயன்பாட்டை (கோலாங்கிற்கு) மீண்டும் உருவாக்குகிறது மற்றும் மறுதொடக்கம் செய்கிறது. PHP க்கு, கனசதுரத்திற்குள் உள்ள கோப்பகத்தை நாம் வெறுமனே முன்னோக்கி அனுப்புகிறோம், அங்கு நேரடி-ரீலோட் "தானாக" பெறப்படும்.

- தன்னியக்க சோதனைகளை உருவாக்குகிறது. வெற்றிடங்களின் வடிவத்தில், ஆனால் பயன்படுத்த மிகவும் பொருத்தமானது.

• மைக்ரோ சர்வீஸ் வரிசைப்படுத்தல்.

மைக்ரோ சர்வீஸை வரிசைப்படுத்துவது எங்களுக்கு ஒரு வேலையாக இருந்தது. பின்வருபவை தேவைப்பட்டன:

I. டோக்கர்ஃபைல்.

II. கட்டமைப்பு.
III. ஹெல்ம் விளக்கப்படம், இது சிக்கலானது மற்றும் பின்வருவனவற்றை உள்ளடக்குகிறது:

- விளக்கப்படங்கள் தங்களை;
- வார்ப்புருக்கள்;
- வெவ்வேறு சூழல்களை கணக்கில் எடுத்துக்கொண்டு குறிப்பிட்ட மதிப்புகள்.

குபெர்னெட்டஸ் மேனிஃபெஸ்டுகளை மறுவேலை செய்வதன் வலியை நாங்கள் அகற்றியுள்ளோம், எனவே அவை இப்போது தானாக உருவாக்கப்படுகின்றன. ஆனால் மிக முக்கியமாக, அவர்கள் வரிசைப்படுத்தலை வரம்பிற்கு எளிதாக்கினர். இப்போது எங்களிடம் ஒரு Dockerfile உள்ளது, மேலும் டெவலப்பர் முழு கட்டமைப்பையும் ஒரே ஒரு சிறிய app.toml கோப்பில் எழுதுகிறார்.

ஆம், app.toml இல் ஒரு நிமிடம் எதுவும் செய்ய முடியாது. சேவையின் எங்கு, எத்தனை நகல்களை (தேவ் சர்வரில், ஸ்டேஜிங்கில், உற்பத்தியில்) உயர்த்த வேண்டும் என்பதைக் குறிப்பிடுகிறோம், மேலும் அதன் சார்புகளைக் குறிப்பிடுகிறோம். [இன்ஜின்] பிளாக்கில் உள்ள கோட்டின் அளவு = "சிறியது" என்பதைக் கவனியுங்கள். குபெர்னெட்ஸ் வழியாக சேவைக்கு ஒதுக்கப்படும் வரம்பு இதுவாகும்.

பின்னர், கட்டமைப்பின் அடிப்படையில், தேவையான அனைத்து ஹெல்ம் விளக்கப்படங்களும் தானாகவே உருவாக்கப்பட்டு தரவுத்தளங்களுக்கான இணைப்புகள் உருவாக்கப்படுகின்றன.

• அடிப்படை சரிபார்ப்பு. இத்தகைய காசோலைகளும் தானியங்கி முறையில் செய்யப்படுகின்றன.
கண்காணிக்க வேண்டும்:
- ஒரு Dockerfile உள்ளதா;
— app.toml உள்ளதா;
— ஆவணங்கள் கிடைக்குமா?
- சார்பு ஒழுங்காக உள்ளதா?
- எச்சரிக்கை விதிகள் அமைக்கப்பட்டுள்ளதா.
கடைசி கட்டத்தில்: எந்த தயாரிப்பு அளவீடுகளை கண்காணிக்க வேண்டும் என்பதை சேவையின் உரிமையாளரே தீர்மானிக்கிறார்.

• ஆவணங்கள் தயாரித்தல்.
இன்னும் சிக்கல் நிறைந்த பகுதி. இது மிகவும் வெளிப்படையானதாகத் தெரிகிறது, ஆனால் அதே நேரத்தில் இது "அடிக்கடி மறந்துவிடும்" ஒரு பதிவாகும், எனவே சங்கிலியில் பாதிக்கப்படக்கூடிய இணைப்பு.
ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும் ஆவணங்கள் இருப்பது அவசியம். இது பின்வரும் தொகுதிகளை உள்ளடக்கியது.

I. சேவையின் சுருக்கமான விளக்கம். அது என்ன செய்கிறது மற்றும் ஏன் தேவைப்படுகிறது என்பது பற்றிய சில வாக்கியங்கள்.

II. கட்டிடக்கலை வரைபட இணைப்பு. ஒரு விரைவான பார்வையுடன், எடுத்துக்காட்டாக, நீங்கள் ரெடிஸை தற்காலிக சேமிப்பிற்காகப் பயன்படுத்துகிறீர்களா அல்லது நிலையான பயன்முறையில் முக்கிய தரவு சேமிப்பகமாகப் பயன்படுத்துகிறீர்களா என்பதைப் புரிந்துகொள்வது எளிது. இப்போது Avito இல் இது சங்கமத்திற்கான இணைப்பு.

III. ரன்புக். சேவையைத் தொடங்குதல் மற்றும் அதைக் கையாள்வதில் உள்ள நுணுக்கங்கள் பற்றிய சிறு வழிகாட்டி.

IV. அடிக்கடி கேட்கப்படும் கேள்விகள், சேவையுடன் பணிபுரியும் போது உங்கள் சகாக்கள் சந்திக்கும் பிரச்சனைகளை முன்னறிவிப்பது நல்லது.

V. APIக்கான இறுதிப்புள்ளிகளின் விளக்கம். திடீரென்று நீங்கள் சேருமிடங்களைக் குறிப்பிடவில்லை என்றால், உங்களுடன் தொடர்புடைய மைக்ரோ சர்வீஸ்கள் இருக்கும் சக ஊழியர்கள் நிச்சயமாக அதற்கு பணம் செலுத்துவார்கள். இப்போது நாம் ஸ்வாக்கரைப் பயன்படுத்துகிறோம், இதற்கு சுருக்கமாக அழைக்கப்படும் எங்கள் தீர்வு.

VI. லேபிள்கள். அல்லது சேவையானது எந்த தயாரிப்பு, செயல்பாடு அல்லது நிறுவனத்தின் கட்டமைப்புப் பிரிவு ஆகியவற்றைக் காட்டும் குறிப்பான்கள். உதாரணமாக, ஒரு வாரத்திற்கு முன்பு உங்கள் சகாக்கள் இதே வணிகப் பிரிவிற்குச் செய்த செயல்பாட்டை நீங்கள் குறைக்கிறீர்களா என்பதை விரைவாகப் புரிந்துகொள்ள அவை உங்களுக்கு உதவுகின்றன.

VII. சேவையின் உரிமையாளர் அல்லது உரிமையாளர்கள். பெரும்பாலான சந்தர்ப்பங்களில், அது — அல்லது அவற்றை — தானாகவே PaaS ஐப் பயன்படுத்தி தீர்மானிக்க முடியும், ஆனால் பாதுகாப்பான பக்கத்தில் இருக்க, டெவலப்பர் அவற்றை கைமுறையாகக் குறிப்பிட வேண்டும்.

இறுதியாக, குறியீடு மதிப்பாய்வு போன்ற ஆவணங்களை மதிப்பாய்வு செய்வது ஒரு நல்ல நடைமுறையாகும்.

தொடர்ச்சியான ஒருங்கிணைப்பு

• களஞ்சியங்களை தயார் செய்தல்.
• டீம்சிட்டியில் பைப்லைனை உருவாக்குதல்.
• உரிமைகளை அமைத்தல்.
• சேவை உரிமையாளர்களைத் தேடுங்கள். இங்கே ஒரு கலப்பின திட்டம் உள்ளது - கைமுறையாக குறிப்பது மற்றும் PaaS இலிருந்து குறைந்தபட்ச ஆட்டோமேஷன். மற்றொரு மேம்பாட்டுக் குழுவிற்கு ஆதரவுக்காக சேவைகள் மாற்றப்படும்போது அல்லது எடுத்துக்காட்டாக, சேவை டெவலப்பர் வெளியேறினால், முழுமையான தானியங்கு திட்டம் தோல்வியடையும்.
• அட்லஸில் ஒரு சேவையைப் பதிவு செய்தல் (மேலே பார்க்க). அதன் அனைத்து உரிமையாளர்கள் மற்றும் சார்புகளுடன்.
• இடம்பெயர்வுகளை சரிபார்க்கிறது. அவற்றில் ஏதேனும் ஆபத்தானவையா என்பதை நாங்கள் சரிபார்க்கிறோம். எடுத்துக்காட்டாக, சேவையின் வெவ்வேறு பதிப்புகளுக்கு இடையேயான தரவுத் திட்டத்தின் இணக்கத்தன்மையை உடைக்கக்கூடிய மாற்று அட்டவணை அல்லது வேறு ஏதேனும் ஒன்று தோன்றும். பின்னர் இடம்பெயர்வு செய்யப்படவில்லை, ஆனால் ஒரு சந்தாவில் வைக்கப்படுகிறது - சேவை உரிமையாளரைப் பயன்படுத்துவது பாதுகாப்பானதாக இருக்கும்போது PaaS சமிக்ஞை செய்ய வேண்டும்.

சுட்டுக்கொள்ள

அடுத்த கட்டம் வரிசைப்படுத்துவதற்கு முன் பேக்கேஜிங் சேவைகள்.

• விண்ணப்பத்தை உருவாக்குதல். கிளாசிக் படி - ஒரு டோக்கர் படத்தில்.
• சேவை மற்றும் தொடர்புடைய ஆதாரங்களுக்கான ஹெல்ம் விளக்கப்படங்களை உருவாக்குதல். தரவுத்தளங்கள் மற்றும் தற்காலிக சேமிப்பு உட்பட. CLI-புஷ் கட்டத்தில் உருவாக்கப்பட்ட app.toml கட்டமைப்புக்கு ஏற்ப அவை தானாக உருவாக்கப்படும்.
• துறைமுகங்களைத் திறக்க நிர்வாகிகளுக்கான டிக்கெட்டுகளை உருவாக்குதல் (தேவைப்படும் போது).
• அலகு சோதனைகளை இயக்குதல் மற்றும் குறியீடு கவரேஜைக் கணக்கிடுதல். குறியீடு கவரேஜ் குறிப்பிட்ட வரம்புக்குக் கீழே இருந்தால், பெரும்பாலும் சேவை மேலும் செல்லாது - வரிசைப்படுத்துவதற்கு. இது ஏற்றுக்கொள்ளக்கூடிய விளிம்பில் இருந்தால், சேவைக்கு "அவமானம்" குணகம் ஒதுக்கப்படும்: பின்னர், காலப்போக்கில் காட்டி எந்த முன்னேற்றமும் இல்லை என்றால், டெவலப்பர் சோதனைகளின் அடிப்படையில் எந்த முன்னேற்றமும் இல்லை என்று அறிவிப்பைப் பெறுவார் ( மற்றும் அதற்கு ஏதாவது செய்ய வேண்டும்).
• நினைவகம் மற்றும் CPU வரம்புகளுக்கான கணக்கியல். நாங்கள் முக்கியமாக மைக்ரோ சர்வீஸ்களை கோலாங்கில் எழுதி, குபெர்னெட்டஸில் இயக்குகிறோம். எனவே கோலாங் மொழியின் தனித்தன்மையுடன் தொடர்புடைய ஒரு நுணுக்கம்: இயல்பாக, தொடங்கும் போது, ​​கணினியில் உள்ள அனைத்து கோர்களும் பயன்படுத்தப்படும், நீங்கள் GOMAXPROCS மாறியை வெளிப்படையாக அமைக்கவில்லை என்றால், அதே கணினியில் இதுபோன்ற பல சேவைகள் தொடங்கப்பட்டால், அவை தொடங்கும். வளங்களுக்காக போட்டியிட, ஒருவருக்கொருவர் குறுக்கிட்டு. கீழேயுள்ள வரைபடங்கள், நீங்கள் பயன்பாட்டை சர்ச்சையின்றி மற்றும் வளங்களுக்கான பந்தயத்தில் இயக்கினால், செயலாக்க நேரம் எவ்வாறு மாறுகிறது என்பதைக் காட்டுகிறது. (வரைபடங்களின் ஆதாரங்கள் இங்கே).

செயல்படுத்தும் நேரம், குறைவாக இருந்தால் நல்லது. அதிகபட்சம்: 643ms, குறைந்தபட்சம்: 42ms. புகைப்படம் கிளிக் செய்யக்கூடியது.

அறுவை சிகிச்சைக்கான நேரம், குறைவாக இருந்தால் நல்லது. அதிகபட்சம்: 14091 ns, குறைந்தபட்சம்: 151 ns. புகைப்படம் கிளிக் செய்யக்கூடியது.

சட்டசபை தயாரிப்பு கட்டத்தில், நீங்கள் இந்த மாறியை வெளிப்படையாக அமைக்கலாம் அல்லது நூலகத்தைப் பயன்படுத்தலாம் automaxprocs Uber ஐச் சேர்ந்த தோழர்களிடமிருந்து.

வரிசைப்படுத்த

• மரபுகளைச் சரிபார்த்தல். நீங்கள் உத்தேசித்துள்ள சூழல்களுக்கு சேவைக் கூட்டங்களை வழங்கத் தொடங்கும் முன், பின்வருவனவற்றைச் சரிபார்க்க வேண்டும்:
- API இறுதிப்புள்ளிகள்.
— திட்டத்துடன் API இறுதிப்புள்ளிகள் பதில்களின் இணக்கம்.
- பதிவு வடிவம்.
- சேவைக்கான கோரிக்கைகளுக்கான தலைப்புகளை அமைத்தல் (தற்போது இது netramesh ஆல் செய்யப்படுகிறது)
— நிகழ்வு பஸ்ஸுக்கு செய்திகளை அனுப்பும் போது உரிமையாளர் டோக்கனை அமைத்தல். பேருந்து முழுவதும் சேவைகளின் இணைப்பைக் கண்காணிக்க இது தேவைப்படுகிறது. சேவைகளின் இணைப்பை அதிகரிக்காத (நல்லது) மற்றும் சேவைகளின் இணைப்பை வலுப்படுத்தும் வணிகத் தரவு (இது மிகவும் மோசமானது!) ஆகிய இரண்டையும் நீங்கள் பேருந்திற்கு அனுப்பலாம். இந்த இணைப்பு ஒரு சிக்கலாக மாறும் போது, ​​பஸ்ஸை யார் எழுதுகிறார்கள் மற்றும் படிக்கிறார்கள் என்பதைப் புரிந்துகொள்வது சேவைகளை சரியாகப் பிரிக்க உதவுகிறது.

Avito இல் இன்னும் பல மாநாடுகள் இல்லை, ஆனால் அவற்றின் குளம் விரிவடைகிறது. குழு புரிந்து கொள்ளக்கூடிய மற்றும் புரிந்துகொள்ளக்கூடிய வடிவத்தில் இதுபோன்ற ஒப்பந்தங்கள் அதிகமாகக் கிடைக்கின்றன, மைக்ரோ சர்வீஸ்களுக்கு இடையே நிலைத்தன்மையைப் பராமரிப்பது எளிது.

செயற்கை சோதனைகள்

• மூடிய வளைய சோதனை. இதற்கு நாம் இப்போது திறந்த மூலத்தைப் பயன்படுத்துகிறோம் Hoverfly.io. முதலில், இது சேவையின் உண்மையான சுமையை பதிவு செய்கிறது, பின்னர் - ஒரு மூடிய வளையத்தில் - அது அதை பின்பற்றுகிறது.

• அழுத்த சோதனை. அனைத்து சேவைகளையும் சிறந்த செயல்திறனுக்கு கொண்டு வர முயற்சிக்கிறோம். மேலும் ஒவ்வொரு சேவையின் அனைத்து பதிப்புகளும் சுமை சோதனைக்கு உட்பட்டதாக இருக்க வேண்டும் - இதன் மூலம் சேவையின் தற்போதைய செயல்திறன் மற்றும் அதே சேவையின் முந்தைய பதிப்புகளின் வித்தியாசத்தை நாம் புரிந்து கொள்ள முடியும். சேவை புதுப்பித்தலுக்குப் பிறகு, அதன் செயல்திறன் ஒன்றரை மடங்கு குறைந்தால், அதன் உரிமையாளர்களுக்கு இது ஒரு தெளிவான சமிக்ஞையாகும்: நீங்கள் குறியீட்டைத் தோண்டி நிலைமையை சரிசெய்ய வேண்டும்.
சேகரிக்கப்பட்ட தரவை நாங்கள் பயன்படுத்துகிறோம், எடுத்துக்காட்டாக, தானியங்கு அளவிடுதலைச் சரியாகச் செயல்படுத்தவும், இறுதியில், சேவை எவ்வளவு அளவிடக்கூடியது என்பதை பொதுவாகப் புரிந்துகொள்ளவும்.

சுமை சோதனையின் போது, ​​வள நுகர்வு நிர்ணயிக்கப்பட்ட வரம்புகளை சந்திக்கிறதா என்பதை நாங்கள் சரிபார்க்கிறோம். நாங்கள் முதன்மையாக உச்சநிலைகளில் கவனம் செலுத்துகிறோம்.

a) மொத்த சுமையைப் பார்க்கிறோம்.
- மிகவும் சிறியது - சுமை திடீரென்று பல முறை குறைந்துவிட்டால், பெரும்பாலும் ஏதாவது வேலை செய்யாது.
- மிகப் பெரியது - தேர்வுமுறை தேவை.

b) RPS இன் படி கட்ஆஃப் பார்க்கிறோம்.
தற்போதைய பதிப்பிற்கும் முந்தைய பதிப்புக்கும் மொத்த அளவுக்கும் உள்ள வித்தியாசத்தை இங்கே பார்க்கலாம். எடுத்துக்காட்டாக, ஒரு சேவை 100 ஆர்பிஎஸ் உற்பத்தி செய்தால், அது மோசமாக எழுதப்பட்டுள்ளது, அல்லது இது அதன் தனித்தன்மை, ஆனால் எந்தவொரு சந்தர்ப்பத்திலும், சேவையை மிக நெருக்கமாகப் பார்க்க இது ஒரு காரணம்.
மாறாக, பல RPS இருந்தால், ஒருவேளை சில வகையான பிழைகள் இருக்கலாம் மற்றும் சில இறுதிப்புள்ளிகள் பேலோடை இயக்குவதை நிறுத்திவிட்டன, மேலும் சில வெறுமனே தூண்டப்படும் return true;

கேனரி சோதனைகள்

நாங்கள் செயற்கை சோதனைகளில் தேர்ச்சி பெற்ற பிறகு, குறைந்த எண்ணிக்கையிலான பயனர்களுக்கு மைக்ரோ சர்வீஸைச் சோதிக்கிறோம். சேவையின் நோக்கம் கொண்ட பார்வையாளர்களில் ஒரு சிறிய பங்கைக் கொண்டு கவனமாகத் தொடங்குகிறோம் - 0,1% க்கும் குறைவாக. இந்த கட்டத்தில், சரியான தொழில்நுட்ப மற்றும் தயாரிப்பு அளவீடுகள் கண்காணிப்பில் சேர்க்கப்படுவது மிகவும் முக்கியம், இதனால் அவை சேவையில் உள்ள சிக்கலை விரைவில் காண்பிக்கும். கேனரி சோதனைக்கான குறைந்தபட்ச நேரம் 5 நிமிடங்கள், முக்கியமானது 2 மணிநேரம். சிக்கலான சேவைகளுக்கு, நேரத்தை கைமுறையாக அமைக்கிறோம்.
பகுப்பாய்வு செய்வோம்:
- மொழி சார்ந்த அளவீடுகள், குறிப்பாக, php-fpm தொழிலாளர்கள்;
- சென்ட்ரியில் பிழைகள்;
- பதில் நிலைகள்;
- பதில் நேரம், சரியான மற்றும் சராசரி;
- தாமதம்;
- விதிவிலக்குகள், பதப்படுத்தப்பட்ட மற்றும் கையாளப்படாத;
- தயாரிப்பு அளவீடுகள்.

சுருக்க சோதனை

அழுத்தி சோதனை செய்வது "அழுத்துதல்" சோதனை என்றும் அழைக்கப்படுகிறது. நுட்பத்தின் பெயர் Netflix இல் அறிமுகப்படுத்தப்பட்டது. அதன் சாராம்சம் என்னவென்றால், முதலில் நாம் ஒரு நிகழ்வை உண்மையான போக்குவரத்துடன் தோல்வியடையும் அளவிற்கு நிரப்புகிறோம், இதனால் அதன் வரம்பை அமைக்கிறோம். பின்னர் நாம் மற்றொரு நிகழ்வைச் சேர்த்து இந்த ஜோடியை ஏற்றுகிறோம் - மீண்டும் அதிகபட்சமாக; அவற்றின் உச்சவரம்பு மற்றும் டெல்டாவை முதல் "கசக்குடன்" பார்க்கிறோம். எனவே ஒரு நேரத்தில் ஒரு நிகழ்வை இணைத்து மாற்றங்களின் வடிவத்தைக் கணக்கிடுகிறோம்.
"அழுத்துதல்" மூலம் சோதனை தரவு பொதுவான அளவீடுகள் தரவுத்தளத்தில் பாய்கிறது, அங்கு நாம் செயற்கையான சுமை முடிவுகளை அவற்றுடன் வளப்படுத்துவோம் அல்லது "செயற்கைகளை" மாற்றுவோம்.

உற்பத்தி

• அளவிடுதல். நாங்கள் ஒரு சேவையை உற்பத்திக்கு வெளியிடும்போது, ​​அது எவ்வாறு அளவிடப்படுகிறது என்பதை நாங்கள் கண்காணிக்கிறோம். எங்கள் அனுபவத்தில், CPU குறிகாட்டிகளை மட்டும் கண்காணிப்பது பயனற்றது. அதன் தூய வடிவத்தில் RPS தரப்படுத்தலுடன் ஆட்டோ ஸ்கேலிங் வேலை செய்கிறது, ஆனால் ஆன்லைன் ஸ்ட்ரீமிங் போன்ற சில சேவைகளுக்கு மட்டுமே. எனவே நாங்கள் முதலில் பயன்பாடு சார்ந்த தயாரிப்பு அளவீடுகளைப் பார்க்கிறோம்.

இதன் விளைவாக, அளவிடும் போது நாங்கள் பகுப்பாய்வு செய்கிறோம்:
- CPU மற்றும் RAM குறிகாட்டிகள்,
- வரிசையில் உள்ள கோரிக்கைகளின் எண்ணிக்கை,
- பதில் நேரம்,
- திரட்டப்பட்ட வரலாற்று தரவுகளின் அடிப்படையில் முன்னறிவிப்பு.

ஒரு சேவையை அளவிடும் போது, ​​அதன் சார்புகளைக் கண்காணிப்பதும் முக்கியம், இதனால் சங்கிலியின் முதல் சேவையை நாம் அளவிட மாட்டோம், மேலும் அது அணுகும் சேவைகள் சுமையின் கீழ் தோல்வியடையும். சேவைகளின் முழுக் குழுவிற்கும் ஏற்றுக்கொள்ளக்கூடிய சுமையை நிறுவ, "அருகிலுள்ள" சார்பு சேவையின் வரலாற்றுத் தரவை நாங்கள் பார்க்கிறோம் (CPU மற்றும் RAM குறிகாட்டிகளின் கலவையின் அடிப்படையில், ஆப்ஸ்-குறிப்பிட்ட அளவீடுகளுடன்) மற்றும் அவற்றை வரலாற்றுத் தரவுகளுடன் ஒப்பிடுகிறோம். துவக்க சேவை, மற்றும் பல "சார்பு சங்கிலி" ", மேலிருந்து கீழாக.

சேவை

மைக்ரோ சர்வீஸ் செயல்பாட்டிற்கு வந்த பிறகு, அதில் தூண்டுதல்களை இணைக்கலாம்.

தூண்டுதல்கள் ஏற்படும் பொதுவான சூழ்நிலைகள் இங்கே உள்ளன.
— சாத்தியமான ஆபத்தான இடம்பெயர்வுகள் கண்டறியப்பட்டது.
- பாதுகாப்பு புதுப்பிப்புகள் வெளியிடப்பட்டுள்ளன.
- சேவை நீண்ட காலமாக புதுப்பிக்கப்படவில்லை.
— சேவையின் சுமை குறிப்பிடத்தக்க அளவில் குறைந்துள்ளது அல்லது அதன் சில தயாரிப்பு அளவீடுகள் சாதாரண வரம்பிற்கு வெளியே உள்ளன.
- சேவை இனி புதிய இயங்குதளத் தேவைகளைப் பூர்த்தி செய்யாது.

சில தூண்டுதல்கள் செயல்பாட்டின் ஸ்திரத்தன்மைக்கு பொறுப்பாகும், சில - கணினி பராமரிப்பின் செயல்பாடாக - எடுத்துக்காட்டாக, சில சேவைகள் நீண்ட காலமாக பயன்படுத்தப்படவில்லை மற்றும் அதன் அடிப்படை படம் பாதுகாப்பு சோதனைகளில் தேர்ச்சி பெறவில்லை.

டாஷ்போர்டு

சுருக்கமாக, டாஷ்போர்டு எங்கள் முழு PaaS இன் கட்டுப்பாட்டுப் பலகமாகும்.

• சேவையைப் பற்றிய தகவல்களின் ஒரு புள்ளி, அதன் சோதனைக் கவரேஜ், அதன் படங்களின் எண்ணிக்கை, தயாரிப்பு நகல்களின் எண்ணிக்கை, பதிப்புகள் போன்றவை.
• சேவைகள் மற்றும் லேபிள்கள் மூலம் தரவை வடிகட்டுவதற்கான ஒரு கருவி (வணிக அலகுகளைச் சேர்ந்த குறிப்பான்கள், தயாரிப்பு செயல்பாடு போன்றவை)
• தடமறிதல், பதிவு செய்தல் மற்றும் கண்காணிப்பதற்கான உள்கட்டமைப்பு கருவிகளுடன் ஒருங்கிணைப்பதற்கான ஒரு கருவி.
• சேவை ஆவணத்தின் ஒரு புள்ளி.
• சேவைகள் முழுவதும் அனைத்து நிகழ்வுகளின் ஒரு பார்வை.

மொத்தம்

PaaS ஐ அறிமுகப்படுத்துவதற்கு முன், ஒரு புதிய டெவலப்பர் தயாரிப்பில் மைக்ரோ சர்வீஸைத் தொடங்குவதற்குத் தேவையான அனைத்து கருவிகளையும் புரிந்துகொள்வதற்கு பல வாரங்கள் செலவிடலாம்: குபெர்னெட்ஸ், ஹெல்ம், எங்கள் உள் டீம்சிட்டி அம்சங்கள், தரவுத்தளங்கள் மற்றும் கேச்களுக்கான இணைப்புகளை தவறு-சகிப்புத்தன்மையுடன் அமைத்தல் போன்றவை. விரைவு தொடக்கத்தைப் படித்து சேவையை உருவாக்குவதற்கு இரண்டு மணிநேரம் ஆகும்.

HighLoad++ 2018 க்கு இந்த தலைப்பில் ஒரு அறிக்கை கொடுத்துள்ளேன், நீங்கள் அதைப் பார்க்கலாம் видео и வழங்கல்.

இறுதிவரை படிப்பவர்களுக்கு போனஸ் டிராக்

அவிடோவில் உள்ள டெவலப்பர்களுக்கான உள் மூன்று நாள் பயிற்சியை நாங்கள் ஏற்பாடு செய்கிறோம் கிறிஸ் ரிச்சர்ட்சன், மைக்ரோ சர்வீஸ் கட்டிடக்கலை நிபுணர். இந்தப் பதிவின் வாசகர்களில் ஒருவருக்கு அதில் பங்கேற்கும் வாய்ப்பை வழங்க விரும்புகிறோம். இது பயிற்சி திட்டம் வெளியிடப்பட்டது.

பயிற்சி மாஸ்கோவில் ஆகஸ்ட் 5 முதல் 7 வரை நடைபெறும். இவை முழுமையாக ஆக்கிரமிக்கப்படும் வேலை நாட்கள். மதிய உணவு மற்றும் பயிற்சி எங்கள் அலுவலகத்தில் இருக்கும், மேலும் தேர்ந்தெடுக்கப்பட்ட பங்கேற்பாளர் பயணத்திற்கும் தங்குமிடத்திற்கும் அவரே பணம் செலுத்துவார்.

நீங்கள் பங்கேற்பதற்கு விண்ணப்பிக்கலாம் இந்த Google வடிவத்தில். உங்களிடமிருந்து - நீங்கள் ஏன் பயிற்சியில் கலந்து கொள்ள வேண்டும் என்ற கேள்விக்கான பதில் மற்றும் உங்களை எவ்வாறு தொடர்புகொள்வது என்பது பற்றிய தகவல். ஆங்கிலத்தில் பதிலளிக்கவும், ஏனென்றால் கிறிஸ் பயிற்சியில் கலந்துகொள்ளும் பங்கேற்பாளரைத் தேர்ந்தெடுப்பார்.
இந்த இடுகைக்கான புதுப்பிப்பு மற்றும் டெவலப்பர்களுக்கான Avito சமூக வலைப்பின்னல்களில் பயிற்சி பங்கேற்பாளரின் பெயரை அறிவிப்போம் (AvitoTech in பேஸ்புக், Вконтакте, ட்விட்டர்) ஜூலை 19 க்குப் பிறகு இல்லை.

ஆதாரம்: www.habr.com