மோனோலித்தில் இருந்து மைக்ரோ சர்வீஸுக்கு மாற்றம்: வரலாறு மற்றும் நடைமுறை

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

திட்டம் அதன் வரலாற்றை மிக நீண்ட காலத்திற்கு முன்பு, 2000 இன் தொடக்கத்தில் தொடங்கியது. முதல் பதிப்புகள் விஷுவல் பேசிக் 6 இல் எழுதப்பட்டன. காலப்போக்கில், இந்த மொழியின் வளர்ச்சியை எதிர்காலத்தில் ஆதரிக்க கடினமாக இருக்கும் என்பது தெளிவாகியது, ஏனெனில் IDE. மற்றும் மொழியே மோசமாக வளர்ந்திருக்கிறது. 2000 களின் இறுதியில், மிகவும் நம்பிக்கைக்குரிய C#க்கு மாற முடிவு செய்யப்பட்டது. புதிய பதிப்பு பழைய பதிப்பின் திருத்தத்திற்கு இணையாக எழுதப்பட்டது, படிப்படியாக மேலும் மேலும் குறியீடு .NET இல் எழுதப்பட்டது. C# இல் உள்ள பின்தளம் ஆரம்பத்தில் ஒரு சேவை கட்டமைப்பில் கவனம் செலுத்தியது, ஆனால் வளர்ச்சியின் போது, ​​தர்க்கத்துடன் கூடிய பொதுவான நூலகங்கள் பயன்படுத்தப்பட்டன, மேலும் சேவைகள் ஒரே செயல்பாட்டில் தொடங்கப்பட்டன. இதன் விளைவாக "சேவை மோனோலித்" என்று நாங்கள் அழைத்த ஒரு பயன்பாடு இருந்தது.

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

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

உள்ளடக்கம்

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

தற்போதுள்ள தீர்வின் கட்டிடக்கலை மற்றும் சிக்கல்கள்

ஆரம்பத்தில், கட்டிடக்கலை இப்படி இருந்தது: UI என்பது ஒரு தனி பயன்பாடு, மோனோலிதிக் பகுதி விஷுவல் பேசிக் 6 இல் எழுதப்பட்டுள்ளது, .NET பயன்பாடு என்பது மிகப் பெரிய தரவுத்தளத்துடன் பணிபுரியும் தொடர்புடைய சேவைகளின் தொகுப்பாகும்.

முந்தைய தீர்வின் தீமைகள்

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

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

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

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

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

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

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

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

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

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

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

மாற்றம் சிக்கல்கள்

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

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

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

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

மோனோலித்தில் இருந்து மைக்ரோ சர்வீஸுக்கு எப்படி நகர்த்துவது

மைக்ரோ சர்வீஸ்களை வழங்குதல்

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

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

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

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

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

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

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

உண்மையான UI லாஜிக் கடைசி இரண்டு வரிகளில் மட்டுமே உள்ளது. நாங்கள் அதை சேவையகத்திற்கு மாற்றினோம், இதனால் அதை மீண்டும் பயன்படுத்த முடியும், இதன் மூலம் UI ஐ குறைத்து சரியான கட்டமைப்பை அடைய முடியும்.

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

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

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

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

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

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

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

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

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

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

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

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

தரவுத்தளத்துடன் பணிபுரிதல்

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

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

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

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

தரவுத்தளப் பகிர்வின் இரண்டு உலகளாவிய முறைகளைப் பயன்படுத்தினோம்: ஏற்கனவே உள்ள அட்டவணைகளை பகிர்தல் மற்றும் செயலாக்கத்துடன் பகிர்தல்.

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

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

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

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

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

பின்னர் இந்த இணைப்பை அகற்றுவோம், அதாவது, பிரிக்கப்பட்ட அட்டவணைகளிலிருந்து ஒரு ஒற்றைப் பயன்பாட்டிலிருந்து தரவைப் படிப்பதும் API க்கு மாற்றப்படும்.

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

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

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

இந்தத் திட்டம் செயல்பட, எங்களுக்கு ஒரு மாற்றம் காலம் தேவைப்படும்.

பின்னர் இரண்டு சாத்தியமான அணுகுமுறைகள் உள்ளன.

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

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

இரண்டு அணுகுமுறைகளும் செயல்படுகின்றன, சூழ்நிலையைப் பொறுத்து தேர்வு செய்யவும்.

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

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

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

மூலக் குறியீட்டுடன் பணிபுரிதல்

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

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

தனித்தனியாகப் பயன்படுத்தக்கூடிய உள்கட்டமைப்பு நூலகங்களைக் கொண்டிருப்பது எங்களுக்கு அதிர்ஷ்டம்.

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

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

குறியீடு பிரிக்கும் செயல்முறைக்கு நாங்கள் பல விதிகளை வகுத்துள்ளோம்.

முதல்: சேவைகள், செயல்பாடுகள் மற்றும் செருகுநிரல்களுக்கு இடையே வணிக தர்க்கத்தைப் பகிர நாங்கள் இனி விரும்பவில்லை. மைக்ரோ சர்வீஸ்களுக்குள் வணிக தர்க்கத்தை சுயாதீனமாக்க விரும்புகிறோம். மறுபுறம், மைக்ரோ சர்வீஸ்கள் முற்றிலும் சுதந்திரமாக இருக்கும் சேவைகளாக கருதப்படுகின்றன. இந்த அணுகுமுறை ஓரளவு வீணானது என்று நான் நம்புகிறேன், மேலும் அதை அடைவது கடினம், ஏனெனில், எடுத்துக்காட்டாக, C# இல் உள்ள சேவைகள் எந்தவொரு சந்தர்ப்பத்திலும் நிலையான நூலகத்தால் இணைக்கப்படும். எங்கள் கணினி C# இல் எழுதப்பட்டுள்ளது; நாங்கள் இன்னும் பிற தொழில்நுட்பங்களைப் பயன்படுத்தவில்லை. எனவே, பொதுவான தொழில்நுட்பக் கூட்டங்களைப் பயன்படுத்திக்கொள்ளலாம் என்று முடிவு செய்தோம். முக்கிய விஷயம் என்னவென்றால், அவற்றில் வணிக தர்க்கத்தின் எந்த துண்டுகளும் இல்லை. நீங்கள் பயன்படுத்தும் ORM-க்கு மேல் ஒரு வசதியான ரேப்பர் இருந்தால், அதை சேவையிலிருந்து சேவைக்கு நகலெடுப்பது மிகவும் விலை உயர்ந்தது.

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

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

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

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

எனவே, மூலக் குறியீட்டில் பணிபுரிவதன் மூலம், கட்டமைப்பை சிறிது மாற்றுவதன் மூலம் மற்றும் களஞ்சியங்களைப் பிரிப்பதன் மூலம், நாங்கள் எங்கள் சேவைகளை மேலும் சுயாதீனமாக்குகிறோம்.

உள்கட்டமைப்பு பிரச்சனைகள்

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

சூழலில் கைமுறையாக நிறுவுதல்

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

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

தனி பதிவு

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

Filebeat ஐப் பயன்படுத்தி, சேவையகங்களிலிருந்து எங்கள் பதிவுகளை சேகரிக்கவும், பின்னர் அவற்றை மாற்றவும், UI இல் வினவல்களை உருவாக்க கிபானாவைப் பயன்படுத்தவும் மற்றும் சேவைகளுக்கு இடையில் அழைப்பு எவ்வாறு சென்றது என்பதைப் பார்க்கவும் வாய்ப்பைப் பெறுகிறோம். டிரேஸ் ஐடி இதற்கு பெரிதும் உதவுகிறது.

சோதனை மற்றும் பிழைத்திருத்தம் தொடர்பான சேவைகள்

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

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

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

கூடுதலாக, சுமை சோதனையின் தேவை அதிகரித்துள்ளது; முன்பு இது அரிதான சந்தர்ப்பங்களில் மட்டுமே மேற்கொள்ளப்பட்டது. சோதனைகளை இயக்க JMeter, அவற்றைச் சேமிக்க InfluxDB மற்றும் செயல்முறை வரைபடங்களை உருவாக்க Grafana ஆகியவற்றைப் பயன்படுத்துகிறோம்.

நாம் என்ன சாதித்தோம்?

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

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

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

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

சுருக்கம்

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

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

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

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