क्या आपको हमेशा Docker, microservices और reactive प्रोग्रामिंग की आवश्यकता है?

डेनिस Tsyplakov , समाधान वास्तुकार, DataArt द्वारा पोस्ट किया गया

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

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

नियमित रूप से अंतिम पैराग्राफ में गलतियां होती हैं, जिनमें से कुछ पर मैं एक लेख में चर्चा करूंगा।

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

मान लीजिए कि हम जावा में एक निश्चित एप्लिकेशन बनाते हैं, कहते हैं, तारीखों में हेरफेर करने के लिए प्रोजेक्ट में टाइममैगस लाइब्रेरी जोड़ें (एक उदाहरण काल्पनिक है)। पुस्तकालय उत्कृष्ट है, यह हमें कई सुविधाएँ प्रदान करता है जो मानक कक्षा के पुस्तकालय में उपलब्ध नहीं हैं। ऐसा निर्णय हानिकारक कैसे हो सकता है? आइए देखें संभावित परिदृश्य:

1. सभी डेवलपर्स एक गैर-मानक लाइब्रेरी को नहीं जानते हैं, नए डेवलपर्स के लिए प्रवेश सीमा अधिक होगी। मौका बढ़ जाता है कि एक अज्ञात पुस्तकालय का उपयोग कर एक तारीख में हेरफेर करते समय एक नया डेवलपर एक गलती करेगा।
2. वितरण का आकार बढ़ रहा है। जब स्प्रिंग बूट पर औसत एप्लिकेशन का आकार आसानी से 100 एमबी तक बढ़ सकता है, तो इसका कोई मतलब नहीं है। मैंने ऐसे मामलों को देखा, जब एक विधि के लिए, 30 एमबी की लाइब्रेरी को वितरण किट में खींचा गया था। उन्होंने इसे इस तरह से उचित ठहराया: "मैंने पिछले प्रोजेक्ट में इस लाइब्रेरी का उपयोग किया था, और वहां एक सुविधाजनक तरीका है।"
3. पुस्तकालय के आधार पर, प्रारंभ समय काफी बढ़ सकता है।
4. लाइब्रेरी डेवलपर अपने दिमाग की उपज को छोड़ सकता है, फिर लाइब्रेरी जावा के नए संस्करण के साथ संघर्ष करना शुरू कर देगा, या इसमें एक बग का पता लगाया जाएगा (इसके द्वारा, उदाहरण के लिए, समय क्षेत्र बदलते हुए), और कोई पैच जारी नहीं किया जाएगा।
5. कुछ बिंदु पर लाइब्रेरी लाइसेंस आपके उत्पाद के लाइसेंस के साथ संघर्ष करेगा (क्या आप उन सभी उत्पादों के लाइसेंस की जांच करते हैं जो आप उपयोग करते हैं)।
6. जार नरक - TimeMagus लाइब्रेरी को SuperCollections लाइब्रेरी के नवीनतम संस्करण की आवश्यकता है, फिर कुछ महीनों के बाद आपको लाइब्रेरी को किसी थर्ड-पार्टी API के साथ एकीकरण के लिए कनेक्ट करना होगा, जो SuperCollections के नवीनतम संस्करण के साथ काम नहीं करता है, और केवल संस्करण 2.x के साथ काम करता है। आप API नहीं जोड़ सकते। इस API के साथ काम करने के लिए कोई अन्य पुस्तकालय नहीं है।

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

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

डाक में काम करनेवाला मज़दूर

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

पहले, यह कुछ राक्षसी तरीके से किया गया था, और कुछ कार्यों को हल नहीं किया गया था। उदाहरण के लिए, आपके पास एक PHP एप्लिकेशन है जो छवियों के साथ काम करने के लिए ImageMagick लाइब्रेरी का उपयोग करता है, आपके एप्लिकेशन को विशिष्ट php.ini सेटिंग्स की भी आवश्यकता होती है, और एप्लिकेशन को Apache httpd का उपयोग करके होस्ट किया जाता है। लेकिन एक समस्या है: कुछ नियमित दिनचर्या को क्रोन से पायथन स्क्रिप्ट चलाकर लागू किया जाता है, और इन लिपियों द्वारा उपयोग की जाने वाली लाइब्रेरी आपके आवेदन में उपयोग किए गए पुस्तकालयों के संस्करणों के साथ संघर्ष करती है। डॉकर आपको एक कंटेनर में सेटिंग्स, लाइब्रेरी और एक HTTP सर्वर के साथ अपने पूरे एप्लिकेशन को पैक करने की अनुमति देता है, जो पोर्ट 80 पर अनुरोधों को पूरा करता है, और दूसरे कंटेनर में रूट करता है। सभी एक साथ पूरी तरह से काम करेंगे, और आप पुस्तकालयों के संघर्ष के बारे में भूल सकते हैं।

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



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

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

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



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

इसके अलावा, डॉकटर के साथ, नेटवर्क प्रोटोकॉल में समस्याओं का विश्लेषण काफी जटिल है, न केवल देरी बढ़ती है, बल्कि सभी समय अलग-अलग हो जाते हैं।

डॉकटर की वास्तव में आवश्यकता कब है?

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

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

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

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

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

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

Kubernetes

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

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

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

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

यह सवाल उठाता है, "रुको, एक जार फ़ाइल कैसे है?"। इस प्रणाली में अधिक से अधिक परमाणु माइक्रोसर्विसेज शामिल होने चाहिए! आइए देखें कि माइक्रोसिरोवर्स के साथ सिस्टम को कौन और क्या करना चाहिए।

Mikroservisy

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

हमारे पास स्प्रिंग बूट 1 और जावा 8 में एक एप्लिकेशन है। एक अद्भुत, स्थिर संयोजन। लेकिन वर्ष 2019 है, और चाहे हम इसे पसंद करें या न करें, हमें स्प्रिंग बूट 2 और जावा 12 की ओर बढ़ने की आवश्यकता है। यहां तक ​​कि स्प्रिंग बूट के नए संस्करण के लिए एक बड़ी प्रणाली का अपेक्षाकृत सरल संक्रमण बहुत श्रमसाध्य हो सकता है, लेकिन जावा 8 से जावा के लिए रसातल पर कूदने के बारे में। 12 मैं बात नहीं करना चाहता। यही है, सिद्धांत रूप में सब कुछ सरल है: हम पलायन करते हैं, जो समस्याएं उत्पन्न हुई हैं, उन्हें ठीक करते हैं, हम सब कुछ परीक्षण करते हैं और इसे उत्पादन में चलाते हैं। व्यवहार में, इसका मतलब कई महीनों का काम हो सकता है जो व्यवसाय में नई कार्यक्षमता नहीं लाता है। जावा 12 की एक छोटी सी चाल, जैसा कि आप जानते हैं, यह भी काम नहीं करता है। यहाँ माइक्रोसिस्टवर्क आर्किटेक्चर हमारी मदद कर सकता है।

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

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

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

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

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

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

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

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



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

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

माइक्रोसर्विस की आवश्यकता कब होती है?

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

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



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

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

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

प्रतिक्रियाशील वास्तुकला और प्रतिक्रियाशील प्रोग्रामिंग

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



, . , , : « , !?» , , , , «». , 100% , , .

— , — . .

? , .

- , - . - -, , HTTP-. , . , . , , , .

? , HTTP- , ( callback) ( ) . , - ( , HTTP-) .

— . . . . 3 Ghz , , . . . , Java-, HTTP- — 5-10%. , , , , 100 50 $/ — $500 . , , .

, ? .

, . , , , , , , . , , . .

- . , JDBC ( . ADA, R2DBC, ). 90 % , . — HTTP- , . , .

?

, , , ( ) . — - , . , , , HTTP.

, , , , , , .

. , « , » , , , . , , , 10 11 , , , .

निष्कर्ष

, . , , , .