सभी के प्यारे REST, STATEless, CRUD, CGI, FastСGI और MVC से अपर पैलियोलिथिक तकनीक पर वापस

"केवल हठधर्मिता से विज्ञान शुरू होता है।"
// गैलीलियो गैलीली

“मैं दासों से ईर्ष्या करने लगा। वे सब कुछ पहले से जानते हैं। उनके पास मजबूत विश्वास है। ”
// मार्क ज़खारोव की फिल्म "किल द ड्रैगन" जो यूजीन श्वार्ट्ज के नाटक पर आधारित है

कुछ साल और एक दिन बीत चुका है, ताकि मैं नए प्रोजेक्ट शुरू करने वाले लोगों से सुना (या पढ़ा) न जाऊं, एक वाक्यांश जैसे "REST API और MVC के लिए सर्वर इंजन लें, और भेजें । " सबसे पहले, मैंने सोचा कि इन शब्दों का एक स्रोत है, हो सकता है कि कुछ किताबों को सभी स्टोरों तक पहुंचाया गया या कहीं न कहीं सर्च इंजनों के शीर्ष पर एक लेख है जो डेवलपर्स को लाश करता है। यदि आप उनसे पता लगाते हैं कि वे REST और MVC द्वारा क्या समझते हैं, तो आप मन से क्षतिग्रस्त हो सकते हैं। खैर, एमवीसी के साथ सब कुछ स्पष्ट है, मैंने लंबे समय तक इस बारे में लिखा था , कुछ भी नहीं बदला है, यह केवल खराब हो गया है, यह Google छवियों में "mvc" टाइप करने के लायक है और हम किसी भी दिशा में एक डरावना तीर देखेंगे । ठीक है, जैसा कि REST के लिए, वे निम्नलिखित उत्तर देते हैं: ठीक है, हमें ब्राउज़र GUI और मोबाइल एप्लिकेशन से सर्वर विधियों को कॉल करने की आवश्यकता है, उदाहरण के लिए: setUserCity (userId, cityId) या गणनामैट्रिक्स (डेटा) या startideoConverter (विकल्प, स्रोत, गंतव्य) और फिर हम मुठभेड़ करेंगे भारी भार और REST आर्किटेक्चर सब कुछ हल कर देगा। इसके बाद, मैं उन सवालों के बारे में पूछता हूं जिनसे आंखें पहले ही गोल हो जाती हैं जो अभी भी धर्मी विश्वास से जल रहे थे, लड़ाई के लिए उत्सुक थे और जानते थे कि वास्तव में इस दुनिया में क्या हो रहा है। अब हम शब्दावली के विनाश पर विचार करने के लिए आगे बढ़ सकते हैं, जिसके उपरिकेंद्र पर हम आपके साथ हैं।

MVC प्रश्न

पहला सवाल: मुझे "MVC क्या है?" मुझे क्या मिलेगा:

एमवीपी के लिए, इस तरह की समझ और योजनाएं भी पर्याप्त हैं, इसमें संदेह भी न करें।

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

तीसरा सवाल: आपने MVC को REST के साथ कैसे संयोजित किया?
मैं विरोध नहीं कर सकता, मैं सामान्य विकल्प प्रकाशित करूंगा:

• खैर, हमने RVC का उपयोग करके MVC लागू किया है
• खैर, हमने MVC का उपयोग करके REST लागू किया है

मैं इस पर टिप्पणी नहीं कर सकता, यह पूरी तरह से स्पष्ट है कि हम एक पारिभाषिक तबाही से निपट रहे हैं, लेकिन बाद में इस पर और अधिक।

REST के बारे में प्रश्न

पहला सवाल: ठीक है, मेरे डियर्स, ये सेटअस्पेरिटी, कैलकुलेटमैट्रिक्स और स्टार्टवीडियोऑन्सर को REST पर कैसे लागू किया जा सकता है?
मेरा उत्तर: REST का पूरा बिंदु यह है कि यह फाइलों पर काम करता है, जिनमें से प्रत्येक का अपना विशिष्ट URL है, और इस फ़ाइल पर केवल HTTP विधियों का उत्पादन किया जा सकता है: GET, PUT, POST, DELETE। इसलिए, कृपया कृपया इन सभी setUserCity को HTTP POST / user / id से बदल दें और पूरे क्रमबद्ध उपयोगकर्ता को वहां भेजें। या एक अन्य विकल्प, आपको प्रत्येक उपयोगकर्ता पैरामीटर के लिए एक अलग URL होना चाहिए। जाहिर है, HTTP विधियों के माध्यम से कहे जाने वाले CRUD मेथड (क्रिएट, रीड, अपडेट, डिलीट) डेटाबेस में फाइलों या ऑब्जेक्ट्स में हेरफेर करने के लिए पर्याप्त हैं। उदाहरण के लिए, प्रपत्र और फ़ॉर्म दर्ज करने के लिए, उन्हें और विलोपन और संपादन के साथ तालिकाओं में सहेजें। लेकिन किसी भी आधुनिक अनुप्रयोग को ऐसी आदिम चुनौतियों के लिए कम नहीं किया जा सकता है। और डेवलपर्स, सबसे अधिक बार, आरईएसटी द्वारा इसके विपरीत को समझते हैं - आरपीसी (दूरस्थ प्रक्रियाओं को कॉल करके), जब हम किसी भी संख्या में तरीके बना सकते हैं, न कि केवल सीआरयूडी, और जब एक URL पूरी तरह से अलग-अलग उत्तर दे सकता है, जिसके आधार पर उपयोगकर्ता उसे किस मापदंडों और किस क्रम में बुलाया गया था। और यह REST बिल्कुल भी नहीं है, उदाहरण के लिए, Habr http://habrahabr.ru/tracker/ पर हम में से प्रत्येक के लिए एक अलग सूची देता है और यह हर जगह Google, Facebook, Github, आदि पर है। इसलिए, भ्रामक REST शब्द को हटा दें, API करें और यह है।

दूसरा सवाल: ठीक है, वास्तव में आपके लिए क्या है?
यहाँ राय की सीमा MVC के लिए उतनी चौड़ी नहीं है, लेकिन पारिभाषिक तबाही यह है: जैसा कि मैंने ऊपर दिखाया है, REST को REST के रूप में बिल्कुल भी नहीं समझा जाता है, लेकिन विज्ञान में वे सब कुछ करने के लिए और REST पर हठधर्मी साहित्य का अध्ययन करते हैं, REST समर्थन के साथ रूपरेखाएँ देखें। और परिणामस्वरूप, RPC और REST का एक हाइब्रिड निकलता है। और सबसे बुरा, यह सब अनजाने में होता है ।

तीसरा प्रश्न: क्या आप बता सकते हैं कि वास्तव में REST आपको भारी भार से कैसे बचाएगा?
मेरा जवाब: यह स्टेटलेस है , लेकिन इसका क्या मतलब है और हमें सर्वर पर राज्य को छोड़ने की क्या आवश्यकता है - हम नीचे चर्चा करेंगे।

STATEless का अर्थ क्या है

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

खुशी ऊपरी Paleolithic प्रोग्रामर के लिए आया था

उस समय जब मेरी प्रोग्रामिंग विश्वदृष्टि विकसित हो रही थी (1997-2002), मुख्यधारा एक त्रिस्तरीय अनुप्रयोग वास्तुकला (विंडो क्लाइंट, एप्लिकेशन सर्वर, डीबीएमएस) थी। और क्लाइंट ने आरपीसी के माध्यम से एप्लिकेशन सर्वर के साथ बातचीत की। सब कुछ STATEful था, लेकिन तब ऐसे कोई कार्य नहीं थे जिन्हें कई मशीनों पर एप्लिकेशन सर्वर को स्केल करने की आवश्यकता होती। और इसलिए, कई सालों से, 2002 से 2012 तक, मैंने REST और STATEless को धीरज दिया, अत्यधिक भरी हुई प्रणालियों के लिए पूर्ण विकसित STATEful प्रोग्रामिंग और RPC के बारे में मेरे दिल में सपना देखते हुए। अब, जब अधिकांश भाषाओं और प्लेटफार्मों के पास अपने स्वयं के ईवेंट-लूप समाधान हैं, जैसे कि Node.js, पायथन की ट्विस्टेड और रूबी इवेंट मशीन, मैं एक पूरी तरह से खुश व्यक्ति की तरह महसूस करता हूं और अब यह नहीं जानता कि स्टेटलेस की जरूरत क्यों है और जहां वाक्यांश जैसे " हम REST API और MVC के लिए सर्वर इंजन लेंगे, और इसे ड्राइव करते हैं । "

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

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

और एमवीसी के साथ हम अभी तक नहीं किए गए हैं

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

मैं "मॉडल" शब्द का उपयोग करने का प्रस्ताव करता हूं, क्योंकि यह विज्ञान और प्रौद्योगिकी में उपयोग करने के लिए प्रथागत है, अर्थात यह एक वास्तविक प्रणाली और / या प्रक्रिया का सरलीकृत प्रतिनिधित्व है । यह निम्नानुसार है कि मॉडल में पैरामीटर और विधियाँ हो सकती हैं। लेकिन इन तरीकों की परिभाषा फिट होनी चाहिए। उदाहरण के लिए, CRUD विधियाँ किसी वास्तविक दुनिया की वस्तु के मॉडल का हिस्सा नहीं हो सकती हैं, क्योंकि कोई भी वास्तविक वस्तु स्वयं बना या हटा नहीं सकती है। CRUD मॉडल का हिस्सा नहीं है, लेकिन स्टोरेज लेयर API का हिस्सा है, और ड्रॉइंग के तरीके ग्राफिक्स लेयर API का हिस्सा हैं। मॉडल को इसके भंडारण, नेटवर्क पर ट्रांसमिशन प्रोटोकॉल, ब्राउज़र में सुविधाओं को प्रदान करने, आदि के बारे में कुछ भी पता नहीं होना चाहिए। एक मॉडल के लिए एक विधि का एक अच्छा उदाहरण है: SteppingMotor.setSpeed ​​(x) जब मॉडल एक भौतिक डिवाइस ड्राइवर है या एक भौतिक डिवाइस को मॉडल करने के लिए उपयोग किया जाता है। एक और अच्छा उदाहरण है इक्वेशन.कालक्यूलर रॉट्स () जैसे गणितीय मॉडल। और एक तीसरा उदाहरण सूचना मॉडल है, उदाहरण के लिए: Patient.assignBed (bedId)।

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

ऊपरी पैलियोलिथिक अनुप्रयोग विकास युक्तियाँ

घटना-उन्मुख समाधानों में से, मैं व्यक्तिगत रूप से Node.js का उपयोग करता हूं, लेकिन मुझे लगता है कि वे सार्वभौमिक हो सकते हैं:
1. RPC और STATEful के सिद्धांतों के अनुसार क्लाइंट और सर्वर (ब्राउजर एप्लिकेशन और नेटवर्क एपीआई) को प्रक्रियाओं के लिए ग्लूइंग सत्रों के साथ अलग करें।
2. रैम का उपयोग करें, लगातार डेटाबेस में चढ़ो मत। STATEful तेज अनुप्रयोगों को लिखने का एक शानदार अवसर है, और इसलिए भी नहीं कि इवेंट लूप फ्रेमवर्क में गैर-अवरोधक I / O की आवश्यकता होती है, लेकिन स्मृति के सही उपयोग के कारण। अधिकांश I / O संचालन को क्वेरी प्रसंस्करण के दौरान भी करने की आवश्यकता नहीं है, पढ़ना एक सक्रिय और समानांतर तरीके से किया जा सकता है, और लेखन आलसी है। एप्लिकेशन की मेमोरी में डेटा तैनात करें, हैश, ऑब्जेक्ट्स, एरे का निर्माण करें जो एक स्टेटमेंट प्रक्रिया में एक लंबा और खुशहाल जीवन जीएगा।
3. विभिन्न प्रक्रियाओं के बीच ZeroMQ (और अन्य MQs), टीसीपी, एचटीटीपी, आईपीसी और कुछ और के माध्यम से बातचीत। इस प्रकार, विभिन्न प्रक्रियाओं का डेटा, यह किस प्रकार का डेटा है, इसके आधार पर या तो मेमोरी में डुप्लिकेट किया जा सकता है (कैश्ड अगर यह साझा डेटा है) या "चिपचिपा" सत्रों में विभाजित किया जा सकता है या इंटरप्रोसेस संचार के माध्यम से एक दूसरे के साथ सिंक्रनाइज़ किया जा सकता है।

निष्कर्ष

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

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