बीडीडी और आईओडी के साथ माइक्रोसर्विसेज डेवलपमेंट

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



के बारे में लेखक: केन पुघ लचीलापन विकसित करने के लिए कंपनियों को सिखाता है, स्वीकृति परीक्षण-संचालित विकास, बीडीडी, देवओप त्वरण का उपयोग करके उच्च-गुणवत्ता प्रणाली बनाता है। केन ने सॉफ्टवेयर डेवलपमेंट पर कई किताबें लिखी हैं, जोफ अवार्ड 2006 प्रीफैक्टिंग विजेता, एसएएफ एजाइल सॉफ्टवेयर इंजीनियरिंग पाठ्यक्रम के रचनाकारों में से एक था।

BDD में व्यवहार अक्सर दिए गए / जब / फिर निर्माण द्वारा व्यक्त किया जाता है । हमें एक निश्चित राज्य दिया जाता है जब कोई कार्रवाई या घटना होती है, तो राज्य बदल जाता है और / या जानकारी वापस आ जाती है।

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

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

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

एक तुल्यकालिक सेवा के एक उदाहरण पर विचार करें।

समकालिक सेवा

एक सेवा की कल्पना करें जो बिक्री के आदेश पर छूट की गणना करती है। पूरी प्रक्रिया संबंधित कार्यों का एक समूह है।



इस सेवा के व्यवहार को निम्नानुसार वर्णित किया जा सकता है:

Get discount for a customer Given these inputs Customer category Order Amount Then service outputs Discount Amount 

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

यह संदेश प्रारूप के रूप में JSON या XML का उपयोग कर सकता है। हालांकि, कार्यान्वयन विवरणों को निर्दिष्ट किए बिना सेवा का वर्णन करना सिंटैक्स से संचालन के शब्दार्थ को अलग करने में मदद करता है।

व्यवहार क्या है?

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


उदाहरण उन डोमेन शब्दों को दिखाता है जिनके लिए आगे शोधन की आवश्यकता हो सकती है - उदाहरण के लिए, मान्य मानों का वर्णन करें।



यह समझा जाता है कि यदि इनपुट डेटा स्वीकार्य मानों की सीमा में आता है तो सेवा सही परिणाम देती है।

व्यवहार विवरण, विशेष रूप से माइक्रोसिस्टर्स के लिए, अक्सर विफलताओं और त्रुटियों की स्थिति में प्रतिक्रियाएं शामिल होती हैं। संभावित विफलताओं का विवरण उपभोक्ता को यह समझने में मदद करता है कि ऐसे मामलों में क्या करना है। सेवा के ग्राहक इनमें से कुछ विफलताओं को ठीक करने के लिए, विशेष पुस्तकालयों का उपयोग कर सकते हैं, जैसे कि नेटफ्लिक्स से हिस्टिक्स।

हमारी सेवा की कुछ संभावित त्रुटियां:


संचार प्रोटोकॉल में विफलताएं संख्यात्मक या चरित्र स्थिरांक के रूप में व्यक्त की जा सकती हैं।

BDD में सार्थक नामों का उपयोग विफलता के शब्दार्थ पर जोर देने में मदद करता है, न कि इसके वाक्य-विन्यास पर।

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

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

सेवा बीडीडी परीक्षण इसकी इकाई परीक्षणों के लिए एक संदर्भ बना सकते हैं। डिजाइन प्रक्रिया में, बीडीडी परीक्षण पास करने की जिम्मेदारी कक्षाओं और विधियों के साथ टिकी हुई है । यूनिट परीक्षण इन जिम्मेदारियों को निर्धारित करते हैं।

प्लग

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

परिवर्तन अक्सर अपरिहार्य होता है, इसलिए आमतौर पर स्टब्स की आवश्यकता होती है।

एक स्टब हमेशा समान मूल्यों को वापस कर सकता है, उदाहरण के लिए:


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

वैकल्पिक रूप से, छूट सेवा ठूंठ केवल उसी राशि को वापस कर सकता है, इनपुट की परवाह किए बिना।

यह ठूंठ एक व्यापक परिदृश्य में कैसे फिट हो सकता है? एक आदेश के लिए प्रणाली के व्यवहार पर विचार करें, जिसमें छूट और कर दोनों शामिल हैं। कर की गणना छूट के समान, माइक्रो सर्विस द्वारा की जाती है।



एक खरीदार है।


समायोज्य छूट।


कर की स्थापना की है।


जब एक ग्राहक एक आदेश देता है:


फिर विकल्प का आदेश दें।

राज्य के साथ सेवाएँ

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


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

वर्तमान आंकड़ों को देखते हुए।


जब कोई आइटम अपडेट किया जाता है।


फिर अपडेट किया गया डेटा।


आप यह भी सत्यापित कर सकते हैं कि छूट की गणना करने के लिए अद्यतन डेटा का उपयोग किया जाता है।


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

टेस्ट फॉर्मूलेशन और ऑटोमेशन

एक बार माइक्रोसर्विस का व्यवहार सुसंगत है, इसे स्वचालित परीक्षणों के रूप में तैयार किया जा सकता है। कई microservice परीक्षण प्रणाली, जैसे PACT या कराटे हैं। इसके अलावा, आप ककड़ी या एफआईटी जैसे बीडीडी फ्रेमवर्क का उपयोग कर सकते हैं।

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

उदाहरण के लिए, ककड़ी ऑब्जेक्ट फ़ाइल शामिल हो सकती है।


चरण विकल्प आपके परीक्षण सम्मेलनों पर निर्भर करते हैं।

पहले दो कॉलम के मानों को किसी भी कॉलिंग कन्वेंशन में स्थानांतरित किया जा सकता है, उदाहरण के लिए, क्वेरी मापदंडों के लिए। शरीर में परिणाम तीसरे कॉलम से मेल खाना चाहिए। यदि क्वेरी के नाम और मान स्तंभों के नाम और मूल्य हैं, तो यह परीक्षण और कार्यान्वयन के बीच के अंतर को कम करता है।

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

उदाहरण के लिए टेस्ट में विफलताओं को भी शामिल किया जाना चाहिए।

निष्कर्ष

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

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

• सेवा प्रदाता, ग्राहक डेवलपर और परीक्षक - माइक्रोसर्विस के लिए बीडीडी ट्रायड के सहयोग पर केंद्रित है।
  
• IOD का उपयोग करते हुए माइक्रोसैस इंटरफेस के लिए स्पष्ट रूप से परिभाषित सम्मेलनों का निर्माण करें।
  
• परीक्षण की गति बढ़ाने के लिए आमतौर पर माइक्रोसॉर्क्स को टेस्ट प्लग की आवश्यकता होती है।
  
• टेस्ट स्वतंत्र होना चाहिए।
  
• परीक्षणों में नकारात्मक परिदृश्यों का परीक्षण करें।
  

27-28 मई को, क्वालकॉन्फ़ सम्मेलन में आरआईटी ++ उत्सव के दौरान, आर्टीम मालिशेव कोड में डोमेन मॉडल को स्पष्ट रूप से व्यक्त करने के महत्व के बारे में बात करेंगे और उदाहरणों के साथ इसे दिखाएंगे।

गुणवत्ता वाले उत्पादों के विकास के बारे में बात करें और अपने विचारों को साझा करें!