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

Question

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

Comments

डेटाबेस स्वतंत्र हैं

— ईवान

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

— वालफ्रैट

पृथक रहते हुए सेवाएं आसानी से डेटाबेस साझा कर सकती हैं: बस प्रत्येक सेवा को अपने स्वयं के डेटाबेस उपयोगकर्ता को अपनी तालिकाओं तक पहुंच दें, लेकिन अन्य सेवाओं के तालिकाओं को नहीं।

— मोनिका

आपको एक से अधिक कोड मॉड्यूल की आवश्यकता क्यों है? आप बस एक बड़े स्पेगेटी वर्ग में सभी कोड डाल सकते हैं! यह कम काम है !!! (नीचे की ओर, निश्चित रूप से, यह है कि परिवर्तन प्रबंधन एक बहुत बड़ी समस्या बन जाता है।)

— जॉन वू

@ सोलोमनऑफ़सैट अकेले अपनी सेवाओं को अलग करने के लिए पर्याप्त नहीं है। उन "उपयोगकर्ताओं" में से एक अभी भी एक रन दूर क्वेरी को निष्पादित कर सकता है जो धीमा हो जाता है या सब कुछ नीचे ले जाता है। यह अभी भी विफलता का एक बिंदु है। आपने केवल उन्हें अलग-थलग कर दिया है।

— रबरडक

Answer 1

हमें इसकी आवश्यकता भी क्यों है?

तुम नहीं।

प्रत्येक सेवा के लिए एक अलग डेटाबेस बनाना डोमेन सीमाओं को लागू करने में मदद करता है, लेकिन यह केवल एक दृष्टिकोण है। आपकी सभी सेवाएँ समान डेटाबेस साझा करने से आपको कुछ भी नहीं रोक रही हैं।

जब तक आपकी सेवाएं व्यवहार करती हैं और अन्य सेवाओं के स्वामित्व वाले डेटा के लिए अप्रत्याशित चीजें नहीं करती हैं, आप ठीक रहेंगे।

मुझे नहीं पता कि आप क्या पढ़ते हैं, लेकिन आपको इस बात की जानकारी होनी चाहिए कि माइक्रोसॉफ़्ट आर्किटेक्चर पर कई अलग-अलग राय हैं। यहाँ विषय पर एक अच्छा ब्लॉग पोस्ट है।

मैंने देखा है कि लोग इस विचार को आंशिक रूप से संदर्भित करते हैं, जैसा कि "प्रत्येक माइक्रोसिस्ट को स्वयं के डेटाबेस को नियंत्रित करना चाहिए और दो सेवाओं को डेटाबेस साझा नहीं करना चाहिए।" यह विचार ध्वनि है: सेवाओं में एक भी डेटाबेस को साझा न करें क्योंकि तब आप संघर्षों में भाग लेते हैं जैसे कि रीडिंग / राइटिंग पैटर्न, डेटा-मॉडल संघर्ष, समन्वय चुनौतियाँ, आदि।

लेकिन एक एकल डेटाबेस हमें बहुत सारी सफारी और उपयुक्तताएं प्रदान करता है: ACID लेनदेन, देखने के लिए एकल स्थान, अच्छी तरह से समझा गया (थोरा?), प्रबंधन करने का एक स्थान आदि।

माइक्रोसर्विस की यात्रा बस इतनी ही है: एक यात्रा । यह प्रत्येक कंपनी के लिए अलग होगा। कोई कठिन और तेज़ नियम नहीं हैं, केवल ट्रेडऑफ़ हैं।

माइक्रोसेर्वर के बारे में सबसे कठिन हिस्सा: आपका डेटा

Comments

कुछ वातावरणों में, आपका भंडारण वैसे भी एक और माइक्रोसेवर है ...

— svidgen

आपको वास्तव में इसकी आवश्यकता है। माइक्रोसर्विस का एक प्रमुख लाभ यह है कि हर चीज का पूर्ण पृथक्करण हो सके। एक टीम पूरी तरह से Microsoft स्टैक से LAMP तक जाने के लिए एक दिन तय कर सकती है, यहां तक ​​कि अन्य टीमों से सलाह के बिना। यदि एक ही डेटाबेस साझा किया जाता है, तो आप किसी भी मुक्त नहीं हैं। टीम A SQL Server 2012 से SQL Server 2016 में जाना चाहता है, लेकिन टीम B नहीं कर सकता, क्योंकि वे एक सुविधा का उपयोग कर रहे हैं जिसे नए संस्करण से हटा दिया गया था। दुर्भाग्य से, यह संस्करणों तक सीमित नहीं है; हर बात दो टीमों में आम तौर पर संघर्ष हो सकता है।

— आर्सेनी मूरज़ेंको

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

— डैन विल्सन

मैंने एक ऐसा संगठन भी नहीं देखा है जो वास्तव में टीमों को अत्यधिक भिन्न प्लेटफार्मों (जैसे .NET बनाम दीपक) का उपयोग करने की अनुमति देता है। इस तरह के एक दुष्ट निर्णय को बहुत जल्दी डर से खत्म कर दिया जाएगा कि कुछ सेवाओं को सिलोस में खत्म किया जाएगा और केवल एक टीम द्वारा बनाए रखा जा सकता है।

— डैन विल्सन

@DanWilson: बेशक बाद में डेटाबेस को विभाजित करना संभव है। समस्या यह है कि जब आप एक साझा डेटाबेस से शुरू करते हैं, तो विभाजन एक कठिन विकल्प बन जाता है। मूल उदाहरण: आप डेटाबेस के अगले संस्करण से एक सुविधा चाहते हैं; दूसरी टीम अभी तक माइग्रेट नहीं कर सकती। ज्यादातर मामलों में, आप विभाजित नहीं करेंगे (बहुत मुश्किल), लेकिन नई सुविधा का उपयोग नहीं करना पसंद करते हैं, जो दुर्भाग्यपूर्ण है।

— आर्सेनी मूरज़ेंको

Answer 2

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

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

अलग डेटाबेस की बात चर्चा से परे है। या मैं सादा गलत हूं?

उस ने कहा, तुम भी गलत हो।

जब आप क्लाउड में काम कर रहे होते हैं, तो डेटाबेस सस्ते होते हैं। आम तौर पर नि: शुल्क! ज़रूर, सर्वर में पैसा खर्च होता है, लेकिन हम एक व्यक्तिगत सर्वर के बारे में बात नहीं कर रहे हैं प्रति माइक्रो सर्विस (कम से कम, पहले नहीं)। (तार्किक) डेटाबेस के एक समूह के साथ एक एकल सर्वर ठीक है जब तक आप क्रॉस-डेटाबेस प्रश्नों (जो कि "स्वतंत्र रूप से तैनात और स्केलेबल" को नुकसान पहुंचाने वाली निर्भरता का परिचय देते हैं) से बचने के बारे में मेहनती हैं। Azure SQL जैसी कुछ क्लाउड डेटाबेस सेवाओं में नर्क, क्रॉस DB प्रश्न असंभव हैं। तुम वहाँ भी मेहनती होने की जरूरत नहीं है ...

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

स्थानों के बहुत मेहनती नहीं हैं। उनके पास प्रवेश स्तर के देवता हैं, या ऐसे लोग जो माइक्रोसेर्वस के दृष्टिकोण को महत्व नहीं देते हैं, या जिनके पास खराब टीम लीड है, या समयरेखा दबाव है जो लोगों को शॉर्टकट लेने का कारण बनता है।

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

Comments

महान। मुझे लगता है कि अगर हम अमेज़ॅन या uber के आकार के नहीं हैं तो हमें बस इससे बचना चाहिए।

— प्रश्न

@PostingQuestions - आपको ऐसा क्यों लगता है?

— तेलस्टिन

हम परियोजनाएं कर रहे हैं, लेकिन यह महसूस नहीं करते कि हमें इसकी आवश्यकता है।

— प्रश्न

Answer 3

हमें इसकी आवश्यकता भी क्यों है?

माइक्रोसर्विस का भारी लाभ- और अधिक बड़े पैमाने पर, SOA- इंटर्नल के एब्स्ट्रक्शन का उच्च स्तर है - न केवल कार्यान्वयन, बल्कि उपयोग की जा रही तकनीकों का भी। उदाहरण के लिए, यदि एक प्रणाली को पाँच टीमों द्वारा पाँच माइक्रोसिस्टर्स के रूप में विकसित किया जाता है, तो एक टीम अपनी राय के लिए अन्य टीमों से पूछे बिना भी पूरी तरह से अलग तकनीकी ढेर (उदाहरण के लिए Microsoft स्टैक से LAMP तक) को स्थानांतरित करने का निर्णय ले सकती है।

अमेज़ॅन AWS या ट्वाइलियो को देखें। क्या आपको पता है कि जावा या रूबी में उनकी सेवाएं लागू हैं या नहीं? क्या वे Oracle या PostgreSQL या Cassandra या MongoDB का उपयोग करते हैं? वे कितनी मशीनों का उपयोग करते हैं? क्या आपको भी इसकी परवाह है; दूसरे शब्दों में, क्या वे तकनीकी विकल्प उन सेवाओं को उपयोग करने के तरीके को प्रभावित कर रहे हैं? ... और अधिक महत्वपूर्ण बात, यदि वे एक अलग डेटाबेस में जाते हैं, तो क्या आपको अपने क्लाइंट एप्लिकेशन को तदनुसार बदलना होगा?

अब, यदि दो सेवाएं एक ही डेटाबेस का उपयोग करती हैं, तो क्या होता है? यहां उन मुद्दों का एक छोटा हिस्सा है जो उत्पन्न हो सकते हैं:

• टीम का विकास करने वाली सेवा 1 SQL Server 2012 से SQL Server 2016 में जाना चाहती है। हालाँकि, टीम 2 एक deprecated सुविधा पर निर्भर करती है जिसे SQL Server 2016 में हटा दिया गया था।

• सेवा 1 एक बहुत बड़ी सफलता है। डेटाबेस को दो मशीनों (मास्टर और फ़ेलओवर) पर होस्ट करना अब कोई विकल्प नहीं है। लेकिन क्लस्टर को कई मशीनों तक स्केल करने के लिए रणनीति बनाने की आवश्यकता होती है जैसे कि शार्किंग। इस बीच, टीम 2 वर्तमान पैमाने से खुश है, और किसी और चीज के लिए स्थानांतरित करने का कोई कारण नहीं देखता है।

• सेवा 1 को अपने डिफ़ॉल्ट एन्कोडिंग के रूप में UTF-8 में जाना चाहिए। सेवा 2, हालांकि, कोड पेज 1252 विंडोज लैटिन 1 का उपयोग करके खुश है।

• सेवा 1 एक विशिष्ट नाम के साथ एक उपयोगकर्ता जोड़ने का फैसला करता है। हालाँकि, यह उपयोगकर्ता पहले से मौजूद है, दूसरी टीम द्वारा कुछ महीने पहले बनाया गया था।

• सेवा 1 को विभिन्न विशेषताओं की बहुत आवश्यकता है। सेवा 2 एक अत्यधिक महत्वपूर्ण घटक है और हमलों के जोखिम को कम करने के लिए डेटाबेस सुविधाओं को अपने न्यूनतम स्तर पर रखने की आवश्यकता है।

• सेवा 1 के लिए 15 टीबी डिस्क स्थान की आवश्यकता होती है; गति महत्वपूर्ण नहीं है, इसलिए साधारण हार्ड डिस्क पूरी तरह से ठीक हैं। सेवा 2 को अधिकतम 50 जीबी की आवश्यकता होती है, लेकिन इसे जितनी जल्दी हो सके एक्सेस करने की आवश्यकता होती है, जिसका अर्थ है कि डेटा को एसएसडी पर संग्रहीत किया जाना चाहिए।

• ...

हर छोटी पसंद हर किसी को प्रभावित करती है। हर फैसले को हर टीम के लोगों को सहयोग से लेना होगा। समझौता करना पड़ता है। एसओए के संदर्भ में जो भी आप चाहते हैं उसे करने के लिए एक पूर्ण स्वतंत्रता की तुलना करें।

यह बहुत [...] असहनीय है।

फिर आप गलत कर रहे हैं। मुझे लगता है कि आप मैन्युअल रूप से तैनात कर रहे हैं ।

यह नहीं है कि चीजों को कैसे किया जाना चाहिए। आपको वर्चुअल मशीन (या डॉकर कंटेनर) की तैनाती को स्वचालित करने की आवश्यकता है जो डेटाबेस चलाते हैं। एक बार जब आप उन्हें स्वचालित कर लेते हैं, तो दो सर्वर या बीस सर्वर या दो हजार सर्वर को तैनात करना बहुत अलग नहीं होता है।

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

यदि किसी विशाल डेटाबेस को विशेष सिस्टम प्रशासक की आवश्यकता होती है, तो केवल एक टीम द्वारा उपयोग किए जाने वाले डेटाबेस को अनिवार्य रूप से इस टीम द्वारा प्रबंधित किया जा सकता है (DevOps भी इसके बारे में है), सिस्टम प्रशासक के समय को मुक्त करता है।

यह बहुत महंगा है

लागत को परिभाषित करें।

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

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

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

Answer 4

डिपेंडेंडिन जो आप "महंगा" मानते हैं।

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

वे सभी सेवाएँ एकल डेटाबेस उदाहरण / सर्वर को भी साझा कर सकती हैं और केवल सेवा के लिए अलग-अलग स्कीमा हैं।

यहां मुख्य तर्क यह है कि सेवा को अपने डेटा को नियंत्रित और नियंत्रित करने की आवश्यकता है। यह कैसे प्राप्त होता है, यह पसंद और तकनीकी विवरण का विषय है।

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

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