👩🏻‍🤝‍👨🏼 👼🏿 🌡️ मोबाइल एप्लिकेशन संदर्भ सेवा 🕴🏿 🤸 ☔️

रुस्लान अरोमातोव, मुख्य विकासक, ICD

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

पृष्ठभूमि

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

लेकिन यह सरल योजना एक सरल कारण से काम नहीं करती है - सभी क्लाइंट अपडेट नहीं होते हैं। और आँकड़ों को देखते हुए, ऐसे बहुत सारे ग्राहक हैं।

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

"प्राथमिक!" - तुम कहो। - "इस डेटा को सर्वर से डाउनलोड करें और आप खुश रहेंगे।"

और आप सही होंगे। हम ऐसा करते हैं। ~~यही है, हम असहमत हैं~~ ।

हालाँकि, यह सब इतना सरल नहीं है। हमारे पास iOS और Android दोनों के लिए एप्लिकेशन हैं। प्रत्येक प्लेटफ़ॉर्म में कई अलग-अलग संस्करण हैं जिनकी कार्यक्षमता और एपि अलग-अलग हैं।
नतीजतन, ऐसा हो सकता है कि हमें एंड्रॉइड एप्लिकेशन के लिए फ़ाइल को एपी संस्करण के साथ 27 से अधिक अपडेट करने की आवश्यकता है, लेकिन आईओएस और पिछले संस्करणों को स्पर्श न करें।

यह तब और भी दिलचस्प हो जाता है जब, उदाहरण के लिए, हमें भुगतान प्राप्तकर्ताओं के आइकन अपडेट करने या नए आइकन के साथ नए आइटम जोड़ने की आवश्यकता होती है। हम प्रत्येक विशिष्ट प्रकार की स्क्रीन के लिए सात अलग-अलग प्रस्तावों में आइकन के प्रत्येक उदाहरण को आकर्षित करते हैं: एंड्रॉइड के लिए हमारे पास उनमें से 4 (एचडीपीआई, xhdpi, xxhdpi, xxxhdpi) और 3 के लिए iOS (1x, 2x, 3x) है। मुझे एक विशेष आवेदन किसको भेजना चाहिए?

"ठीक है फिर फ़ाइल पैरामीटर भेजें जो एक विशेष एप्लिकेशन द्वारा आवश्यक हैं।"

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

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

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

"फिर एप्लिकेशन स्टार्टअप पर एक संग्रह में माउस के पूरे सेट को डाउनलोड करें।"

अच्छा विचार। सच में नहीं। लेकिन एक अति सूक्ष्म अंतर है।

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

और हमने अभी तक सर्वर पर इस तरह के काम की लागत की गणना नहीं की है। मान लीजिए कि प्रति घंटे 10,000 ग्राहक हमारे पास आते हैं (यह औसत मूल्य है, यह अधिक होता है)। आवेदन शुरू करने के लिए निर्देशिकाओं की पृष्ठभूमि अद्यतन आरंभ करता है(हाँ, अब आप जानते हैं कि हम इसे क्या कहते हैं)। यदि एक क्लाइंट को 1 किलोबाइट अपडेट करने की आवश्यकता है, तो एक घंटे में सर्वर 10 मेगाबाइट से अधिक देगा। पैसा, सही? और अगर अपडेट के सेट का वजन 1 मेगाबाइट है? इस मामले में, हमें पहले से ही 10 गीगाबाइट देने होंगे। कुछ बिंदु पर, हम इस निष्कर्ष पर पहुंचे कि यातायात पर विचार किया जाना चाहिए।

फिर आपको यह समझने की ज़रूरत है कि कौन सी फाइलें बदल गई हैं और कौन सी नहीं हैं, और केवल आवश्यक डाउनलोड करें।

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

निर्देशिका सेवा

सामान्य तौर पर, यह एक नियमित वेब सेवा है जो http की फाइलों को आवेदन की सभी आवश्यकताओं को ध्यान में रखकर भेजती है। इसमें कई डॉकटर कंटेनर होते हैं, जिसके अंदर एक जावा एप्लिकेशन जेटी के वेब सर्वर के साथ काम करता है। बैकएंड विनाइल इंजन पर टारेंटूल डेटाबेस है (इसमें कोई दर्दनाक विकल्प नहीं था - इस डेटाबेस के लिए पूरी जानकारी थी। आप मास्टर-स्लेव प्रतिकृति के आधार पर मेरे पिछले लेख जीरोएमक्यू और टारेंटूल पर आधारित स्मार्ट कैश सेवा में पढ़ सकते हैं )। फ़ाइलों को प्रबंधित करने के लिए एक सेवा वेब इंटरफ़ेस है, पूरी तरह से स्व-लिखित भी है।

इस लेख के विषय में तकनीकी कार्यान्वयन विवरण विशेष रूप से महत्वपूर्ण नहीं हैं। यह php + apache + mysql, C # + IIS + MSSQL या कोई अन्य बंडल हो सकता है, जिसमें बिना डेटाबेस शामिल है।

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

लेकिन इस लेख में मैं केवल संदर्भ प्रणाली की संरचना के बारे में बात करूंगा, और हम उन्हें अनुप्रयोगों में कैसे उपयोग करेंगे।

अनुप्रयोगों में आवश्यक फाइलें, हम 3 अलग-अलग प्रकारों में विभाजित करते हैं।

फ़ाइलें जो हमेशा एप्लिकेशन में होनी चाहिए, और ऑपरेटिंग सिस्टम के प्रकार से स्वतंत्र होना चाहिए। उदाहरण के लिए, यह एक बैंकिंग सेवा समझौते के साथ एक पीडीएफ फाइल है।
-, , ( ) . , .
, , . - , , . , .

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

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

2. शेड्यूल (या बटन के अनुसार), सेवा सभी निर्देशिकाओं की सभी फ़ाइलों के माध्यम से चलती है, और उनके आधार पर दोनों प्रकार की फ़ाइलों के लिए (आईओएस और एंड्रॉइड के लिए 2 संस्करण), और दूसरे के संसाधन फ़ाइलों के लिए इंडेक्स फाइल्स (दोनों के अंदर) का एक सेट बनाता है। प्रकार (स्क्रीन के प्रत्येक प्रकार के लिए 7 संस्करण)।
यह कुछ इस तरह दिखता है:

{
  "version": "43",
  "date": "04 Apr 2020 12:31:59",
  "os": "android",
  "screen": "any",
  "hashType": "md5",
  "ts": 1585992719,
  "files": [
    {
      "id": "WBRbDUlWhhhj",
      "name": "action-in-rhythm-of-life.json",
      "dir": "actions",
      "ts": 1544607853,
      "hash": "68c589c4fa8a44ded4d897c3d8b24e5c"
    },
    {
      "id": "o3K4mmPOOnxu",
      "name": "banks.json",
      "dir": "banks",
      "ts": 1583524710,
      "hash": "c136d7be420b31f65627f4200c646e0b"
    }
  ]
}

अनुक्रमित में किसी दिए गए प्रकार की सभी फाइलों पर जानकारी होती है, जिसके आधार पर अनुप्रयोगों पर निर्देशिकाओं को अपडेट करने का तंत्र बनाया गया है।

3. स्टार्टअप पर अनुप्रयोग, पहली चीज़ जो वे डाउनलोड करते हैं, वह है उनकी फ़ाइल कैश के अंदर / नई निर्देशिका में फ़ाइलें अनुक्रमणिका । और / वर्तमान निर्देशिका में वे फाइलों के वर्तमान सेट के लिए फाइलों के साथ-साथ अनुक्रमित हैं।

4. नई और पुरानी सूचकांक फ़ाइलों के आधार पर (सभी वर्तमान फ़ाइलों से जिसमें हैश माना जाता है) की भागीदारी के आधार पर, फ़ाइलों की सूची बनाई जाती है जिन्हें अद्यतन या हटाए जाने की आवश्यकता होती है, और अद्यतन करने की आवश्यकता आम तौर पर स्थापित होती है।

5. उसके बाद, / नई निर्देशिका के लिएएप्लिकेशन डायरेक्ट लिंक के माध्यम से सर्वर से आवश्यक फाइलें डाउनलोड करते हैं (इसके लिए इंडेक्स में फाइल आईडी जिम्मेदार है)। इस स्थिति में, पहले से / नई निर्देशिका में मौजूद फ़ाइलों की उपस्थिति और हैश को ध्यान में रखा जाता है , क्योंकि यह फिर से शुरू हो सकता है।

6. जैसे ही फाइलों का पूरा सेट / नई निर्देशिका में प्राप्त होता है , उन्हें इंडेक्स फाइल के खिलाफ चेक किया जाता है (कभी-कभी ऐसा हुआ कि फाइलें पूरी तरह से डाउनलोड नहीं हुई थीं)।

7. यदि चेक सफल रहा, तो संपूर्ण फ़ाइल ट्री को / करंट डायरेक्टरी में रिप्लेसमेंट के साथ ले जाया जाता है । ताजा सूचकांक फ़ाइल वर्तमान हो जाता है।

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

लेकिन यह इतना मुश्किल क्यों है?

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

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

अंत में, मैं यह जोड़ सकता हूं कि फ्रंट सर्वर स्वयं भी सेवा का उपयोग करते हैं, जो स्टार्टअप पर क्लाइंट अनुरोधों को संसाधित करने के लिए आवश्यक डेटा डाउनलोड करते हैं।

और आप एप्लिकेशन को सामग्री अपडेट कैसे वितरित करते हैं?

मोबाइल एप्लिकेशन संदर्भ सेवा

पृष्ठभूमि

निर्देशिका सेवा

More articles: