स्वायत्त माइक्रोसर्विसेज, इवेंट क्यू और सर्विस डिस्कवरी


15

मैं हाल ही में सूक्ष्म सेवाओं के बारे में बहुत कुछ पढ़ रहा हूं, और यहां कुछ निष्कर्ष मुझे अभी तक मिले हैं (कृपया मुझे सही करें अगर मैं किसी भी बिंदु पर गलत हूं)।

  1. माइक्रो-सर्विसेज आर्किटेक्चर डोमेन संचालित डिजाइन के साथ अच्छी तरह से चला जाता है। आमतौर पर एक एमएस एक बंधे हुए संदर्भ का प्रतिनिधित्व करता है।
  2. यदि माइक्रो-सर्विस को कार्यक्षमता की आवश्यकता होती है जो माइक्रो-सेवा बी में रहता है , तो मेरा मॉडल शायद गलत है और और बी को वास्तव में एक माइक्रो-सेवा / बीसी होना चाहिए।
  3. सूक्ष्म सेवाओं (प्रत्यक्ष HTTP अनुरोध) के बीच समकालिक संचार खराब है, क्योंकि यह सूक्ष्म सेवाओं के उद्देश्य को धता बताता है, और घटकों के बीच युग्मन का परिचय देता है।
  4. सेवाओं के बीच अतुल्यकालिक संचार वांछनीय है। सेवाओं को संदेश कतारों में घटनाओं को प्रकाशित करना चाहिए, इसलिए अन्य सेवाएं घटना के अपने हिस्से की सदस्यता और प्रक्रिया कर सकती हैं, या इसका उपयोग उनके संदर्भ के लिए आवश्यक डेटा के एक हिस्से को दोहराने के लिए कर सकती हैं। इस तरह, सेवाएं अनुरोधों को संसाधित कर सकती हैं यहां तक ​​कि अन्य सेवाएं भी नीचे हैं, जो तुल्यकालिक संचार में नहीं होगी।
  5. यदि सूक्ष्म-सेवा A प्रकाशित करता है, तो सूक्ष्म-सेवा B उस घटना को सब्सक्राइब करता है और परिणाम के रूप में एक नई घटना का उत्पादन करता है, सूक्ष्म-सेवा A को एक नई बनाई गई घटना को संसाधित नहीं करना चाहिए, क्योंकि यह एक परिपत्र निर्भरता होगी। इस स्थिति में, हमें तीसरी सूक्ष्म सेवा शुरू करनी चाहिए, या एबी सूक्ष्म सेवा में और बी को जोड़ना चाहिए ।
  6. सूक्ष्म सेवा वास्तव में एक भ्रामक शब्द है। हमें छोटे संदर्भों के लिए प्रयास करना चाहिए, लेकिन ऐसा होने की आवश्यकता नहीं है। शब्द "माइक्रो-सर्विस" नहीं होना चाहिए, लेकिन " नौकरी सेवा करने के लिए पर्याप्त बड़ा " होना चाहिए ।
  7. सूक्ष्म-सेवाएँ हमें अधिक सहजता के साथ और बिना किसी डर के नई कार्यक्षमताओं को लागू करने की अनुमति देती हैं कि हम पूरी प्रणाली को तोड़ देंगे। यह एक नई सेवा शुरू करने या मौजूदा में से किसी एक को फिर से शुरू करने के द्वारा किया जा सकता है।
  8. प्रत्येक माइक्रो-सर्विस में स्वयं का डेटा-स्टोरेज होना चाहिए। इस वास्तुकला में डेटा प्रतिकृति / दोहराव वांछनीय व्यवहार है।

इस वास्तुकला की मेरी समझ की पुष्टि करने के अलावा, मेरे सवाल का दूसरा हिस्सा ज्यादातर सेवा खोज से संबंधित है। यदि सेवाएँ एसिंक्रोनस रूप से संचार कर रही हैं, और अमेज़ॅन एसक्यूएस जैसी केंद्रीय घटना कतार का उपयोग कर रही है, तो क्या इसका मतलब है कि सेवा की खोज की तरह वास्तुकला में इसका स्थान नहीं है?

सिस्टम में अन्य सेवाओं के बारे में सेवाओं का कोई ज्ञान नहीं होना चाहिए। वे केवल अपने संदर्भ और घटनाओं के बारे में जानते हैं जिन्हें उन्हें प्रकाशित या सदस्यता लेना चाहिए?

जवाबों:


4

आपके निष्कर्ष ज्यादातर स्थापित किए गए लगते हैं और बहुत अच्छी तरह से माइक्रो-सर्विसेज के लिए जाने के लिए योग करते हैं।

लेकिन मैं पूरी तरह से 2, 5 और 8 का समर्थन नहीं करूंगा:

  • 2) एक साधारण निर्भरता को स्वचालित रूप से विलय की ओर नहीं ले जाना चाहिए। आपको ऐसी निर्भर कॉल की आवृत्ति और अन्य सेवाओं से कॉल की आवृत्ति पर भी विचार करना होगा।

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

  • 5) बेशक, आपको संदेश हैंडलिंग में अंतहीन साइकिल चलाने से बचने की आवश्यकता है।

    लेकिन एक मध्यस्थ को जोड़ने से यह नहीं रोका जाएगा: A, C द्वारा संभाला एक संदेश लॉन्च कर सकता है, जो B द्वारा संभाला एक संदेश लॉन्च करता है, जो A द्वारा संभाला एक संदेश लॉन्च करता है और यहां आप एक लूप में फंस जाते हैं।

    इस समस्या का आकलन केवल माइक्रो-सर्विस स्तर पर विचार करके नहीं किया जा सकता है: प्रश्न वास्तव में संदेश प्रकार और सामग्री के बारे में है जो चक्र को जन्म दे सकता है। ग्राफ़ जो सेवाओं में संदेशों के वितरण और प्रसंस्करण को मॉडल करता है, इसलिए इसका विश्लेषण पूरे के रूप में किया जाना चाहिए (वास्तव में यह जटिल हो सकता है, इसलिए आप एक निगरानी माइक्रोसर्विस की कल्पना कर सकते हैं जो ऐसे चक्रों का पता लगाता है और उन्हें तोड़ता है)।

  • 8) हां, प्रत्येक माइक्रोसेव्स के पास अपना समर्पित भंडारण / डेटाबेस होगा।

    सेवाओं को स्वतंत्र करने की अनुमति देने के लिए न्यूनतम प्रतिकृति की आवश्यकता होती है। हालाँकि मैं यह बताने के लिए अभी तक नहीं गया कि प्रतिकृति वांछित है: प्रतिकृति प्रक्रियाओं के माध्यम से छिपे हुए युग्मन से बचने के लिए इसे न्यूनतम रखना होगा।

    माइक्रोसर्विस ढीले युग्मन के बारे में हैं। यह कभी-कभी डेटा को दोहराने के बजाय संबंधित डेटा को पुनः प्राप्त करने के लिए किसी अन्य माइक्रो-सर्विस को कॉल करके अधिक प्रभावी ढंग से प्राप्त किया जा सकता है।

दो अंतिम अनिर्धारित पुष्टिएँ यहाँ दृढ़ता से उत्तर देने के लिए व्यापक हैं। मुझे लगता है कि आपका सुझाव एक अच्छा प्रारंभिक बिंदु है, लेकिन यह वास्तव में वास्तु आवश्यकताओं और बाधाओं पर निर्भर करता है।


"यह कभी-कभी डेटा को दोहराने के बजाय, संबंधित डेटा को पुनः प्राप्त करने के लिए एक और माइक्रोफ़ोन कॉल करके अधिक प्रभावी ढंग से प्राप्त किया जा सकता है", इसलिए, डेटा के कुछ हिस्से को लाने के लिए थोड़े से सिंक्रोनस संचार और डायरेक्ट कॉल (HTTP के माध्यम से) के साथ कुछ भी गलत नहीं है, जब तक वह क्वेरी वितरित लेन-देन / आदेश का प्रतिनिधित्व नहीं करती है, अन्यथा हम उस आदेश की परमाणुता की गारंटी नहीं दे सकते हैं?
रॉबर्ट

1
यहाँ कोई सही समाधान नहीं है: यह ढीली युग्मन और एन्कैप्सुलेशन ( microservices.io/patterns/data/database-per-service.html ) है जो आसानी से संतुलन के खिलाफ है, लेकिन अतिरेक ( microservices.io- patterns/data/event-driven-altectureure) .html ) समग्र चित्र के संदर्भ में ( microservices.io/patterns/microservices.html )
क्रिस्टोफ़

3

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

सिस्टम में अन्य सेवाओं के बारे में सेवाओं का कोई ज्ञान नहीं होना चाहिए। वे केवल अपने संदर्भ और घटनाओं के बारे में जानते हैं जिन्हें उन्हें प्रकाशित या सदस्यता लेना चाहिए?

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

यदि सेवाएँ एसिंक्रोनस रूप से संचार कर रही हैं, और अमेज़ॅन एसक्यूएस जैसी केंद्रीय घटना कतार का उपयोग कर रही है, तो क्या इसका मतलब है कि सेवा की खोज की तरह वास्तुकला में इसका स्थान नहीं है?

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

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


2
  1. माइक्रो-सर्विसेज आर्किटेक्चर डोमेन संचालित डिजाइन के साथ अच्छी तरह से चला जाता है। आमतौर पर एक एमएस एक बंधे हुए संदर्भ का प्रतिनिधित्व करता है।

सहमत नहीं हैं। DDD बहुत OO होता है। एक आदेश दिया है? ऑर्डर। डेलिवर () जबकि माइक्रो-सर्विसेज में डिलिवरी सेवा होगी। डिलिवर (ऑर्डर)

  1. यदि माइक्रो-सेवा ए को कार्यक्षमता की आवश्यकता होती है जो माइक्रो-सेवा बी में रहता है, तो मेरा मॉडल शायद गलत है और ए और बी को वास्तव में एक माइक्रो-सेवा / बीसी होना चाहिए।

असहमत, आपको सूक्ष्म सेवाओं को सूक्ष्म रखने की कोशिश करनी चाहिए। उन्हें और भी छोटा कर दिया!

  1. सूक्ष्म सेवाओं (प्रत्यक्ष HTTP अनुरोध) के बीच समकालिक संचार खराब है, क्योंकि यह सूक्ष्म सेवाओं के उद्देश्य को धता बताता है, और घटकों के बीच युग्मन का परिचय देता है।

सहमत नहीं हैं। सेवाओं को इस बात की परवाह नहीं करनी चाहिए कि कौन उन्हें कॉल कर रहा है और कॉलर्स को यह ध्यान नहीं देना चाहिए कि तर्क एक माइक्रोसैस सर्विस में लागू है।

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

कतारें अच्छी हैं। लेकिन आपका तर्क गलत है। सिंक रिस्पॉन्स और एसिक्स के बीच एकमात्र अंतर यह है कि आप सिंक एक का इंतजार करते हैं। आप RPC शैली कॉल को कतारों और कई श्रमिकों के साथ कार्यान्वित कर सकते हैं जिनमें कोई संभावना नहीं है।

  1. यदि सूक्ष्म-सेवा A प्रकाशित करता है, तो सूक्ष्म-सेवा B उस घटना को सब्सक्राइब करता है और परिणाम के रूप में एक नई घटना का उत्पादन करता है, सूक्ष्म-सेवा A को एक नई बनाई गई घटना को संसाधित नहीं करना चाहिए, क्योंकि यह एक परिपत्र निर्भरता होगी। इस स्थिति में, हमें तीसरी सूक्ष्म सेवा शुरू करनी चाहिए, या एबी सूक्ष्म सेवा में ए और बी को जोड़ना चाहिए।

सहमत नहीं हैं। यह एक परिपत्र निर्भरता नहीं है क्योंकि आपकी सूक्ष्म सेवाएं युग्मित नहीं हैं। इसके अलावा, आप पुनरावृत्तियों के लिए पूरा करना चाहते हैं, SendEmail, EmailFailed, SendAgain को 3 माइक्रो-सेवाओं की आवश्यकता नहीं है

  1. सूक्ष्म सेवा वास्तव में एक भ्रामक शब्द है। हमें छोटे संदर्भों के लिए प्रयास करना चाहिए, लेकिन ऐसा होने की आवश्यकता नहीं है। शब्द "माइक्रो-सर्विस" नहीं होना चाहिए, लेकिन "नौकरी सेवा करने के लिए पर्याप्त बड़ा" होना चाहिए।

सहमत नहीं हैं। नैनो-सेवाओं की जाँच करें।

  1. सूक्ष्म-सेवाएँ हमें अधिक सहजता के साथ और बिना किसी डर के नई कार्यक्षमताओं को लागू करने की अनुमति देती हैं कि हम पूरी प्रणाली को तोड़ देंगे। यह एक नई सेवा शुरू करने या मौजूदा में से किसी एक को फिर से शुरू करने के द्वारा किया जा सकता है।

सहमत नहीं हैं। हां, आपको डिकॉयलिंग मिल जाती है, लेकिन सूक्ष्म सेवाओं का ऑर्केस्ट्रेशन किसी भी मोनोलिथ परियोजना की तरह चुनौतीपूर्ण हो सकता है

  1. प्रत्येक माइक्रो-सर्विस में स्वयं का डेटा-स्टोरेज होना चाहिए। इस वास्तुकला में डेटा प्रतिकृति / दोहराव वांछनीय व्यवहार है।

सहमत नहीं हैं। हालाँकि आपको भंडारण को साझा नहीं करना चाहिए, लेकिन जहाँ संभव हो, वहाँ आपकी सूक्ष्म सेवाओं को स्टेटलेस होने की कोशिश करनी चाहिए। डेटा को तब तक डुप्लिकेट न करें जब तक कि उसकी आमद न हो


1

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

और आपके अन्य प्रश्न के लिए, कतार आधारित संचार के लिए सेवा की खोज की आवश्यकता नहीं है।


0

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

एलन केई ने ओओपी की कल्पना जैविक प्रणालियों के बाद की है, जहां कोशिकाएं एक-दूसरे से अपेक्षाकृत स्वतंत्र होती हैं और केवल उन संदेशों के माध्यम से संचार करती हैं जो अन्य कोशिकाओं पर बाहरी इंटरफेस में प्लग करते हैं।

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

उदाहरण के लिए, बस के बारे में अन्य उत्तरों में कहा गया सब कुछ OOP के बारे में एक पाठ्यपुस्तक के बयान हैं।


0

चूँकि मैं अक्सर बाउंडेड कॉनटेक्स्ट और कोर डोमेन जैसी महत्वपूर्ण अवधारणा के बारे में गलत समझ रखता हूँ, इसलिए मैं इस पर थोड़ा विस्तार करना चाहता हूँ।

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

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

इस दृष्टिकोण का उपयोग करके सेवा सीमाओं की पहचान करने का एक उदाहरण है।

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