एक अलग माइक्रोसॉर्क्स द्वारा "स्वामित्व" डेटाबेस से डेटा पढ़ना इतना बुरा क्यों है

Question

मैंने हाल ही में माइक्रोसॉफ़्ट वास्तुकला पर इस उत्कृष्ट लेख को पढ़ा है: http://www.infoq.com/articles/microservices-intro

यह बताता है कि जब आप अमेज़न पर एक वेब पेज लोड करते हैं, तो उस पेज को सेवा देने के लिए 100+ माइक्रोसर्विसेज सहयोग करते हैं।

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

क्या मुझसे कोई चूक हो रही है? क्या कोई और कारण है कि डेटा को केवल एक एपीआई के माध्यम से पढ़ा जाना चाहिए?

कहने की जरूरत नहीं है, मेरी कंपनी अमेज़ॅन की तुलना में काफी छोटी है (और हमेशा रहेगी) और हमारे उपयोगकर्ताओं की अधिकतम संख्या लगभग 5 मिलियन हो सकती है।

Comments

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

— जोप एगेन

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

— पैट्रिक

लेकिन उस मामले में, दृष्टिकोण केवल एपीआई का हिस्सा नहीं बन जाता है, कम से कम अर्थ उद्देश्यों के लिए? यह सिर्फ एक बात है कि आप एपीआई को क्या कह रहे हैं और यह आपको क्या बनाए रखने के लिए मजबूर करता है। (आमतौर पर डेटाबेस के ऊपर एक परत लगातार रखना आसान होता है।)

— lc

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

— डेविड

Answer 1

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

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

आवेदन परत से सीधे भंडारण परत के साथ Fumbling निर्भरता उलटा सिद्धांत क्या करने के लिए सुझाव के विपरीत है।

Comments

यह एक बड़ा मुद्दा है! एक बात जो मुझे कम चिंतित करती है, वह यह है कि अब Postgres के पास डॉक्यूमेंट स्टोर और RDBMS ( withouttheloop.com/articles/2014-09-30-postgresql-nosql ) दोनों के लिए समर्थन है । आपकी बात अभी भी मान्य है, और मैं इस पर ध्यान से विचार करूंगा।

— डेविड

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

— बेन

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

— back2dos

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

— back2dos

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

— back2dos

Answer 2

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

अब, यदि आप उनके डेटाबेस में झांकते हैं

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

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

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

Comments

कृपया ध्यान दें कि उपरोक्त सभी बिंदु वैध हैं, भले ही आप पूरे प्रोजेक्ट पर काम करने वाले एकमात्र डेवलपर हों। एक जटिल परियोजना का प्रबंधन करना, यहां तक ​​कि अपने आप से, इन सभी चिंताओं को आमंत्रित करता है।

— इसका कर्क राशि

Answer 3

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

एक डेटाबेस से पढ़ना और यहां तक ​​कि पढ़ना जो आपके घटकों के बाहर है व्यापार डोमेन वास्तुकला की इस शैली के खिलाफ है।

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

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

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

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

Answer 4

पिछले 20 वर्षों में मैंने कुछ बड़े माड्यूलर डेटाबेस डिज़ाइन देखे हैं और मैंने डेविड द्वारा सुझाए गए परिदृश्य को देखा है जो अब कुछ ही समय में हैं जहाँ एप्लिकेशन ने अपने स्वयं के स्कीमा / तालिकाओं के सेट तक पहुंच लिखी है और किसी अन्य स्कीमा / तक पहुंच को पढ़ा है। तालिकाओं का सेट। अधिकतर यह डेटा कि एक एप्लिकेशन / मॉड्यूल को केवल-पढ़ने के लिए एक्सेस मिलता है, जिसे "मास्टर डेटा" के रूप में वर्णित किया जा सकता है ।

उस समय में मैंने उन समस्याओं को नहीं देखा है जो पूर्व के उत्तर सुझा रहे हैं, जिन्हें मुझे देखना चाहिए था इसलिए मुझे लगता है कि पिछले उत्तरों में उठाए गए बिंदुओं पर अधिक विस्तार से ध्यान देने योग्य है।

परिदृश्य: आप सीधे RDBMS में कुछ घटकों को बाँधते हैं, और आप एक विशेष घटक को एक प्रदर्शन बोतल-नेक बनाते हुए देखते हैं

मैं इस टिप्पणी से सहमत हूँ, सिवाय इसके कि यह भी एक तर्क है कि स्थानीय स्तर पर डेटा की एक प्रति माइक्रोसेवा को पढ़ने के लिए है। यही है, अधिकांश परिपक्व डेटाबेस प्रतिकृति का समर्थन करते हैं और इसलिए किसी भी डेवलपर के प्रयास के बिना "मास्टर डेटा" को भौतिक रूप से माइक्रोसैस डेटाबेस पर दोहराया जा सकता है यदि वह वांछित है या जरूरत है।

कुछ लोग इसे "एंटरप्राइज डेटाबेस" के रूप में पुराने तालमेल में पहचान सकते हैं जो कोर तालिकाओं को "डिपार्टमेंटल डेटाबेस" के रूप में दर्शाते हैं। यहां एक बिंदु यह है कि आम तौर पर यह अच्छा होता है अगर कोई डेटाबेस बदले हुए डेटा (केवल बाइनरी फॉर्म में और स्रोत डेटाबेस के लिए कम से कम लागत पर डेल्टा) की प्रतिकृति में हमारे साथ ऐसा करता है।

इसके विपरीत, जब हमारे डेटाबेस विकल्प इस 'शेल्फ' प्रतिकृति समर्थन को बंद नहीं होने देते हैं तो हम एक ऐसी स्थिति में पहुंच सकते हैं, जहां हम "मास्टर डेटा" को माइक्रोसेवा डेटाबेस से बाहर धकेलना चाहते हैं और इसके परिणामस्वरूप डेवलपर के प्रयास का एक महत्वपूर्ण हिस्सा हो सकता है और यह भी एक काफी कम कुशल तंत्र हो।

डेटाबेस को असामान्य करना चाहते हैं, लेकिन आप नहीं कर सकते क्योंकि अन्य सभी घटक प्रभावित होंगे

मेरे लिए यह कथन सही नहीं है। अपभ्रंश एक "योजक" परिवर्तन है और "विराम परिवर्तन" नहीं है और न ही किसी अनुप्रयोग को अपभ्रंश के कारण तोड़ना चाहिए।

एकमात्र तरीका यह है कि एक एप्लिकेशन को तोड़ता है, जहां एप्लिकेशन कोड "सेलेक्ट * ..." जैसी चीज का उपयोग करता है और एक अतिरिक्त कॉलम को हैंडल नहीं करता है। मेरे लिए कि आवेदन में एक बग होगा?

कैसे एक आवेदन को तोड़ सकते हैं? मुझे FUD लगता है।

स्कीमा निर्भरता:

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

मुख्य आंकडे

स्कीमा जिसे हम आम तौर पर चाहते हैं कि एक माइक्रो-सर्विस के पास केवल-पढ़ने के लिए पहुंच हो, आमतौर पर मैं उद्यम के लिए " मास्टर डेटा " के रूप में वर्णन करता हूं । इसमें मुख्य डेटा है जो उद्यम के लिए आवश्यक है।

ऐतिहासिक रूप से इसका मतलब यह है कि जिस स्कीमा पर हम निर्भरता जोड़ते हैं, वह परिपक्व और स्थिर (उद्यम और अपरिवर्तनीय कुछ मौलिक) है।

मानकीकरण

यदि 3 डेटाबेस डिज़ाइनर जाते हैं और एक सामान्य डीबी स्कीमा डिज़ाइन करते हैं तो वे उसी डिज़ाइन पर समाप्त हो जाएंगे। ठीक है, कुछ 4NF / 5NF भिन्नता हो सकती है लेकिन ज्यादा नहीं। और भी बहुत सारे सवाल हैं जो डिजाइनर मॉडल को मान्य करने के लिए कह सकते हैं ताकि डिजाइनर को विश्वास हो सके कि वे 4NF को मिल गए हैं (क्या मैं भी आशावादी हूं? क्या लोग 4NF के लिए संघर्ष कर रहे हैं?)।

अद्यतन: तक 4NF यहाँ मेरा मतलब है स्कीमा में सभी तालिकाओं (सभी तालिकाओं उचित रूप से 4NF अप करने के लिए सामान्यीकृत गया) 4NF अप करने के लिए अपने उच्चतम सामान्य रूप के लिए मिला है।

मेरा मानना ​​है कि सामान्यीकरण डिज़ाइन प्रक्रिया यही है कि डेटाबेस डिज़ाइनर सामान्य रूप से सामान्यीकृत डेटाबेस स्कीमा पर निर्भर होने के विचार के साथ सहज होते हैं।

सामान्यीकरण की प्रक्रिया एक ज्ञात "सही" डिज़ाइन के लिए डीबी डिज़ाइन प्राप्त करती है और प्रदर्शन से भिन्न होने के लिए वहां से भिन्नता होनी चाहिए।

1. समर्थित DB प्रकार (JSON, ARRAY, भू प्रकार समर्थन आदि) के आधार पर भिन्नताएं हो सकती हैं
2. कुछ 4NF / 5NF के आधार पर भिन्नता के लिए तर्क दे सकते हैं
3. हम भौतिक भिन्नता को बाहर करते हैं (क्योंकि इससे कोई फर्क नहीं पड़ता)
4. हम इसे OLTP डिज़ाइन तक सीमित करते हैं न कि DW डिज़ाइन के लिए क्योंकि वे स्कीमा हैं जिन्हें हम केवल पढ़ने के लिए एक्सेस देना चाहते हैं

यदि 3 प्रोग्रामर जहां लागू करने के लिए एक डिज़ाइन दिया गया है (कोड के रूप में) तो उम्मीद 3 अलग कार्यान्वयन (संभावित रूप से बहुत अलग) के लिए होगी।

मेरे लिए संभावित रूप से "सामान्यीकरण में विश्वास" का सवाल है।

ब्रेकिंग स्कीमा में बदलाव?

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

कॉलम / टेबल को गिराकर या ब्रेकिंग प्रकार परिवर्तन करके स्पष्ट रूप से परिवर्तन संभव हैं। संभव हाँ, लेकिन व्यावहारिक रूप से मैंने यहाँ किसी भी समस्या का अनुभव नहीं किया है। शायद इसलिए कि यह समझा जाता है कि परिवर्तन क्या होते हैं और इनका प्रबंधन अच्छी तरह से किया जाता है?

मुझे साझा रीड-ओनली स्कीमा के संदर्भ में स्कीमा परिवर्तन के मामलों को सुनने में दिलचस्पी होगी।

एक microservice के बारे में अधिक महत्वपूर्ण और महत्वपूर्ण है: इसके एपीआई या इसके डेटाबेस स्कीमा? एपीआई, क्योंकि यह दुनिया के बाकी हिस्सों के साथ इसका अनुबंध है।

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

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

एपीआई के साथ मुद्दे?

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

What motivates people to desire local read-only access?

एपीआई अनुकूलन:

लिंक्डइन में उनके एपीआई के अनुकूलन के मुद्दे पर (2009 से) एक दिलचस्प प्रस्तुति है और यह उनके पैमाने पर उनके लिए महत्वपूर्ण क्यों है। http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment

संक्षेप में, एक बार एक एपीआई को कई अलग-अलग उपयोग के मामलों का समर्थन करना पड़ता है, यह आसानी से उस स्थिति में पहुंच सकता है जहां यह एक उपयोग के मामले को बेहतर तरीके से समर्थन करता है और बाकी को नेटवर्क के नजरिए और डेटाबेस के नजरिए से खराब तरीके से।

यदि एपीआई में लिंक्डइन की तरह ही परिष्कार नहीं है, तो आप आसानी से परिदृश्यों को प्राप्त कर सकते हैं:

• API को आपकी आवश्यकता से बहुत अधिक डेटा प्राप्त होता है (बेकार)
• Chatty API का जहाँ आपको एपीआई को कई बार कॉल करना होगा

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

मुझे संदेह है कि वहाँ लोगों का एक समूह है जो इसे जोड़ सकते हैं:

• मास्टर डेटा की कम लागत प्रतिकृति माइक्रोसर्विस डेटाबेस (बिना विकास लागत और तकनीकी रूप से कुशल)
• सामान्यीकरण में विश्वास और स्कीमा में अनुप्रयोगों के लचीलेपन में परिवर्तन होता है
• आसानी से हर उपयोग के मामले का अनुकूलन करने और संभावित रूप से चैट / बेकार / अक्षम रिमोट एपीआई कॉल से बचने की क्षमता
• इसके अलावा बाधाओं और सुसंगत डिजाइन के संदर्भ में कुछ अन्य लाभ

इस जवाब को बहुत लंबा रास्ता मिल गया है। क्षमा याचना!!

Comments

एक कॉलम जोड़ने से आम तौर पर एप्लिकेशन टूट जाते हैं। यदि आपके पास "सैलरी" है तो एक नया कॉलम "सैलरी_सर्किट" पेश होने पर सभी वेतन को तोड़ने वाला आवेदन पत्र समाप्त हो जाता है।

— कुबंझक

वास्तव में? मुझे लगता है कि "टूट" की आपकी परिभाषा पर निर्भर करता है। यदि ऐप "सैलरी_क्यूरिटी" के बिना अपेक्षित रूप से उत्पादन और परिचालन में था, तो आप उस एप्लिकेशन को अब टूटा हुआ क्यों मानेंगे?

— रॉब बेंग्रेव

एप्लिकेशन त्रुटि के बिना चलता है और कुछ संख्या प्रदर्शित करता है। लेकिन यह बेकार है। जब सीईओ देखता है कि पिछले महीने की सैलरी का योग 50 हजार के बजाय 6 मिलियन है (दक्षिण कोरियाई वोन में भुगतान किए गए एक नए कर्मचारी के कारण) एक उपयोगी / बेकार आउटपुट की परिभाषा पर ज्यादा चर्चा नहीं की जाएगी।

— kubanczyk

Answer 5

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