हाय, मैं Stanislav Yablonskiy हूं, Pixonic (MY.GAMES) में प्रमुख सर्वर डेवलपर। माइक्रोसेसिस सॉफ्टवेयर विकास का एक दृष्टिकोण है (मुख्य रूप से बैकेंड विकास) जहां कार्यक्षमता को सबसे छोटे संभव घटकों में विभाजित किया जाता है, जिनमें से प्रत्येक स्वतंत्र रूप से संचालित होता है। माइक्रोसेसेंस आज बहुत लोकप्रिय हैं, लेकिन उनका उपयोग नेटवर्क, मेमोरी और सीपीयू के मामले में महत्वपूर्ण ओवरहेड लाता है। प्रत्येक कॉल नेटवर्क के माध्यम से डेटा को श्रृंखलाकरण, भेजने और प्राप्त करने की आवश्यकता में बदल जाता है. इसके अलावा, क्लासिक डेटाबेस लेनदेन का उपयोग करना अब संभव नहीं है, जिससे या तो वितरित लेनदेन या अंततः स्थिरता होती है. वितरित लेनदेन धीमी और महंगी हैं, जबकि संभावित निष्पक्षता का मतलब है कि ऑपरेशन के परिणाम तुरंत प्रकट नहीं हो सकते हैं, और डेटा अस्थायी रूप से असंगत हो सकता है। माइक्रो सेवाओं का उपयोग करना डेवलपर्स को प्रत्येक व्यक्तिगत सेवा में अधिक कोड लिखने के लिए मजबूर करता है क्योंकि अन्य सेवाओं से पहले से ही लिखे गए तर्क तक पहुंचने में कठिनाई होती है. कभी-कभी, मौजूदा कोड का पुनः उपयोग करना मुश्किल होता है, या आप यह भी नहीं जान सकते हैं कि यह मौजूद है - क्योंकि अन्य लोग एक अलग परियोजना पर काम कर रहे हो सकते हैं. माइक्रोसेवेज ‘Overheads’ ओवरहेड डेब्यू डिबगिंग microservices के साथ बहुत अधिक मुश्किल हो जाता है. एक नियमित डिबगर इस तरह की स्थितियों में लगभग बेकार है क्योंकि आप सभी सेवाओं को एक बार में डिबग नहीं कर सकते. बिना एक उचित रूप से सेट अप लॉगिंग, ट्रैकिंग, और मीट्रिक प्रणाली, डिबगिंग लगभग असंभव है जब तक समस्या को स्थानीयकृत नहीं किया जाता है. इसका मतलब है कि आपको एक विशेष वातावरण की आवश्यकता है जहां न केवल डिबग किया जा रहा सेवा चल रही है, बल्कि इसके सभी निर्भरताएं (अन्य सेवाएं, डेटाबेस, पंक्तियां, आदि)। HTTP ओवरहेड HTTP प्रोटोकॉल में कई अंतर्निहित कार्यक्षमता है. यह विभिन्न मार्गों, पैरामीटर पारित करने के तरीकों, प्रतिक्रिया कोड का समर्थन करता है, और कई उपयोग के लिए तैयार सेवाओं (प्रॉक्सी सहित) द्वारा समर्थित है। प्रोटोटाइप Overhead नेटवर्क संचार के लिए श्रृंखलाकरण और संदेश प्राप्त करते समय deserialization की आवश्यकता होती है। जब आप संदेश एक्सचेंज के लिए protobuf का उपयोग करते हैं, तो आपको: वस्तुओं का निर्माण, उनमें बदलाव के लिए बदलाव किया जाता है। उपयोग के तुरंत बाद उन्हें हटा दें। यह कचरे कलेक्टर या गतिशील स्मृति प्रबंधक के लिए बहुत अधिक काम पैदा करता है। नेटवर्क ओवरहेड नेटवर्क पर डेटा स्थानांतरित करना सेवा प्रतिक्रिया समय बढ़ाता है. यह मेमोरी और सीपीयू खपत को बढ़ाता है, भले ही माइक्रोसेसिस एक ही होस्ट पर चल रहे हों. मेमोरी ओवरहेड संदेश भेजने और प्राप्त करने के लिए अतिरिक्त डेटा संरचनाओं को बनाए रखने, अलग-अलग तारों का उपयोग करने और उन्हें सिंक्रनाइज़ करने की आवश्यकता होती है। सीपीओ ओवरहेड स्वाभाविक रूप से, इस सभी इंटर-प्रोसेस और इंटर-कंटेनर संचार को कंप्यूटिंग संसाधनों की आवश्यकता होती है। डेटाबेस ओवरहेड सामान्य लेन-देन असंभव होते हैं जब ऑपरेशन कई माइक्रो सेवाओं को फैलाते हैं। वितरित लेन-देन बहुत धीमी होते हैं और जटिल - अक्सर मैन्युअल - समन्वय की आवश्यकता होती है। नेटवर्क डिस्क ओवरहेड माइक्रोसेवेस कंटेनर अक्सर नेटवर्क-मुद्रित डिस्क पर चलते हैं. यह लाटेनता को बढ़ाता है, प्रदर्शन को कम करता है (आईओपीएस), और इसे अप्रत्याशित बनाता है. परियोजना पारदर्शिता माइक्रो सेवाओं को डिजाइन और विकसित करना परियोजना को विकसित करने और पुनर्विचार करने में कठिनाइयों का कारण बनता है। एक सेवा की जिम्मेदारी क्षेत्र को बदलना आसान नहीं है। आप कुछ को सिर्फ नाम नहीं बदल सकते हैं या हटा सकते हैं. आप सिर्फ एक सेवा से दूसरे सेवा में कोड नहीं स्थानांतरित कर सकते हैं. यह आमतौर पर आवश्यक है: बहुत समय और प्रयास, कई API संस्करण, और सुविधाओं को सेवाओं के बीच फिर से वितरित करने से पहले जटिल प्रवास। इसके अलावा, यदि आप एक लाइब्रेरी को अपडेट करना या प्रतिस्थापित करना चाहते हैं, तो आपको केवल एक नहीं बल्कि सभी परियोजनाओं पर ऐसा करने की आवश्यकता होगी। बुनियादी ढांचे Overhead आप सिर्फ "माइक्रोसेस" नहीं कर सकते. आपको बुनियादी ढांचे की आवश्यकता होगी - नहीं, बुनियादी ढांचे की आवश्यकता होगी: कंटेनर (प्रत्येक में साझा पुस्तकालयों की प्रतियां होती हैं), क्यूबर्ट्स Cloud सेवाएं, रैबिट एमके (RabbitMQ, Kafka) कॉन्फ़िगरेशन सिंक्रनाइज़िंग उपकरण (Zookeeper, Etcd, Consul), और इतने पर। यह सब मशीनों और लोगों दोनों से बड़े पैमाने पर संसाधनों की आवश्यकता होती है। स्वतंत्र डिप्लोमा Overhead स्वतंत्र तैनाती का समर्थन करने का मतलब है: प्रत्येक सेवा को अलग-अलग तैनात किया जाना चाहिए, प्रत्येक के पास अपना सीआई / सीडी पाइपलाइन होना चाहिए, और सबसे कठिन हिस्सा - API संस्करण। प्रत्येक सेवा को एक साथ कई एपीआई संस्करणों का समर्थन करना होगा. और कॉलर्स को इन संस्करणों को ट्रैक करना होगा और समय पर अपने कॉल अपडेट करना होगा. फैला हुआ गेंद ब्लेड साफ माइक्रो सेवाओं के बजाय, आप एक वितरित गंदगी की गेंद के साथ समाप्त हो जाएंगे - जहां कार्यक्षमता खराब रूप से वितरित की जाती है, बाहरी कॉल आंतरिक सेवा कॉल की पूरी श्रृंखला को शुरू करते हैं, और यह सब बहुत धीमा है। क्या मोनोलिथ वास्तव में इतना डरावना है? मॉड्यूलर Monoliths मॉड्यूलर मोनोलिट आपको अधिकांश माइक्रोसेस ओवरहेड से बचने की अनुमति देते हैं - जबकि अभी भी अलगाव प्रदान करते हैं जिसे बाद में आवश्यक होने पर उपयोग किया जा सकता है। इस दृष्टिकोण में एप्लिकेशन (मुख्य रूप से बैकेंड) को एकल सेवा के रूप में लिखना शामिल है, जिसमें निम्नलिखित मॉड्यूल होते हैं: स्पष्ट रूप से परिभाषित सीमाएं, और न्यूनतम पारस्परिकता। इससे उन्हें सेवाओं में विभाजित करना संभव है यदि स्केलिंग वास्तव में इसकी आवश्यकता है। इंतजार करो, क्या आप ऐसा कर सकते हैं? माइक्रोसेस आर्किटेक्चर के कई लाभ एक मोनोलिट में प्राप्त किए जा सकते हैं: भाषा विशेषताओं के साथ मॉड्यूलरता लागू की जा सकती है: कक्षाएं, नामस्पेस, परियोजनाएं और असेंबली; कई डेटाबेस - संभव है, यदि वास्तव में आवश्यक है; कई भाषाएं - यह भी संभव है, उदाहरण के लिए, उच्च स्तर के विकास के लिए JavaScript, Python, या Erlang जैसे स्क्रिप्टिंग भाषाओं के साथ C/C++/C#/Java का संयोजन; Interop – कई प्लेटफॉर्म जावा, C#, Python, JavaScript, या Erlang से C/C++ कॉल का समर्थन करते हैं; संदेश पंक्तियां - बस उचित डेटा संरचना का उपयोग करें। और जब आप डिबग करना चाहते हैं - एक कुंजीपीट, और पूरे आवेदन आपकी उंगलियों के पास है। अभिनेता फ्रेमवर्क एक्टर फ्रेमवर्क आपको माइक्रोसेवेज बनाने की अनुमति देते हैं - माइक्रोसेवेज के बिना। सभी तार्किक वर्गों ( अभिनेताओं) में विभाजित हैं जो केवल एक संदेश बस (कवों) के माध्यम से संवाद करते हैं। ये अभिनेता हो सकते हैं: एक ही प्रक्रिया में मौजूद हैं, या कई प्रक्रियाओं में वितरित किया जाता है। इस तरह, आप माइक्रोसेस प्रोग्रामिंग मॉडल प्राप्त करते हैं, लेकिन अधिकांश बुनियादी ढांचे फ्रेमवर्क द्वारा संचालित होते हैं। Conclusion निष्कर्ष आर्किटेक्चर को निम्नलिखित के आधार पर चुना जाना चाहिए: परियोजना की आवश्यकताएं, उपलब्ध संसाधन, टीम की विशेषज्ञता माइक्रोसेसेंस एक चांदी की गोली नहीं हैं. वे विशाल परियोजनाओं और टीमों के लिए उपयोगी हैं - लेकिन मोनोलिथ पुराना नहीं है और डिफ़ॉल्ट रूप से तकनीकी ऋण नहीं है। सबसे महत्वपूर्ण बात यह है कि लचीलापन और जटिलता, स्केलेबलता और रखरखाव के बीच संतुलन है - ताकि आपके द्वारा बनाए गए सिस्टम प्रभावी और टिकाऊ हो।
