वेब अनुप्रयोग विकास

सभी के लिए "सब कुछ नया बुरा है" पर चर्चा करना मज़ेदार है, और पिछले कुछ वर्षों से हम सर्वर पर NoSQL / NewSQL और क्लाइंट पर Angular / Knockout / Ember पर उत्साहपूर्वक चर्चा और प्रयास कर रहे हैं। लेकिन ये रुझान अंत में प्रतीत होते हैं। नीचे बैठने और आगे क्या है, इसके बारे में सोचने के लिए एक शानदार पल। जैसा कि एम। आंद्रेसेन ने कहा, "सॉफ्टवेयर दुनिया खा रहा है।" वहीं, मोबाइल / वेब एप नियमित एप खाते हैं। इसलिए, यह पता लगाने के लिए विशेष रूप से दिलचस्प है, लेकिन मोबाइल और वेब अनुप्रयोगों की दुनिया में सब कुछ कहाँ है? सब के बाद, वे, यह पता चला है, हर किसी को खाओ। मेरा मानना ​​है कि अगला बिग टॉपिक डेटा सिंक्रोनाइज़ेशन होगा, और यहाँ क्यों है।

और वास्तव में ग्राहक पर क्या होता है?

एक ब्राउज़र में, डेवलपर्स पहले से ही पूरी तरह से "सामान्य" एमवीसी अनुप्रयोगों का निर्माण कर रहे हैं। MVC आर्किटेक्चर अपने आप में नया नहीं है (1970 के दशक से), लेकिन यह केवल 10 साल पहले वेब पर आया था, Google मेल के साथ। यह दिलचस्प है कि शुरू में GMail परियोजना को गीक्स के लिए एक आवारा माना जाता था, लेकिन, जैसा कि लैरी पेज ने कहा था, "सामान्य उपयोगकर्ता 10 साल के समय में हमारे जैसे अधिक दिखेंगे" । खैर, यह काम किया, और GMail अब सब कुछ का उपयोग करता है।

HTML5 के आगमन के साथ, ब्राउज़र में पहले से ही अपना स्वयं का डेटा वेयरहाउस (यहां तक ​​कि दो), जावास्क्रिप्ट में अपना स्वयं का व्यवसाय तर्क और सर्वर के लिए स्थायी कनेक्शन है। अब, डेवलपर्स दो दुनियाओं में से सर्वश्रेष्ठ को संयोजित करने का प्रयास कर रहे हैं: स्थानीय अनुप्रयोगों की उपलब्धता और त्वरित प्रतिक्रिया और वेब अनुप्रयोगों के निरंतर "ऑनलाइन मोड"।


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

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


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

और सर्वर पर वास्तव में क्या होता है?

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


विशेष प्रणालियों के इस सभी तेजी से गुणा ने डेटा सिंक्रनाइज़ेशन की समस्या को भी उठाया। "चिड़ियाघर" के लिए सबसे सफल समाधान के रूप में, कई ने अपाचे काफ्का का उल्लेख किया। ऐसी वास्तुकला में, विभिन्न डेटा स्लाइस विभिन्न प्रणालियों में संग्रहीत किए जाते हैं जो "बस" के माध्यम से घटनाओं का आदान-प्रदान करना पसंद करते हैं। दरअसल, N सिस्टम को एकीकृत करते समय, आप O (N * N) एडेप्टर या एक सामान्य ईवेंट कतार लिख सकते हैं। एन = 2..3 के साथ, यह अति सूक्ष्म अंतर अभी भी बहुत ध्यान देने योग्य नहीं है, लेकिन लिंक्डइन पर, जाहिर है, एन महान है।

और अब एक ही समय में दो सिगरेट चूतड़। सिस्टम में समान डेटा के प्रतिकृतियों की संख्या की कल्पना करें - सर्वर पर और क्लाइंट की तरफ। मान लें कि MongoDB + Redis + Hadoop + WebStorage + CoreData। यह सब कैसे सक्षम रूप से सिंक्रनाइज़ करने के लिए?

और यह सब किस ओर ले जाता है?

तो भविष्य के रुझान क्या होंगे? कोई भी निश्चित रूप से नहीं कहेगा, लेकिन आप यह पता लगा सकते हैं कि क्या देखना है। वास्तव में, नए विचार बेहद धीरे-धीरे और बेहद कम दिखाई देते हैं। उदाहरण के लिए, MongoDB ओप्लोग के माध्यम से मास्टर-स्लेव प्रतिकृति का उपयोग करता है, जो केवल वृद्धिशील सुधार के माध्यम से MySQL प्रतिकृति से भिन्न होता है और लेस्ली लामपोर्ट द्वारा 1979-1984 से राज्य मशीन प्रतिकृति के काम पर आधारित है।

NoSQL Systems - Riak, Voldemort, Cassandra, CouchDB एक महत्वपूर्ण कदम आगे बढ़ाने और अंततः सुसंगतता, कारण क्रम, तार्किक और वेक्टर घड़ियों से कुछ निचोड़ने की कोशिश करते हैं - ये दृष्टिकोण समान अस्सी के दशक के उसी Lamport और C.Fidge के कार्यों पर वापस जाते हैं।

Google वेव और डॉक्स से एक साथ संपादन तकनीक में सुपर-डुपर ऑपरेशनल ट्रांसफ़ॉर्मेशन पहली बार 1989 में सीए एलिस और एसजे गिब्स द्वारा वर्णित किया गया था और अब अप्रचलित है।

ताजा पर्याप्त नहीं है, लेकिन यह भी भर में आता है। NoSQL विक्रेताओं द्वारा CRDT डेटा संरचनाओं के साथ पानी की कोशिश करने का प्रयास 2000 के दशक के अंत से सिद्धांतों पर आधारित है - एक बहुत ही atypical freshman।

तो, आइए इस बारे में सोचें कि नए वातावरण में क्या बढ़ेगा। नए रुझान अनिवार्य रूप से संकीर्ण हलकों में पहले से ही ज्ञात कुछ द्वारा निर्धारित किए जाएंगे। मैं तीन मुख्य संदिग्धों की पेशकश कर सकता हूं।

सामान्य बस और घटना-उन्मुख

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


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

सूचना-केंद्रित आर्किटेक्चर

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

लगभग पांच साल पहले, इंटरनेट की अनैतिकता पर विचारों का एक दिलचस्प आदान-प्रदान हुआ था। टीसीपी के अग्रणी वैन जैकबसन ने कहा है कि मौजूदा आर्किटेक्चर स्केलेबिलिटी की सीमा तक पहुंच चुके हैं और आपको स्क्रैच के लिए एक इनसेंट्रिक इंटरनेट डिजाइन करने की आवश्यकता है। प्रतिभागियों का एक अन्य समूह, जहां से मैं आयन स्टोइका को याद कर सकता हूं, आम तौर पर उस स्थिति को पकड़ लेता है जो HTTP निश्चित रूप से पुराना था, लेकिन HTTP के लिए CDN अवसंरचना को समायोजित करके, हम URL को केवल सर्वर-फ़ाइल पथ के बजाय सूचना के टुकड़े के लिए एक पहचानकर्ता के रूप में समझ सकते हैं। इसलिए, HTTP + CDN doublet, HTTP में स्टेटिक के प्रसार के साथ सभी दबाने की समस्याओं को हल करने के लिए आवश्यक हद तक निराधार हो सकता है। और, शायद, लोग ज्यादातर सही थे।

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

CRDT के प्रकार

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

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

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

मोबाइल एप्लिकेशन में CRDT इंजन आपको इंटरनेट से एक स्थायी कनेक्शन की अनुपस्थिति में भी पूरी तरह से डेटा के साथ काम करने की अनुमति देगा, और केवल तब ही जब कनेक्शन बिना किसी टकराव और डेटा हानि के, सिंक्रनाइज़ किया जाता है। आदर्श रूप से, यह उपयोगकर्ता के लिए पूरी तरह से अदृश्य हो सकता है। वस्तुओं के लिए एक प्रकार का ड्रॉपबॉक्स / गिट। हां, फायरबेस, उल्का, डर्बी, गूगल ड्राइव रियलटाइम एपीआई - इस दिशा में कदम है। लेकिन बम, MySQL या jQuery का स्तर अभी तक नहीं बना है - इसका मतलब है कि कुछ अभी तक तैयार नहीं है।

यदि, उदाहरण के लिए, हम मानसिक रूप से CRDT, सूचना-केंद्रित और घटना-उन्मुख को पार करते हैं, तो हमें एक काल्पनिक CRDT बस मिलती है, जो समान CORBA / DCOM / RMI के विपरीत, न केवल दूरस्थ वस्तुओं तक पहुँचने की अनुमति देगी, बल्कि उनकी स्थानीय प्रतियों के साथ कैसे काम करेंगी। इसी समय, ये स्थानीय प्रतियां एक फ्लैट "कैश" नहीं होंगी, लेकिन रिकॉर्ड करने की क्षमता के साथ पूर्ण लाइव प्रतिकृतियां हैं, जो स्वचालित रूप से सिंक्रनाइज़ हो जाएंगी।

भविष्य के वेब अनुप्रयोगों के लिए वास्तुकला क्या नहीं है?