भाग एक, जिसमें पाठक आंतरिक 2GIS उत्पादों के उद्भव के संक्षिप्त इतिहास और कई लिपियों से एक पूर्ण अनुप्रयोग के लिए डेटा वितरण प्रणाली के विकास से परिचित होगा।आज मैं आपको एक कहानी सुनाऊंगा जो 9 साल पहले डब्लूजीआईएस में शुरू हुई थी।
मुझे बस वहां नौकरी मिली। मुझे हमारे बाहरी उत्पादों के लिए एक बड़ी आंतरिक प्रणाली से डेटा निर्यात करने के लिए मॉड्यूल से निपटना पड़ा। और इस लेख में मैं आपके साथ साझा करना चाहता हूं कि कैसे हम इस मोनोलिथ को कई भागों में विभाजित करते हैं, कैसे एक राक्षस ने कई दर्जनों उत्पादों को उत्पन्न किया, और कैसे इन सभी उत्पादों और परियोजनाओं को आपस में डेटा स्तर पर एकीकृत किया गया।
मुझे कहना होगा कि यह बिना किसी तकनीकी विवरण के सिर्फ एक समीक्षा लेख है। तकनीक दूसरे भाग में होगी, जिसमें हम डेटा निर्यात के बारे में बात करेंगे। इस बीच, प्रौद्योगिकी के सतही उल्लेख के साथ केवल मटन के बिना प्रकाश पढ़ना।
चलो चलते हैं। 2010 तक तब 2GIS अभी भी एक ट्यूब DoubleGIS था, बाहरी उत्पादों से एक डेस्कटॉप संस्करण और एक आदिम ऑनलाइन और पीडीए के लिए एक संस्करण था। और इनसाइड में हमारे पीसी संस्करण के उपयोगकर्ताओं और DGPP नामक एक राक्षस के लिए एक अपडेट डिलीवरी सिस्टम शामिल था, जो संगठनों और नक्शे, सीआरएम की एक निर्देशिका को संपादित करने और उत्पादों को निर्यात करने के लिए डेटा निर्यात करता था। डेटाबेस फायरबर्ड में था। प्रणाली का विकेंद्रीकरण किया गया था। प्रत्येक शहर की अपनी स्थापना और अपना डेटाबेस था। फ़ाइल निर्यात / आयात के माध्यम से आदिम एकीकरण प्रदान किया गया था। और इस पर, द्वारा और बड़े, यह सब है।
DGPP स्वयं एक C ++ एप्लिकेशन था जिसमें VBA स्क्रिप्ट्स का एक सेट था। शुरुआत में, एक तीसरे पक्ष के कार्यालय ने डब्लूएलजीआईएस के लिए इस प्रणाली को विकसित किया, और केवल समय के साथ कंपनी ने अपनी छत के नीचे सिस्टम के विकास को अपने स्वयं के आरएंडडी का गठन किया। DGPP का विकास कठिन और कठिन हो गया है।
और यह डब्लूएलजीआईएस के तेजी से विकास का समय था। नए शहर खुल रहे थे। स्मार्टफोन के लिए मोबाइल संस्करण तैयार किया जा रहा था। नई सुविधाएँ दिखाई दीं। एक विज्ञापन मॉडल विकसित हो रहा था। सामान्य तौर पर, बड़ी संख्या में परिवर्तन की आवश्यकता थी, और उन्हें जल्दी से करने की आवश्यकता थी।
पहली बात हमने डीजीपीपी को टुकड़ों में अलग करना शुरू कर दिया था। हमने इसे एक अलग अनुप्रयोग में खींच लिया, जो कि WPF पर थूथन के साथ एक विंडोज़ सेवा है। समानांतर में, एक नए सीआरएम पर काम चल रहा था। उस समय के समय को बचाने के लिए, Microsoft Dynamics CRM को आधार प्लेटफ़ॉर्म के रूप में चुना गया था।
निर्यात के लिए, आपको बस सीखना होगा कि फायरबर्ड से डेटा कैसे निकाला जाए और वीबीए स्क्रिप्ट से डेटा तैयार करने के लिए सभी तर्क निकाले जाएं। इसके अलावा, प्लसस पर लागू ट्रांसपोर्ट डेटा के लिए कुछ एल्गोरिदम थे। उन्हें तेज करने के लिए फिर से लिखना पड़ा।
यहां यह एक बिंदु पर ध्यान देने योग्य है। हमारे डेस्कटॉप DoubleGIS ने एक विशेष द्विआधारी प्रारूप में डेटा का उपभोग किया, जिसे एक COM ऑब्जेक्ट में लिपटे C ++ पुस्तकालय द्वारा तैयार किया गया था। और फिर इसका उपयोग करना काफी तर्कसंगत था, बस परियोजना के संदर्भ के रूप में इसे जोड़ना। सबसे अच्छा समाधान नहीं है, लेकिन मैं इस बारे में बाद में बात करूंगा।
जैसे-जैसे समय बीतता गया, हमने एक मोबाइल संस्करण और एक नया CRM लॉन्च किया। एक नया बाहरी उत्पाद क्षितिज पर प्रकाशित हुआ है - सार्वजनिक एपीआई 2 जीआईएस। और DGPP से वे पहले ही संगठनों की एक निर्देशिका के साथ काम करने के लिए एक सबसिस्टम को अलग करना शुरू कर चुके हैं जिसका नाम InfoRussia है।
निर्यात में, दो प्रणालियों से विज्ञापन डेटा पढ़ना आवश्यक हो गया: पुराने DGPP और नए CRM। इसके अलावा, CRM का कार्यान्वयन धीरे-धीरे आगे बढ़ रहा था, अर्थात, कुछ शहरों में, अब तक केवल DGPP ही बना रहा, जबकि अन्य में DGPP ने एक निर्देशिका और मानचित्र तथा CRM को व्यावसायिक जानकारी के साथ एक साथ काम किया। इसके अलावा, लंबे समय में इन्फोरासिया की रिलीज, जो कई महीनों से चली आ रही थी, चमक रही थी।
नई प्रणालियों ने न केवल उनकी उपस्थिति से जटिलता का परिचय दिया। उन्होंने तैनाती की अवधारणा को बदल दिया। विकेंद्रीकृत DGPP के विपरीत जो हर शहर में खड़ा था, इन प्रणालियों को केंद्रीकृत किया गया था, जिनमें से प्रत्येक अपने स्वयं के मोटा DBMS के साथ थी। इसके अलावा, उन्हें डेटा का आदान-प्रदान करने की आवश्यकता थी।
इस समस्या को हल करने के लिए, हमने अपनी एंटरप्राइज सर्विस बस (ESB) को लागू किया। उस समय, व्यावहारिक रूप से कोई परिपक्व समाधान नहीं था जो हमारे लिए कुछ महत्वपूर्ण कार्यात्मक आवश्यकताओं की पूर्ति सुनिश्चित करेगा: एक्सएमएल को प्रसारित करने की क्षमता, संदेशों का क्रम और वितरण की गारंटी। फिर हम SQL सर्वर ब्रोकर पर बस गए, जिसने आवश्यक सभी चीज़ों को बॉक्स से बाहर कर दिया। सच है, उसके पास औसत दर्जे की डिलीवरी की गति थी, लेकिन उस समय वह हमारे साथ काफी खुश थी।
अंतिम चरण फिजी नामक एक मानचित्र सेवा का विमोचन था। उन्होंने आंशिक रूप से बस में अपना डेटा अपलोड किया। यह संबंधित निर्देशिकाओं और सहपाठियों। जियोडाटा को रेस्ट एपीआई के माध्यम से उससे लिया जा सकता था, जिसका इस्तेमाल खुद
फिजी क्लाइंट ने भी किया था, जिसे
WPF में लिखा गया था ।
इस वास्तुकला में, निर्यात केंद्रीय था। इसके माध्यम से, सभी डेटा स्ट्रीम एक एकल रिपॉजिटरी में विलय हो गए और अंत उत्पादों और हमारे उपयोगकर्ताओं को वितरित किए गए।
इसके अलावा, यह हिमखंड का एक छोटा सा हिस्सा था। आंतरिक प्रक्रियाओं के स्वचालन, नई आवश्यकताओं के उद्भव और नई सुविधाओं के कारण उत्पादों की एक बड़ी संख्या का उदय हुआ। एनालिटिक्स करना, उपयोगकर्ता के फीडबैक के साथ काम करना, नए बिक्री मॉडल और नए वाणिज्यिक उत्पादों को पेश करना, खोज, परिवहन एल्गोरिदम और सामान्य रूप से, बाहरी उत्पादों को विकसित करना आवश्यक था।
एक ओर, निर्यात में बड़ी संख्या में डेटा प्रदाता हैं, और दूसरी ओर, बड़ी संख्या में उपभोक्ता, जिनमें से प्रत्येक एक विशिष्ट रूप में डेटा प्राप्त करना चाहते थे और इसे विशेष तैयारी एल्गोरिदम के माध्यम से चलाते थे।
और फिर मेरी कहानी समाप्त हो गई।
लेख के दूसरे भाग में मैं आपको निर्यात के बारे में बताऊंगा और साझा करूंगा कि वह इन सभी परिवर्तनों से कैसे बचे। कोई कहानी नहीं होगी, लेकिन विशिष्ट दृष्टिकोण होंगे जो हमने कार्यों की एक विशिष्ट सूची को हल करने में लागू किए हैं।