மைக்ரோ சர்வீஸ்கள்: அவை என்ன, அவை ஏன் மற்றும் அவற்றை எப்போது செயல்படுத்த வேண்டும்

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

கான்வேயின் சட்டம் மற்றும் வணிகம், அமைப்பு மற்றும் தகவல் அமைப்பு ஆகியவற்றுக்கு இடையேயான உறவு

மீண்டும் ஒருமுறை நான் மேற்கோள் காட்ட அனுமதிக்கிறேன்:

"ஒரு அமைப்பை வடிவமைக்கும் எந்தவொரு நிறுவனமும் (பரந்த அர்த்தத்தில்) அந்த அமைப்பில் உள்ள குழுக்களின் கட்டமைப்பைப் பிரதிபலிக்கும் வடிவமைப்பைப் பெறும்."
- மெல்வின் கான்வே, 1967

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

தகவல் அமைப்புகளின் வணிக நோக்குநிலை

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

எல்லாம் பாய்கிறது, எல்லாம் மாறுகிறது, அல்லது மைக்ரோ சர்வீஸ்கள் சிக்கலை எதிர்த்துப் போராடுவதற்கான வழிமுறையா?

தொடர்வதற்கு முன், மைக்ரோ சர்வீஸ் கட்டிடக்கலை பற்றிய சில தவறான கருத்துக்களைப் பார்ப்போம்.

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

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

தயாரிப்பு வாழ்க்கை சுழற்சி மற்றும் சேவை வாழ்க்கை சுழற்சி

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

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

சிக்கலான தன்மையை எதிர்த்துப் போராடுவதற்கான வழிமுறையாக மைக்ரோ சர்வீஸ்கள்... கட்டமைப்பு மேலாண்மை

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

கண்டுபிடிப்புகள்

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

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