यह बहुत सारी संभावित प्रतिक्रियाओं के साथ एक खुला हुआ सवाल है जो इस बात पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं। फिर भी मैं एक उत्तर के रूप में कुछ चीजें जोड़ूंगा, क्योंकि एक टिप्पणी पर्याप्त बड़ी नहीं होगी।
सेवा एक डेटाबेस कनेक्शन पूल के रूप में कार्य करेगी (मुझे लगता है कि 2000+ डेटाबेस पर कनेक्शन समस्याओं का कारण होगा);
हाँ यह एक अच्छा विचार है। आप कम संख्या में कनेक्शन खोले रखते हैं और सेवा में अनुरोध आने पर आप उनका पुन: उपयोग करते हैं। लेकिन आपको यह जानने की आवश्यकता है कि डेटाबेस के लिए कितनी तेजी से अनुरोध किया जाएगा और प्रत्येक अनुरोध कितना उपयोग करता है, अन्यथा एक छोटा पूल आसानी से समाप्त हो सकता है और डेटाबेस कनेक्शन जारी होने की प्रतीक्षा करते समय अन्य अनुरोध अवरुद्ध हो जाएंगे।
कैशिंग वहां मदद कर सकता है, पहले से ही प्राप्त किए गए डेटा को वापस करने के लिए (जैसे मैंने कहा, यह निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं - यदि प्रश्न अद्वितीय हैं तो आप बहुत कैश नहीं कर सकते हैं)।
यह भी ध्यान दें कि आपके द्वारा लगाई गई सेवाओं की संख्या से पूल का आकार कई गुना बढ़ जाएगा। कुछ सेवाएं और आप बड़े डेटाबेस पूल आकार का उपयोग कर सकते हैं; अधिक सेवाओं और आपको पूल के आकार को कम करने की आवश्यकता है, ताकि आपके पास डेटाबेस में खोले गए समान कनेक्शन हों, कुल मिलाकर।
कुछ प्रश्नों की सेवा के लिए लॉग-शिपिंग के साथ अन्य रीड-ओनली डेटाबेस के साथ डेटाबेस रखना संभव है;
डेटाबेस आसानी से आपकी अड़चन बन सकता है। बहुत सारे कनेक्शन और / या बहुत सारे प्रश्न और आप इसे तोड़ सकते हैं। उस समय यह मायने नहीं रखता है कि आप अपनी सेवाओं को किसी भी संख्या में क्षैतिज रूप से बढ़ा सकते हैं। सभी अनुरोध अंततः एक ही डेटाबेस तक पहुंचेंगे।
इसकी सुरक्षा के लिए कई तरीके हैं: मेरे द्वारा पहले से उल्लेखित कैशिंग (आपके उपयोग के मामले पर निर्भर करता है), कुछ प्रश्नों की सेवा के लिए अन्य सर्वरों पर कुछ जानकारी की नकल करें, जैसा कि आपने उल्लेख किया है, CQRS (आपके उपयोग के मामले पर निर्भर करता है), एक रिलेशनल बनाम नॉन-रिलेशनल का उपयोग करें (आपके उपयोग के मामले पर फिर से निर्भर करता है), आदि।
ध्यान दें कि जब आप उस तरह डेटा वितरित करते हैं, तो कैप प्रमेय लागू होना शुरू होता है। इस बात से अवगत रहें कि आपको स्थिरता और उपलब्धता के बीच समझौता करने की आवश्यकता हो सकती है।
यह बेहतर होगा क्योंकि हम REST सेवाओं को चलाने के लिए और अधिक मशीनें जोड़ सकते हैं;
हां, REST सेवा पैमाने पर होगी, लेकिन जैसा कि मैंने ऊपर उल्लेख किया है, यदि आप डेटाबेस की रक्षा नहीं करते हैं, तो यह आसानी से अड़चन बन सकती है।
सुरक्षा और बैंडविड्थ बचत कारणों के लिए संपीड़न के साथ HTTPS का उपयोग करना संभव है;
हां, साथ ही साथ अन्य चीजें ... शायद आप बाद में प्रमाणीकरण / प्राधिकरण चाहते हैं, आदि।
2000+ मशीनों को फिर से तैयार किए बिना व्यावसायिक संस्थाओं पर कुछ केंद्रीकृत परिवर्तन करना संभव है;
हां, लेकिन एक निश्चित सीमा तक और सभी प्रकार के परिवर्तन नहीं। यदि आप एक परिवर्तन करते हैं तो आपको क्लाइंट को भी अपडेट करना होगा। तो ग्राहकों को नवीनतम संस्करण में अपडेट करने की रणनीति के बारे में सोचें या यदि आप पुराने ग्राहकों को अभी भी काम करने और एप्लिकेशन का उपयोग करने की अनुमति देते हैं।
यह अन्य प्रणालियों के साथ बेहतर एकीकृत करता है (बस इसे REST सेवा की ओर इंगित करता है)।
हां, लेकिन इसका मतलब है कि आपकी सेवा के लिए ग्राहक जो शायद आप नियंत्रित नहीं कर सकते।
यदि आप एक ब्रेकिंग परिवर्तन करते हैं और आपके पास अपने 2000+ जावाएफ़एक्स ग्राहकों को अपडेट करने के लिए एक अच्छी रणनीति है तो कोई समस्या नहीं है। लेकिन अगर अन्य ग्राहक मौजूद हैं और आपके पास उन पर नियंत्रण नहीं है, तो आपको REST सेवा पर संस्करण लागू करने और एक से अधिक संस्करण का समर्थन करने की आवश्यकता हो सकती है जब तक कि सभी नवीनतम को अपडेट न कर सकें।
जैसा मैंने कहा, यह इस बात पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं। कुल मिलाकर, आपका एक अच्छा विचार है। लेकिन ध्यान रखें कि सामान केवल मुफ्त में नहीं आएगा क्योंकि आप एक डेटाबेस के सामने एक आरईएसटी सेवा को चिपकाते हैं।
बस मेरे 2 सेंट!