सूक्ष्मजीव दुनिया को आसान बनाते हैं (लेकिन नहीं)

हर कोई अब microservices के बारे में बात कर रहा है। लगभग हर बैठक, सम्मेलन और बैठक एक कहानी के बिना पूरी नहीं होती है कि माइक्रोसर्विस क्या हैं और वे कितने अच्छे हैं, वे परियोजना की जटिलता को कैसे कम करते हैं, आदि।

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

उदाहरण के लिए: एक बहुत जटिल पेचीदा मोनोलिथ था, हमने इसे कई सेवाओं में विभाजित किया, उनमें से प्रत्येक बहुत अच्छा लग रहा है, कोई भी कोड का पता लगा सकता है, लेकिन पर्यावरण का क्या होता है? जटिलता बढ़ती जा रही है: ये वितरित किए गए लेनदेन हैं जिन्हें समझने के लिए लॉग इन करने की आवश्यकता है कि यह एकल लेनदेन है; प्रत्येक सेवा के लिए CI / CD और डिलीवरी जोड़ी जाती है; इंटरैक्शन स्कीम गैर-तुच्छ हो जाती है।

सबसे विवादास्पद शोध या कथन जो मैंने रिपोर्टों में सुने हैं और जिनके साथ मैं बहस करने के लिए तैयार हूं:

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

लेकिन अन्य टीम के सदस्यों के बारे में क्या?

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

सबसे पहले, नया विश्लेषक अपना सिर भी तोड़ सकता है, जब तक कि वह आंतरिक चुनौतियों की सभी जटिलताओं को नहीं समझता।

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

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

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

और क्या वे बात नहीं कर रहे हैं

कठिनाई बढ़ रही है

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

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

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

लेकिन उनमें त्रुटियां हो सकती हैं जिन्हें ठीक करना होगा। यदि हम बिना किसी समस्या के मरम्मत का सामना करते हैं, तो परिवर्तनों को 200-300 सेवाओं में बदलने के लिए, इसमें समय और विकसित नियंत्रण लगेगा। और अगर आपको अद्यतन लाइब्रेरी के साथ सेवाओं को फिर से बनाने की आवश्यकता है, या यहां तक ​​कि कॉल को फिर से करना है (उन्होंने इसे उसी तरह तय किया, इसके लिए प्रदान नहीं किया है), तो यह सब मज़ेदार नहीं होगा।

मोनोलिथ - मिट्टी की एक बड़ी गेंद नहीं

आमतौर पर माइक्रोसर्विसेस की खूबसूरत दुनिया के बारे में कहानियाँ कैसे शुरू होती हैं? "हमारे पास एक मोनोलिथ था, यह मिट्टी की एक ठोस गांठ थी, जिसमें सब कुछ भ्रमित और समझ से बाहर है," प्लस वे एक भयानक तस्वीर दिखाएंगे। और मोनोलिथ पहले से ही कुछ भयावह हो गया है, "आप खराब काम करेंगे, आपकी परियोजना एक मोनोलिथ में बदल जाएगी।" लेकिन नहीं।

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

तो क्या उपयोग करें?

अच्छा सवाल है, और केवल आप ही जवाब दे सकते हैं। क्योंकि केवल आप जानते हैं कि आप क्या व्यावसायिक समस्याएं तय करते हैं, परियोजना क्या होगी। कोई चांदी की गोली नहीं है, कोई आदर्श वास्तुकला नहीं है जिसका उपयोग किया जा सकता है और हमेशा "खुशी" होगी।

और मोनोलिथ में, और माइक्रोसेवा में, प्रलेखन का पालन करें और इसे अद्यतित रखें। प्रलेखन इसके बिना की तुलना में बेहतर है।

एक विकास प्रक्रिया बनाएं जिसमें कोड की गुणवत्ता केवल बढ़ेगी (समीक्षा, इकाई परीक्षण)। लेकिन गुणवत्ता के बारे में आप एक पूरी किताब लिख सकते हैं, यह एक अलग बड़ी बातचीत का विषय है।

सरल और समझने योग्य कोड microservices के बारे में नहीं है, कोड ऐसा होना चाहिए जो एक प्राथमिकता हो।

टेस्ट ऑटोमेशन कोड क्वालिटी के बारे में भी है।

सब कुछ आप स्वचालित कर सकते हैं - CI / CD। संभवतः एक प्रौद्योगिकी स्टैक है जिसे CI / CD में खींचना बहुत मुश्किल है, लेकिन 99% असेंबलियों / डिलीवरी को स्वचालित किया जा सकता है।