केंद्रीकृत बस बनाम सेवा मेष: एक माइटप को लड़ाई में कैसे बदलना है

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

प्रारूप के बारे में कुछ शब्द

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

ईएसबी क्यों है ठंडा?

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

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

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



इसके अलावा यह पता चला है कि सबसे अधिक बार वे कतारों में या REST के माध्यम से बस के साथ संवाद करते हैं।

समय के साथ, हालांकि, कई मामलों में एक बस और आरईएसटी की आवश्यकता गायब हो गई। लेकिन यह एक रोलबैक की तरह लग रहा था, महत्वपूर्ण सवाल फिर से लटका:

• अगर टायर नहीं है तो ऑर्केस्ट्रेट कैसे करें। ऐसा कहां होगा?
  
• डेटा और प्रोटोकॉल प्रारूपों के साथ क्या करना है?
  

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

यह व्यवस्था कितनी कमजोर है? अगर एक कंप्यूटर हैक हो जाए तो क्या होगा?

हमेशा अतिरेक और केंद्रीकरण होता है। इस घटना में कि कोई क्रम से बाहर है, सिस्टम काम करेगा।

टायर के लिए कौन जिम्मेदार है? आपकी टीम या तीसरे पक्ष के डेवलपर्स?

आंतरिक टीम में, हम परिचालन सेवाएं प्रदान करते हैं, विश्वसनीयता और निगरानी प्रदान करते हैं। अगर कुछ काम नहीं करता है, तो हम जानते हैं कि कहां देखना है। एक सवाल है: "क्या ऐसे मामलों और तीसरे पक्ष की टीमों में विक्रेताओं पर भरोसा करना संभव है?" यहां अच्छी निगरानी की जरूरत है। क्योंकि गुणवत्ता, किसी भी मामले में, आंतरिक टीम की जिम्मेदारी है।



जैसे-जैसे बस बढ़ती है, सेवाएं जुड़ती नहीं हैं। क्या आप रिलीज़ के साथ सेवाओं को बदलते हैं या क्या? चंचल के साथ क्या करना है?

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

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

टीम को कब तक उस सेवा की तलाश है जो उन्हें चाहिए, और वह इसके लिए कहां दिखती है?

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

या हो सकता है कि सेवा जाल कूलर है?

शुरू करने के लिए, 3-4 वर्षों में वास्तव में बहुत कुछ बदल गया है। लेकिन वास्तव में क्या हुआ? वही भोज जो सभी वक्ता नियमित रूप से दोहराते हैं, और जिसके द्वारा हम भी पास नहीं हो सकते, ऐसा हुआ है: दुनिया बदल रही है।

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

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

अब आइए कल्पना करें कि कंपनी में 20 सिस्टम नहीं हैं - आखिरकार, यह बहुत ही आर्किटेक्चर को स्थानांतरित करने का प्रयास करता है जिसे buzzword "microservices" कहा जाता है। और एक माइक्रोसेवा क्या है? कई परिभाषाएं हैं, उनमें से एक का समय-समय पर मार्टिन फॉलर द्वारा उपयोग किया जाता है: यह एक सेवा है जो एक मिड-डेवलपर एक स्प्रिंट में विकसित करने में सक्षम है। कल्पना कीजिए कि एक बड़ी कंपनी में ऐसी कितनी सेवाएं होंगी। उदाहरण के लिए, नेटफ्लिक्स ने 800-900 पर अपने माइक्रोसेवा की संख्या का अनुमान लगाया है। सिद्धांत रूप में, एक कंपनी में जो एक भागीदार बाहरी पारिस्थितिकी तंत्र का निर्माण करना चाहता है, ये सेवाएं एक हजार से अधिक हो सकती हैं। लेकिन लंबी अवधि में इनमें से प्रत्येक सेवा एक जबरदस्त भार का सामना करती है और इसे स्वतंत्र रूप से विकसित करना चाहिए।

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

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

सवाल उठता है: "हम एक्सेसिबिलिटी, सिक्योरिटी आदि को खोए बिना समान तेज गति कैसे सुनिश्चित कर सकते हैं?" इसका उत्तर बहुत सरल है: "स्पष्ट मध्यस्थ के बिना, इन सेवाओं को सीधे बातचीत करने दें।"

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

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



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

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

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

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

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

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

क्या ESB के आधार पर डिस्ट्रीब्यूटेड निर्माण संभव है? यही है, क्या एक सिस्टम से दूसरे को बनाना संभव है? और यदि हां, तो इन विवादों का क्या मतलब है?

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

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

क्या आपका बैंक समझता है कि ईएसबी ने खुद को रेखांकित किया है यदि वह इसमें महत्वपूर्ण बजट निवेश करना जारी रखता है?

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

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

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

विकेंद्रीकृत एकीकरण के लिए संक्रमण की योजना को आप कैसे देखते हैं?

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

कौन जीता?

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

अंत में, हम एक वीडियो प्रदान करते हैं जो हमारी लड़ाई के माहौल को महसूस करने में मदद करेगा: