माइक्रोसर्विसेस एंड कैननिकल मॉडल


9

जब मैं इस साइट पर माइक्रोसर्विस के बारे में पढ़ रहा था , तो मैं नीचे दिए गए स्टेटमेंट पर आया। विहित स्कीमा का क्या अर्थ है? क्या यह डोमेन मॉडल के समान नहीं है?

माइक्रोसर्विसेज आर्किटेक्चर पैटर्न SOA के अन्य भागों को भी अस्वीकार कर देता है, जैसे कि एक विहित स्कीमा की अवधारणा।


क्या आप उस कथन के स्रोत को जान पाएंगे? (लिंक करने के उद्देश्य से)
जैक

ज़रूर जैक, यह यहाँ है - nginx.com/blog/introduction-to-microservices/…
विक्की

मुझे लगता है कि आप इस विकिपीडिया लेख को देख रहे हैं। हालाँकि, मुझे लेख समझने में आसान नहीं लगता।
बजे आर्सेनी मूरज़ेंको

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

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

जवाबों:


5

@ArseniMourzenko टिप्पणी पर भरोसा करने के लिए अग्रिम में माफी, लेकिन एक बार जब मैंने विकिपीडिया को पढ़ना शुरू कर दिया तो मुझे तुरंत समझ में आया कि कैनोनिकल स्कीमा का मतलब क्या है।

यहाँ ओपी की टिप्पणी जो वास्तविक संदेह पर केंद्रित है

मेरा मानना ​​है कि यहां तक ​​कि माइक्रोसॉर्स्क आर्किटेक्चर में भी, अनुरोध और प्रतिक्रिया को कुछ डेटा मॉडल का पालन करना पड़ता है।

कुछ डेटा मॉडल हां, लेकिन ऐसा लगता है कि लेख 2 या अधिक सेवाओं के बीच "साझा" या "सामान्य" डेटा मॉडल का उल्लेख कर रहा है।

विहित स्कीमा एक पैटर्न क्रम डेटा परिवर्तनों में से सेवाओं को बचाने के लिए होती है। यह आपको डुप्लिकेट कोड से भी बचाता है। लेकिन फिर आप अपनी सेवा को बाहरी डेटा मॉडल पर भी युग्मित कर रहे हैं। (ऊपर दिए गए विकिपीडिया के पृष्ठ पर आरेख देखें)

यह सेवाओं के बीच आम "भाषा" का एक प्रकार है।

ऐसा लगता है कि लेख "पारिस्थितिकी तंत्र" से एमएस की कुल स्वतंत्रता पर जोर दे रहा है जहां वह रहता है।

उदाहरण के लिए इसका उल्लेख ईएसबी से करें।

वे ESBs का उपयोग करने से बहुत अधिक बचते हैं और इसके बजाय खुद ही माइक्रोसॉर्क्स में ESB जैसी कार्यक्षमता को लागू करते हैं।

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

इसलिए, लेख पर वापस, ऐसा लगता है कि लेखक इस तथ्य की ओर इशारा कर रहा है कि एमएस किसी भी बाहरी प्रणाली (और उनकी बाधाओं) से जुड़े होने को अस्वीकार करता है


धन्यवाद @Laiv मैं 9 घंटे में इनाम दूंगा - इसलिए मुझे प्रतिबंधित कर रहा है :)
पंटर विक्की

1

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

Domain-Driven Design parlance में माइक्रोसॉफ़्ट को बाउंडेड कॉन्टेक्ट्स के साथ निकटता से जोड़ा जाना चाहिए।


If you find that you have microservices making synchronous calls। जरूरी नहीं कि अतुल्यकालिक कॉलिंग हो। यह ईएसबी अतुल्यकालिक संदेशों के साथ भी हो सकता है। मुझे लगता है कि यह साझा स्कीमों या डेटा कॉन्ट्रैक्ट्स के युग्मित होने के तथ्य पर केंद्रित है। मेरा मानना ​​है कि एमएस आर्किटेक्चर में, यह सर्विसपीस के बीच किसी भी संचार पी 2 पी से बचा जाना चाहिए। संचार किसी भी आंतरिक (आंतरिक सेवा परत) या बाहरी (ESB, कतार, आदि) परत के बजाय अनुप्रयोगों के माध्यम से
खुश होना चाहिए
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.