माइक्रोसर्विस या मोनोलिथ: एक समाधान की तलाश में

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

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

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

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

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

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

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

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

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

1. लोड सीमा और पूर्वानुमान की आवश्यकता है, कार्य निष्पादन के कारण समय की देरी बारी में महत्वपूर्ण नहीं है
2. अलगाव उत्पादकता में महत्वपूर्ण वृद्धि देगा।

इस दृष्टिकोण के परिणामस्वरूप, हमें एक सिस्टम मिला, जो कि कर्नेल में स्थित कार्यक्षमता का 95%, और माइक्रोसर्विस में 5% है। लेकिन एक ही समय में, कोर कुल भार का केवल 60% है। और एक ही समय में, आप गारंटी दे सकते हैं कि व्यक्तिगत सर्वर पर लोड महत्वपूर्ण मानों से अधिक नहीं है।

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

धन्यवाद!