ऐसा लगता है कि माइक्रोसर्विसेज का प्रचार-प्रसार का चरम हमारे पीछे रह गया है। अब हम सप्ताह में कई बार “मैंने अपने मोनोलिथ को 150 सेवाओं में कैसे स्थानांतरित किया” के बारे में पोस्ट नहीं पढ़ते हैं। अब मैं अधिक समझदारी भरे विचार सुनता हूँ: "मैं मोनोलिथ से नफरत नहीं करता, मुझे बस दक्षता की परवाह है।" हमने कई बार पलायन भी देखा। माइक्रोसर्विसेज से मोनोलिथ तक वापस. जब आप एक बड़े अनुप्रयोग से अनेक छोटी सेवाओं पर जाते हैं, तो आपको कुछ नई समस्याओं का समाधान करना होगा। आइये हम उन्हें यथासंभव संक्षेप में सूचीबद्ध करें।

स्थापना: मूल रसायन विज्ञान से क्वांटम यांत्रिकी तक

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

इस प्रणाली को समझना आसान नहीं है

आइये एक क्षण के लिए अपने जूनियर पर रुकें। मोनोलिथिक अनुप्रयोगों में, यदि कोई त्रुटि हुई, तो उसका पता लगाना और तुरंत डिबगिंग शुरू करना आसान था। अब हमारे पास एक सेवा है जो दूसरी सेवा से बातचीत करती है, जो संदेश बस पर कुछ पंक्तिबद्ध करती है, जिसे दूसरी सेवा संसाधित करती है - और फिर एक त्रुटि घटित होती है। हमें इन सभी टुकड़ों को एक साथ जोड़ना होगा ताकि अंततः पता चल सके कि सेवा A संस्करण 11 पर चल रही है, और सेवा E पहले से ही संस्करण 12 की अपेक्षा कर रही है। यह मेरे मानक समेकित लॉग से बहुत अलग है: मुझे प्रक्रिया को चरण दर चरण पूरा करने के लिए एक इंटरैक्टिव टर्मिनल/डीबगर का उपयोग करना होगा। डिबगिंग और समझना अनिवार्यतः अधिक कठिन हो गया है।

यदि हम उन्हें डीबग नहीं कर सकते, तो शायद हम उनका परीक्षण कर सकते हैं।

इन दिनों सतत एकीकरण और सतत विकास आम बात होती जा रही है। मैं जो भी नए ऐप देखता हूँ, उनमें से ज़्यादातर हर नए रिलीज़ के साथ स्वचालित रूप से परीक्षण बनाते और चलाते हैं और जाँच से पहले परीक्षणों को पास करने और समीक्षा करने की आवश्यकता होती है। ये बहुत अच्छी प्रक्रियाएँ हैं जिन्हें छोड़ा नहीं जाना चाहिए और ये कई कंपनियों के लिए एक बड़ा बदलाव रहा है। लेकिन अब, वास्तव में सेवा का परीक्षण करने के लिए, मुझे अपने ऐप का पूर्ण कार्यशील संस्करण तैयार करना होगा। क्या आपको 8 सर्विस K150 क्लस्टर वाला वह नया इंजीनियर याद है? खैर, अब हम अपने CI सिस्टम को सिखाएंगे कि इन सभी प्रणालियों को कैसे लाया जाए ताकि यह जांचा जा सके कि सब कुछ वास्तव में काम कर रहा है। यह संभवतः बहुत अधिक प्रयास है, इसलिए हम प्रत्येक भाग का अलग-अलग परीक्षण करेंगे: मुझे विश्वास है कि हमारी विशिष्टताएं पर्याप्त अच्छी हैं, API साफ है, तथा सेवा विफलता अलग-थलग है तथा इसका प्रभाव अन्य पर नहीं पड़ेगा।

सभी समझौतों के पीछे कोई अच्छा कारण होता है। सही?

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

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

स्रोत: www.habr.com