गो पर अत्यधिक विश्वसनीय सर्वर विकसित करने की तकनीक

समय-समय पर, वेब प्रोग्रामर ऐसे कार्यों का सामना करते हैं जो पेशेवरों को भी डरा सकते हैं। हम उन सर्वर अनुप्रयोगों को विकसित करने के बारे में बात कर रहे हैं, जिनमें गलतियाँ करने का अधिकार नहीं है, उन परियोजनाओं के बारे में जिनमें विफलता की लागत बहुत अधिक है। सामग्री का लेखक, जिसका अनुवाद आज हम प्रकाशित करते हैं, इस तरह के कार्यों के बारे में बात करेंगे।

आपकी परियोजना को किस स्तर की विश्वसनीयता की आवश्यकता है?

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

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

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

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

शायद समाधान TDD है?

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

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

टेस्ट विश्वसनीयता की कुंजी है

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

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

टेस्ट जल्दी होना चाहिए। बहुत तेज है।

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

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

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

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

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

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

अत्यधिक विश्वसनीय परियोजनाओं के लिए एक शानदार विकल्प क्यों है?

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

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

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

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

गो में एक व्यापक मानक पुस्तकालय है। निर्भरता एक जोखिम है, खासकर जब उनका स्रोत परियोजनाएं होती हैं जिसमें कोड की विश्वसनीयता पर अपर्याप्त ध्यान दिया जाता है। एक सर्वर अनुप्रयोग जो उत्पादन में जाता है उसमें सभी निर्भरताएँ होती हैं। इसके अलावा, अगर कुछ गलत होता है, तो तैयार एप्लिकेशन का डेवलपर इसके लिए जिम्मेदार होगा, न कि उसके द्वारा उपयोग किए गए पुस्तकालयों में से एक बनाने वाला। नतीजतन, ऐसे वातावरण में जहां परियोजनाएं लिखी जाती हैं, जिनके लिए छोटी निर्भरताएं होती हैं, विश्वसनीय अनुप्रयोग बनाना अधिक कठिन होता है।

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

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

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

व्यावहारिक प्रयोग

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

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

That एक जटिल परियोजना को उन भागों में विभाजित करना जो प्रबंधन के लिए सुविधाजनक हों

जटिलता विश्वसनीयता का सबसे खराब दुश्मन है। जटिल प्रणालियों के साथ काम करते समय सबसे अच्छे तरीकों में से एक "विभाजित और जीतना" के लंबे समय से ज्ञात सिद्धांत को लागू करना है। कार्य को छोटे उप-प्रकारों में विभाजित करने और उनमें से प्रत्येक को अलग से हल करने की आवश्यकता है। हमारे कार्य के विभाजन के लिए कौन सा पक्ष? हम साझा जिम्मेदारी के सिद्धांत का पालन करेंगे। हमारी परियोजना के प्रत्येक भाग की अपनी जिम्मेदारी का क्षेत्र होना चाहिए।

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

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

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

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


एप्लिकेशन सर्वर आर्किटेक्चर

इन सेवाओं के कोड को प्रोजेक्ट फ़ोल्डर /services/publicapi , /services/virtualmachine और /services/statestorage ।

Ibilities सेवा जिम्मेदारियों की स्पष्ट परिभाषा

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

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

इंटरफेस का वर्णन करने के लिए एक विकल्प प्रोटोबॉफ़ का उपयोग करना है। यह संदेश और सेवा समापन बिंदुओं का वर्णन करने के लिए एक सरल भाषा और भाषा स्वतंत्र प्रोटोकॉल है।

StateStorage सेवा के लिए इंटरफेस के साथ शुरू करते हैं। हम एक कुंजी-मूल्य दृश्य संरचना के रूप में आवेदन की स्थिति प्रस्तुत करेंगे। यहाँ statestorage.proto फ़ाइल के लिए कोड है:

 syntax = "proto3"; package statestorage; service StateStorage { rpc WriteKey (WriteKeyInput) returns (WriteKeyOutput); rpc ReadKey (ReadKeyInput) returns (ReadKeyOutput); } message WriteKeyInput { string key = 1; int32 value = 2; } message WriteKeyOutput { } message ReadKeyInput { string key = 1; } message ReadKeyOutput { int32 value = 1; } 

हालाँकि क्लाइंट PublicApi सेवा के माध्यम से उपयोग करते हैं, यह ऊपर बताए गए स्पष्ट माध्यमों ( publicapi.proto फ़ाइल) के समान स्पष्ट इंटरफ़ेस के साथ हस्तक्षेप नहीं करता है:

 syntax = "proto3"; package publicapi; import "protocol/transactions.proto"; service PublicApi { rpc Transfer (TransferInput) returns (TransferOutput); rpc GetBalance (GetBalanceInput) returns (GetBalanceOutput); } message TransferInput { protocol.Transaction transaction = 1; } message TransferOutput { string success = 1; int32 result = 2; } message GetBalanceInput { protocol.Address from = 1; } message GetBalanceOutput { string success = 1; int32 result = 2; } 

अब हमें Transaction और Address डेटा स्ट्रक्चर्स ( transactions.proto फाइल) का वर्णन करने की आवश्यकता है:

 syntax = "proto3"; package protocol; message Address { string username = 1; } message Transaction { Address from = 1; Address to = 2; int32 amount = 3; } 

परियोजना में, सेवाओं के लिए प्रोटो-डिस्क्रिप्शन को /types/services फ़ोल्डर में रखा जाता है, और सामान्य-प्रयोजन डेटा संरचनाओं के विवरण /types/protocol फ़ोल्डर में होते हैं।

एक बार इंटरफ़ेस विवरण तैयार होने के बाद, उन्हें गो कोड में संकलित किया जा सकता है।

इस दृष्टिकोण के फायदे उस कोड हैं जो इंटरफ़ेस विवरण से मेल नहीं खाते हैं बस संकलन परिणामों में प्रकट नहीं होता है। वैकल्पिक तरीकों का उपयोग करके हमें यह सत्यापित करने के लिए विशेष परीक्षण लिखने की आवश्यकता होगी कि कोड इंटरफ़ेस विवरण से मेल खाता है।

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

कृपया ध्यान दें कि हमारी परियोजना में परिवहन परत RPC लागू नहीं है और सेवाओं के बीच डेटा का आदान-प्रदान सामान्य पुस्तकालय कॉल की तरह दिखता है। जब हम विभिन्न सर्वरों पर सेवाएँ वितरित करने के लिए तैयार होते हैं, तो हम सिस्टम में gRPC जैसी ट्रांसपोर्ट लेयर जोड़ सकते हैं।

Used परियोजना में उपयोग किए जाने वाले परीक्षण के प्रकार

चूंकि परीक्षण अत्यधिक विश्वसनीय कोड की कुंजी हैं, मेरा सुझाव है कि हम पहले बात करते हैं कि हम अपनी परियोजना के लिए कौन से परीक्षण लिखेंगे।

यूनिट परीक्षण

इकाई परीक्षण परीक्षण पिरामिड के मूल हैं। हम अलगाव में प्रत्येक मॉड्यूल का परीक्षण करेंगे। मॉड्यूल क्या है? गो में, हम एक पैकेज में अलग-अलग फ़ाइलों के रूप में मॉड्यूल का अनुभव कर सकते हैं। उदाहरण के लिए, यदि हमारे पास फ़ाइल /services/publicapi/handlers.go , तो हम इसके लिए इकाई परीक्षण को उसी पैकेज में /services/publicapi/handlers_test.go पर /services/publicapi/handlers_test.go ।

इकाई परीक्षणों को परीक्षण कोड के रूप में एक ही पैकेज में रखना सबसे अच्छा है, जो परीक्षणों को गैर-निर्यात किए गए चर और कार्यों तक पहुंच की अनुमति देता है।

सेवा टेस्ट

निम्नलिखित प्रकार के परीक्षण को विभिन्न नामों से जाना जाता है। ये तथाकथित सेवा, एकीकरण या घटक परीक्षण हैं। उनका सार कई मॉड्यूल लेना और उनके संयुक्त कार्य का परीक्षण करना है। ये परीक्षण परीक्षण पिरामिड में इकाई परीक्षणों की तुलना में एक स्तर अधिक हैं। हमारे मामले में, हम संपूर्ण सेवा का परीक्षण करने के लिए एकीकरण परीक्षणों का उपयोग करेंगे। ये परीक्षण सेवा के विनिर्देशों को निर्धारित करते हैं। उदाहरण के लिए, StateStorage सेवा के लिए परीक्षण /services/statestorage/spec फ़ोल्डर में रखे जाएंगे।

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

अंत-से-अंत परीक्षण

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

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

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

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

Development सबसे अधिक विकास

अंत-से-अंत परीक्षण विकास

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

कई महान रूपरेखाएं हैं जो हमें वह देती हैं जो हमें चाहिए। उनमें से गोकेनवे और जिन्कगो हैं ।

व्यक्तिगत रूप से, मुझे जिन्कगो और गोमेगा (भयानक नाम, लेकिन क्या करना है) के संयोजन का उपयोग करना पसंद है, जो Describe() जैसे Describe() और Describe() और It() ।

हमारे परीक्षण क्या दिखेंगे? उदाहरण के लिए, यहां उपयोगकर्ता संतुलन जांच तंत्र ( sanity.go file) के लिए एक परीक्षण दिया गया है:

 package spec import ... var _ = Describe("Sanity", func() { var ( node services.Node ) BeforeEach(func() { node = services.NewNode() node.Start() }) AfterEach(func() { node.Stop() }) It("should show balances with GET /api/balance", func() { resp, err := http.Get("http://localhost:8080/api/balance?from=user1") Expect(err).ToNot(HaveOccurred()) Expect(resp.StatusCode).To(Equal(http.StatusOK)) Expect(ResponseBodyAsString(resp)).To(Equal("0")) }) }) 

चूंकि सर्वर HTTP के माध्यम से बाहरी दुनिया से सुलभ है, हम http.Get का उपयोग करके इसके वेब एपीआई के साथ काम करेंगे। लेन-देन परीक्षण के बारे में क्या? यहाँ इसी परीक्षण के लिए कोड है:

 It("should transfer funds with POST /api/transfer", func() { resp, err := http.Get("http://localhost:8080/api/transfer?from=user1&to=user2&amount=17") Expect(err).ToNot(HaveOccurred()) Expect(resp.StatusCode).To(Equal(http.StatusOK)) Expect(ResponseBodyAsString(resp)).To(Equal("-17")) resp, err = http.Post("http://localhost:8080/api/balance?from=user2", "text/plain", nil) Expect(err).ToNot(HaveOccurred()) Expect(resp.StatusCode).To(Equal(http.StatusOK)) Expect(ResponseBodyAsString(resp)).To(Equal("17")) }) 

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

→ यहाँ पूर्ण परीक्षण कोड दिया गया है

सेवा परीक्षण विकास

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

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

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

हम फ़ाइल /services/statestorage/mock.go में स्टब कोड /services/statestorage/mock.go । यह उन वस्तुओं के रूप में एक ही जगह पर स्टब ऑब्जेक्ट्स रखने के लिए सबसे अच्छा है जो उन्हें गैर-निर्यात किए गए चर और कार्यों तक पहुंच प्रदान करने के लिए नकल करते हैं। इस स्तर पर स्टब सेवा का एक योजनाबद्ध कार्यान्वयन है, लेकिन, जैसा कि सेवा विकसित होती है, हमें स्टब के कार्यान्वयन को विकसित करने की आवश्यकता हो सकती है। यहाँ स्टब ऑब्जेक्ट ( mock.go फ़ाइल) के लिए कोड है:

 package statestorage import ... type MockService struct { mock.Mock } func (s *MockService) Start() { s.Called() } func (s *MockService) Stop() { s.Called() } func (s *MockService) IsStarted() bool { return s.Called().Bool(0) } func (s *MockService) WriteKey(input *statestorage.WriteKeyInput) (*statestorage.WriteKeyOutput, error) { ret := s.Called(input) return ret.Get(0).(*statestorage.WriteKeyOutput), ret.Error(1) } func (s *MockService) ReadKey(input *statestorage.ReadKeyInput) (*statestorage.ReadKeyOutput, error) { ret := s.Called(input) return ret.Get(0).(*statestorage.ReadKeyOutput), ret.Error(1) } 

यदि आप अलग-अलग प्रोग्रामर को व्यक्तिगत सेवाओं का विकास देते हैं, तो पहले स्टब्स बनाने और उन्हें टीम को पास करने के लिए समझ में आता है।

चलिए VirtualMachine लिए एक सेवा परीक्षण विकसित करने के VirtualMachine वापस आते हैं। मुझे यहां किस परिदृश्य की जाँच करनी चाहिए? प्रत्येक समापन बिंदु के लिए सेवा इंटरफ़ेस और डिज़ाइन परीक्षणों पर ध्यान देना सबसे अच्छा है। हम "GetBalance" विधि का प्रतिनिधित्व करने वाले तर्क के साथ "GetBalance" CallContract() समापन बिंदु के लिए एक परीक्षण लागू करते हैं। यहां संबंधित कोड ( contracts.go फ़ाइल) है:

 package spec import ... var _ = Describe("Contracts", func() { var ( service uut.Service stateStorage *_statestorage.MockService ) BeforeEach(func() { service = uut.NewService() stateStorage = &_statestorage.MockService{} service.Start(stateStorage) }) AfterEach(func() { service.Stop() }) It("should support 'GetBalance' contract method", func() { stateStorage.When("ReadKey", &statestorage.ReadKeyInput{Key: "user1"}).Return(&statestorage.ReadKeyOutput{Value: 100}, nil).Times(1) addr := protocol.Address{Username: "user1"} out, err := service.CallContract(&virtualmachine.CallContractInput{Method: "GetBalance", Arg: &addr}) Expect(err).ToNot(HaveOccurred()) Expect(out.Result).To(BeEquivalentTo(100)) Expect(stateStorage).To(ExecuteAsPlanned()) }) }) 

कृपया ध्यान दें कि हम जिस सेवा का परीक्षण कर रहे हैं, VirtualMachine , एक साधारण निर्भरता इंजेक्शन तंत्र के माध्यम से Start() विधि में अपनी निर्भरता, StateStorage लिए एक संकेतक प्राप्त करता है। यह वह जगह है जहां हम स्टब ऑब्जेक्ट के उदाहरण को पास करते हैं। इसके अलावा, लाइन stateStorage.When("ReadKey", &statestorage.ReadKeyInput{Key… ध्यान दें। stateStorage.When("ReadKey", &statestorage.ReadKeyInput{Key… , जहां हम स्टब ऑब्जेक्ट को बताते हैं कि इसे एक्सेस करते समय कैसे व्यवहार करना चाहिए। ReadKey विधि को ReadKey , तो इसे एक मान वापस करना चाहिए। 100. फिर, लाइन Expect(stateStorage).To(ExecuteAsPlanned()) , हम Expect(stateStorage).To(ExecuteAsPlanned()) कि यह कमांड बिल्कुल एक बार कहा जाता है।

इसी तरह के परीक्षण सेवा के लिए विनिर्देश बन जाते हैं। VirtualMachine सेवा के लिए परीक्षणों का पूरा सेट यहां पाया जा सकता है । हमारी परियोजना की अन्य सेवाओं के लिए टेस्ट सूट यहां और यहां देखे जा सकते हैं ।

यूनिट टेस्ट डेवलपमेंट

शायद "GetBalance" पद्धति के लिए अनुबंध का कार्यान्वयन बहुत सरल है, तो "GetBalance" थोड़ी अधिक जटिल "Transfer" विधि को लागू करने के बारे में बात करते हैं। इस विधि द्वारा दर्शाए गए धन को एक खाते से दूसरे खाते में स्थानांतरित करने के अनुबंध को नए शेष की गणना करने और आवेदन की स्थिति में क्या हुआ है, यह रिकॉर्ड करने के लिए प्रेषक और धन के प्राप्तकर्ता के शेष पर डेटा पढ़ने की आवश्यकता है। इस सब के लिए सेवा परीक्षण हमारे द्वारा लागू किए गए ( transactions.go फ़ाइल) के समान है:

 It("should support 'Transfer' transaction method", func() { stateStorage.When("ReadKey", &statestorage.ReadKeyInput{Key: "user1"}).Return(&statestorage.ReadKeyOutput{Value: 100}, nil).Times(1) stateStorage.When("ReadKey", &statestorage.ReadKeyInput{Key: "user2"}).Return(&statestorage.ReadKeyOutput{Value: 50}, nil).Times(1) stateStorage.When("WriteKey", &statestorage.WriteKeyInput{Key: "user1", Value: 90}).Return(&statestorage.WriteKeyOutput{}, nil).Times(1) stateStorage.When("WriteKey", &statestorage.WriteKeyInput{Key: "user2", Value: 60}).Return(&statestorage.WriteKeyOutput{}, nil).Times(1) t := protocol.Transaction{From: &protocol.Address{Username: "user1"}, To: &protocol.Address{Username: "user2"}, Amount: 10} out, err := service.ProcessTransaction(&virtualmachine.ProcessTransactionInput{Method: "Transfer", Arg: &t}) Expect(err).ToNot(HaveOccurred()) Expect(out.Result).To(BeEquivalentTo(90)) Expect(stateStorage).To(ExecuteAsPlanned()) }) 

परियोजना पर काम करने की प्रक्रिया में, हम अंत में इसके आंतरिक तंत्र को बनाने और फ़ाइल processor.go में स्थित एक मॉड्यूल बनाने के लिए प्राप्त करते हैं। processor.go , जिसमें अनुबंध का कार्यान्वयन शामिल है। यहाँ मूल संस्करण है ( processor.go फ़ाइल):

 package virtualmachine import ... func (s *service) processTransfer(fromUsername string, toUsername string, amount int32) (int32, error) { fromBalance, err := s.stateStorage.ReadKey(&statestorage.ReadKeyInput{Key: fromUsername}) if err != nil { return 0, err } toBalance, err := s.stateStorage.ReadKey(&statestorage.ReadKeyInput{Key: toUsername}) if err != nil { return 0, err } _, err = s.stateStorage.WriteKey(&statestorage.WriteKeyInput{Key: fromUsername, Value: fromBalance.Value - amount}) if err != nil { return 0, err } _, err = s.stateStorage.WriteKey(&statestorage.WriteKeyInput{Key: toUsername, Value: toBalance.Value + amount}) if err != nil { return 0, err } return fromBalance.Value - amount, nil } 

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

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

 package virtualmachine import ... var transferTable = []struct{ to string //  ,    read1Err error //       read2Err error //       write1Err error //       write2Err error //       output int32 //   errs bool //        }{ {"user2", errors.New("a"), nil, nil, nil, 0, true}, {"user2", nil, errors.New("a"), nil, nil, 0, true}, {"user2", nil, nil, errors.New("a"), nil, 0, true}, {"user2", nil, nil, nil, errors.New("a"), 0, true}, {"user2", nil, nil, nil, nil, 90, false}, } func TestTransfer(t *testing.T) { Ω := NewGomegaWithT(t) for _, tt := range transferTable { s := NewService() ss := &_statestorage.MockService{} s.Start(ss) ss.When("ReadKey", &statestorage.ReadKeyInput{Key: "user1"}).Return(&statestorage.ReadKeyOutput{Value: 100}, tt.read1Err) ss.When("ReadKey", &statestorage.ReadKeyInput{Key: "user2"}).Return(&statestorage.ReadKeyOutput{Value: 50}, tt.read2Err) ss.When("WriteKey", &statestorage.WriteKeyInput{Key: "user1", Value: 90}).Return(&statestorage.WriteKeyOutput{}, tt.write1Err) ss.When("WriteKey", &statestorage.WriteKeyInput{Key: "user2", Value: 60}).Return(&statestorage.WriteKeyOutput{}, tt.write2Err) output, err := s.(*service).processTransfer("user1", tt.to, 10) if tt.errs { Ω.Expect(err).To(HaveOccurred()) } else { Ω.Expect(err).ToNot(HaveOccurred()) Ω.Expect(output).To(BeEquivalentTo(tt.output)) } } } 

«Ω» — , — ( Gomega ). .

, TDD, , , . processTransfer() .

VirtualMachine . .

100% . , . .

, ? . , , , .

▍ -

. ? HTTP- Go (goroutine). , — , . , , , .

- . , , , , . - /e2e/stress . - ( stress.go ):

 package stress import ... const NUM_TRANSACTIONS = 20000 const NUM_USERS = 100 const TRANSACTIONS_PER_BATCH = 200 const BATCHES_PER_SEC = 40 var _ = Describe("Transaction Stress Test", func() { var ( node services.Node ) BeforeEach(func() { node = services.NewNode() node.Start() }) AfterEach(func() { node.Stop() }) It("should handle lots and lots of transactions", func() { //  HTTP-     transport := http.Transport{ IdleConnTimeout: time.Second*20, MaxIdleConns: TRANSACTIONS_PER_BATCH*10, MaxIdleConnsPerHost: TRANSACTIONS_PER_BATCH*10, } client := &http.Client{Transport: &transport} //      ledger := map[string]int32{} for i := 0; i < NUM_USERS; i++ { ledger[fmt.Sprintf("user%d", i+1)] = 0 } //     HTTP   rand.Seed(42) done := make(chan error, TRANSACTIONS_PER_BATCH) for i := 0; i < NUM_TRANSACTIONS / TRANSACTIONS_PER_BATCH; i++ { log.Printf("Sending %d transactions... (batch %d out of %d)", TRANSACTIONS_PER_BATCH, i+1, NUM_TRANSACTIONS / TRANSACTIONS_PER_BATCH) time.Sleep(time.Second / BATCHES_PER_SEC) for j := 0; j < TRANSACTIONS_PER_BATCH; j++ { from := randomizeUser() to := randomizeUser() amount := randomizeAmount() ledger[from] -= amount ledger[to] += amount go sendTransaction(client, from, to, amount, &done) } for j := 0; j < TRANSACTIONS_PER_BATCH; j++ { err := <- done Expect(err).ToNot(HaveOccurred()) } } //   for i := 0; i < NUM_USERS; i++ { user := fmt.Sprintf("user%d", i+1) resp, err := client.Get(fmt.Sprintf("http://localhost:8080/api/balance?from=%s", user)) Expect(err).ToNot(HaveOccurred()) Expect(resp.StatusCode).To(Equal(http.StatusOK)) Expect(ResponseBodyAsString(resp)).To(Equal(fmt.Sprintf("%d", ledger[user]))) } }) }) func randomizeUser() string { return fmt.Sprintf("user%d", rand.Intn(NUM_USERS)+1) } func randomizeAmount() int32 { return rand.Int31n(1000)+1 } func sendTransaction(client *http.Client, from string, to string, amount int32, done *chan error) { url := fmt.Sprintf("http://localhost:8080/api/transfer?from=%s&to=%s&amount=%d", from, to, amount) resp, err := client.Post(url, "text/plain", nil) if err == nil { ioutil.ReadAll(resp.Body) resp.Body.Close() } *done <- err } 

, - . ( rand.Seed(42) ) , . . , , — , .

- HTTP , TCP- ( , , ). , , 200 IdleConnection TCP- . , 100.

… :

 fatal error: concurrent map writes goroutine 539 [running]: runtime.throw(0x147bf60, 0x15) /usr/local/go/src/runtime/panic.go:616 +0x81 fp=0xc4207159d8 sp=0xc4207159b8 pc=0x102ca01 runtime.mapassign_faststr(0x13f5140, 0xc4201ca0c0, 0xc4203a8097, 0x6, 0x1012001) /usr/local/go/src/runtime/hashmap_fast.go:703 +0x3e9 fp=0xc420715a48 sp=0xc4207159d8 pc=0x100d879 services/statestorage.(*service).WriteKey(0xc42000c060, 0xc4209e6800, 0xc4206491a0, 0x0, 0x0) services/statestorage/methods.go:15 +0x10c fp=0xc420715a88 sp=0xc420715a48 pc=0x138339c services/virtualmachine.(*service).processTransfer(0xc4201ca090, 0xc4203a8097, 0x6, 0xc4203a80a1, 0x6, 0x2a4, 0xc420715b30, 0x1012928, 0x40) services/virtualmachine/processor.go:19 +0x16e fp=0xc420715ad0 sp=0xc420715a88 pc=0x13840ee services/virtualmachine.(*service).ProcessTransaction(0xc4201ca090, 0xc4209e67c0, 0x30, 0x1433660, 0x12a1d01) Ginkgo ran 1 suite in 1.288879763s Test Suite Failed 

? StateStorage ( map ), . , , . , map sync.map . .

processTransfer() . , — . , , , , . , processTransfer() . .

, . , , .

 e2e/stress/transactions.go:44 Expected <string>: -7498 to equal <string>: -7551 e2e/stress/transactions.go:82 ------------------------------ Ginkgo ran 1 suite in 5.251593179s Test Suite Failed 

, . , , ( , ). , , .

— . TDD . ? , 100%?! , — . processTransfer() , , .

. , , . .

परिणाम

, , , -, , , ? ? — .

, -. , «» processTransfer() . , , . , — . , - . , , .

. , . , StateStorage WriteKey , , , , WriteKeys , , .

, : . « ». -, , , , , . — . , , — .

, — GitHub. . , , , , , , .

प्रिय पाठकों! ?