एनेस्थीसिया के बिना उत्पादन पर जावा कोड पैचिंग

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

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

उदाहरण के लिए:


आप इसे आसानी से ठीक कर सकते हैं:


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

इसके अलावा, एक दूसरे पर और अनन्तता के लिए "पैच" डालना संभव है।

लेकिन यह उपकरण सर्वव्यापी नहीं है और जावा कार्यक्षमता प्रदान करने वाली मानक कार्यक्षमता पर आधारित है: java.lang.instrument.Instrumentation और इसका तरीका शून्य redefineClasses (ClassDefinition ... परिभाषाएँ) बताता है ।

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

यदि बहुत सरलता से: आप कोड को केवल विधियों और बिंदु के अंदर बदल सकते हैं।

और यहां थोड़ी देर के लूप का एक उदाहरण है, जो कि जब तक विधि पूरी नहीं होती है, तब तक तय नहीं किया जाएगा।



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

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

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

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

3. सफल विधानसभा के मामले में, पैच को एक विशेष भंडार में भेजा जाता है, और परिणाम विंडो में एक कुंजी (या हैश) जारी की जाती है, जिसे पैच को विशिष्ट रूप से पहचानने की आवश्यकता होती है और कुछ गारंटी देता है कि यह कोड उत्पादन को मिलेगा।



खैर, और फिर से - आप असीमित संख्या में बार-बार पैच कर सकते हैं और उसी संस्करण संख्या के साथ बनाता है जो हैश द्वारा अलग होगा।

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



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

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

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

7. पूरी प्रक्रिया: एप्लिकेशन को पैच करने की आवश्यकता के बारे में एक संकेत का आगमन, इसके डाउनलोडिंग, सत्यापन, अनपैकिंग और एप्लिकेशन को विस्तार से लॉग किया जाता है, दोनों सामान्य लॉग में एप्लिकेशन और अपने आप से, ताकि आप जल्दी और बिना अनावश्यक इशारों के प्रक्रिया की निगरानी कर सकें।

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

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

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

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

एप्लिकेशन या सर्वर को पुनरारंभ करने के साथ क्या करना है? यह सभी सहपाठी अनुप्रयोगों के तर्क में पहले से ही अंतर्निहित है: किसी भी अनुप्रयोग में सबसे पहले एचसीआर मॉड्यूल है। और अगर इनिशियलाइज़ेशन के दौरान एप्लिकेशन को पैच करने की आवश्यकता के बारे में जानकारी देखी जाती है, तो पहले पैच लागू किया जाएगा।

और अब हॉट कोड रिप्लेसमेंट के बारे में थोड़ा पता है।

1. हमारे JavaAgent। JavaAgent, अगर कोई भूल गया है , तो यह एक अलग, विशेष रूप से गठित * .jar संग्रह है जिसे JVM द्वारा उठाया जाता है जब अनुप्रयोग एक अतिरिक्त पैरामीटर का उपयोग करना शुरू करता है, उदाहरण के लिए: -Javaagent: /path/to/lib.my-agent.jar जावागेंट की अतिरिक्त विशेषताओं के लिए धन्यवाद और कोड प्रतिस्थापन जादू का उपयोग करना संभव है। यह एजेंट में है कि java.lang.instrument.Instrumentation क्लास उपलब्ध है। लेकिन, मैंने उसे (एजेंट) अतिरिक्त कोड के साथ बंद नहीं किया, क्योंकि एजेंट अपडेट एक गैर-तुच्छ कार्य है, लेकिन बस इंस्ट्रूमेंटेशन क्लास के उदाहरण को उपयोगिता वर्ग के स्थिर क्षेत्र में ले जाया गया है। इस प्रकार, सभी जोड़तोड़ आवेदन में कहीं से भी शुरू किए जा सकते हैं।
2. कॉन्फ़िगरेशन सेवा - हमारे किसी भी एप्लिकेशन के कॉन्फ़िगरेशन के लिए ज़िम्मेदार है और इसलिए इसे पहले प्रत्येक एप्लिकेशन में आरंभीकृत किया जाता है। यह वहाँ है कि हॉट कोड प्रतिस्थापन की मुख्य कार्यक्षमता छिपी हुई है। एप्लिकेशन स्टार्टअप पर या किसी विशेष एप्लिकेशन के लिए HCR कॉन्फ़िगरेशन को बदलते समय, संस्करण संगतता की जाँच की जाती है और उपरोक्त सभी जोड़तोड़ किए जाते हैं।
3. टीमसिटी और स्क्रिप्ट का निर्माण - आसानी से "पैच" बनाने और उनमें केवल संशोधित या जोड़े गए वर्गों और संसाधनों को बचाने के लिए।

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

और हमारे डेवलपर्स ने स्वतंत्र रूप से और खुशी से चंगा किया और सर्वर और लोड की संख्या के बिना उत्पादन में सीधे और स्वतंत्र रूप से अपनी गलतियों को ठीक किया।