सेवाएँ, माइक्रोसॉफ़्ट और बैच उन्मुख प्रोग्रामिंग

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

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

मैं एक सेवा-उन्मुख और microservice वास्तुकला बनाने के संदर्भ में कोड पुन: उपयोग के विषय को उठाना चाहता हूं।

पुन: प्रयोज्य कोड क्या है?

पुन: प्रयोज्य कोड को एक अलग इकाई में अलग-थलग किया जाता है, जिसे अलग-अलग भाषाओं में अलग-अलग भाषाओं में कहा जाता है - पुस्तकालय, पैकेज, निर्भरता, आदि। आमतौर पर, इस तरह के कोड को एक अलग भंडार में संग्रहीत किया जाता है, और इस कोड को जोड़ने और उपयोग करने के लिए प्रलेखन है (README.md)। इसके अतिरिक्त, कोड को परीक्षणों द्वारा कवर किया जा सकता है, परिवर्तन करने के निर्देश हो सकते हैं (CONTRIBUTING.md), और CI कॉन्फ़िगर किया जा सकता है। विवरण से जुड़े विभिन्न बैज केवल किसी दिए गए इकाई की परिपक्वता के दृश्य प्रतिनिधित्व में सुधार करते हैं, और सौंपे गए सितारों की संख्या इस समाधान की लोकप्रियता का संकेत देगी। आपको उदाहरणों के लिए दूर नहीं जाना होगा - बस अपनी पसंदीदा भाषा में किसी भी लोकप्रिय फ्रेमवर्क के जीथब पृष्ठ को खोलें, उदाहरण के लिए vue.js. सामान्य तौर पर, पुस्तकालयों के उच्च-गुणवत्ता वाले डिजाइन के तरीके एक वैगन और एक छोटी ट्रॉली हैं।

सेवाएँ और microservices

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

सेवा-उन्मुख वास्तुकला मानता है कि प्रत्येक सेवा दूसरों के साथ न्यूनतम रूप से जुड़ी हुई है। फिर भी, इंटरसेक्स सेवा को बाहर नहीं किया जाता है, लेकिन यह केवल यह माना जाता है कि इसे कम से कम किया जाना चाहिए। अनुरोध प्राप्त करने के लिए, एक सेवा आमतौर पर कुछ मानकीकृत एपीआई को लागू करती है। यह कुछ भी हो सकता है - REST, SOAP, JSONRPC या newfangled GraphQL।

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

थोड़ी कल्पना

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

एक काल्पनिक ऑनलाइन स्टोर की वास्तुकला:



इंटरनेट पर चिपकी हुई केवल एपीआई सेवा सभी फ्रंट-एंड सिस्टम तक पहुंच प्रदान करती है - ऑनलाइन स्टोर का वेब इंटरफेस, साथ ही साथ मोबाइल एप्लिकेशन।

ग्राहक सूचना सेवा ग्राहकों के बारे में जानकारी संग्रहीत करती है, उन्हें कैसे शुरू करें, अधिकृत करें, उनके बारे में आवश्यक जानकारी जारी करें।

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

आदेश सेवा आदेशों से संचालित होती है। यहां ऑर्डर के गठन का तर्क, इसकी पुष्टि, भुगतान प्रकार का चयन और वितरण पता, आदि है।

ग्राहक सूचना सेवा PUSH / SMS / ईमेल संदेश भेज सकती है। उदाहरण के लिए, संचार का प्रकार किसी विशेष क्लाइंट की सेटिंग्स पर निर्भर करता है, और ग्राहक सूचना प्राप्त करने के लिए वांछित समय भी निर्धारित कर सकते हैं।

ये सेवाएं सशर्त रूप से अवसंरचनात्मक हैं, क्योंकि उनके बिना ऑनलाइन स्टोर इस तरह से कार्य नहीं कर सकता है।

निकट भविष्य में परियोजना की टीमों द्वारा प्रचार और ऑफ़र और डाइजेस्ट के वितरण को विकसित किया जाना चाहिए। ये सेवाएं सशर्त रूप से किराना हैं।

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

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

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

और बड़ी कंपनियों के बारे में क्या?

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

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

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

एकल पारिस्थितिकी तंत्र के लाभ

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

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

मरहम में उड़ना

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

पुनश्च

और पैकेज-उन्मुख दृष्टिकोण सिर्फ इसलिए है क्योंकि मेरे स्टैक पर पुन: प्रयोज्य कोड को पैकेज कहा जाता है। खैर, यह अजीब लगता है। हाल ही में, मैंने अपने एक सहकर्मी के साथ संवाद किया, जिसने मुझे यह लेख लिखने के लिए प्रेरित किया:

- सहयोगी: आप पाँच में एक खजांची में बदल जाते हैं
- मुझे: अर्थ?)
- सहयोगी: जल्द ही आप पूछेंगे "क्या आपको पैकेज की आवश्यकता है?"
- मैं: कृपया एक विचार खोलें। मुझे समझ नहीं आया
- सहयोगी: ठीक है, umpteenth समय के लिए आप मेरी समस्या को हल करने के लिए एक तैयार पैकेज है

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