आइए बात करते हैं सकारात्मक और नकारात्मक microservice दृष्टिकोण की।
पहला नकारात्मक। जब आप microservices बनाते हैं, तो आप अपने कोड में निहित जटिलता जोड़ रहे हैं। आप ओवरहेड जोड़ रहे हैं। आप पर्यावरण (जैसे डेवलपर्स के लिए) को दोहराने के लिए कठिन बना रहे हैं। आप डिबगिंग रुक-रुक कर समस्याओं को कठिन बना रहे हैं।
मुझे एक वास्तविक नकारात्मक पहलू समझाएं। काल्पनिक रूप से उस मामले पर विचार करें जहां आपके पास पृष्ठ उत्पन्न करते समय 100 माइक्रोसेवाएं हैं, जिनमें से प्रत्येक समय 99.9% सही काम करता है। लेकिन उस समय के 0.05% वे गलत परिणाम देते हैं। और उस समय का 0.05% एक धीमा कनेक्शन अनुरोध है जहां, कहने के लिए, कनेक्ट करने के लिए एक टीसीपी / आईपी टाइमआउट की आवश्यकता होती है और इसमें 5 सेकंड लगते हैं। आपके अनुरोध के पूरी तरह से काम करने के समय का लगभग 90.5%। लेकिन लगभग 5% समय आपके पास गलत परिणाम है और लगभग 5% समय आपका पृष्ठ धीमा है। और हर गैर-प्रजनन योग्य विफलता का एक अलग कारण है।
जब तक आप निगरानी, पुनरुत्पादन और इतने पर टूलींग के बारे में बहुत कुछ नहीं सोचते हैं, यह एक गड़बड़ में बदल जाता है। विशेष रूप से तब होता है जब एक माइक्रोसेवक दूसरे को कॉल करता है जो एक और कुछ परतों को गहरा कहता है। और एक बार समस्या होने पर, यह केवल समय के साथ खराब हो जाएगा।
ठीक है, यह एक दुःस्वप्न की तरह लगता है (और एक से अधिक कंपनियों ने इस रास्ते से नीचे जाकर खुद के लिए भारी समस्याएं पैदा की हैं)। सफलता केवल तभी संभव है जब आप संभावित नकारात्मक पक्ष से अवगत हों और इसे संबोधित करने के लिए लगातार काम करें।
तो उस अखंड दृष्टिकोण का क्या?
यह पता चला है कि एक अखंड अनुप्रयोग केवल सूक्ष्मदर्शी के रूप में संशोधित करना आसान है। और एक फ़ंक्शन कॉल RPC कॉल की तुलना में व्यवहार में सस्ता और अधिक विश्वसनीय दोनों है। तो आप एक ही चीज को विकसित कर सकते हैं सिवाय इसके कि यह अधिक विश्वसनीय है, तेजी से चलता है, और इसमें कम कोड शामिल है।
ठीक है, फिर कंपनियां माइक्रोसिस्टर्सेज के दृष्टिकोण पर क्यों जाती हैं?
उत्तर इसलिए है क्योंकि जैसे-जैसे आप स्केल करते हैं, एक सीमा होती है कि आप एक अखंड एप्लिकेशन के साथ क्या कर सकते हैं। इतने सारे उपयोगकर्ताओं के बाद, इतने सारे अनुरोध, और इतने पर, आप एक ऐसे बिंदु पर पहुंच जाते हैं जहां डेटाबेस पैमाने पर नहीं होते हैं, वेबसर्वर आपके कोड को मेमोरी में नहीं रख सकते हैं, और इसी तरह। इसके अलावा microservice दृष्टिकोण अपने आवेदन के स्वतंत्र और वृद्धिशील उन्नयन के लिए अनुमति देते हैं। इसलिए एक माइक्रोसैस आर्किटेक्चर आपके एप्लिकेशन को स्केल करने का एक समाधान है।
अंगूठे का मेरा व्यक्तिगत नियम यह है कि कोडिंग से स्क्रिप्टिंग भाषा (जैसे पायथन) से अनुकूलित C ++ में जाना आम तौर पर प्रदर्शन और स्मृति उपयोग दोनों पर परिमाण के 1-2 आदेशों में सुधार कर सकता है। किसी वितरित आर्किटेक्चर के लिए दूसरे रास्ते पर जाना संसाधन आवश्यकताओं को बढ़ाता है लेकिन आपको अनिश्चित काल के लिए स्केल करता है। आप एक वितरित वास्तुकला काम कर सकते हैं, लेकिन ऐसा करना कठिन है।
इसलिए मैं कहूंगा कि यदि आप एक निजी परियोजना शुरू कर रहे हैं, तो अखंड जाएं। अच्छी तरह से करना सीखें। वितरित न करें क्योंकि (Google | eBay | Amazon | etc) हैं। यदि आप वितरित की गई किसी बड़ी कंपनी में उतरते हैं, तो ध्यान दें कि वे इसे कैसे काम करते हैं और इसे खराब नहीं करते हैं। और यदि आप संक्रमण करने के लिए हवा करते हैं, तो बहुत सावधान रहें, क्योंकि आप बहुत कठिन काम कर रहे हैं जो बहुत आसान है, बहुत गलत है।
प्रकटीकरण, मेरे पास सभी आकारों की कंपनियों में करीब 20 साल का अनुभव है। और हां, मैंने दोनों अखंड और वितरित आर्किटेक्चर को करीब और व्यक्तिगत देखा है। यह उस अनुभव पर आधारित है जो मैं आपको बता रहा हूं कि एक वितरित माइक्रोसेर आर्किटेक्चर वास्तव में ऐसा कुछ है जो आप करते हैं क्योंकि आपको इसकी आवश्यकता है, और इसलिए नहीं कि यह किसी तरह से क्लीनर और बेहतर है।
