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

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

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

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

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

सामग्री

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

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

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

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

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

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

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

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

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

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

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

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

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

परिनियोजन लचीलापन। मैं अपनी ज़रूरत के अनुसार सेवाओं को संयोजित करना चाहूंगा, न कि कोड बलों के रूप में।

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

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

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

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

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

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

मोनोलिथ से माइक्रोसर्विस में कैसे स्विच करें

माइक्रोसोर्स्ट आवंटन

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

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

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

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

होस्ट के साथ बिल्डिंग प्रोग्राम क्लास में कोड की एक लाइन है। हमने टॉपरफेल को एक सहायक वर्ग में छिपा दिया।

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

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

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

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

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



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

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

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

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

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

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

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

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

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



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



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



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



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

एक DB के साथ काम करें

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

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

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

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

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

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

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

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

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



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



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



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



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



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



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

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

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

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

दोनों दृष्टिकोण काम कर रहे हैं, स्थिति के अनुसार चुनें।

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



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



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

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

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



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

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

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

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

हमने कोड पृथक्करण प्रक्रिया के लिए कई नियम बनाए हैं।

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

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

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

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



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



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

इन्फ्रास्ट्रक्चर मुद्दे

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

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

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



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

अलग लॉगिंग

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



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

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

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

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

Specflow. NUnit Ansible. , . - . , , Jira.

, . JMeter, — InfluxDB, — Grafana.

?

-, «». , production-, -. 1,5 , , .

. , , . .

. , .

, . , . Scrum-. , .

• . , , , . .
• . , , . , , , Scrum.
• — . . . legacy, , .
  
  : . . , , , , , , , — , . . , , .
  
  PS ( ) – .
  .