माइक्रोसर्विसेज और डेटा स्टोरेज


26

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

  • क्षैतिज रूप से स्केलेबल - मैं लोड और / या नीचे जाने वाले सर्वर के साथ सामना करने के लिए एक माइक्रोस सर्विस की कई निरर्थक प्रतियां चला सकता हूं।
  • ढीले-ढाले जोड़े - मैं दूसरों को बदलने के लिए बिना माइक्रोसॉफ़्ट के आंतरिक कार्यान्वयन को बदल सकता हूं, और मैं स्वतंत्र रूप से तैनात कर सकता हूं और उन्हें बदल सकता हूं ... आदि।

मेरी समस्या डेटा स्टोरेज को लेकर है। जैसा कि मैंने देखा कि इसके कई विकल्प हैं:

  1. सभी माइक्रोसर्विसेज द्वारा साझा की गई एक एकल डाटाबेस सेवा - यह ढीली कपलिंग के किसी भी लाभ को पूरी तरह से समाप्त करने वाली प्रतीत होगी।
  2. प्रत्येक microservice पर एक स्थानीय रूप से स्थापित डेटाबेस उदाहरण - मैं इसे क्षैतिज रूप से स्केल करने का एक तरीका नहीं देख सकता, इसलिए मुझे नहीं लगता कि यह एक विकल्प होगा।
  3. प्रत्येक microservice की खुद की डेटाबेस सेवा है - यह सबसे अधिक आशाजनक लगता है, क्योंकि यह ढीले युग्मन और क्षैतिज स्केलिंग के लाभों को सुरक्षित रखता है (निरर्थक डेटाबेस प्रतियों का उपयोग और / या कई में पैनापन)

मेरे लिए, तीसरा विकल्प एकमात्र विकल्प प्रतीत होता है, लेकिन यह मेरे लिए अविश्वसनीय रूप से हेवीवेट लगता है, और एक बहुत ही कठिन समाधान है। अगर मैं इसे सही समझ रहा हूं, तो 4-5 माइक्रोसर्विसेज के साथ एक साधारण एप्लिकेशन के लिए मुझे 16-20 सर्वर चलाना होगा - प्रति माइक्रोसेवक (सर्वर की विफलता के मामले में, और डाउनटाइम के बिना तैनाती के लिए) दो डेटाबेस सेवा प्रति माइक्रोसॉर्स सेवा (सर्वर की विफलता आदि के मामले में ...)।

यह, काफी स्पष्ट रूप से, थोड़ा हास्यास्पद लगता है। एक साधारण एपीआई को चलाने के लिए 16-20 सर्वर, यह ध्यान में रखते हुए कि एक यथार्थवादी परियोजना में संभवतः 4-5 से अधिक सेवाएं होंगी? क्या कुछ मौलिक अवधारणा है जो मुझे याद आ रही है जो इसे बताएगी?

उत्तर देते समय कुछ चीजें जो मदद कर सकती हैं:

  • मैं इस परियोजना का एकमात्र विकासकर्ता हूं, और भविष्य के भविष्य के लिए होगा।
  • मैं Node.js और MongoDB का उपयोग कर रहा हूं, लेकिन मुझे भाषा-अज्ञेय उत्तरों में दिलचस्पी होगी - एक उत्तर यह भी हो सकता है कि मैं सिर्फ गलत तकनीकों का उपयोग कर रहा हूं!

आपको प्रत्येक माइक्रोसैस सर्विस के लिए किसी अन्य डेटाबेस सेवा की आवश्यकता क्यों है? डेटाबेस सेवा का काम संबंधित माइक्रोसैस सर्विस के तहत ही जोड़ा जा सकता है क्योंकि इसमें पहले से ही डेटाबेस डोमेन ज्ञान है। है ना?
सज्जाद हिसैन खान

जवाबों:


21

आपके तीन विकल्पों में से पहला (एकल, साझा डेटाबेस) और तीसरा ("डेटाबेस सेवा") सबसे आम हैं।

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

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

हालाँकि, मैं एक मध्यवर्ती समाधान प्रस्तावित करूँगा।

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

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


1

प्रत्येक microservice की खुद की डेटाबेस सेवा है - यह सबसे अधिक आशाजनक लगता है, क्योंकि यह ढीले युग्मन और क्षैतिज स्केलिंग के लाभों को सुरक्षित रखता है (निरर्थक डेटाबेस प्रतियों का उपयोग और / या कई में पैनापन)

इस बात से सहमत। तीसरे विकल्प सूक्ष्म सेवाओं के लिए स्वाभाविक पसंद है। यदि सूक्ष्म सेवा वास्तव में स्वतंत्र होने का इरादा रखती है (और वितरित मोनोलिथ का हिस्सा नहीं है ), तो यह सामान्य है कि उनके पास प्रत्येक, एक डेटाबेस हो।

[...] दो वास्तविक माइक्रोसर्विस इंस्टेंस प्रति माइक्रोसर्विस (सर्वर विफलता के मामले में, और डाउनटाइम के बिना तैनात करने के लिए), और प्रति माइक्रोसेव्स (सर्वर विफलता के मामले में ...) दो डेटाबेस सेवा इंस्टेंसेस।

यदि आप एक लोड संतुलन रखना चाहते हैं, तो आप सूक्ष्म सेवाओं की मात्रा के बारे में सही हैं। यदि आप 4 माइक्रो सेवाओं की योजना बना रहे हैं, तो आपको प्रत्येक माइक्रो सर्विस के कम से कम 2 इंस्टेंस (कुल मिलाकर 8) तैयार करने की आवश्यकता है, जैसा कि आप पहले ही समझा चुके हैं।

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

यह, काफी स्पष्ट रूप से, थोड़ा हास्यास्पद लगता है। एक साधारण एपीआई को चलाने के लिए 16-20 सर्वर, यह ध्यान में रखते हुए कि एक यथार्थवादी परियोजना में संभवतः 4-5 से अधिक सेवाएं होंगी? क्या कुछ मौलिक अवधारणा है जो मुझे याद आ रही है जो इसे बताएगी?

एक साधारण एपीआई के लिए यह संख्या मेल नहीं खाती। ध्यान दें कि क्या आप "माइक्रोसैस सर्विस फर्स्ट" के जाल में नहीं गिर रहे हैं ।


मैं जोड़ूंगा कि जहां तक ​​डेटाबेस जाते हैं, अतिरेक को शुरू करने के लिए स्पष्ट स्थान वास्तव में हार्डवेयर स्तर पर है, विशेष रूप से RAID और बैकअप के साथ भंडारण के लिए। बेशक, आप 100% अपटाइम की गारंटी नहीं दे सकते क्योंकि भंडारण से संबंधित चीजें गलत हो सकती हैं (हेक, बस एक सॉफ्टवेयर क्रैश हो सकता है), लेकिन वे आमतौर पर डेटा हानि की तुलना में एक सौदे के इतने बड़े नहीं होते हैं। यदि आप खर्चों के बारे में चिंतित हैं, तो आप निश्चित रूप से केवल सादे डेटा अखंडता पर ध्यान केंद्रित करना चाहते हैं और बाद में अपटाइम अधिकतमकरण के बारे में चिंता करना चाहते हैं।
कैट

0

Microservices शायद उन्मुख में सेवा उन्मुख वास्तुकला का एक रूप है। उनका सामान्य उद्देश्य युग्मन को कम करना और स्वतंत्र विकास और तैनाती के लिए अनुमति देना है।

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

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

इसलिए, जब हम अलग-अलग microservices के बारे में बात कर रहे हैं, हम तार्किक स्तर पर एपीआई और अलग-अलग जिम्मेदारियों और अलग-अलग विकास / तैनाती चक्रों के बारे में बोल रहे हैं। और जब हम क्षैतिज स्केलिंग के बारे में बात कर रहे हैं, तो हम भौतिक स्तर पर एक (एकल) microservice के कार्यान्वयन और स्टेटलेस और स्टेटफुल घटकों में इसके अपघटन के बारे में बात कर रहे हैं।

कई माइक्रोसर्विसेज को लागू करते समय, हमारे पास राज्य घटकों के लिए डेटाबेस प्रौद्योगिकी के पुन: उपयोग के लिए विकल्प हैं:

  • प्रति माइक्रोसेवर के लिए अलग डेटाबेस
  • इसके साथ साझा डेटाबेस:
    • अलग / निजी स्कीमा प्रति microservice
    • microservice प्रति अलग / निजी टेबल

अधिक देखें यहाँ

सभी माइक्रोसर्विसेज द्वारा साझा की गई एक एकल डाटाबेस सेवा - यह ढीली कपलिंग के किसी भी लाभ को पूरी तरह से समाप्त करने वाली प्रतीत होगी।

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

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

आम तौर पर, एक अच्छी राशि है जो कि माइक्रोसिस्टर्स और स्टेटफुल दृढ़ता के बारे में लिखी गई है, यहां भी देखें ।


-1

ठीक है, मैंने इस धागे में सभी पदों के माध्यम से पढ़ा है और आपको बता सकता हूं कि मैं इस प्रश्न से भ्रमित हूं: यह डेटाबेस और सर्वर के साथ डेटा एक्सेस सेवा (डीबी सेवा) के साथ सेवाओं के साथ माइक्रोसॉर्स्ट (एमएस) को मिलाता है ...

यदि MS एक स्वतंत्र (परिनियोज्य) घटक है जो एक सरल कार्य को एक निराधार तरीके से हल करता है, तो उसे क्या चाहिए? यदि एक अधिक जटिल कार्य हल किया जाना है, जिसे एक से अधिक सरल उप-कार्यों (MS?) को एक साथ हल करने की आवश्यकता है, तो क्या यह अभी भी एक एमएस है? SOA में, इसे ऑर्केस्ट्रेटिंग सेवा कहा जाता है। यह "प्रक्रिया" को कार्यान्वित करता है और एमएस इनवोकेशन को समन्वित करता है, इस प्रकार इसे अपने राज्य (सभी ऑर्केस्ट्रेशन / आयोजकों / रचनाकारों / आदि को स्थिर रखने की आवश्यकता होती है) और एक व्यक्तिगत डेटास्टोर की आवश्यकता होती है: ऑर्केस्ट्रेटर की स्थिति को और कोई नहीं कर सकता है।

हालाँकि, हम डेटाबेस के बारे में नहीं बल्कि डेटाबेस एक्सेस MS / सेवा के बारे में बात करते हैं, और यह पूरी तरह से अलग मामला है। एक MS को कंपनी में एकत्र किए गए कुछ डेटा की आवश्यकता हो सकती है (एप्लिकेशन में यह उसके भीतर संचालित नहीं होता है) और यह डेटा के लिए अपने API / इंटरफ़ेस के माध्यम से दूसरे MS से नहीं पूछ सकता है। यह सबसे आम और यथार्थवादी परिदृश्य है। और उसी या भिन्न एप्लिकेशन के किसी अन्य MS को इस डेटा की आवश्यकता हो सकती है या इसे बदल भी सकता है। हां, वे डेटा के लिए प्रतिस्पर्धा करते हैं क्योंकि यह एमएस के उभरने से पहले हमेशा था।

हम crash द्वार ’को क्यों दुर्घटनाग्रस्त कर रहे हैं, जो अच्छी तरह से ज्ञात और खुला है? एक एमएस और एक नियमित आत्मनिर्भर वस्तु के बीच इस संबंध में क्या अंतर है? एमएस के लिए हमें एक व्यक्तिगत डेटाबेस की आवश्यकता क्यों है अगर यह (लचीलेपन और व्यावहारिकता उद्देश्यों के लिए) वैसे भी अपनी डेटा एक्सेस सेवा (डीएएस) को संलग्न करना चाहिए? यह मत भूलो कि डीएएस डेटाबेस से भौतिक कनेक्टिविटी के बारे में जागरूकता से एक व्यावसायिक कार्य के साथ एमएस को ढालता है। यह ढीला-युग्मन और लचीलापन एमएस को स्वतंत्र रूप से उस पर कोई डेटाबेस लंगर के साथ कई अनुप्रयोगों में भाग लेने के लिए संरक्षित करना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.