🌳 🚵🏿 🤞🏻 चित्रों में क्लाइंट-सर्वर आर्किटेक्चर 😛 🥥 🌒

एक परिचित तस्वीर? लेकिन आप लगातार इस वास्तुकला के साथ सामना कर रहे हैं - जब आप ऑनलाइन मूवी टिकट खरीदते हैं, तो समुद्र में एक टिकट बुक करते हैं या एक डॉक्टर के साथ एक नियुक्ति करते हैं।

क्लाइंट-सर्वर आर्किटेक्चर पर सभी साइटें और इंटरनेट सेवाएं निर्मित हैं। इसका उपयोग डेस्कटॉप कार्यक्रमों द्वारा भी किया जाता है जो इंटरनेट पर डेटा संचारित करते हैं। इसलिए, आईटी पेशेवरों को यह समझने की आवश्यकता है कि यह क्या है और यह कैसे काम करता है।

मैं इस बारे में लेख में बात करूंगा। मैं उँगलियों पर समझाता हूँ, उदाहरण और मजेदार चित्रों के साथ =) यदि आपको वीडियो प्रारूप अधिक पसंद है, तो आप उसी विषय पर मेरा youtube वीडियो देख सकते हैं।

सामग्री

यह क्या है और यह कैसे काम करता है

यहां हमारे पास एक निश्चित वासा है जिसने कार खरीदने का फैसला किया है। जैसे कि विज्ञापन में - तेज, शक्तिशाली, सुंदर! वह सिर्फ एक हवाई जहाज की पूंछ की तरह खड़ा है, वास्या के पास उस तरह का पैसा नहीं है।

बेशक, वासा कई वर्षों तक खुदाई कर सकता है, और फिर एक कार खरीद सकता है। लेकिन आप यहाँ और अभी चाहते हैं! हां, और एक वाहन की आवश्यकता है ...

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

बेशक, फिर आप उन्हें भुगतान वापस कर देंगे। रुचि घोड़ा है। लेकिन अब आप पहले से ही कुछ महंगा खरीद सकते हैं।

वसिया ने सोचा, अनुमान लगाया और कहा:

- हाँ, मैं इसे इसी तरह चाहता हूँ! मैं अपने वेतन से बैंक को 100 रूबल का भुगतान कर सकता हूं, लेकिन मैं इसे नहीं बचा सकता। मैं इसे खर्च करूंगा।

इसलिए, वासा बैंक में जाता है और कहता है:

- मैं वासिली इवानोव हूं, मुझे 1000 रूबल के लिए कार ऋण चाहिए।

क्लर्क कात्या को अपने क्रेडिट इतिहास की जांच करनी होगी। अचानक उसे ऋण नहीं दिया जा सकता है, क्या उसके पास एक बुरी कहानी है? हो सकता है कि उसने पहले से ही 10 क्रेडिट बनाए हों और कोई भुगतान न किया हो? या हो सकता है कि वह एक आतंकवादी हो? यह जांचना आवश्यक है कि ऑपरेटर काली सूचियों को दिल से नहीं जानते हैं।

ग्राहक डेटा की जाँच के लिए कात्या का एक विशेष कार्यक्रम है। यह कार्यक्रम या तो वेब या डेस्कटॉप हो सकता है:

वेब - गूगल या फेसबुक जैसे ब्राउज़र में खुला
डेस्कटॉप - एक कंप्यूटर पर, एक शब्द या कैलकुलेटर की तरह

यह बात मायने नहीं रखती कि कटिया ब्राउज़र को देख रही है या सिर्फ कार्यक्रम में। किसी भी मामले में, यह एक ग्राहक होगा। ग्राहक आपका आवेदन है। वह जिसके साथ हमारा ऑपरेटर काम कर रहा है।

कात्या ने कार्यक्रम "वसीली इवानोव" को ड्राइव किया और क्लाइंट के बारे में जानकारी प्राप्त की - क्या वह ब्लैक लिस्ट में है? क्या पहले कोई क्रेडिट इतिहास था? आदि। लेकिन एप्लिकेशन की गिबिल में क्या होता है?

कात्या ने क्लाइंट पर डेटा डाला। लेकिन जब उसने "चेक" पर क्लिक किया, तो क्लाइंट ने सर्वर को एक अनुरोध भेजा:

- मुझे वासियो इवानोव के बारे में जानकारी दें!

सर्वर ने डेटाबेस, डेटाबेस के लिए एक अनुरोध भेजा:

- ग्राहकों से जहां fio = 'वासिली इवानोव' का चयन करें। (मुझे 'वासिली इवानोव' नाम की सारी जानकारी दें)

आधार ने उत्तर दिया:

- यहाँ आपके पास वह सब कुछ है जो मैंने पाया है।

सर्वर ने ग्राहक को यह जानकारी दी:

और क्लाइंट ने पहले ही इसे कट्या के लिए तैयार कर लिया है:

कट्या लग रहा है:

- हाँ, क्रेडिट इतिहास अच्छा है।

और उसने वस्या को प्रस्ताव दिया:

- कृपया, यदि आप ऋण लेना चाहते हैं, तो हम 12 रूबल के लिए 1000 रूबल प्रतिवर्ष 80% पर आवंटित करने के लिए तैयार हैं। व्यवस्था की?

वासना प्रसन्न है:

- हाँ, सब कुछ मुझे सूट करता है, मुझे और पैसे दो, और मैं कार के पीछे भाग गया!
हर कोई खुश है, हर कोई खुश है।

कट्या को यह भी नहीं पता है कि कार्यक्रम में डेटा किस तरह से किया गया था जब उसने अपने ग्राहक का पूरा नाम हटा दिया था। लेकिन आपको और मुझे यह पता लगाना चाहिए कि यह किस तरह का रास्ता है। और ये सारी कठिनाइयाँ क्यों? ऐसा ढांचा क्यों? कोई क्लाइंट क्यों है, एक सर्वर क्यों है?

मुझे क्लाइंट की आवश्यकता क्यों है

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

हमें एक सर्वर की आवश्यकता क्यों है

वह अधिक शक्तिशाली है।

कई ग्राहक हो सकते हैं। बैंक के साथ उदाहरण में, हमारे पास रूस के 10 शहरों में 10 शाखाएं हो सकती हैं, और प्रत्येक शाखा में 10 ऑपरेशन एजेंट हैं। एक हजार केटेक, और प्रत्येक के पास एक अलग कंप्यूटर है।

लेकिन हम चाहते हैं कि एप्लिकेशन जल्दी से काम करे। ताकि यह बेवकूफी न करे और फ्रीज न हो, ऑपरेटर को बेवजह और क्लाइंट को इंतजार करवाए। तो, कार को एक शक्तिशाली की जरूरत है। लेकिन अगर प्रत्येक ऑपरेटर का कंप्यूटर शक्तिशाली बना दिया जाता है, तो आपको बहुत सारा पैसा निवेश करना होगा!

इसलिए, हम सभी मूल तर्क को सर्वर पर स्थानांतरित करते हैं। और अब हम इसे शक्तिशाली बना रहे हैं! और ग्राहक मशीनें सस्ती हो सकती हैं, क्योंकि उनके पास "अनुरोध की जानकारी और खूबसूरती से प्रस्तुतिकरण" की शैली में केवल तर्क है।

कोई कोड दोहराव नहीं

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

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

यह सुरक्षित है।

सर्वर पर और डेटाबेस में जानकारी संग्रहीत की जाती है जो एक साधारण ऑपरेटर के लिए दुर्गम है। यह:

ग्राहक डेटा
उसके वित्त के बारे में जानकारी
बैंक ब्लैक लिस्ट करते हैं
...

यह जानकारी सभी को और सभी को क्यों दिखाएं? ऑपरेटर केवल उसका इंटरफ़ेस देखता है। मैंने पूरा नाम निकाल दिया - मुझे जवाब मिला कि लोन देना है या नहीं। सब। उसे किसी और चीज की जरूरत नहीं है।

ऐसे क्लर्क हैं जो डेनिसी के लिए ग्राहक जानकारी को मर्ज करने के लिए तैयार हैं। बेईमान लोग हैं जो अपने कंधों पर गलती से देखने के लिए तैयार हैं। या हो सकता है कि ग्राहक खुद ही ऐसा व्यक्ति हो। कल्पना कीजिए, वासिया नाजुक कटिया को हिलाती है, उसके कंप्यूटर पर बैठ जाती है, और उसके खाते में लाखों तक स्थानांतरित कर देती है जब तक कि यह गार्ड द्वारा बंधे न हो।

हमें आधार की आवश्यकता क्यों है

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

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

DB (डेटाबेस) - एक अलग सॉफ्टवेयर उत्पाद जो आपको इसकी अनुमति देता है:

जल्दी से जानकारी प्राप्त करें
सिस्टम को पुनरारंभ करने पर भी जानकारी को बचाएं।

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

हाँ, एक आधार नहीं हो सकता है। लेकिन जब यह होता है, तो हम डेटा की सुरक्षा में विश्वास करते हैं और आसानी से खोज सकते हैं।

आर्किटेक्चर के फायदे

हम वास्तुकला के लाभों को संक्षेप में प्रस्तुत करते हैं:

एक शक्तिशाली सर्वर 100+ शक्तिशाली क्लाइंट मशीनों से सस्ता है - अगर हम चाहते हैं कि एप्लिकेशन धीमा न हो, तो हमें एक अच्छी मशीन की आवश्यकता है। आपके पास एक होगा। या कुछ, अगर लोड बड़ा है, लेकिन स्पष्ट रूप से ग्राहकों की संख्या से कम है।
— , « » « , 100 ».
— . , .

एक लिंक

गिर गया है - हर कोई आराम कर रहा है। यदि सर्वर गिर गया है या आधार गिर गया है, अर्थात, एक लिंक खराब हो गया है - सब कुछ, हर कोई एक मूर्खता में है, हर कोई आराम कर रहा है। सैकड़ों, हजारों, और यहां तक कि लाखों ग्राहक, यदि कोई हो, तो कोई भी काम नहीं कर सकता है। सभी ऑपरेशन अधिकारी दुखी होकर खिड़की पर देख रहे हैं "सॉरी, कुछ गड़बड़ हो गई है" और ग्राहक के सामने हाथ हिलाया।

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

फिर ग्राहक को यह कैसे समझ में आता है कि उसे अनुरोध कहां भेजा जाए?

सर्वर के सामने एक बैलेंसर रखा जाता है, और क्लाइंट वहां रिक्वेस्ट भेजता है। क्लस्टर में कितने भी सर्वर डाल दिए जाएं, ग्राहक को कोई दिलचस्पी नहीं है। इसका एक URL है - बैलेंसर का पता।

और अब ग्राहक को एक अनुरोध प्राप्त होता है:

- मुझे वासिआ इवानोव के बारे में सारी जानकारी दें।

बैलेंसर कहता है:

- दोस्तों, एक नया अनुरोध! कौन कम भरा हुआ है?

पहला सर्वर:

- मेरे पास कतार में 5 अनुरोध हैं।

दूसरा:

- और मेरे पास 2.

बैलेंसर दूसरे सर्वर के लिए एक अनुरोध भेजता है।

इस तरह की योजना का उपयोग अत्यधिक लोड किए गए एप्लिकेशन के लिए किया जाता है - जब बहुत सारे अनुरोध होते हैं कि एक सर्वर केवल उनके साथ सामना नहीं कर सकता है।

फेसबुक, अमेज़न, गूगल - लाखों उपयोगकर्ता वहाँ जाते हैं। एक सर्वर उन्हें संभाल नहीं सकता। इसलिए, वे एक क्लस्टर डालते हैं, और बैलेंसर उनके बीच लोड साझा करता है। और इस मामले में, क्लस्टर में 2 सर्वर नहीं हो सकते हैं, लेकिन 10, 15, जब तक हमें ज़रूरत होती है, हम कई सेट करते हैं।

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

इस योजना को हॉट स्टैंडबाय कहा जाता है - जब हमारे पास समानांतर में चलने वाले कई सर्वर होते हैं, और बैलेंसर उनके बीच लोड वितरित करता है।

एक ठंड आरक्षित योजना भी हो सकती है - जब हमारा दूसरा सर्वर "बस के मामले में" एक बैकअप है। सभी अनुरोध पहले सर्वर पर जाते हैं, दूसरे पर टिकी हुई है।

लेकिन अगर पहले सर्वर पर कुछ होता है और वह मर जाता है, तो बैलेंसर दूसरे सर्वर

पर लोड रीडायरेक्ट करेगा: इस समय, सर्वर 1 पर समस्या से निपटने के लिए प्रशासकों के पास समय होगा।

कोल्ड रिजर्व स्कीम का उपयोग तब किया जाता है जब एक सर्वर लोड को झेलने और अच्छी गति देने में सक्षम हो। लेकिन आवेदन व्यापार महत्वपूर्ण और सरल अस्वीकार्य है।

यह न केवल सरल हो सकता है क्योंकि कुछ बुरा हुआ है। एक नियमित अनुप्रयोग अद्यतन भी है। दोनों बैकअप योजनाएं आपको दर्द रहित रूप से अपग्रेड करने की अनुमति देती हैं। यदि क्लस्टर में दो सर्वर हैं, तो अपडेट इस तरह दिखाई देगा:

सभी लोड को सर्वर 2 पर पुनर्निर्देशित करें
सर्वर 1 बंद करो
अद्यतन सर्वर 1
हम इसे लॉन्च करते हैं और इस पर पूरे लोड को निर्देशित करते हैं
सर्वर 2 बंद करो
इसे अपडेट करो
हम लॉन्च करते हैं
लोड को फिर से विभाजित करें (यदि यह एक गर्म रिजर्व है)

यही है, आवेदन बिल्कुल भी काम करना बंद नहीं करता है!

इस प्रकार, अतिरेक योजनाएं हमें "1 लिंक गिरने की समस्या को खत्म करने में मदद करती हैं - हर कोई आराम कर रहा है।" क्लाइंट को कभी पता नहीं चलेगा कि क्लस्टर में एक या अधिक सर्वर मृत हैं, सब कुछ उसके लिए काम किया है, और यह काम करता है।

उच्च लागत

सर्वर उपकरण महंगा है। वहां आप एक होम कंप्यूटर के लिए एक नियमित एसएसडी नहीं डाल सकते हैं। क्यों? क्योंकि हार्डवेयर के लिए सर्वर की आवश्यकताएं पूरी तरह से अलग हैं + विशिष्ट कार्यों के लिए समर्थन है:

- HDD में एक विशेष नियंत्रक फर्मवेयर है, जो कि RAID में डिस्क ऑपरेशन के लिए अनुकूलित है, यह घर पर आवश्यक नहीं है।

- एसएसडी में कैपेसिटर के एक समूह की उपस्थिति होती है जो बिजली की विफलता के मामले में ऊर्जा को स्टोर करते हैं, ताकि डीडीआर कैश से डेटा को गैर-वाष्पशील मेमोरी में फेंकने के लिए पर्याप्त समय हो और डेटा टूट न जाए।

एसएसडी - एक तेजी से काम करने वाली डिस्क, एचडीडी - सामान्य। RAID - जब हमने एन डिस्क को एक साथ जोड़ा, और डीडीआर कैश रैम है

साथ ही, सर्वर समाधान में आमतौर पर बहुत अधिक वारंटी होती है: 5 वर्ष, एक वर्ष नहीं।

कीमत के लिए वे 2 बार भिन्न होते हैं। उदाहरण के लिए, एसएसडी:

एक घर के लिए गीगाबाइट की लागत 16.53r है
एक सर्वर एंटरप्राइज गिग के लिए 32 रूबल की लागत है

दिसंबर 2019 के आंकड़े। यह ब्रांडेड आयरन लेने के लिए नहीं, बल्कि निर्माता से लिया गया है।

यह बहुत अलग नहीं लगता है, है ना? लेकिन मुद्दा यह है कि एक घर के लिए 1 टीबी आंखों के लिए पर्याप्त है - और सब कुछ फोटो, और फिल्मों में फिट होगा, और अनुप्रयोगों का एक गुच्छा ... और एक डेटाबेस के लिए, कभी-कभी 10 टीबी छोटे होंगे। और यदि आप एक क्लस्टर बनाते हैं, तो हम लागत को 2 से गुणा करते हैं, यदि अधिक नहीं। इसलिए, कीमत अंतर बहुत बड़ा लगता है, लेकिन जब गीगाबाइट में परिवर्तित किया जाता है, तो एक छोटा सा सामने आता है।

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

एक सिस्टम प्रशासक किराया करने की आवश्यकता हैツ

हमें एक सिस्टम एडमिनिस्ट्रेटर को नियुक्त करने की आवश्यकता है जो हमारे सभी एप्लिकेशन सर्वर और डेटाबेस की निगरानी करेगा। उपकरण की लागत में उसका वेतन जोड़ें!

क्या टेस्ट करना है

यह समझने के लिए कि क्या परीक्षण करना है, आपको यह समझने की आवश्यकता है कि कोई व्यक्ति क्या व्यवहार कर रहा है।

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

इसलिए, परीक्षक पहले ग्राहक की जांच करता है! क्योंकि सर्वर पूरी तरह से काम कर सकता है, आप एपीआई स्तर पर परीक्षण भी लिख सकते हैं और वे सभी हरे रंग के होंगे, और ऐसा लगता है कि हर कोई आहत है! और उपयोगकर्ता रिपोर्ट डाउनलोड करेगा और त्रुटि देखेगा। ओह।

सर्वर चल रहा है, क्लाइंट पर कोई त्रुटि आई है। और सैकड़ों "हरे" ऑटोटेस्ट्स की परवाह न करें। उपयोगकर्ता के पास अभी भी एक त्रुटि है। और हमारा काम उसके दृष्टिकोण से देखना है।

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

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

ग्राहक में अब जो भी उपयोगकर्ता देखता है वह सिर्फ एक कैश है, "मैंने जो दर्ज किया है वह मैं प्रदर्शित करता हूं।" यदि आप डेटाबेस की जाँच नहीं करते हैं, तो ऐसी समस्या अभी खुल भी नहीं सकती है। उपयोगकर्ता उत्पाद कार्ड खोलता है - कुछ फ़ील्ड नहीं भरे हैं:

- ठीक है, शायद वे भरे नहीं थे।

और वे भर गए! बस बदमाशों को बचाने का काम किया। इसलिए, यदि हमारे पास केवल एक ब्लैक बॉक्स है, तो हमें जांचने की ज़रूरत है, "क्या डेटा वास्तव में सहेजा गया है?" बचाया? कार्ड को एक नई विंडो में खोलें या एपीआई विधि के माध्यम से जानकारी को कॉल करें।

यदि आपके पास डेटाबेस तक पहुंच है - बस इस पर जांच करें कि सब कुछ ठीक है। यदि आपके पास सर्वर लॉग्स तक पहुंच है, तो उन्हें त्रुटियों के लिए जांचें।

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

ठीक है, अगर बुरे लोग ऐसा कर सकते हैं, तो परीक्षक को भी ऐसा करने में सक्षम होना चाहिए! क्योंकि परीक्षक हमारे उत्पाद के बारे में जानकारी प्रदान करता है।

परीक्षक कमजोरियों की जांच करता है और फिर टीम को बताता है:

- दोस्तों, इसलिए मैंने जांच की, हमारे पास ऐसे और ऐसे संभावित छेद हैं। आइए इस बारे में सोचें कि क्या हमें उन्हें किसी तरह से बंद करने की आवश्यकता है या नहीं।

यह तथ्य नहीं है कि वे समस्या को ठीक कर देंगे। शायद आपके पास एक गैर-महत्वपूर्ण अनुप्रयोग है - डेटा लीक नहीं होगा, आप पैसे जमा नहीं करते हैं। फिर कोई भी एक बार फिर से परेशान नहीं करेगा, क्योंकि सुरक्षा के लिए परीक्षण महंगा है, कुछ विशेषज्ञ हैं।

लेकिन कुछ बुनियादी जाँचें जैसे कि sql इंजेक्शन या XSS हमले आपके आवेदन पर जाँच और जाँच के लायक हैं। कम से कम उनकी आलोचना को समझने के लिए। आखिरकार, अगर हमला क्लाइंट को तोड़ देता है - ठीक है, तो खुद को पिनोचियो होने दें। और अगर हमला सर्वर डालता है, तो यह बहुत अच्छा नहीं है। और किसी को कम से कम यह जानना चाहिए कि यह क्या होता है।

संपूर्ण

क्लाइंट वह प्रोग्राम है जिसके साथ उपयोगकर्ता काम करता है। वह नहीं जानता कि क्या यह उसके कंप्यूटर पर पूरा कार्यक्रम है, या कहीं आधार वाला सर्वर या यहां तक कि एक पूरे RAID को इसके साथ जोड़ने में बाधा है। यह ब्राउज़र में या डेस्कटॉप एप्लिकेशन के साथ काम करता है। और उसे बस इतना पता होना चाहिए कि कहां प्रहार करना है।

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

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

कभी-कभी वे कहते हैं कि "एप्लिकेशन सर्वर" और "डेटाबेस सर्वर"। यह सामान्य है, क्योंकि वास्तव में सर्वर सिर्फ एक मशीन, एक कंप्यूटर है। और डेटाबेस और एप्लिकेशन सर्वर आमतौर पर सुरक्षा के लिए, विभिन्न मशीनों पर संग्रहीत होते हैं। इस मामले में, यदि वे "एप्लिकेशन सर्वर" कहते हैं - हम अपनी योजना के दूसरे लिंक के बारे में बात कर रहे हैं।

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

DB (डेटाबेस) - डेटा वेयरहाउस। यहां आप आसानी से जानकारी खोज सकते हैं + सुनिश्चित हैं कि यह बना रहेगा, भले ही एप्लिकेशन में कुछ टूट जाए।

डेटाबेस के लिए कितना स्थान आवश्यक है, यह डेटा की मात्रा पर निर्भर करता है। बैंकों में विशाल आधार हैं, जहां 1tb कुछ ही होगा। और बहुत छोटे हैं जो आप अपनी मशीन पर स्थापित कर सकते हैं। उदाहरण के लिए,XAMPP को सप्लाई किया जा सकता है। और इसकी संभावना नहीं है कि आप इसमें इतना डेटा रट लेते हैं कि आपके पास उनके लिए जगह नहीं है।

एक अलग आधार नहीं हो सकता है, तो संरचना दो स्तरीय हो जाएगी: क्लाइंट-सर्वर। और बस यही!

योजना सशर्त है, वास्तविक जीवन में हमारे पास कम से कम ग्राहक होंगे। और यदि एप्लिकेशन को बहुत अधिक लोड किया जाता है, तो कई सर्वर और कई डेटाबेस होंगे:

PS - मेरे ब्लॉग में "उपयोगी" टैग के तहत अधिक उपयोगी लेख देखें

चित्रों में क्लाइंट-सर्वर आर्किटेक्चर