सेवा उन्मुख आर्किटेक्चर में बिजनेस डेटा पूछताछ/रिपोर्टिंग

Question

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

लेकिन!

हमारे व्यापार का एक महत्वपूर्ण हिस्सा है जिसके परिणामस्वरूप, बढ़ती हुई सिरदर्द है, अर्थात् रिपोर्टिंग।

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

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

मैं व्यक्तिगत रूप से पिछली छोर में रिपोर्टिंग उद्देश्यों के लिए डेटा प्रतिकृति का प्रशंसक नहीं हूं, क्योंकि इसमें एक दुःस्वप्न में वृद्धि करने की एक और प्रवृत्ति हो सकती है (जो कि यह हमारे विरासत मोनोलिथ में भी है)। तो यह समस्या वास्तव में आधुनिक माइक्रोस्कोप बनाम विरासत monoliths के बारे में नहीं है, लेकिन सामान्य रूप से डेटा निर्भरताओं के बारे में है।

क्या आपको इस तरह के मुद्दों का सामना करना पड़ा है और यदि हां, तो आपने इसे कैसे हल किया?

संपादित करें:

हम कुछ संभावित समाधान कैसे इस को हल करने के घर में चर्चा कर दिया गया है, लेकिन उनमें से कोई वास्तव में अच्छा कर रहे हैं और मैं इस सवाल का जवाब मैं देख रहा हूँ मिल नहीं किया है अभी तक कि हल करती है बड़े पैमाने पर मुद्दों।

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

2. एक अलग माइक्रोस्कोस या सूक्ष्मजीवों का एक सेट बनाएं जो विशिष्ट रिपोर्ट लाने के लिए हैं। उनमें से प्रत्येक माइक्रोस्कोप सेट करने के लिए कनेक्ट होता है जो प्रासंगिक डेटा रखता है और रिपोर्ट को अपेक्षित बनाता है। यह हालांकि कड़ा युग्मन प्रस्तुत करता है और बड़े डेटासेट के साथ अविश्वसनीय रूप से जटिल और धीमा हो सकता है।

3. एक अलग माइक्रोस्कोस या माइक्रोसर्विसेज का एक सेट बनाएं जिसमें प्रत्येक पृष्ठभूमि में पृष्ठभूमि में अन्य डेटाबेस से दोहराए गए डेटाबेस हैं। यह समस्याग्रस्त है क्योंकि टीम डेटाबेस जोड़े जा रहे हैं और डेटा को सीधे दोहराया गया है और उपयोग किए जा रहे डेटाबेस की तकनीक पर एक मजबूत निर्भरता है।

4. क्या प्रत्येक सेवा RabbitMQ को एक ईवेंट भेजती है कि बीआई सेवाएं उठाएगी और फिर आवश्यक होने पर अतिरिक्त डेटा प्राप्त करेंगी। यह मेरे लिए अब तक का सबसे अच्छा लगता है, लेकिन अब तक सबसे जटिल है क्योंकि सभी सेवाओं को प्रासंगिक डेटा प्रकाशित करना शुरू करना है। यह वही है जो मैं वर्तमान समय में, एक बहुत ही अमूर्त स्तर से, व्यक्तिगत रूप से चुनता हूं।

Answer 1

समाधान विभिन्न सेवाओं से डेटा को केंद्रीय रिपोर्टिंग डेटाबेस में एकत्र करना है - यह संभव है कि एकत्रित डेटा समय के साथ संस्करणित हो - यानी आप रिपोर्टिंग डेटा पर जा सकते हैं और पॉइंट-इन-टाइम डेटा प्राप्त कर सकते हैं जो सही है (उस समय के लिए)

सेवा में वह डेटा प्राप्त करना विभिन्न सेवा या आवधिक आयात, "लॉग" एकत्रीकरण या संयोजनों द्वारा प्रकाशित घटनाओं के माध्यम से हो सकता है।

मैं इस पैटर्न फोन aggregated reporting

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

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

इसके अलावा

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

चाहते हो सकता है

पीएस मैंने यह भी लिखा है कि InfoQ piece on BI & SOA टॉम ने टिप्पणियों में उल्लेख किया - जो अनिवार्य रूप से इस विचार के बारे में बात करता है - यह आलेख 2007 से है, यानी मैंने इसे एक दशक से अधिक समय तक सफलतापूर्वक लागू किया है (विभिन्न तकनीकों, लिखने पर स्कीमा से आगे बढ़ना पढ़ने आदि पर स्कीमा के लिए। लेकिन समान सिद्धांत)

Answer 2

तो, मुझे यकीन है कि यह अपनी आवश्यकताओं का जवाब होगा नहीं कर रहा हूँ - लेकिन मैं बीआई के लिए हमारे समग्र दृष्टिकोण का वर्णन करेंगे:

1. हमारे सिस्टम में सब कुछ एक घटना उत्पन्न करता है: बैकएंड में कार्रवाई, मोबाइल ऐप्स में कार्रवाइयां - हम जो भी ट्रैक करना चाहते हैं वह प्रासंगिक डेटा (आईडी, समय, नाम इत्यादि) के साथ ईवेंट उत्पन्न करता है।
2. सभी घटनाओं को संग्रह के लिए कुछ सामान्य फ़नल में भेजा जाता है - यह एक बैकएंड ऐप है जो ईवेंट लेता है - सुनिश्चित करता है कि वे मान्य हैं - और उन्हें स्टोर करते हैं।
3. आप कुछ नो-एसक्यूएल स्टोरेज (जैसे लोचदार खोज) या क्लाउड (जैसे Google के BigQuery) में ईवेंट स्टोर कर सकते हैं।
4. एक बार जब वे अंदर आते हैं, तो यह सिर्फ आपकी इच्छित तस्वीर प्राप्त करने के लिए पूछताछ और क्रॉस-रेफरेंसिंग का मामला है। हमारे बीआई लोग यही करते हैं: वे एकत्रित घटनाओं के ढेर से एक तस्वीर उत्पन्न करते हैं।