डॉट कॉन्टेस्ट सेंटर के प्रमुख के साथ डॉटनक्स्ट 2018 में साक्षात्कार

22 और 23 नवंबर को, .NET प्रेमियों के लिए अगला डॉटनेट 2018 सम्मेलन मास्को में आयोजित किया गया था। मेरा नाम मैक्सिम स्मिरनोव है, मैं अल्फा-बैंक में .NET क्षमता केंद्र का प्रमुख हूं और आपको डॉटनेट के किनारे पर लिए गए साक्षात्कारों में से एक का एक पाठ संस्करण पेश करना चाहता हूं।


हमारे बैंक में जीवन और रोमांच के बारे में, जावा के साथ सह-अस्तित्व और कटौती के तहत कार्यान्वयन की समस्याओं के बारे में।

सामान्य रूप से अल्फा में कितना .NET है और हमें इसकी आवश्यकता क्यों है

हाल ही में, हमने .NET का उपयोग करने के मामले में काफी ध्यान दिया है। यदि लगभग 5 साल पहले अल्फा में इतने सहायक नहीं थे (मुख्य रूप से कॉर्पोरेट अनुप्रयोगों में, कॉर्पोरेट व्यवसाय को उधार देने, निवेश, आदि), तो लगभग 16-20 लोग इस तरह के भार के साथ सामना करते थे। और अब बैंक सक्रिय रूप से बड़े पैमाने पर और मध्यम कॉर्पोरेट व्यवसाय के क्षेत्रों को विकसित कर रहा है, जो कि क्रेडिट सिस्टम के विकास के लिए एक अच्छी प्रेरणा बन गया है।

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

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

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

जाँच - साबित - कार्यान्वित

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

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

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

अब हम धीरे-धीरे लिगेसी से छुटकारा पा रहे हैं - हम इसे सेवाओं में लपेटते हैं और कार्यात्मक रूप से इसे माइक्रो-सर्विसेज में फिर से लिखते हैं।

.NET Core VS .NET फ्रेमवर्क

मैं फिर से ध्यान दूंगा कि हमने .NET कोर लागू किया। इसलिए, इस अर्थ में कई समस्याएं हैं कि .NET फ्रेमवर्क में कुछ शांत चीजें हैं, लेकिन वे .NET कोर में नहीं हैं, और अभी भी नहीं हैं। उदाहरण के लिए, SOAP सेवाएँ।

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

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

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

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

फ्रंट, .NET और NodeJS

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

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

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

मोबाइल फोन एकीकरण

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

नए के प्रतिरोध के बारे में

जब आपके पास एक बड़ी कंपनी (और यहां तक ​​कि सिर्फ कुछ टीमें) हैं, तो आप हमेशा नए उपकरणों की शुरुआत से असंतुष्ट रहेंगे। आम तौर पर हमेशा, यह सामान्य है। कलाकार जो इसे देखते हैं, और यह सब

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

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



बेशक, यदि आप दृश्य में सब कुछ लिखते हैं, तो यह प्रश्न आम तौर पर हटा दिया जाता है।

यहाँ कोई विजुअल स्टूडियो में कोड लिखता है, जबकि अन्य नहीं। जब हमने क्लस्टर पर स्विच किया, तो यह पता चला कि ऐसी कई तकनीकें हैं जो विंडोज के तहत काम नहीं करती हैं। उदाहरण के लिए, Ansible। विंडोज पर एक क्लाइंट पार्ट है, लेकिन सर्वर पार्ट को अब नहीं उठाया जा सकता है। इसलिए, या तो लिनक्स पर एक वर्चुअल मशीन ले जाएं, या बस लिनक्स सर्वर पर सब कुछ करें।

सामान्य तौर पर, हम ऐसे ही रहते हैं। यदि आपके पास बैंक में .NET, और .NET के बारे में कोई प्रश्न हैं - तो लिखिए, मुझे उत्तर देने में खुशी होगी।