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

इस लेख में, मैं इस बारे में बात करूंगा कि जिस प्रोजेक्ट पर मैं काम कर रहा हूं वह एक बड़े मोनोलिथ से माइक्रोसर्विसेज के एक सेट में कैसे बदल गया।

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

इस संयोजन के कुछ फायदों में से एक बाहरी एपीआई के माध्यम से एक-दूसरे को कॉल करने की सेवाओं की क्षमता थी। अधिक सही सेवा और भविष्य में माइक्रोसर्विस आर्किटेक्चर में परिवर्तन के लिए स्पष्ट पूर्वापेक्षाएँ थीं।

हमने 2015 के आसपास अपघटन पर अपना काम शुरू किया। हम अभी तक एक आदर्श स्थिति में नहीं पहुंचे हैं - अभी भी एक बड़ी परियोजना के कुछ हिस्से हैं जिन्हें शायद ही मोनोलिथ कहा जा सकता है, लेकिन वे माइक्रोसर्विसेज की तरह भी नहीं दिखते हैं। फिर भी, प्रगति महत्वपूर्ण है.
मैं इसके बारे में लेख में बात करूंगा।

सामग्री

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

मौजूदा समाधान की वास्तुकला और समस्याएं

प्रारंभ में, आर्किटेक्चर इस तरह दिखता था: यूआई एक अलग एप्लिकेशन है, मोनोलिथिक भाग विजुअल बेसिक 6 में लिखा गया है, .NET एप्लिकेशन काफी बड़े डेटाबेस के साथ काम करने वाली संबंधित सेवाओं का एक सेट है।

पिछले समाधान के नुकसान

विफलता का एकल बिंदु
हमारी विफलता का एक ही बिंदु था: .NET एप्लिकेशन एक ही प्रक्रिया में चलता था। यदि कोई मॉड्यूल विफल हो जाता है, तो संपूर्ण एप्लिकेशन विफल हो जाता है और उसे पुनः आरंभ करना पड़ता है। चूँकि हम विभिन्न उपयोगकर्ताओं के लिए बड़ी संख्या में प्रक्रियाओं को स्वचालित करते हैं, उनमें से एक में विफलता के कारण, हर कोई कुछ समय के लिए काम नहीं कर सका। और सॉफ़्टवेयर त्रुटि के मामले में, बैकअप से भी मदद नहीं मिली।

सुधारों की कतार
यह कमी बल्कि संगठनात्मक है. हमारे एप्लिकेशन के कई ग्राहक हैं, और वे सभी इसे जल्द से जल्द सुधारना चाहते हैं। पहले, समानांतर में ऐसा करना असंभव था, और सभी ग्राहक लाइन में खड़े थे। यह प्रक्रिया व्यवसायों के लिए नकारात्मक थी क्योंकि उन्हें यह साबित करना था कि उनका कार्य मूल्यवान था। और विकास टीम ने इस कतार को व्यवस्थित करने में समय बिताया। इसमें बहुत समय और प्रयास लगा, और उत्पाद अंततः उतनी तेज़ी से नहीं बदल सका जितना वे चाहते थे।

संसाधनों का न्यूनतम उपयोग
एक ही प्रक्रिया में सेवाओं को होस्ट करते समय, हम हमेशा कॉन्फ़िगरेशन को सर्वर से सर्वर पर पूरी तरह से कॉपी करते हैं। हम सबसे अधिक भरी हुई सेवाओं को अलग से रखना चाहते थे ताकि संसाधनों की बर्बादी न हो और हमारी तैनाती योजना पर अधिक लचीला नियंत्रण प्राप्त हो सके।

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

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

माइक्रोसर्विसेज से उम्मीदें

तैयार होने पर घटकों को जारी करना। समाधान को विघटित करके और विभिन्न प्रक्रियाओं को अलग करके तैयार होने पर घटकों की डिलीवरी।

छोटी उत्पाद टीमें. यह महत्वपूर्ण है क्योंकि पुराने मोनोलिथ पर काम करने वाली एक बड़ी टीम को प्रबंधित करना मुश्किल था। ऐसी टीम को एक सख्त प्रक्रिया के अनुसार काम करने के लिए मजबूर किया गया था, लेकिन वे अधिक रचनात्मकता और स्वतंत्रता चाहते थे। केवल छोटी टीमें ही इसे वहन कर सकती थीं।

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

परिनियोजन लचीलापन. हम सेवाओं को उस तरीके से संयोजित करना चाहेंगे जिस तरह से हमें इसकी आवश्यकता है, न कि जिस तरह से कोड इसे मजबूर करता है।

नई तकनीकों का प्रयोग. यह किसी भी प्रोग्रामर के लिए दिलचस्प है।

संक्रमण की समस्याएँ

बेशक, अगर एक मोनोलिथ को माइक्रोसर्विसेज में तोड़ना आसान होता, तो सम्मेलनों में इसके बारे में बात करने और लेख लिखने की कोई आवश्यकता नहीं होती। इस प्रक्रिया में कई कमियाँ हैं; मैं उनमें से मुख्य का वर्णन करूँगा जो हमारे लिए बाधा बनीं।

पहली समस्या अधिकांश मोनोलिथ के लिए विशिष्ट: व्यावसायिक तर्क की सुसंगतता। जब हम एक मोनोलिथ लिखते हैं, तो हम अपनी कक्षाओं का पुन: उपयोग करना चाहते हैं ताकि अनावश्यक कोड न लिखें। और जब माइक्रोसर्विसेज की ओर बढ़ते हैं, तो यह एक समस्या बन जाती है: सभी कोड काफी मजबूती से जुड़े होते हैं, और सेवाओं को अलग करना मुश्किल होता है।

काम की शुरुआत के समय, रिपॉजिटरी में 500 से अधिक परियोजनाएं और कोड की 700 हजार से अधिक लाइनें थीं। ये काफी बड़ा फैसला है और दूसरी समस्या. इसे आसानी से लेना और इसे माइक्रोसर्विसेज में विभाजित करना संभव नहीं था।

तीसरी समस्या -आवश्यक बुनियादी ढांचे की कमी. वास्तव में, हम मैन्युअल रूप से स्रोत कोड को सर्वर पर कॉपी कर रहे थे।

मोनोलिथ से माइक्रोसर्विसेज की ओर कैसे जाएं

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

सबसे पहले, हमने तुरंत अपने लिए निर्धारित किया कि माइक्रोसर्विसेज को अलग करना एक पुनरावृत्तीय प्रक्रिया है। हमें हमेशा व्यावसायिक समस्याओं को समानांतर रूप से विकसित करने की आवश्यकता होती थी। हम इसे तकनीकी रूप से कैसे लागू करेंगे यह पहले से ही हमारी समस्या है। इसलिए, हमने एक पुनरावृत्तीय प्रक्रिया के लिए तैयारी की। यदि आपके पास एक बड़ा एप्लिकेशन है और यह शुरू में दोबारा लिखे जाने के लिए तैयार नहीं है तो यह किसी अन्य तरीके से काम नहीं करेगा।

माइक्रोसर्विसेज को अलग करने के लिए हम किन तरीकों का उपयोग करते हैं?

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

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

होस्ट के साथ असेंबली प्रोग्राम क्लास में कोड की सिर्फ एक पंक्ति है। हमने टॉपशेल्फ़ के साथ एक सहायक कक्षा में काम छुपाया।

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

       }
    }
}

माइक्रोसर्विसेज आवंटित करने का दूसरा तरीका है: नई समस्याओं को हल करने के लिए उन्हें बनाएँ। यदि उसी समय मोनोलिथ नहीं बढ़ता है, तो यह पहले से ही उत्कृष्ट है, जिसका अर्थ है कि हम सही दिशा में आगे बढ़ रहे हैं। नई समस्याओं को हल करने के लिए, हमने अलग सेवाएँ बनाने का प्रयास किया। यदि ऐसा कोई अवसर होता, तो हमने अधिक "कैनोनिकल" सेवाएँ बनाईं जो पूरी तरह से अपने स्वयं के डेटा मॉडल, एक अलग डेटाबेस का प्रबंधन करती हैं।

हमने, कई लोगों की तरह, प्रमाणीकरण और प्राधिकरण सेवाओं के साथ शुरुआत की। वे इसके लिए बिल्कुल उपयुक्त हैं. वे स्वतंत्र हैं, एक नियम के रूप में, उनके पास एक अलग डेटा मॉडल है। वे स्वयं मोनोलिथ के साथ बातचीत नहीं करते हैं, केवल कुछ समस्याओं को हल करने के लिए यह उनकी ओर मुड़ता है। इन सेवाओं का उपयोग करके, आप एक नए आर्किटेक्चर में परिवर्तन शुरू कर सकते हैं, उन पर बुनियादी ढांचे को डीबग कर सकते हैं, नेटवर्क लाइब्रेरी से संबंधित कुछ दृष्टिकोण आज़मा सकते हैं, आदि। हमारे संगठन में ऐसी कोई टीम नहीं है जो प्रमाणीकरण सेवा न बना सके।

माइक्रोसर्विसेज आवंटित करने का तीसरा तरीकाजिसका हम उपयोग करते हैं वह हमारे लिए थोड़ा विशिष्ट है। यह यूआई परत से व्यावसायिक तर्क को हटाना है। हमारा मुख्य यूआई एप्लिकेशन डेस्कटॉप है; यह, बैकएंड की तरह, C# में लिखा गया है। डेवलपर्स ने समय-समय पर गलतियाँ कीं और तर्क के कुछ हिस्सों को यूआई में स्थानांतरित कर दिया जो बैकएंड में मौजूद होना चाहिए था और पुन: उपयोग किया जाना चाहिए था।

यदि आप यूआई भाग के कोड से एक वास्तविक उदाहरण देखते हैं, तो आप देख सकते हैं कि इस समाधान में से अधिकांश में वास्तविक व्यावसायिक तर्क शामिल हैं जो केवल यूआई फॉर्म के निर्माण के लिए ही नहीं, बल्कि अन्य प्रक्रियाओं में भी उपयोगी हैं।

वास्तविक यूआई तर्क केवल अंतिम कुछ पंक्तियों में है। हमने इसे सर्वर पर स्थानांतरित कर दिया ताकि इसका पुन: उपयोग किया जा सके, जिससे यूआई कम हो और सही आर्किटेक्चर प्राप्त हो सके।

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

सेवाओं को प्रसंस्करण से अलग करना बंधे हुए संदर्भ की अवधारणा से अटूट रूप से जुड़ा हुआ है। यह डोमेन संचालित डिज़ाइन की एक अवधारणा है। इसका मतलब डोमेन मॉडल का एक भाग है जिसमें एक ही भाषा के सभी शब्दों को विशिष्ट रूप से परिभाषित किया गया है। आइए उदाहरण के तौर पर बीमा और बिल के संदर्भ को देखें। हमारे पास एक अखंड अनुप्रयोग है, और हमें बीमा में खाते के साथ काम करने की आवश्यकता है। हम डेवलपर से अपेक्षा करते हैं कि वह किसी अन्य असेंबली में मौजूदा खाता वर्ग ढूंढे, उसे बीमा वर्ग से संदर्भित करे, और हमारे पास कार्यशील कोड होगा। DRY सिद्धांत का सम्मान किया जाएगा, मौजूदा कोड का उपयोग करके कार्य तेजी से किया जाएगा।

परिणामस्वरूप, यह पता चलता है कि खातों और बीमा के संदर्भ जुड़े हुए हैं। जैसे-जैसे नई आवश्यकताएं सामने आएंगी, यह युग्मन विकास में बाधा उत्पन्न करेगा, जिससे पहले से ही जटिल व्यावसायिक तर्क की जटिलता बढ़ जाएगी। इस समस्या को हल करने के लिए, आपको कोड में संदर्भों के बीच की सीमाओं को ढूंढना होगा और उनके उल्लंघनों को दूर करना होगा। उदाहरण के लिए, बीमा के संदर्भ में, यह बहुत संभव है कि 20 अंकों वाला सेंट्रल बैंक खाता नंबर और खाता खोलने की तारीख पर्याप्त होगी।

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

हमने दृढ़ता से निर्णय लिया कि हम उस कोड से नहीं बचेंगे जिसके लिए वितरित लेनदेन की आवश्यकता होगी। हमारे मामले में, इस नियम का पालन करना काफी आसान हो गया। हमने अभी तक ऐसी स्थितियों का सामना नहीं किया है जहां सख्त वितरित लेनदेन की वास्तव में आवश्यकता होती है - मॉड्यूल के बीच अंतिम स्थिरता काफी पर्याप्त है।

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

यदि ऐसी स्थिति उत्पन्न होती है जब डेटा के हिस्से को लगातार सहेजना आवश्यक होता है, तो हम संभवतः इसे एक प्रक्रिया में संसाधित करने के लिए सेवा के समेकन के लिए जाएंगे।

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

सबसे पहले, हम कोड को दोबारा लिखकर एक माइक्रोसर्विस बनाते हैं। हम कुछ पहलुओं में सुधार कर रहे हैं जिनसे हम खुश नहीं थे। हम ग्राहक से नई व्यावसायिक आवश्यकताओं को लागू करते हैं। हम यूआई और बैकएंड के बीच कनेक्शन में एक एपीआई गेटवे जोड़ते हैं, जो कॉल फ़ॉरवर्डिंग प्रदान करेगा।

इसके बाद, हम इस कॉन्फ़िगरेशन को संचालन में जारी करते हैं, लेकिन पायलट स्थिति में। हमारे अधिकांश उपयोगकर्ता अभी भी पुरानी व्यावसायिक प्रक्रियाओं के साथ काम करते हैं। नए उपयोगकर्ताओं के लिए, हम मोनोलिथिक एप्लिकेशन का एक नया संस्करण विकसित कर रहे हैं जिसमें अब यह प्रक्रिया शामिल नहीं है। अनिवार्य रूप से, हमारे पास पायलट के रूप में काम करने वाले एक मोनोलिथ और एक माइक्रोसर्विस का संयोजन है।

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

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

डेटाबेस के साथ कार्य करना

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

हमारे डेटाबेस में, कई अन्य लोगों की तरह, एक और महत्वपूर्ण खामी थी - इसका विशाल आकार। यह डेटाबेस एक मोनोलिथ के जटिल व्यावसायिक तर्क और विभिन्न बंधे हुए संदर्भों की तालिकाओं के बीच संचित संबंधों के अनुसार डिज़ाइन किया गया था।

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

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

हमने डेटाबेस विभाजन के दो वैश्विक तरीकों का उपयोग किया: मौजूदा तालिकाओं का विभाजन और प्रसंस्करण के साथ विभाजन।

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

प्रसंस्करण वाले एक विभाग की आवश्यकता तब होती है जब व्यवसाय मॉडल बहुत बदल गया है, और तालिकाएँ अब हमें बिल्कुल भी संतुष्ट नहीं करती हैं।

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

आइए कल्पना करें कि हमारे पास एक समाधान है जिसमें दो मोनोलिथ मॉड्यूल एक डेटाबेस के साथ इंटरैक्ट करते हैं। हमें यह सुनिश्चित करने की ज़रूरत है कि केवल एक मॉड्यूल अलग-अलग तालिकाओं के अनुभाग के साथ इंटरैक्ट करता है, और दूसरा एपीआई के माध्यम से इसके साथ इंटरैक्ट करना शुरू कर देता है। आरंभ करने के लिए, यह पर्याप्त है कि केवल एपीआई के माध्यम से रिकॉर्डिंग की जाए। माइक्रोसर्विसेज की स्वतंत्रता के बारे में बात करने के लिए यह एक आवश्यक शर्त है। रीडिंग कनेक्शन तब तक बना रह सकता है जब तक कोई बड़ी समस्या न हो।

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

बाद में हम इस कनेक्शन को हटा देंगे, यानी, अलग-अलग तालिकाओं से एक मोनोलिथिक एप्लिकेशन से डेटा पढ़ने को भी एपीआई में स्थानांतरित कर दिया जाएगा।

इसके बाद, हम सामान्य डेटाबेस से उन तालिकाओं का चयन करेंगे जिनके साथ केवल नया माइक्रोसर्विस काम करता है। हम तालिकाओं को एक अलग स्कीमा या यहां तक ​​कि एक अलग भौतिक डेटाबेस में भी स्थानांतरित कर सकते हैं। माइक्रोसर्विस और मोनोलिथ डेटाबेस के बीच अभी भी रीडिंग कनेक्शन है, लेकिन चिंता की कोई बात नहीं है, इस कॉन्फ़िगरेशन में यह काफी लंबे समय तक रह सकता है।

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

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

इस योजना को कार्यान्वित करने के लिए, हमें संभवतः एक संक्रमण अवधि की आवश्यकता होगी।

तब दो संभावित दृष्टिकोण हैं।

पहले: हम नए और पुराने डेटाबेस में सभी डेटा की नकल करते हैं। इस मामले में, हमारे पास डेटा अतिरेक है और सिंक्रनाइज़ेशन समस्याएं उत्पन्न हो सकती हैं। लेकिन हम दो अलग-अलग क्लाइंट ले सकते हैं। एक नए संस्करण के साथ काम करेगा, दूसरा पुराने के साथ।

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

दोनों दृष्टिकोण काम करते हैं, स्थिति के आधार पर चयन करें।

जब हम आश्वस्त हो जाते हैं कि सब कुछ काम करता है, तो मोनोलिथ का वह हिस्सा जो पुराने डेटाबेस संरचनाओं के साथ काम करता है, उसे निष्क्रिय किया जा सकता है।

अंतिम चरण पुरानी डेटा संरचनाओं को हटाना है।

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

स्रोत कोड के साथ कार्य करना

जब हमने मोनोलिथिक प्रोजेक्ट का विश्लेषण करना शुरू किया तो स्रोत कोड आरेख इस तरह दिखता था।

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

हम भाग्यशाली थे कि हमारे पास बुनियादी ढांचागत पुस्तकालय थे जिनका उपयोग अलग से किया जा सकता था।

कभी-कभी ऐसी स्थिति उत्पन्न हो जाती थी जब कुछ सामान्य वस्तुएँ वास्तव में इस परत से संबंधित नहीं होती थीं, बल्कि बुनियादी ढाँचा पुस्तकालय होती थीं। नाम बदलने से इसका समाधान हो गया.

सबसे बड़ी चिंता सीमित संदर्भों को लेकर थी। ऐसा हुआ कि 3-4 संदर्भों को एक सामान्य सभा में मिश्रित कर दिया गया और समान व्यावसायिक कार्यों में एक-दूसरे का उपयोग किया गया। यह समझना आवश्यक था कि इसे कहाँ और किन सीमाओं के साथ विभाजित किया जा सकता है, और इस विभाजन को स्रोत कोड असेंबली में मैप करने के साथ आगे क्या करना है।

हमने कोड विभाजन प्रक्रिया के लिए कई नियम बनाए हैं।

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

हमारी टीम डोमेन-संचालित डिज़ाइन की प्रशंसक है, इसलिए प्याज वास्तुकला हमारे लिए बहुत उपयुक्त थी। हमारी सेवाओं का आधार डेटा एक्सेस लेयर नहीं है, बल्कि डोमेन लॉजिक वाली एक असेंबली है, जिसमें केवल व्यावसायिक तर्क होते हैं और बुनियादी ढांचे से कोई संबंध नहीं होता है। साथ ही, हम फ्रेमवर्क से संबंधित समस्याओं को हल करने के लिए डोमेन असेंबली को स्वतंत्र रूप से संशोधित कर सकते हैं।

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

फिर हमने अलग-अलग रिपॉजिटरी वाले मॉडल की ओर बढ़ना शुरू किया। व्यावसायिक तर्क अब एक सेवा से दूसरी सेवा की ओर प्रवाहित नहीं होता, डोमेन वास्तव में स्वतंत्र हो गए हैं। बंधे हुए संदर्भ अधिक स्पष्ट रूप से समर्थित हैं। हम बुनियादी ढांचा पुस्तकालयों का पुन: उपयोग कैसे करते हैं? हमने उन्हें एक अलग भंडार में अलग कर दिया, फिर उन्हें नुगेट पैकेज में डाल दिया, जिसे हमने आर्टिफैक्टरी में डाल दिया। किसी भी परिवर्तन के साथ, संयोजन और प्रकाशन स्वचालित रूप से होता है।

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

इस प्रकार, स्रोत कोड पर काम करके, आर्किटेक्चर को थोड़ा बदलकर और रिपॉजिटरी को अलग करके, हम अपनी सेवाओं को और अधिक स्वतंत्र बनाते हैं।

बुनियादी ढांचे की समस्याएं

माइक्रोसर्विसेज में जाने के अधिकांश नुकसान बुनियादी ढांचे से संबंधित हैं। आपको स्वचालित तैनाती की आवश्यकता होगी, बुनियादी ढांचे को चलाने के लिए आपको नई लाइब्रेरी की आवश्यकता होगी।

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

प्रारंभ में, हमने परिवेशों के लिए समाधान मैन्युअल रूप से स्थापित किया। इस प्रक्रिया को स्वचालित करने के लिए, हमने एक सीआई/सीडी पाइपलाइन बनाई। हमने निरंतर वितरण प्रक्रिया को चुना क्योंकि व्यावसायिक प्रक्रियाओं के दृष्टिकोण से निरंतर तैनाती अभी भी हमारे लिए स्वीकार्य नहीं है। इसलिए, ऑपरेशन के लिए भेजना एक बटन का उपयोग करके किया जाता है, और परीक्षण के लिए - स्वचालित रूप से।

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

अलग लॉगिंग

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

फ़ाइलबीट का उपयोग करके, हमें सर्वर से अपने लॉग एकत्र करने, फिर उन्हें बदलने, यूआई में क्वेरीज़ बनाने के लिए किबाना का उपयोग करने और यह देखने का अवसर मिलता है कि सेवाओं के बीच कॉल कैसे हुई। ट्रेस आईडी इसमें बहुत मदद करती है।

संबंधित सेवाओं का परीक्षण और डिबगिंग

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

ऐसे सर्वर हैं जो केवल सेवाओं के उत्पादन संस्करण चलाते हैं। घटनाओं की स्थिति में, तैनाती से पहले डिलीवरी की जांच करने और आंतरिक प्रशिक्षण के लिए इन सर्वरों की आवश्यकता होती है।

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

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

हमने क्या हासिल किया है?

सबसे पहले, हमने "रिलीज़" की अवधारणा से छुटकारा पा लिया। वे दो महीने की भयानक रिलीज़ ख़त्म हो गईं जब इस विशाल को उत्पादन वातावरण में तैनात किया गया था, जो अस्थायी रूप से व्यावसायिक प्रक्रियाओं को बाधित कर रहा था। अब हम औसतन हर 1,5 दिन में सेवाओं को तैनात करते हैं, उन्हें समूहीकृत करते हैं क्योंकि वे अनुमोदन के बाद परिचालन में आते हैं।

हमारे सिस्टम में कोई घातक विफलता नहीं है। यदि हम बग के साथ एक माइक्रोसर्विस जारी करते हैं, तो उससे जुड़ी कार्यक्षमता टूट जाएगी, और अन्य सभी कार्यक्षमता प्रभावित नहीं होंगी। इससे उपयोगकर्ता अनुभव में काफी सुधार होता है।

हम परिनियोजन पैटर्न को नियंत्रित कर सकते हैं. यदि आवश्यक हो, तो आप शेष समाधान से अलग सेवाओं के समूहों का चयन कर सकते हैं।

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

सारांश

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

  एक छोटी सी चेतावनी: माइक्रोसर्विसेज में जाने की लागत काफी महत्वपूर्ण है। अकेले बुनियादी ढांचे की समस्या को हल करने में काफी समय लग गया। इसलिए यदि आपके पास एक छोटा एप्लिकेशन है जिसके लिए विशिष्ट स्केलिंग की आवश्यकता नहीं है, जब तक कि आपके पास अपनी टीम के ध्यान और समय के लिए प्रतिस्पर्धा करने वाले बड़ी संख्या में ग्राहक न हों, तो माइक्रोसर्विसेज वह नहीं हो सकती है जिसकी आपको आज आवश्यकता है। यह काफी महंगा है. यदि आप माइक्रोसर्विसेज के साथ प्रक्रिया शुरू करते हैं, तो शुरू में लागत एक मोनोलिथ के विकास के साथ एक ही परियोजना शुरू करने की तुलना में अधिक होगी।

  PS एक अधिक भावनात्मक कहानी (और मानो आपके लिए व्यक्तिगत रूप से) - के अनुसार लिंक.
  यहां रिपोर्ट का पूरा संस्करण है.

स्रोत: www.habr.com