मोनोलिथबाट माइक्रोसर्विसेसमा संक्रमण: इतिहास र अभ्यास

यस लेखमा, म कसरी काम गरिरहेको प्रोजेक्टलाई ठूलो मोनोलिथबाट माइक्रोसर्भिसेसको सेटमा रूपान्तरण भयो भन्ने बारे कुरा गर्नेछु।

परियोजनाले यसको इतिहास धेरै लामो समय पहिले, 2000 को सुरुमा सुरु गर्यो। पहिलो संस्करणहरू भिजुअल बेसिक 6 मा लेखिएको थियो। समयको साथ, यो स्पष्ट भयो कि यस भाषाको विकासलाई भविष्यमा समर्थन गर्न गाह्रो हुनेछ, किनभने IDE र भाषा आफैं कमजोर विकसित छन्। 2000 को अन्त्यमा, यो अधिक आशाजनक C# मा स्विच गर्ने निर्णय गरियो। नयाँ संस्करण पुरानोको परिमार्जनसँगै समानान्तरमा लेखिएको थियो, बिस्तारै .NET मा थप र धेरै कोड लेखिएको थियो। C# मा ब्याकएन्ड सुरुमा सेवा वास्तुकलामा केन्द्रित थियो, तर विकासको क्रममा, तर्कसहितको साझा पुस्तकालयहरू प्रयोग गरिन्थ्यो, र सेवाहरू एकल प्रक्रियामा सुरू गरियो। नतिजा एउटा अनुप्रयोग थियो जसलाई हामीले "सेवा मोनोलिथ" भनिन्छ।

यस संयोजनको केही फाइदाहरू मध्ये एक बाह्य API मार्फत एक अर्कालाई कल गर्ने सेवाहरूको क्षमता थियो। त्यहाँ थप सही सेवामा संक्रमणको लागि स्पष्ट आवश्यकताहरू थिए, र भविष्यमा, माइक्रोसेवा वास्तुकला।

हामीले सन् २०१५ मा विघटनमा हाम्रो काम सुरु गर्‍यौं। हामी अझै एक आदर्श स्थितिमा पुगेका छैनौं - त्यहाँ अझै पनि ठूलो परियोजनाका भागहरू छन् जसलाई मोनोलिथहरू भन्न सकिँदैन, तर तिनीहरू सूक्ष्म सेवाहरू जस्तो देखिँदैनन्। यद्यपि, प्रगति महत्त्वपूर्ण छ।
म लेखमा यसको बारेमा कुरा गर्नेछु।

सामग्रीहरू

• वास्तुकला र अवस्थित समाधान को समस्या
• माइक्रो सेवाहरूबाट अपेक्षाहरू
• संक्रमण समस्याहरू
• कसरी मोनोलिथबाट माइक्रोसर्भिसेसमा सार्ने
  • पहिलो तरिका
  • दोस्रो बाटो
  • तेस्रो बाटो
  • चौथो तरीका
• डाटाबेससँग काम गर्दै
  • अवस्थित तालिकाहरू विभाजन गर्दै
  • प्रशोधन विभाग
• स्रोत कोडसँग काम गर्दै
• पूर्वाधार समस्याहरू
  • वातावरणमा म्यानुअल स्थापना
  • अलग लगिङ
  • परीक्षण र डिबग सम्बन्धित सेवाहरू

वास्तुकला र अवस्थित समाधान को समस्या

प्रारम्भमा, वास्तुकला यस्तो देखिन्थ्यो: UI एउटा छुट्टै अनुप्रयोग हो, मोनोलिथिक भाग भिजुअल बेसिक 6 मा लेखिएको छ, .NET अनुप्रयोग एकदम ठूलो डाटाबेससँग काम गर्ने सम्बन्धित सेवाहरूको सेट हो।

अघिल्लो समाधानको बेफाइदाहरू

असफलताको एकल बिन्दु
हामीसँग असफलताको एकल बिन्दु थियो: .NET अनुप्रयोग एकल प्रक्रियामा चल्यो। यदि कुनै मोड्युल असफल भयो भने, सम्पूर्ण अनुप्रयोग असफल भयो र पुन: सुरु गर्नुपर्‍यो। हामीले विभिन्न प्रयोगकर्ताहरूका लागि धेरै संख्यामा प्रक्रियाहरू स्वचालित गर्नाले, तिनीहरूमध्ये एउटामा असफलताका कारण, सबैले केही समयको लागि काम गर्न सकेनन्। र सफ्टवेयर त्रुटिको अवस्थामा, ब्याकअपले पनि मद्दत गरेन।

सुधारको पङ्क्ति
यो कमजोरी बरु संगठनात्मक छ। हाम्रो अनुप्रयोगसँग धेरै ग्राहकहरू छन्, र तिनीहरू सबै यसलाई सकेसम्म चाँडो सुधार गर्न चाहन्छन्। पहिले, यो समानान्तरमा गर्न असम्भव थियो, र सबै ग्राहकहरू लाइनमा उभिए। यो प्रक्रिया व्यवसायहरूको लागि नकारात्मक थियो किनभने तिनीहरूले आफ्नो कार्य मूल्यवान थियो भनेर प्रमाणित गर्नुपर्‍यो। र विकास टोलीले यो लाम व्यवस्थित गर्न समय बितायो। यसले धेरै समय र प्रयास लियो, र उत्पादन अन्ततः उनीहरूले मन परेको रूपमा छिटो परिवर्तन गर्न सकेन।

श्रोतसाधनको सदुपयोग
एकल प्रक्रियामा सेवाहरू होस्ट गर्दा, हामीले सधैँ पूर्ण रूपमा सर्भरबाट सर्भरमा कन्फिगरेसन प्रतिलिपि गर्छौं। हामी स्रोतहरू बर्बाद नगर्न र हाम्रो डिप्लोइमेन्ट योजनामा ​​थप लचिलो नियन्त्रण प्राप्त गर्नका लागि सबैभन्दा धेरै लोड गरिएका सेवाहरू छुट्टै राख्न चाहन्छौं।

आधुनिक प्रविधि लागू गर्न गाह्रो छ
सबै विकासकर्ताहरूलाई परिचित समस्या: परियोजनामा ​​​​आधुनिक प्रविधिहरू परिचय गर्ने इच्छा छ, तर त्यहाँ कुनै अवसर छैन। एक ठूलो मोनोलिथिक समाधानको साथ, हालको पुस्तकालयको कुनै पनि अपडेट, नयाँमा संक्रमणको उल्लेख नगरी, बरु गैर-तुच्छ कार्यमा परिणत हुन्छ। टोली नेतालाई यो प्रमाणित गर्न लामो समय लाग्छ कि यसले बर्बाद नसाहरू भन्दा बढी बोनस ल्याउनेछ।

परिवर्तन जारी गर्न कठिनाई
यो सबैभन्दा गम्भीर समस्या थियो - हामीले हरेक दुई महिनामा विमोचन जारी गर्दै थियौं।
विकासकर्ताहरूको परीक्षण र प्रयासहरूको बावजुद प्रत्येक रिलीज बैंकको लागि वास्तविक आपदामा परिणत भयो। व्यवसायले हप्ताको सुरुमा यसको केही कार्यक्षमताले काम गर्दैन भनेर बुझ्यो। र विकासकर्ताहरूले गम्भीर घटनाहरूको एक हप्ता उनीहरूलाई पर्खिरहेको बुझे।
परिस्थिति बदल्ने चाहना सबैमा थियो ।

माइक्रो सेवाहरूबाट अपेक्षाहरू

तयार हुँदा अवयवहरूको मुद्दा। समाधान विघटन गरेर र विभिन्न प्रक्रियाहरू अलग गरेर तयार हुँदा कम्पोनेन्टहरूको डेलिभरी।

साना उत्पादन टोलीहरू। यो महत्त्वपूर्ण छ किनभने पुरानो मोनोलिथमा काम गर्ने ठूलो टोलीलाई व्यवस्थापन गर्न गाह्रो थियो। यस्तो टोली कडा प्रक्रिया अनुसार काम गर्न बाध्य थियो, तर तिनीहरू थप रचनात्मकता र स्वतन्त्रता चाहन्थे। केवल साना टोलीहरूले यो खर्च गर्न सक्थे।

अलग-अलग प्रक्रियाहरूमा सेवाहरूको अलगाव। आदर्श रूपमा, म यसलाई कन्टेनरहरूमा अलग गर्न चाहन्थे, तर .NET फ्रेमवर्कमा लेखिएका सेवाहरूको ठूलो संख्या विन्डोजमा मात्र चल्छ। .NET Core मा आधारित सेवाहरू अब देखा परिरहेका छन्, तर ती मध्ये केही अझै छन्।

परिनियोजन लचीलापन। हामी सेवाहरूलाई आवश्यकता अनुसार संयोजन गर्न चाहन्छौं, र कोडले बाध्य पारेको तरिका होइन।

नयाँ प्रविधिको प्रयोग। यो कुनै पनि प्रोग्रामरको लागि रोचक छ।

संक्रमण समस्याहरू

निस्सन्देह, यदि माइक्रोसर्भिसेसमा मोनोलिथ तोड्न सजिलो थियो भने, सम्मेलनहरूमा यसको बारेमा कुरा गर्न र लेखहरू लेख्न आवश्यक पर्दैन। यस प्रक्रियामा धेरै खाटहरू छन्; म हामीलाई बाधा पुर्‍याउने मुख्यहरू वर्णन गर्नेछु।

पहिलो समस्या अधिकांश मोनोलिथहरूको लागि विशिष्ट: व्यापार तर्कको सुसंगतता। जब हामी एक मोनोलिथ लेख्छौं, हामी हाम्रा कक्षाहरू पुन: प्रयोग गर्न चाहन्छौं ताकि अनावश्यक कोड लेख्न नपरोस्। र microservices मा सर्दा, यो एक समस्या हुन्छ: सबै कोड एकदम कडा रूपमा जोडिएको छ, र यो सेवाहरू अलग गर्न गाह्रो छ।

काम सुरु भएको समयमा, भण्डारमा 500 भन्दा बढी परियोजनाहरू र 700 हजार भन्दा बढी कोड लाइनहरू थिए। यो धेरै ठूलो निर्णय हो र दोस्रो समस्या। यसलाई लिने र यसलाई माइक्रोसर्भिसहरूमा विभाजन गर्न सम्भव थिएन।

तेस्रो समस्या - आवश्यक पूर्वाधारको अभाव। वास्तवमा, हामी म्यानुअल रूपमा सर्भरहरूमा स्रोत कोड प्रतिलिपि गर्दै थियौं।

कसरी मोनोलिथबाट माइक्रोसर्भिसेसमा सार्ने

माइक्रोसर्विसेसको प्रावधान

सर्वप्रथम, हामीले तुरुन्तै आफैंले निर्धारण गर्यौं कि माइक्रोसर्भिसेसको विभाजन एक पुनरावृत्ति प्रक्रिया हो। हामीले सधैं समानान्तर रूपमा व्यापार समस्याहरू विकास गर्न आवश्यक थियो। प्राविधिक रूपमा यसलाई कसरी कार्यान्वयन गर्ने हाम्रो समस्या छ। त्यसकारण, हामीले पुनरावृत्ति प्रक्रियाको लागि तयारी गरेका छौं। यदि तपाइँसँग ठूलो एप्लिकेसन छ र यो सुरुमा पुन: लेख्नको लागि तयार छैन भने यसले कुनै अन्य तरिकाले काम गर्दैन।

हामी माइक्रोसर्विसेसहरू अलग गर्न के विधिहरू प्रयोग गर्छौं?

पहिलो तरिका - सेवाहरूको रूपमा अवस्थित मोड्युलहरू सार्नुहोस्। यस सन्दर्भमा, हामी भाग्यशाली थियौं: त्यहाँ पहिले नै दर्ता गरिएका सेवाहरू थिए जसले WCF प्रोटोकल प्रयोग गरेर काम गर्यो। उनीहरूलाई छुट्टाछुट्टै सभामा विभाजन गरिएको थियो। हामीले तिनीहरूलाई अलग-अलग पोर्ट गर्यौं, प्रत्येक निर्माणमा एउटा सानो लन्चर थप्दै। यो अद्भुत Topshelf पुस्तकालय प्रयोग गरेर लेखिएको थियो, जसले तपाईंलाई सेवा र कन्सोल दुवै रूपमा अनुप्रयोग चलाउन अनुमति दिन्छ। यो डिबगिङको लागि सुविधाजनक छ किनकि समाधानमा कुनै अतिरिक्त परियोजनाहरू आवश्यक पर्दैन।

सेवाहरू व्यापार तर्क अनुसार जोडिएका थिए, किनकि तिनीहरूले साझा सम्मेलनहरू प्रयोग गर्थे र साझा डाटाबेससँग काम गर्थे। तिनीहरूलाई तिनीहरूको शुद्ध रूपमा सूक्ष्म सेवाहरू भन्न सकिँदैन। यद्यपि, हामीले यी सेवाहरू अलग-अलग प्रक्रियाहरूमा प्रदान गर्न सक्छौं। यसले मात्रै समानान्तर विकास र असफलताको एकल बिन्दुको समस्यालाई कम गर्दै, एकअर्कामा उनीहरूको प्रभाव कम गर्न सम्भव बनायो।

होस्ट संग विधानसभा कार्यक्रम वर्ग मा कोड को एक मात्र लाइन हो। हामीले सहायक कक्षामा 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 मार्फत।

हामीले दृढताका साथ निर्णय गर्यौं कि हामी वितरित लेनदेन आवश्यक पर्ने कोडलाई बेवास्ता गर्दैनौं। हाम्रो अवस्थामा, यो नियम पछ्याउन एकदम सजिलो भयो। हामीले अहिलेसम्म परिस्थितिहरू सामना गरेका छैनौं जहाँ कडा वितरित लेनदेनहरू वास्तवमै आवश्यक छ - मोड्युलहरू बीचको अन्तिम स्थिरता पर्याप्त छ।

एक विशिष्ट उदाहरण हेरौं। हामीसँग अर्केस्ट्रेटरको अवधारणा छ - एक पाइपलाइन जसले "एप्लिकेशन" को इकाईलाई प्रशोधन गर्छ। उसले बारीमा ग्राहक, खाता र बैंक कार्ड बनाउँछ। यदि ग्राहक र खाता सफलतापूर्वक सिर्जना गरियो, तर कार्ड सिर्जना असफल भयो भने, अनुप्रयोग "सफल" स्थितिमा सर्दैन र "कार्ड सिर्जना गरिएको छैन" स्थितिमा रहन्छ। भविष्यमा, पृष्ठभूमि गतिविधिले यसलाई उठाएर समाप्त गर्नेछ। प्रणाली केही समयको लागि असंगतिको अवस्थामा रहेको छ, तर हामी सामान्यतया यसबाट सन्तुष्ट छौं।

यदि डेटाको अंशलाई निरन्तर रूपमा बचत गर्न आवश्यक हुँदा स्थिति उत्पन्न भयो भने, हामी सम्भवतः एक प्रक्रियामा प्रशोधन गर्न सेवाको समेकनमा जानेछौं।

माइक्रोसेवा आवंटित गर्ने उदाहरण हेरौं। तपाईं यसलाई अपेक्षाकृत सुरक्षित रूपमा उत्पादनमा कसरी ल्याउन सक्नुहुन्छ? यस उदाहरणमा, हामीसँग प्रणालीको छुट्टै भाग छ - एउटा पेरोल सेवा मोड्युल, कोड खण्डहरू मध्ये एउटा जसको हामी माइक्रोसर्भिस बनाउन चाहन्छौं।

सबै भन्दा पहिले, हामी कोड पुन: लेखेर एक microservice सिर्जना गर्छौं। हामी केही पक्षहरू सुधार गर्दैछौं जुन हामीसँग सन्तुष्ट थिएनौं। हामी ग्राहकबाट नयाँ व्यापार आवश्यकताहरू लागू गर्छौं। हामी UI र ब्याकइन्ड बीचको जडानमा API गेटवे थप्छौं, जसले कल फर्वार्डिङ प्रदान गर्नेछ।

अर्को, हामी यो कन्फिगरेसन सञ्चालनमा जारी गर्छौं, तर पायलट अवस्थामा। हाम्रा धेरै प्रयोगकर्ताहरू अझै पनि पुरानो व्यापार प्रक्रियाहरूसँग काम गर्छन्। नयाँ प्रयोगकर्ताहरूका लागि, हामी मोनोलिथिक अनुप्रयोगको नयाँ संस्करण विकास गर्दैछौं जुन अब यो प्रक्रिया समावेश गर्दैन। अनिवार्य रूपमा, हामीसँग पाइलटको रूपमा काम गर्ने मोनोलिथ र माइक्रोसर्भिसको संयोजन छ।

एक सफल पायलटको साथ, हामी बुझ्छौं कि नयाँ कन्फिगरेसन वास्तवमै कामयोग्य छ, हामी समीकरणबाट पुरानो मोनोलिथ हटाउन सक्छौं र पुरानो समाधानको स्थानमा नयाँ कन्फिगरेसन छोड्न सक्छौं।

कुलमा, हामी मोनोलिथको स्रोत कोड विभाजन गर्नका लागि लगभग सबै अवस्थित विधिहरू प्रयोग गर्छौं। ती सबैले हामीलाई अनुप्रयोगको भागहरूको आकार घटाउन र तिनीहरूलाई नयाँ पुस्तकालयहरूमा अनुवाद गर्न, राम्रो स्रोत कोड बनाउन अनुमति दिन्छ।

डाटाबेससँग काम गर्दै

डाटाबेस स्रोत कोड भन्दा खराब विभाजित गर्न सकिन्छ, किनकि यसले हालको स्कीमा मात्र समावेश गर्दैन, तर संचित ऐतिहासिक डाटा पनि समावेश गर्दछ।

हाम्रो डाटाबेस, अरू धेरैजस्तै, अर्को महत्त्वपूर्ण कमजोरी थियो - यसको ठूलो आकार। यो डाटाबेस एक मोनोलिथको जटिल व्यापार तर्क अनुसार डिजाइन गरिएको थियो, र विभिन्न बाउन्ड गरिएका सन्दर्भहरूको तालिकाहरू बीचको सम्बन्धहरू।

हाम्रो अवस्थामा, सबै समस्याहरू (ठूलो डाटाबेस, धेरै जडानहरू, कहिलेकाहीँ तालिकाहरू बीचको अस्पष्ट सीमाहरू) शीर्ष गर्नको लागि, एक समस्या उत्पन्न भयो जुन धेरै ठूला परियोजनाहरूमा देखा पर्दछ: साझा डाटाबेस टेम्प्लेटको प्रयोग। डेटा तालिकाहरूबाट दृश्य, प्रतिकृति मार्फत लिइयो, र अन्य प्रणालीहरूमा पठाइयो जहाँ यो प्रतिकृति आवश्यक थियो। नतिजाको रूपमा, हामीले तालिकाहरूलाई छुट्टै स्कीमामा सार्न सकेनौं किनभने तिनीहरू सक्रिय रूपमा प्रयोग भएका थिए।

कोडमा सीमित सन्दर्भहरूमा एउटै विभाजनले हामीलाई विभाजनमा मद्दत गर्दछ। यसले सामान्यतया हामीलाई डाटाबेस स्तरमा डाटा कसरी तोड्छ भन्ने राम्रो विचार दिन्छ। हामी बुझ्दछौं कि कुन तालिकाहरू एक बाउन्ड गरिएको सन्दर्भसँग सम्बन्धित छन् र कुन अर्कोमा।

हामीले डाटाबेस विभाजनको दुई विश्वव्यापी विधिहरू प्रयोग गर्यौं: अवस्थित तालिकाहरूको विभाजन र प्रशोधनसँग विभाजन।

यदि डेटा संरचना राम्रो छ, व्यापार आवश्यकताहरू पूरा गर्दछ, र सबैजना यसमा खुसी छन् भने अवस्थित तालिकाहरू विभाजन गर्नु राम्रो तरिका हो। यस अवस्थामा, हामी अवस्थित तालिकाहरूलाई छुट्टै योजनामा ​​अलग गर्न सक्छौं।

व्यापार मोडेल धेरै परिवर्तन भएको बेला प्रशोधन संग एक विभाग आवश्यक छ, र तालिकाहरु अब हामीलाई कुनै पनि सन्तुष्ट छैन।

अवस्थित तालिकाहरू विभाजन गर्दै। हामीले के छुट्याउने भनेर निर्धारण गर्न आवश्यक छ। यो ज्ञान बिना, केहि पनि काम गर्दैन, र यहाँ कोडमा बाउन्ड गरिएको सन्दर्भहरूको विभाजनले हामीलाई मद्दत गर्नेछ। नियमको रूपमा, यदि तपाइँ स्रोत कोडमा सन्दर्भहरूको सीमाहरू बुझ्न सक्नुहुन्छ भने, यो स्पष्ट हुन्छ कि कुन तालिकाहरू विभागको लागि सूचीमा समावेश गर्नुपर्छ।

कल्पना गरौं कि हामीसँग एउटा समाधान छ जसमा दुई मोनोलिथ मोड्युलले एउटा डाटाबेससँग अन्तरक्रिया गर्छ। हामीले यो सुनिश्चित गर्न आवश्यक छ कि केवल एउटा मोड्युलले अलग गरिएको तालिकाको खण्डसँग अन्तरक्रिया गर्छ, र अर्कोले API मार्फत यसको साथ अन्तरक्रिया गर्न थाल्छ। सुरु गर्न, यो पर्याप्त छ कि एपीआई मार्फत मात्र रेकर्डिङ गरिन्छ। यो हाम्रो लागि सूक्ष्म सेवाहरूको स्वतन्त्रताको बारेमा कुरा गर्न आवश्यक शर्त हो। पढ्ने जडानहरू लामो समयसम्म रहन सक्छ जबसम्म त्यहाँ कुनै ठूलो समस्या छैन।

अर्को चरण यो हो कि हामीले कोडको खण्डलाई छुट्याउन सक्छौं जुन अलग गरिएको तालिकाहरूसँग काम गर्दछ, प्रक्रिया बिना वा बिना, एक अलग माइक्रोसर्भिसमा र यसलाई छुट्टै प्रक्रिया, कन्टेनरमा चलाउन सक्छौं। यो मोनोलिथ डाटाबेस र त्यससँग सीधै सम्बन्धित नहुने तालिकाहरूसँग जडान भएको छुट्टै सेवा हुनेछ। मोनोलिथ अझै पनि छुट्याउन सकिने भागसँग पढ्नको लागि अन्तरक्रिया गर्दछ।

पछि हामी यो जडान हटाउनेछौं, त्यो हो, अलग गरिएको तालिकाहरूबाट मोनोलिथिक अनुप्रयोगबाट डेटा पढ्ने पनि API मा स्थानान्तरण गरिनेछ।

अर्को, हामी सामान्य डाटाबेसबाट तालिकाहरू चयन गर्नेछौं जसमा नयाँ माइक्रोसर्भिसले मात्र काम गर्छ। हामी टेबलहरूलाई छुट्टै स्कीमामा वा छुट्टै भौतिक डाटाबेसमा पनि सार्न सक्छौं। माइक्रोसर्भिस र मोनोलिथ डाटाबेसको बीचमा अझै पनि पढ्ने जडान छ, तर चिन्ता गर्नुपर्ने केही छैन, यो कन्फिगरेसनमा यो लामो समयसम्म बाँच्न सक्छ।

अन्तिम चरण भनेको सबै जडानहरू पूर्ण रूपमा हटाउनु हो। यस अवस्थामा, हामीले मुख्य डाटाबेसबाट डाटा माइग्रेट गर्नुपर्ने हुन सक्छ। कहिलेकाहीँ हामी धेरै डाटाबेसहरूमा बाह्य प्रणालीहरूबाट नक्कल गरिएका केही डाटा वा डाइरेक्टरीहरू पुन: प्रयोग गर्न चाहन्छौं। यो हामीलाई समय समयमा हुन्छ।

प्रशोधन विभाग। यो विधि पहिलोसँग धेरै समान छ, केवल उल्टो क्रममा। हामी तुरुन्तै नयाँ डाटाबेस र नयाँ माइक्रोसर्भिस आवंटित गर्छौं जसले एपीआई मार्फत मोनोलिथसँग अन्तरक्रिया गर्दछ। तर एकै समयमा, त्यहाँ डाटाबेस तालिकाहरूको सेट रहन्छ जुन हामी भविष्यमा मेटाउन चाहन्छौं। हामीलाई अब यसको आवश्यकता छैन; हामीले यसलाई नयाँ मोडेलमा बदल्यौं।

यो योजना काम गर्नको लागि, हामीलाई सम्भवतः संक्रमण अवधि चाहिन्छ।

त्यसपछि त्यहाँ दुई सम्भावित दृष्टिकोणहरू छन्।

पहिलो: हामी नयाँ र पुरानो डाटाबेसमा सबै डाटा नक्कल गर्छौं। यस अवस्थामा, हामीसँग डेटा रिडन्डन्सी छ र सिङ्क्रोनाइजेसन समस्याहरू उत्पन्न हुन सक्छ। तर हामी दुई फरक ग्राहक लिन सक्छौं। एउटाले नयाँ संस्करणसँग काम गर्नेछ, अर्कोले पुरानो संस्करणसँग।

दोस्रो: हामी केहि व्यापार मापदण्ड अनुसार डाटा विभाजन गर्छौं। उदाहरणका लागि, हामीसँग प्रणालीमा 5 उत्पादनहरू छन् जुन पुरानो डाटाबेसमा भण्डारण गरिएका थिए। हामी छैठौंलाई नयाँ व्यापार कार्यमा नयाँ डेटाबेसमा राख्छौं। तर हामीलाई API गेटवे चाहिन्छ जसले यो डाटालाई सिङ्क्रोनाइज गर्नेछ र ग्राहकलाई कहाँ र के बाट प्राप्त गर्ने भनेर देखाउनेछ।

दुबै दृष्टिकोणले काम गर्दछ, परिस्थिति अनुसार छनौट गर्नुहोस्।

हामीले सबै कुरा काम गर्छ भन्ने पक्का गरेपछि, पुरानो डाटाबेस संरचनाहरूसँग काम गर्ने मोनोलिथको भाग असक्षम गर्न सकिन्छ।

अन्तिम चरण पुरानो डाटा संरचना हटाउन हो।

संक्षेपमा, हामी भन्न सक्छौं कि हामीसँग डाटाबेसमा समस्याहरू छन्: स्रोत कोडको तुलनामा योसँग काम गर्न गाह्रो छ, साझेदारी गर्न गाह्रो छ, तर यो गर्न सकिन्छ र गर्नुपर्छ। हामीले केही तरिकाहरू फेला पारेका छौं जसले हामीलाई यो धेरै सुरक्षित रूपमा गर्न अनुमति दिन्छ, तर स्रोत कोड भन्दा डाटासँग गल्ती गर्न अझै सजिलो छ।

स्रोत कोडसँग काम गर्दै

हामीले मोनोलिथिक परियोजनाको विश्लेषण सुरु गर्दा स्रोत कोड रेखाचित्र जस्तो देखिन्थ्यो।

यसलाई लगभग तीन तहमा विभाजन गर्न सकिन्छ। यो सुरु गरिएको मोड्युल, प्लगइन, सेवा र व्यक्तिगत गतिविधिहरूको एक तह हो। वास्तवमा, यी एक मोनोलिथिक समाधान भित्र प्रवेश बिन्दुहरू थिए। ती सबैलाई सामान्य तहले कडा रूपमा बन्द गरिएको थियो। यो व्यापार तर्क थियो कि सेवाहरु साझा र धेरै जडानहरु। प्रत्येक सेवा र प्लगइनको आकार र विकासकर्ताहरूको विवेकमा निर्भर गर्दै, १० वा बढी साधारण सभाहरू सम्म प्रयोग गरिन्छ।

हामी छुट्टै प्रयोग गर्न सकिने पूर्वाधार पुस्तकालयहरू पाउँदा भाग्यमानी थियौं।

कहिलेकाहीँ यस्तो अवस्था उत्पन्न हुन्छ जब केही सामान्य वस्तुहरू वास्तवमा यस तहसँग सम्बन्धित थिएनन्, तर पूर्वाधार पुस्तकालयहरू थिए। यो पुन: नामकरण गरेर हल भयो।

सबैभन्दा ठूलो चिन्ता सीमाबद्ध सन्दर्भ थियो। यो भयो कि 3-4 सन्दर्भहरू एक साझा सभामा मिश्रित थिए र एउटै व्यापार कार्यहरूमा एकअर्का प्रयोग गरियो। यसलाई कहाँ र कुन सीमामा विभाजन गर्न सकिन्छ र यस विभाजनलाई स्रोत कोड एसेम्बलीहरूमा नक्साङ्कन गर्दा के गर्ने भन्ने कुरा बुझ्न आवश्यक थियो।

हामीले कोड विभाजन प्रक्रियाका लागि धेरै नियमहरू बनाएका छौं।

पहिलो: हामी अब सेवाहरू, गतिविधिहरू र प्लगइनहरू बीच व्यापार तर्क साझा गर्न चाहँदैनौं। हामी माइक्रोसर्भिसेस भित्र व्यापार तर्क स्वतन्त्र बनाउन चाहन्छौं। अर्कोतर्फ, माइक्रोसर्भिसेसहरूलाई पूर्ण रूपमा स्वतन्त्र रूपमा अवस्थित सेवाहरूको रूपमा आदर्श रूपमा सोचिन्छ। मलाई विश्वास छ कि यो दृष्टिकोण केहि बेकार छ, र यो प्राप्त गर्न गाह्रो छ, किनकि, उदाहरण को लागी, C# मा सेवाहरू कुनै पनि अवस्थामा मानक पुस्तकालय द्वारा जडान हुनेछ। हाम्रो प्रणाली C# मा लेखिएको छ; हामीले अझै अन्य प्रविधिहरू प्रयोग गरेका छैनौं। त्यसकारण, हामीले साझा प्राविधिक सम्मेलनहरू प्रयोग गर्न सक्ने निर्णय गर्यौं। मुख्य कुरा यो हो कि तिनीहरूले व्यापार तर्कको कुनै टुक्राहरू समावेश गर्दैनन्। यदि तपाइँसँग तपाइँले प्रयोग गरिरहनु भएको ORM मा सुविधा र्यापर छ भने, त्यसपछि यसलाई सेवाबाट सेवामा प्रतिलिपि गर्न धेरै महँगो छ।

हाम्रो टोली डोमेन-संचालित डिजाइनको प्रशंसक हो, त्यसैले प्याज वास्तुकला हाम्रो लागि उत्कृष्ट फिट थियो। हाम्रा सेवाहरूको आधार डाटा पहुँच तह होइन, तर डोमेन तर्कको साथ एक सम्मेलन हो, जसमा केवल व्यापार तर्क समावेश छ र पूर्वाधारसँग कुनै जडान छैन। एकै समयमा, हामी फ्रेमवर्कसँग सम्बन्धित समस्याहरू समाधान गर्न डोमेन असेंबलीलाई स्वतन्त्र रूपमा परिमार्जन गर्न सक्छौं।

यस चरणमा हामीले हाम्रो पहिलो गम्भीर समस्याको सामना गर्यौं। सेवाले एउटा डोमेन एसेम्बलीलाई सन्दर्भ गर्नु पर्ने थियो, हामी तर्कलाई स्वतन्त्र बनाउन चाहन्थ्यौं, र DRY सिद्धान्तले हामीलाई यहाँ धेरै बाधा पुर्यायो। विकासकर्ताहरूले नक्कलबाट बच्न छिमेकी सभाहरूबाट कक्षाहरू पुन: प्रयोग गर्न चाहन्थे, र परिणाम स्वरूप, डोमेनहरू फेरि एकसाथ जोडिन थाले। हामीले परिणामहरू विश्लेषण गर्यौं र निर्णय गर्यौं कि सायद समस्या स्रोत कोड भण्डारण उपकरणको क्षेत्रमा पनि छ। हामीसँग सबै स्रोत कोड भएको ठूलो भण्डार थियो। सम्पूर्ण परियोजनाको समाधान स्थानीय मेसिनमा भेला गर्न धेरै गाह्रो थियो। त्यसकारण, परियोजनाका भागहरूका लागि अलग-अलग साना समाधानहरू सिर्जना गरियो, र कसैले पनि तिनीहरूलाई केही साझा वा डोमेन असेम्बली थप्न र तिनीहरूलाई पुन: प्रयोग गर्न निषेध गरेन। एक मात्र उपकरण जसले हामीलाई यो गर्न अनुमति दिँदैन कोड समीक्षा थियो। तर कहिले काहिँ असफल पनि हुन्छ ।

त्यसपछि हामी छुट्टै रिपोजिटरीहरूको साथ मोडेलमा जान थाल्यौं। व्यापार तर्क अब सेवाबाट सेवामा प्रवाह गर्दैन, डोमेनहरू साँच्चै स्वतन्त्र भएका छन्। सीमाबद्ध सन्दर्भहरू अझ स्पष्ट रूपमा समर्थित छन्। हामी कसरी पूर्वाधार पुस्तकालयहरू पुन: प्रयोग गर्छौं? हामीले तिनीहरूलाई छुट्टै भण्डारमा अलग गर्यौं, त्यसपछि तिनीहरूलाई Nuget प्याकेजहरूमा राख्यौं, जुन हामीले आर्टिफ्याक्ट्रीमा राख्यौं। कुनै पनि परिवर्तन संग, विधानसभा र प्रकाशन स्वतः हुन्छ।

हाम्रा सेवाहरूले आन्तरिक पूर्वाधार प्याकेजहरूलाई बाह्य जस्तै रूपमा सन्दर्भ गर्न थाले। हामी Nuget बाट बाह्य पुस्तकालयहरू डाउनलोड गर्छौं। आर्टिफ्याक्ट्रीसँग काम गर्न, जहाँ हामीले यी प्याकेजहरू राख्यौं, हामीले दुई प्याकेज प्रबन्धकहरू प्रयोग गर्यौं। साना रिपोजिटरीहरूमा हामीले नुगेट पनि प्रयोग गर्यौं। धेरै सेवाहरूसँग भण्डारहरूमा, हामीले Paket प्रयोग गर्यौं, जसले मोड्युलहरू बीच थप संस्करण स्थिरता प्रदान गर्दछ।

यसरी, स्रोत कोडमा काम गरेर, वास्तुकलालाई थोरै परिवर्तन गरेर र भण्डारहरू अलग गरेर, हामी हाम्रा सेवाहरूलाई थप स्वतन्त्र बनाउँछौं।

पूर्वाधार समस्याहरू

माइक्रो सर्भिसेजमा सर्ने अधिकांश नकारात्मक पक्षहरू पूर्वाधारसँग सम्बन्धित छन्। तपाईलाई स्वचालित परिनियोजन चाहिन्छ, तपाईलाई पूर्वाधार चलाउन नयाँ पुस्तकालयहरू चाहिन्छ।

वातावरणमा म्यानुअल स्थापना

सुरुमा, हामीले म्यानुअल रूपमा वातावरणको लागि समाधान स्थापना गर्यौं। यस प्रक्रियालाई स्वचालित बनाउन, हामीले CI/CD पाइपलाइन सिर्जना गर्यौं। हामीले निरन्तर डेलिभरी प्रक्रिया छनोट गर्‍यौं किनभने निरन्तर डिप्लोइमेन्ट हाम्रो लागि व्यापार प्रक्रियाहरूको दृष्टिकोणबाट स्वीकार्य छैन। त्यसकारण, अपरेशनको लागि पठाउने बटन प्रयोग गरी गरिन्छ, र परीक्षणको लागि - स्वचालित रूपमा।

हामी स्रोत कोड भण्डारणको लागि एटलासियन, बिटबकेट र निर्माणको लागि बाँस प्रयोग गर्छौं। हामी केकमा बिल्ड स्क्रिप्टहरू लेख्न चाहन्छौं किनभने यो C# जस्तै हो। रेडिमेड प्याकेजहरू आर्टिफ्याक्ट्रीमा आउँछन्, र Ansible स्वचालित रूपमा परीक्षण सर्भरहरूमा पुग्छ, त्यसपछि तिनीहरू तुरुन्तै परीक्षण गर्न सकिन्छ।

अलग लगिङ

एक समयमा, मोनोलिथको विचारहरू मध्ये एक साझा लगिङ प्रदान गर्नु थियो। हामीले डिस्कमा भएका व्यक्तिगत लगहरूसँग के गर्ने भनेर पनि बुझ्न आवश्यक छ। हाम्रा लगहरू पाठ फाइलहरूमा लेखिएका छन्। हामीले मानक ELK स्ट्याक प्रयोग गर्ने निर्णय गर्यौं। हामीले प्रदायकहरू मार्फत ELK लाई सीधै लेखेका छैनौं, तर हामीले पाठ लगहरू परिमार्जन गर्ने र तिनीहरूमा सेवाको नाम थपेर ट्रेस ID लेख्ने निर्णय गर्यौं, ताकि यी लगहरूलाई पछि पार्स गर्न सकियोस्।

फाइलबिट प्रयोग गरेर, हामीले सर्भरहरूबाट हाम्रा लगहरू सङ्कलन गर्ने, त्यसपछि तिनीहरूलाई रूपान्तरण गर्ने, UI मा प्रश्नहरू निर्माण गर्न किबाना प्रयोग गर्ने र सेवाहरू बीचको कल कसरी भयो भनेर हेर्ने अवसर पाउँछौं। ट्रेस ID ले यससँग धेरै मद्दत गर्दछ।

परीक्षण र डिबग सम्बन्धित सेवाहरू

सुरुमा, हामीले विकास भइरहेको सेवाहरू कसरी डिबग गर्ने भनेर पूर्ण रूपमा बुझेका थिएनौं। मोनोलिथसँग सबै कुरा सरल थियो; हामीले यसलाई स्थानीय मेसिनमा चलायौं। सुरुमा तिनीहरूले माइक्रोसर्विसेसको साथ पनि यस्तै गर्ने प्रयास गरे, तर कहिलेकाहीँ एक माइक्रोसर्भिस पूर्ण रूपमा सुरू गर्न तपाईंले अरू धेरै सुरू गर्न आवश्यक छ, र यो असुविधाजनक छ। हामीले डिबग गर्न चाहने सेवा वा सेवाहरू मात्र स्थानीय मेसिनमा छोड्ने मोडेलमा जान आवश्यक छ भनेर हामीले महसुस गर्यौं। बाँकी सेवाहरू प्रोडसँग कन्फिगरेसनसँग मेल खाने सर्भरहरूबाट प्रयोग गरिन्छ। डिबग गरिसकेपछि, परीक्षणको क्रममा, प्रत्येक कार्यको लागि, परिवर्तन गरिएका सेवाहरू मात्र परीक्षण सर्भरमा जारी गरिन्छ। यसैले, समाधान फारममा परीक्षण गरिएको छ जसमा यो भविष्यमा उत्पादनमा देखा पर्नेछ।

त्यहाँ सर्भरहरू छन् जुन सेवाहरूको उत्पादन संस्करणहरू मात्र चलाउँछन्। यी सर्भरहरू घटनाहरूको मामलामा, डिप्लोइमेन्ट अघि डेलिभरी जाँच गर्न र आन्तरिक प्रशिक्षणको लागि आवश्यक हुन्छ।

हामीले लोकप्रिय Specflow पुस्तकालय प्रयोग गरेर स्वचालित परीक्षण प्रक्रिया थपेका छौं। Ansible बाट परिनियोजन पछि तुरुन्तै NUnit प्रयोग गरेर परीक्षणहरू स्वचालित रूपमा चल्छन्। यदि कार्य कभरेज पूर्ण रूपमा स्वचालित छ भने, त्यहाँ म्यानुअल परीक्षणको लागि कुनै आवश्यकता छैन। यद्यपि कहिलेकाहीँ अतिरिक्त म्यानुअल परीक्षण अझै आवश्यक छ। हामी जिरामा ट्यागहरू प्रयोग गर्छौं जुन निश्चित मुद्दाको लागि कुन परीक्षणहरू चलाउने भनेर निर्धारण गर्न।

थप रूपमा, लोड परीक्षणको आवश्यकता बढेको छ; पहिले यो दुर्लभ अवस्थामा मात्र गरिएको थियो। हामी परीक्षणहरू चलाउन JMeter, भण्डारण गर्न InfluxDB र प्रक्रिया ग्राफहरू बनाउन Grafana प्रयोग गर्छौं।

हामीले के हासिल गरेका छौं?

पहिलो, हामीले "रिलिज" को अवधारणाबाट छुटकारा पायौं। यो कोलोसस उत्पादन वातावरणमा तैनाथ गरिएको थियो, अस्थायी रूपमा व्यापार प्रक्रियाहरू अवरुद्ध हुँदा दुई-महिनाको राक्षसी रिलीजहरू गए। अब हामी प्रत्येक 1,5 दिनमा औसतमा सेवाहरू प्रयोग गर्छौं, तिनीहरूलाई समूहबद्ध गर्दै किनभने तिनीहरू अनुमोदन पछि सञ्चालनमा जान्छन्।

हाम्रो प्रणालीमा कुनै घातक विफलताहरू छैनन्। यदि हामीले बगको साथ माइक्रोसर्भिस जारी गर्यौं भने, त्यससँग सम्बन्धित कार्यक्षमता बिग्रिनेछ, र अन्य सबै प्रकार्यहरू प्रभावित हुने छैनन्। यसले प्रयोगकर्ता अनुभवलाई धेरै सुधार गर्दछ।

हामी तैनाती ढाँचा नियन्त्रण गर्न सक्छौं। यदि आवश्यक भएमा, तपाईंले सेवाहरूको समूहलाई बाँकी समाधानबाट अलग रूपमा चयन गर्न सक्नुहुन्छ।

थप रूपमा, हामीले सुधारहरूको ठूलो लाइनको साथ समस्यालाई उल्लेखनीय रूपमा कम गरेका छौं। हामीसँग अब छुट्टै उत्पादन टोलीहरू छन् जसले केही सेवाहरूसँग स्वतन्त्र रूपमा काम गर्छन्। Scrum प्रक्रिया पहिले नै यहाँ राम्रो फिट छ। एक विशिष्ट टोलीसँग छुट्टै उत्पादन मालिक हुन सक्छ जसले यसलाई कार्यहरू तोक्छ।

सारांश

• सूक्ष्म सेवाहरू जटिल प्रणालीहरू विघटन गर्नका लागि उपयुक्त छन्। प्रक्रियामा, हामीले हाम्रो प्रणालीमा के छ, त्यहाँ के सीमित सन्दर्भहरू छन्, तिनीहरूको सीमाहरू कहाँ छन् भनेर बुझ्न थाल्छौं। यसले तपाइँलाई मोड्युलहरू बीच सुधारहरू वितरण गर्न र कोड भ्रम रोक्न अनुमति दिन्छ।
• लघु सेवाहरूले संगठनात्मक लाभहरू प्रदान गर्दछ। तिनीहरू प्राय: वास्तुकलाको रूपमा मात्र कुरा गरिन्छ, तर कुनै पनि वास्तुकला व्यवसाय आवश्यकताहरू समाधान गर्न आवश्यक छ, र आफ्नै मा होइन। त्यसकारण, हामी भन्न सक्छौं कि माइक्रोसर्भिसेसहरू साना टोलीहरूमा समस्याहरू समाधान गर्नका लागि उपयुक्त छन्, स्क्रम अहिले धेरै लोकप्रिय छ।
• विभाजन एक पुनरावृत्ति प्रक्रिया हो। तपाईले एउटा अनुप्रयोग लिन सक्नुहुन्न र यसलाई माइक्रोसर्भिसेसमा विभाजन गर्न सक्नुहुन्छ। नतिजा उत्पादन कार्यात्मक हुन सम्भव छैन। माइक्रोसर्भिसेसहरू समर्पित गर्दा, अवस्थित विरासतलाई पुन: लेख्न लाभदायक हुन्छ, अर्थात्, यसलाई हामीले मनपर्ने कोडमा परिणत गर्छ र कार्यक्षमता र गतिको सन्दर्भमा व्यापार आवश्यकताहरू अझ राम्रोसँग पूरा गर्दछ।

  एउटा सानो चेतावनी: माइक्रो सर्भिसहरूमा सर्ने लागतहरू धेरै महत्त्वपूर्ण छन्। पूर्वाधारको समस्या मात्रै समाधान गर्न लामो समय लाग्यो । त्यसोभए यदि तपाइँसँग एउटा सानो अनुप्रयोग छ जसलाई विशिष्ट स्केलिङको आवश्यकता पर्दैन, जबसम्म तपाइँसँग तपाइँको टोलीको ध्यान र समयको लागि प्रतिस्पर्धा गर्ने ग्राहकहरूको ठूलो संख्या छैन, तब माइक्रोसेवाहरू तपाइँलाई आज आवश्यक नहुन सक्छ। यो एकदम महँगो छ। यदि तपाईले माइक्रोसर्भिसेसको साथ प्रक्रिया सुरु गर्नुभयो भने, लागत सुरुमा तपाईले मोनोलिथको विकासको साथ एउटै परियोजना सुरु गर्दा भन्दा बढी हुनेछ।

  PS थप भावनात्मक कथा (र व्यक्तिगत रूपमा तपाईंको लागि जस्तै) - अनुसार लिङ्क.
  यहाँ रिपोर्टको पूर्ण संस्करण छ।

स्रोत: www.habr.com