डिस्ट्रीब्यूटेड सिस्टम में सुरक्षित इंटरऑपरेबिलिटी

हाय हमर!

मेरा नाम एलेक्स नद्यपान, Badoo पर मैं PHP-डेवलपर है। और आज मैं अपनी बात के पहले संस्करण PHP मीटअप के लिए एक पाठ संस्करण साझा करूंगा। इसका एक वीडियो और माइटैप की अन्य रिपोर्ट यहां मिल सकती है ।

कम से कम दो घटकों से मिलकर किसी भी प्रणाली इन घटकों के बीच बातचीत में जोखिम के पूरे वर्गों से टकरा (और अगर आपके पास, और PHP, और डेटाबेस, यह एक दो घटक है)।

जिस प्लेटफ़ॉर्म विभाग में मैं काम करता हूं वह हमारे आवेदन के साथ नई आंतरिक सेवाओं को एकीकृत करता है। और इन समस्याओं को हल करने के लिए, हमारे पास संचित अनुभव है, जिसे मैं साझा करना चाहता हूं।

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

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

सेवा दुर्घटना

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

कैसे अपनी सेवाओं को एक ऐसी दुनिया है कि लगातार सर्वर क्रैश हो जाता है में जीवित रहने के लिए बनाने के लिए? समस्याओं के इस वर्ग को हल करने के लिए एक सामान्य दृष्टिकोण अतिरेक है।

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

आइए एक उदाहरण के रूप में सरलतम योजना का उपयोग करते हुए अतिरेक के साथ विशिष्ट समस्याओं पर विचार करें:


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



मास्टर को पुनर्स्थापित करने के बाद, हम बस इसमें से एक नया गुलाम बनाते हैं, और पुराना एक मास्टर में बदल जाता है।

योजना सरल है, लेकिन फिर भी वह बारीकियों का एक बहुत, किसी भी योजना बेमानी की खासियत है।

भार

मान लीजिए कि ऊपर दिए गए उदाहरण में से एक सर्वर लगभग 100k RPS का सामना कर सकता है। अब लोड 60k आर पी एस है, और सब कुछ घड़ी की कल की तरह काम करता है।

लेकिन समय के साथ, आवेदन पर लोड, और इसलिए मास्टर पर लोड बढ़ जाता है। आप दास पर पढ़ने का हिस्सा ले जाकर इसे संतुलित कर सकते हैं।

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

डेटा

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

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

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

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

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

निष्कर्ष

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

मौन सेवा

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

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

चलो इस बात है पीएचपी एफ पी एम workers` की एक निश्चित संख्या के साथ nginx का उपयोग करके संसाधित (दस, उदाहरण के लिए) का कहना है। प्रत्येक अनुरोध 20 के बारे में एमएस, सरल गणना की मदद से द्वारा नियंत्रित किया जाता है, तो हम देख सकते हैं कि हमारी प्रणाली प्रति सेकंड पांच सौ अनुरोधों के बारे में संभाल करने में सक्षम है।

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

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

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

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

निर्णय

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

हमने इस पैटर्न के हमारे कार्यान्वयन को लिखा है। लेकिन इसलिए नहीं कि हम कोड लिखना पसंद करते हैं, बल्कि इसलिए कि जब हमने कई साल पहले इस समस्या को हल किया था, तो कोई तैयार समाधान नहीं थे।

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

यह कुछ इस तरह दिखता है:

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

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

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

यह सब पिछली प्रतिकृति योजना की स्थिति को कम करने के लिए किया जाता है। यह समझने से पहले कि होस्ट अनुपलब्ध है, प्रतीक्षा करने के बजाय, हम तुरंत एक त्रुटि प्राप्त करते हैं और बैकअप होस्ट पर जाते हैं।

कार्यान्वयन

सौभाग्य से, ओपन सोर्स अभी भी खड़ा नहीं है, और आज आप जीथब पर टर्नकी समाधान ले सकते हैं।

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

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

• गणेश
  
• पीएचपी सर्किट ब्रेकर
  
• Phystrix
  

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

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

यहाँ कुछ विकल्प हैं (वहाँ अधिक समृद्ध कार्यक्षमता रहे हैं, लेकिन सर्किट ब्रेकर भी उपलब्ध है):

• दूत
  
• Linkerd
  

निष्कर्ष

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

निगरानी और टेलीमेट्री

यह क्या देता है

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

क्या उपाय करें

एकीकरण मैट्रिक्स

चूंकि हम सेवाओं के बीच बातचीत के बारे में बात कर रहे हैं, इसलिए हम उन सभी चीज़ों पर नज़र रखते हैं जो एप्लिकेशन के साथ सेवा के संचार के संबंध में संभव है। उदाहरण के लिए:

• प्रश्नों की संख्या;
  
• अनुरोध प्रसंस्करण समय (प्रतिशत सहित);
  
• तर्क त्रुटियों की संख्या;
  
• सिस्टम त्रुटियों की संख्या।
  

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

आंतरिक मैट्रिक्स

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

चलो देखते हैं, क्या मैट्रिक्स memcached के उदाहरण से एकत्र किया जा सकता:

• अनुपात हिट / मिस;
  
• विभिन्न कार्यों के लिए प्रतिक्रिया समय;
  
• विभिन्न कार्यों आर पी एस;
  
• अलग-अलग कुंजी पर एक ही डेटा का टूटना;
  
• शीर्ष भरी हुई चाबियाँ;
  
• सभी आंतरिक मैट्रिक्स कि आँकड़े टीम देता है।
  

कैसे करना है?

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

• Datadog
  
• rollbar
  
• नया अवशेष
  

वैकल्पिक रूप से, आप हमेशा अपनी मशीन पर Zabbix, Grafana, या किसी अन्य स्व-होस्ट किए गए समाधान को स्थापित कर सकते हैं।

निष्कर्ष

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

मेमेंटो मोरी

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

उदाहरण के लिए, Badoo में एक पृष्ठ है "आस-पास के लोग।" वहां, उपयोगकर्ता आसपास के अन्य लोगों को उनके साथ चैट करने के लिए खोजते हैं।



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



अधिकांश उपयोगकर्ता इस तथ्य के बारे में भी नहीं जानते हैं: हमारी टीम तुरंत प्रतिक्रिया देती है, और जल्द ही ब्लॉक बस फिर से प्रकट होता है।

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



यह भी वांछनीय है कि एक सेवा की विफलता एक कैस्केडिंग विफलता की ओर नहीं ले जाती है। प्रत्येक सेवा के लिए, कोड लिखा होना चाहिए जो इसके गिरने को संभालता है, अन्यथा एप्लिकेशन पूरी तरह से क्रैश हो सकता है।

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

मरो, तो सही

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

परिणाम

नई सेवा को सिस्टम में समेकित रूप से एकीकृत करने के लिए, हम उसके चारों ओर एक विशेष रैपर एपीआई लिखेंगे, जो निम्नलिखित कार्यों में लेता है:

• लोड संतुलन;
• समय समाप्ति;
• तर्क विफलता;
• सर्किट ब्रेकर;
• निगरानी और टेलीमेटरी;
• प्राधिकरण तर्क;
• क्रमबद्धता और डेटा की de-क्रमबद्धता।

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

आपका ध्यान के लिए धन्यवाद!

साहित्य

• इसे जारी करें!
• साइट विश्वसनीयता इंजीनियरिंग
• बनाना mikroservisov