माइक्रोसर्विसेज में कॉमन कोड इश्यूज

सभी को नमस्कार!

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

माइक्रोसर्विस क्या है? यह एक स्टैंडअलोन एप्लिकेशन है। एक मॉड्यूल नहीं, एक प्रक्रिया नहीं, कुछ ऐसा नहीं जो केवल अलग से तैनात किया गया हो, बल्कि एक पूर्ण, वास्तविक, अलग अनुप्रयोग। इसका अपना मुख्य कार्य है, गिट में अपना भंडार, अपना परीक्षण, अपना एपीआई, अपना स्वयं का वेब सर्वर, अपना README फ़ाइल, अपना स्वयं का डेटाबेस, इसका अपना संस्करण, अपने स्वयं के डेवलपर्स।

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

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

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

क) बहुत संवेदनशील रूप से इसके एपीआई पर नज़र रखता है, क्योंकि यह एकमात्र घटक है जो बाहर से दिखाई देता है;
ख) रिफैक्टरिंग में पूरी तरह से मुक्त महसूस होता है;
ग) माइक्रोसैस सर्विस के उद्देश्य को समझें (यहाँ हम SRP के बारे में याद करते हैं) और उसी के अनुसार एक नया कार्य लागू करते हैं;
डी) दृढ़ता विधि का चयन करता है जो सबसे उपयुक्त है;
आदि

यह सब अच्छा है और कई विचारधाराओं और सिद्धांतों की तरह तार्किक और सामंजस्यपूर्ण लगता है (और यहां वैचारिक सिद्धांतकार अंत करता है और रात के खाने पर जाता है), लेकिन हम अभ्यास कर रहे हैं। कोड को martinfowler.com पर नहीं लिखा जाना चाहिए। और जितनी जल्दी या बाद में हमें इस तथ्य का सामना करना पड़ रहा है कि सभी माइक्रोसर्विसेस:

• लॉग जानकारी;
• प्राधिकरण में शामिल हैं;
• संदेश दलालों तक पहुंचें
• सही त्रुटि संदेश लौटाएं;
• किसी भी तरह सिस्टम में सामान्य संस्थाओं को समझना चाहिए, यदि कोई हो;
• एक सामान्य संदेश प्रारूप (और प्रोटोकॉल) के साथ काम करना चाहिए;

और इसे पहचान के साथ करें।

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

यह निर्भर करता है।

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

1. उपयोगकर्ता वर्ग (या कुछ अन्य व्यावसायिक इकाई) पुस्तकालय में रहता है।

• यानी एक व्यावसायिक इकाई एक माइक्रोसेवा में बंद नहीं है, लेकिन अलग तरीके से फैल गई है (अन्यथा इसे साझा कोड लाइब्रेरी में क्यों रखा गया है?);
• यानी इस व्यावसायिक इकाई के माध्यम से माइक्रोसर्विसेज जुड़े हुए हैं, एक इकाई के साथ काम करने के तर्क को बदलने से कई माइक्रोसेवा प्रभावित होंगे;
• यह बहुत बुरा है, यह बहुत सूक्ष्म है, हालांकि यह "मिट्टी की बड़ी गेंद" नहीं है, लेकिन बहुत जल्दी टीम की विश्वदृष्टि "वितरित मिट्टी की बड़ी गेंद" को जन्म देगी;
• लेकिन सिस्टम में microservices एक ही अवधारणाओं के साथ काम करते हैं, और अवधारणाएं अक्सर इकाइयां हैं, या खेतों के साथ सिर्फ संरचनाएं हैं, मुझे क्या करना चाहिए? DDD को पढ़ें, यह वास्तव में माइक्रोसॉफ़्ट के अंदर संस्थाओं को कैसे एनकैप्सुलेट करना है, इसके लिए वे API के माध्यम से "फ्लाई" नहीं करते हैं।

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

2. संदेश प्रारूप के लिए पार्सिंग कोड पुस्तकालय में रखा गया है।

• यदि जावा में सभी माइक्रोसर्विसेज लिखे गए हैं तो कोड जावा में सबसे अधिक संभावना है;
• यदि कल मैं पायथन में एक सेवा लिखता हूं, तो मैं पार्सर का उपयोग नहीं कर पाऊंगा, लेकिन ऐसा लगता है कि यह बिल्कुल भी समस्या नहीं है, मैं पायथन संस्करण लिखूंगा;
• मुख्य बिंदु: यदि मैं जावा में एक नया माइक्रोसेवा लिख ​​रहा हूं, तो क्या मुझे इस पार्सर का उपयोग करने की आवश्यकता है? हाँ, शायद नहीं। शायद मैं इसके लिए बाध्य नहीं हूँ, हालाँकि यह एक माइक्रोसेवर डेवलपर के रूप में बहुत उपयोगी हो सकता है। खैर, जैसे कि मुझे मावेन रिपॉजिटरी में कुछ उपयोगी मिला।

एक संदेश पार्सर, या एक बेहतर लकड़हारा, या एक लिपटे ग्राहक को RabbitMQ के लिए डेटा भेजने के लिए - यह सहायक, सहायक घटकों की तरह है। वे नुगेट, मावेन या एनपीएम से मानक पुस्तकालयों के बराबर हैं। माइक्रोसेवर डेवलपर हमेशा राजा होता है; वह तय करता है कि मानक पुस्तकालय का उपयोग करना है, या अपना नया कोड बनाना है, या साझा सहायक पुस्तकालय से कोड का उपयोग करना है। यह उसके लिए अधिक सुविधाजनक कैसे होगा, क्योंकि वह SEPARATE AND INDEPENDENT APP लिखता है। क्या कोई विशेष सहायक विकसित हो सकता है? शायद उसके पास शायद संस्करण होंगे। डेवलपर को उसकी सेवा में एक विशिष्ट संस्करण का उल्लेख करने दें, कोई भी उसे सेवा को अपडेट करने के लिए मजबूर नहीं करता है, जब हेल्पर्स को अपडेट करते हैं, तो यह एक सवाल है कि कौन सेवा का समर्थन करता है।

3. जावा इंटरफ़ेस, सार आधार वर्ग, विशेषता।

• या "कोड के फटे हुए टुकड़े" की श्रेणी से एक और टुकड़ा;
• यानी मैं यहाँ स्वतंत्र और स्वतंत्र हूँ, और मेरे जिगर का एक टुकड़ा कहीं और निहित है;
• यहां कोड स्तर पर माइक्रोसर्विस का सामंजस्य दिखाई देता है, इसलिए हम इसकी अनुशंसा नहीं करेंगे;
• प्रारंभिक चरणों में, यह संभवतः कोई ठोस समस्या नहीं लाएगा, लेकिन आने वाले वर्षों के लिए वास्तुकला डिजाइन का सार आराम (या असुविधा) की गारंटी है।

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

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

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

अनुशंसा 1: यह अत्यधिक वांछनीय है कि माइक्रोसिस्टम का कोई समान कोड नहीं है।

सिफारिश 2: यदि अभी भी एक समान कोड है, तो इसे वैकल्पिक "सहायकों" का एक संग्रह (पुस्तकालय) बनने दें। सेवा डेवलपर यह तय करता है कि उनका उपयोग करना है या अपना कोड लिखना है।

सिफारिश 3: किसी भी परिस्थिति में सामान्य कोड में व्यावसायिक तर्क नहीं होना चाहिए। सभी व्यावसायिक तर्क microservices में समझाया जाता है।

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

अनुशंसा 5: सिस्टम का "तार्किक गुरुत्वाकर्षण का केंद्र" हमेशा माइक्रोसर्विसेस में ही रहना चाहिए, न कि कॉमन कोड में।

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

आपका ध्यान और सफल microservices के लिए धन्यवाद।