वास्तु शैली छनोट गर्दै (भाग २)

नमस्ते, habr। नयाँ पाठ्यक्रम स्ट्रिमको लागि नामांकन अहिले OTUS मा खुला छ "सफ्टवेयर आर्किटेक्ट"। पाठ्यक्रमको सुरुवातको पूर्वसन्ध्यामा, म तपाइँसँग मेरो मौलिक लेख साझा गर्न चाहन्छु।

परिचय

सूचना प्रणाली निर्माण गर्दा वास्तु शैलीको छनौट आधारभूत प्राविधिक निर्णयहरू मध्ये एक हो। लेखहरूको यस शृङ्खलामा, म अनुप्रयोगहरू निर्माण गर्नका लागि सबैभन्दा लोकप्रिय वास्तुकला शैलीहरूको विश्लेषण गर्न र कुन वास्तुकला शैली सबैभन्दा उपयुक्त हुन्छ भन्ने प्रश्नको जवाफ दिने प्रस्ताव गर्दछु। प्रस्तुतिको प्रक्रियामा, म एक तार्किक चेन कोर्ने प्रयास गर्नेछु जसले मोनोलिथ्सबाट माइक्रोसर्भिसेसहरूमा वास्तुकला शैलीहरूको विकासको व्याख्या गर्दछ।

बिटको इतिहास

यदि तपाईंले विकासकर्ताहरूलाई सोध्ने प्रयास गर्नुभयो भने: "हामीलाई किन माइक्रो सेवाहरू चाहिन्छ?", तपाईंले विभिन्न जवाफहरू पाउनुहुनेछ। तपाईंले सुन्नुहुनेछ कि माइक्रोसेवाहरूले स्केलेबिलिटी सुधार गर्दछ, कोड बुझ्न सजिलो बनाउँदछ, गल्ती सहिष्णुता सुधार गर्दछ, र कहिलेकाहीँ तपाईंले सुन्नुहुनेछ कि तिनीहरूले तपाईंलाई "तपाईंको कोड सफा गर्न" अनुमति दिन्छ। सूक्ष्म सेवाहरूको उदयको पछाडिको उद्देश्य बुझ्न इतिहासलाई हेरौं।

छोटकरीमा भन्नुपर्दा, हाम्रो हालको बुझाइमा माइक्रोसर्भिसेसहरू निम्नानुसार देखा पर्‍यो: 2011 मा, जेम्स लुईसले विभिन्न कम्पनीहरूको कामको विश्लेषण गर्दै, नयाँ "माइक्रो-एप" ढाँचाको उदयमा ध्यानाकर्षण गरायो, जसले SOA लाई बढावा दिने सन्दर्भमा अनुकूलित गर्यो। सेवाहरू। केही समय पछि, 2012 मा, वास्तुकला शिखर सम्मेलनमा, ढाँचालाई माइक्रोसर्भिस नाम दिइएको थियो। तसर्थ, माइक्रो सर्भिसेसको प्रारम्भिक लक्ष्य कुख्यात सुधार गर्नु थियो बजारको समय.

सन् २०१५ मा माइक्रो सर्भिसेसहरू हाइप वेभमा थिए। केही अध्ययनका अनुसार माइक्रोसर्भिसेजको विषयमा प्रतिवेदन नभई एउटा सम्मेलन पनि सम्पन्न भएको छैन । यसबाहेक, केही सम्मेलनहरू विशेष रूपमा माइक्रोसेवाहरूमा समर्पित थिए। आजकल, धेरै परियोजनाहरूले यो वास्तु शैली प्रयोग गर्न थाल्छन्, र यदि परियोजनाले धेरै लिगेसी कोड समावेश गर्दछ, तब माइक्रोसेवाहरूमा माइग्रेसन सम्भवतः सक्रिय रूपमा भइरहेको छ।

माथिका सबैको बावजुद, विकासकर्ताहरूको एकदम सानो संख्याले अझै पनि "माइक्रो सेवा" को अवधारणा परिभाषित गर्न सक्छ। तर हामी यसको बारेमा केहि पछि कुरा गर्नेछौं ...

मोनोलिथ

वास्तुशिल्प शैली जसले माइक्रोसर्भिसेसलाई विरोध गर्दछ मोनोलिथ (वा सबैमा एक)। मोनोलिथ भनेको के हो भनेर भन्नु सायद कुनै अर्थ छैन, त्यसैले म तुरुन्तै यस वास्तु शैलीको बेफाइदाहरू सूचीबद्ध गर्नेछु, जसले वास्तु शैलीहरूको थप विकास सुरु गर्‍यो: आकार, जडान, परिनियोजन, स्केलेबिलिटी, विश्वसनीयता र कठोरता। तल म प्रत्येक कमजोरीलाई अलग-अलग हेर्नको लागि प्रस्ताव गर्दछु।

आकार

मोनोलिथ धेरै ठूलो छ। र यो सामान्यतया एक धेरै ठूलो डाटाबेस संग संचार। एप्लिकेसन एक विकासकर्ताको लागि सबै बुझ्न धेरै ठूलो हुन्छ। यस कोडमा काम गर्न धेरै समय बिताउनेहरूले मात्र मोनोलिथसँग राम्रोसँग काम गर्न सक्छन्, जबकि शुरुआतीहरूले मोनोलिथ पत्ता लगाउन धेरै समय खर्च गर्नेछन् र तिनीहरूले यो पत्ता लगाउनेछन् भन्ने कुनै ग्यारेन्टी छैन। सामान्यतया, मोनोलिथसँग काम गर्दा, त्यहाँ सधैं केही "सशर्त" वरिष्ठ हुन्छन् जसले मोनोलिथलाई कम वा कम राम्ररी जान्दछन् र डेढ वर्ष भित्र अन्य नयाँ विकासकर्ताहरूको हात पिट्छन्। स्वाभाविक रूपमा, यस्तो सशर्त वरिष्ठ असफलताको एकल बिन्दु हो, र उनको प्रस्थान मोनोलिथ को मृत्यु हुन सक्छ।

जडान

मोनोलिथ "माटोको ठूलो बल" हो, जसमा परिवर्तनहरूले अप्रत्याशित परिणामहरू निम्त्याउन सक्छ। एक ठाउँमा परिवर्तन गरेर, तपाईंले अर्को ठाउँमा मोनोलिथलाई क्षति पुर्‍याउन सक्नुहुन्छ (त्यस्तै "तपाईंले आफ्नो कान खरानी गर्नुभयो, *@ खस्नुभयो")। यो तथ्यको कारण हो कि मोनोलिथमा कम्पोनेन्टहरू धेरै जटिल र, सबैभन्दा महत्त्वपूर्ण, गैर-स्पष्ट सम्बन्धहरू छन्।

तैनाती

एक मोनोलिथ तैनाती, यसको घटकहरू बीचको जटिल सम्बन्धको कारण, यसको आफ्नै अनुष्ठान संग एक लामो प्रक्रिया हो। यस्तो अनुष्ठान सामान्यतया पूर्ण रूपमा मानकीकृत हुँदैन र "मौखिक रूपमा" पारित गरिन्छ।

स्केलेबिलिटी

मोनोलिथ मोड्युलहरूमा विरोधाभासी स्रोत आवश्यकताहरू हुन सक्छन्, हार्डवेयरको सन्दर्भमा सम्झौता गर्न आवश्यक छ। कल्पना गर्नुहोस् कि तपाईंसँग सेवाहरू A र B सम्मिलित एक मोनोलिथ छ। सेवा A ले हार्ड ड्राइभको आकारमा माग गरिरहेको छ, र सेवा B ले RAM मा माग गरिरहेको छ। यस अवस्थामा, या त मोनोलिथ स्थापना भएको मेसिनले दुबै सेवाहरूको आवश्यकताहरूलाई समर्थन गर्नुपर्छ, वा तपाईंले म्यानुअल रूपमा, कृत्रिम रूपमा सेवाहरू मध्ये कुनै एकलाई असक्षम गर्नुपर्नेछ।

अर्को उदाहरण (अधिक क्लासिक): सेवा A सेवा B भन्दा धेरै लोकप्रिय छ, त्यसैले तपाईं त्यहाँ १०० सेवाहरू A, र 100 सेवाहरू B होस् भन्ने चाहनुहुन्छ। फेरि, दुई विकल्पहरू: या त हामी १०० पूर्ण मोनोलिथहरू प्रयोग गर्छौं, वा केहीमा सेवाहरू B म्यानुअल रूपमा असक्षम गर्नुपर्नेछ।

विश्वसनीयता

सबै सेवाहरू सँगै अवस्थित भएकाले, यदि मोनोलिथ खस्यो भने, सबै सेवाहरू एकैचोटि खस्छन्। वास्तवमा, यो यति नराम्रो नहुन सक्छ, कम्तिमा त्यहाँ वितरित प्रणालीमा कुनै आंशिक विफलताहरू हुनेछैन, तर अर्कोतर्फ, 0.001% प्रयोगकर्ताहरू द्वारा प्रयोग गरिएको कार्यक्षमतामा बगको कारणले, तपाईंले सबै प्रयोगकर्ताहरू गुमाउन सक्नुहुन्छ। तपाईको प्रणालीको।

जडता

मोनोलिथको आकारको कारण, नयाँ प्रविधिहरूमा स्विच गर्न गाह्रो छ। फलस्वरूप, त्यो एकदमै सशर्त वरिष्ठलाई कायम राख्नु छुट्टै काम जस्तो देखिन्छ। परियोजनाको सुरुमा छनोट गरिएको टेक्नोलोजी स्ट्याक उत्पादनको विकासमा बाधा पुर्‍याउने ब्लक बन्न सक्छ।

निष्कर्षमा

अर्को पटक हामी कम्पोनेन्टहरू र SOA मा गएर मानिसहरूले यी समस्याहरूलाई कसरी समाधान गर्ने प्रयास गरेका छन् भनेर कुरा गर्नेछौं।

थप पढ्नुहोस्:

• किन SQL सर्भरले ORDER BY बिना परिणामहरू क्रमबद्ध गर्न ग्यारेन्टी गर्दैन
• विकासकर्ताहरू र प्रशासकहरूको लागि वास्तुकला: कसलाई कस्तो सीप चाहिन्छ?

स्रोत: www.habr.com