वर्तमान में हम अपने नए उत्पाद / परियोजना पर काम कर रहे हैं, यह कुछ विशिष्ट औद्योगिक / सेवा उद्यमों के लिए निर्देशित ग्राहक-सर्वर अनुप्रयोग है। हम जावा फ्रंट-एंड के साथ टीसीपी के ऊपर एक कस्टम प्रोटोकॉल चलाकर एक सर्वर (सी लैंग्वेज और लिनक्स ओनली) बना रहे हैं। हम कोडिंग के काम में लगभग 20% हैं और माइक्रो या मोनोलिथिक कर्नेल आर्किटेक्चर के बीच चयन करने की स्थिति का सामना कर रहे हैं।
मुझे पता है कि माइक्रो बनाम मोनोलिथिक आमतौर पर कर्नेल वास्तुकला के संबंध में है, लेकिन हम विशेष रूप से सर्वर के बारे में बात कर रहे हैं।
कस्टम सर्वर और मौजूदा कुछ क्यों नहीं?
- हमारे यूआई की ज़रूरतें बहुत महत्वपूर्ण हैं और बहुत गतिशील हैं, इस प्रकार वेब / वेब-ब्राउज़र आधारित समाधान उचित नहीं थे।
- ग्राहक अंत में सांख्यिकीय प्रसंस्करण महत्वपूर्ण है और इसलिए, फिर से, ब्राउज़रों को थोड़ी मदद मिली। (बेशक, हम सर्वर के अंत में प्रसंस्करण कर सकते हैं और ग्राहक को संसाधित डेटा पर पास कर सकते हैं लेकिन यह सर्वर पर बहुत अधिक भार और ग्राहक संसाधनों का अपव्यय होगा)।
- इसके अलावा, कम से कम एक भी घटना का प्रबंधन करने के लिए कम से कम तीन तकनीकों (JS / HTML / CSS) के साथ एक रेगिस्तान तूफान के बीच में घर में झाडू लगाने जैसे पूरे अनुभव करता है - आप इसे n-बार स्वीप करते हैं, धूल n + 1 बार जमा होती है।
माइक्रो और अखंड सर्वर के बारे में क्या? आप क्या बात कर रहे हैं?
निम्नलिखित (काल्पनिक) ग्राहक अनुरोध पर विचार करें:
request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010
इस तरह के अनुरोध को प्राप्त करने पर, एक सर्वर, आमतौर पर, (हम सादगी के लिए थ्रेड और कांटे जैसी संगोष्ठी तकनीकों की अनदेखी कर रहे हैं):
- अनुरोध स्ट्रिंग पार्स करें
- कार्रवाई की पहचान करें (
HistoricDataSets LIMIT Year (2010)हमारे मामले में प्राप्त करें ) - दृढ़ता परत (ओरेकल, हमारे उदाहरण में, कहने दें) के साथ बातचीत करें और डेटा प्राप्त करें।
प्रोटोकॉल के अनुसार डेटा को फॉर्मेट करें। उदाहरण के लिए:
प्रतिक्रिया-आईडी: 123
सफलता: सही
प्रतिक्रिया-पाठ: डेटासेटइस प्रकार तैयार किए गए डेटा के साथ क्लाइंट को जवाब दें।
इसे हम एक मोनोलिथिक सर्वर (एक अखंड कर्नेल के समान कहते हैं, जहां कर्नेल स्थान में सभी ओएस कामकाज किए जाते हैं)।
रसीद पर फिर से उसी अनुरोध पर विचार करें, इस बार सर्वर (हमने आईपीसी के रूप में केवल साझा की गई मेमोरी को फिर से सरलता के लिए ग्रहण किया है):
Parserप्रक्रिया के लिए साझा मेमोरी में अनुरोध डालता हैParserस्ट्रिंग को पार्स करता है, कार्य को दिखाता है और निर्देशनExecutionerकार्य निष्पादित करने के लिए प्रक्रिया।Executionerतो करने के लिए डेटा गुजरताFomatterप्रक्रिया है जो, एक प्रोटोकॉल स्ट्रिंग में डेटा स्वरूपण के बाद, सर्वर के लिए रिटर्न।- सर्वर इसे क्लाइंट (प्रतिक्रिया) के लिए भेज देता है।
बेशक, के बजाय Parser, Executionerऔर Formatterयह एक एकल लेकिन अलग प्रक्रिया हो सकती थी। इसे हम माइक्रो सर्वर (माइक्रो कर्नेल के समान होना चाहिए जो मुश्किल से न्यूनतम होता है) कह रहे हैं। सर्वर प्रभावी रूप से केवल सुन रहा है और प्रतिक्रिया कर रहा है जबकि सभी चरणों को अलग-अलग प्रक्रिया (एस) द्वारा ध्यान दिया जाता है।
कौन सा चुनना है? हम भ्रमित हैं! जबकि अखंड सर्वरों की कोशिश की जाती है और परीक्षण किया जाता है (अधिकांश HTTP-Web Servers?) और प्रोग्राम को आसान बनाने के लिए और संक्षिप्त रूप से अच्छी तरह से संभाल सकते हैं। माइक्रो सर्वर, प्राइमा फेशिअल, एक काम करने के लिए एक प्रोग्राम के UNIX सिद्धांत के अनुसार तेज और आसान लगते हैं, लेकिन यह भी विकसित करने के लिए जटिल हैं, esp। सम्भावनाओं को ध्यान में रखते हुए।
प्रश्न (ओं)
- क्या हैं (संभवतः हो सकता है) प्रत्येक दृष्टिकोण के पेशेवरों और विपक्षों?
- कब उपयोग करें? (इसकी व्याख्या एक सामान्य प्रश्न के रूप में भी की जा सकती है: IPC का उपयोग कब करें?)
- यदि माइक्रो कर्नेल को चुना जाता है, तो कोर-सर्वर का हिस्सा बनने के लिए किन कार्यों की आवश्यकता है और क्या नहीं?
इसी तरह के / संबंधित प्रश्न
- विशाल अखंड आवेदन के खतरों
- बाहरी बनाम एंबेडेड ब्राउज़र (स्पर्शरेखा)
- बहुभाषाविद (मूर्त) में अखंड एप्लिकेशन को परिवर्तित करने की सलाह
कुछ जानकारी जो सहायक हो सकती है:
- हमारे संभावित ग्राहकों को दो श्रेणियों में विभाजित किया जा सकता है:
- बड़ा: लगभग 1,700 - 2,000 अनुरोध प्रति मिनट
- छोटा: लगभग 650 - 700 अनुरोध प्रति मिनट
- डेटा प्रति अनुरोध चक्र (अनुरोध और बाद की प्रतिक्रिया) को सामान्य रूप से औसतन 1.20 एमबी और लगभग 250-300 एमबी के बदतर स्थिति के साथ वितरित किया जा सकता है।
- उत्पाद अवधारणा अपेक्षाकृत नई है, लेकिन इसमें कोर संचालन को प्रभावित करने की क्षमता है, इसलिए हम ग्राहक बजट को लचीला बनाने के लिए केवल एक निश्चित अंतराल (9-12 महीने) के बाद की तैनाती की उम्मीद करते हैं, यह हार्डवेयर की मात्रा को सीमित करता है जो ग्राहक तैयार होगा। जासूसी करने के लिए। छोटे वाले।
- प्रत्येक ग्राहक का अपना क्लाइंट-सर्वर स्टैक होगा। सर्वर ग्राहक की टीम द्वारा प्रबंधित ग्राहक के हार्डवेयर पर चल रहा होगा, जबकि ग्राहकों को कार्यात्मक कर्मचारियों की मशीनों पर तैनात किया जाएगा
- क्लाइंट और सर्वर अनुप्रयोग दोनों के लिए दूरस्थ अद्यतन आवश्यक है
PUSHयदि सर्वर क्लिक करता है तो सर्वर द्वारा वास्तविक समय सेवाएं 'अत्यधिक' वांछित हो सकती हैं!