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

नमस्ते, Habr। आज मैले पाठ्यक्रमको नयाँ स्ट्रिमको सुरुवातको लागि विशेष गरी लेखेका प्रकाशनहरूको श्रृंखला जारी राख्छु। "सफ्टवेयर आर्किटेक्ट".

परिचय

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

В अन्तिम पटक हामीले मोनोलिथसँग व्यवहार गर्यौं र निष्कर्षमा पुग्यौं कि मोनोलिथमा धेरै समस्याहरू छन्: साइज, कनेक्टिभिटी, डिप्लोइमेन्ट, स्केलेबिलिटी, विश्वसनीयता र कठोरता।

यस पटक म मोड्युल/पुस्तकालयहरू (कम्पोनेन्ट-उन्मुख वास्तुकला) वा सेवाहरू (सेवा-उन्मुख वास्तुकला) को एक सेटको रूपमा प्रणाली व्यवस्थित गर्ने सम्भावनाहरूको बारेमा कुरा गर्न प्रस्ताव गर्दछु।

कम्पोनेन्ट उन्मुख वास्तुकला

कम्पोनेन्ट-उन्मुख वास्तुकलाले कम्पोनेन्टहरूको सेटको रूपमा प्रणाली कार्यान्वयन गर्ने समावेश गर्दछ जुन दुबै वर्तमान र भविष्यका परियोजनाहरूमा प्रयोग गर्न सकिन्छ। प्रणालीलाई घटकहरूमा विभाजन गर्दा, निम्नलाई ध्यानमा राखिन्छ: तिनीहरूको पुन: प्रयोज्यता, तिनीहरूको प्रतिस्थापन योग्यता, सन्दर्भ स्वतन्त्रता, एक्स्टेन्सिबिलिटी, इन्क्याप्सुलेशन र स्वतन्त्रता।

कम्पोनेन्टहरूको उचित प्रयोगको साथ, "फोहोरको ठूलो बल" (ठूलो साइज + उच्च युग्मन) को समस्या हल हुन्छ, र घटकहरू आफैं दुवै विधानसभा एकाइहरू (मोड्युलहरू, पुस्तकालयहरू) र तैनाती एकाइहरू (सेवाहरू) हुन सक्छन्। डिप्लोयमेन्ट इकाइहरू सधैं चलिरहेको प्रक्रियामा म्याप हुँदैनन्: उदाहरणका लागि, वेब अनुप्रयोग र डाटाबेस सँगै प्रयोग गरिन्छ।

प्रायः, मोनोलिथहरू मोड्युलहरूको सेटको रूपमा विकसित हुन्छन्। यो दृष्टिकोणले स्वतन्त्र विकासतर्फ डोर्‍याउँछ, तर स्वतन्त्र स्केलिंग र डिप्लोइमेन्ट, गल्ती सहिष्णुता र समग्र टेक्नोलोजी स्ट्याकबाट स्वतन्त्रताको समस्या रहन्छ। यही कारणले गर्दा मोड्युल आंशिक रूपमा स्वतन्त्र घटक हो।

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

"आदर्श" मोनोलिथ तार्किक रूपमा अलग गरिएको मोड्युलहरूको सेट हो, जसमध्ये प्रत्येकले आफ्नै डाटाबेसमा हेर्छ।

सेवा उन्मुख वास्तुकला

यदि प्रणालीलाई सेवाहरूको सेटको रूपमा व्यवस्थित गरिनु पर्छ भने, हामी सेवा-उन्मुख वास्तुकलाको बारेमा कुरा गर्दैछौं। यसको सिद्धान्तहरू प्रयोगकर्ता-केन्द्रित अनुप्रयोग अन्तरसञ्चालन, व्यापार सेवा पुन: प्रयोग, प्रविधि स्ट्याक स्वतन्त्रता, र स्वायत्तता (स्वतन्त्र विकास, स्केलेबिलिटी, र तैनाती) हुन्।

सेवा-उन्मुख वास्तुकला (SOA = सेवा उन्मुख वास्तुकला) ले एक मोनोलिथका सबै पहिचान गरिएका समस्याहरू समाधान गर्दछ: परिवर्तन हुँदा केवल एउटा सेवा प्रभावित हुन्छ, र राम्रो-परिभाषित API ले कम्पोनेन्टहरूको राम्रो इन्क्याप्सुलेशनलाई समर्थन गर्दछ।

तर सबै कुरा यति सहज छैन: SOA ले नयाँ समस्याहरू सिर्जना गर्दछ। रिमोट कलहरू स्थानीय कलहरू भन्दा महँगो छन्, र कम्पोनेन्टहरू बीचको जिम्मेवारीहरू पुन: वितरण महत्त्वपूर्ण रूपमा महँगो भएको छ।

वैसे, स्वतन्त्र तैनाती को संभावना सेवा को एक धेरै महत्त्वपूर्ण विशेषता हो। यदि सेवाहरू सँगै तैनाथ गरिनु पर्छ वा, थप रूपमा, निश्चित अनुक्रममा, तब प्रणालीलाई सेवा-उन्मुख मान्न सकिँदैन। यस अवस्थामा, तिनीहरू एक वितरित मोनोलिथको बारेमा कुरा गर्छन् (एसओएको दृष्टिकोणबाट मात्र होइन, तर माइक्रोसर्भिस आर्किटेक्चरको दृष्टिकोणबाट पनि विरोधी ढाँचा मानिन्छ)।

सेवा उन्मुख वास्तुकला वास्तुकला समुदाय र विक्रेताहरु द्वारा राम्रोसँग समर्थित छ। यसले धेरै पाठ्यक्रमहरू र प्रमाणपत्रहरू, राम्रोसँग विकसित ढाँचाहरूको उपस्थितिलाई संकेत गर्दछ। पछिल्लो समावेश, उदाहरण को लागी, प्रसिद्ध उद्यम सेवा बस (ESB = उद्यम सेवा बस)। एकै समयमा, ESB विक्रेताहरूबाट झोला हो; यो आवश्यक छैन कि SOA मा प्रयोग गरिन्छ।

सेवा-उन्मुख वास्तुकलाको लोकप्रियता 2008 को वरिपरि शिखरमा पुग्यो, त्यसपछि यो घट्न थाल्यो, जुन माइक्रोसर्भिसेस (~ 2015) को आगमन पछि उल्लेखनीय रूपमा थप नाटकीय भयो।

निष्कर्षमा

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

स्रोत: www.habr.com