सफ्टवेयर प्रणालीहरू डिजाइन गर्दा जटिलतासँग कसरी व्यवहार गर्ने

यो सबै के हो?

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

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

यस लेखमा, म सफ्टवेयर प्रोग्रामहरू सिर्जना गर्दा मैले सामना गरेका केही समस्याहरूसँग मेरो अनुभवहरू साझा गर्नेछु।

क्रस कटिङ चिन्ता के हो?

यदि हामीले विकिपिडियामा हेर्‍यौं भने, हामीले निम्न परिभाषा भेट्टाउनेछौं

पक्ष-उन्मुख सफ्टवेयर विकासमा, क्रस-कटिङ सरोकारहरू कार्यक्रमका पक्षहरू हुन् जसले धेरै मोड्युलहरूलाई प्रभाव पार्छ, तिनीहरूमध्ये कुनैमा पनि समावेश हुने सम्भावना बिना। यी चिन्ताहरू प्रायः डिजाइन र कार्यान्वयन दुवैमा बाँकी प्रणालीबाट सफा रूपमा विघटन गर्न सकिँदैन, र या त स्क्याटरिङ (कोड डुप्लिकेशन), ट्याङ्लिङ (प्रणालीहरू बीचको महत्त्वपूर्ण निर्भरता), वा दुवैको परिणाम हुन सक्छ।

यसले यो के हो भनेर वर्णन गर्दछ, तर म यसलाई थोरै विस्तार र सरल बनाउन चाहन्छु:

क्रस-काटिङ चिन्ता भनेको प्रणाली/संगठनको अवधारणा वा घटक हो जसले अन्य धेरै भागहरूलाई असर गर्छ (वा 'काट्ने')।

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

कोड स्तरमा, क्रस-कटिङ सरोकारहरू प्रायः एस्पेक्ट-ओरिएंटेड प्रोग्रामिङ (AOP) जस्ता प्रविधिहरू प्रयोग गरेर लागू गरिन्छ, जहाँ यी चिन्ताहरूलाई अलग-अलग कम्पोनेन्टहरूमा मोड्युलराइज गरिएको हुन्छ जुन सम्पूर्ण अनुप्रयोगमा लागू गर्न सकिन्छ। यसले व्यापार तर्कलाई यी चिन्ताहरूबाट अलग राख्छ, कोडलाई थप पढ्न योग्य र मर्मत योग्य बनाउँछ।

पक्ष वर्गीकरण

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

त्यसोभए, म पक्षहरूलाई म्याक्रो र माइक्रोमा विभाजन गर्न जाँदैछु।

म्याक्रो पक्षबाट मेरो मतलब मुख्यतया हामीले छनौट गरिएको प्रणाली वास्तुकला र यसको डिजाइन (मोनोलिथिक, माइक्रोसर्भिसेस, सेवा-उन्मुख वास्तुकला), टेक्नोलोजी स्ट्याक, संगठन संरचना, आदि जस्ता सम्पूर्ण प्रणालीको लागि पालना गर्ने विचारहरू भन्ने हो। म्याक्रो पक्षहरू मुख्यतया रणनीतिक र उच्च-स्तरसँग सम्बन्धित छन्। निर्णयहरू।

यस बीचमा, माइक्रो पक्ष कोड स्तर र विकासको धेरै नजिक छ। उदाहरण को लागी, कुन फ्रेमवर्क डाटाबेस संग अन्तरक्रिया को लागी प्रयोग गरिन्छ, फोल्डरहरु र वर्गहरु को परियोजना संरचना, वा विशिष्ट वस्तु डिजाइन ढाँचाहरु।

यद्यपि यो वर्गीकरण आदर्श होइन, यसले सम्भावित समस्याहरू र हामीले तिनीहरूमा लागू गर्ने समाधानहरूको महत्त्व र प्रभावहरूको समझलाई संरचना गर्न मद्दत गर्छ।

यस लेखमा, मेरो प्राथमिक फोकस म्याक्रो पक्षहरूमा हुनेछ।

म्याक्रो पक्षहरू

संगठन संरचना

जब मैले भर्खरै सफ्टवेयर वास्तुकलाको बारेमा जान्न थालें, मैले Conway को कानून र संगठनात्मक संरचनामा यसको प्रभावको बारेमा धेरै रोचक लेखहरू पढें। विशेष गरी यो एक । तसर्थ, यो कानूनले भन्छ

प्रणाली डिजाइन गर्ने कुनै पनि संगठनले (व्यापक रूपमा परिभाषित) डिजाइन उत्पादन गर्नेछ जसको संरचना संगठनको सञ्चार संरचनाको प्रतिलिपि हो।

मैले सधैं विश्वास गरेको छु कि यो अवधारणा वास्तवमा धेरै सार्वभौमिक छ र सुनौलो नियम को प्रतिनिधित्व गर्दछ।

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

कन्वेको कानूनमा फर्केर, मैले यससँग धेरै मुद्दाहरू फेला पारेको छु।

मैले कन्वेको कानूनसँग सामना गरेको पहिलो मुद्दा , जसले प्रणाली डिजाइनले संगठनात्मक संरचनालाई प्रतिबिम्बित गर्छ भन्ने सुझाव दिन्छ, जटिल र व्यापक बाउन्डेड कन्टेक्स्टहरू गठन गर्ने सम्भाव्यता हो। यो जटिलता तब उत्पन्न हुन्छ जब संगठनात्मक संरचना डोमेन सीमाहरूसँग पङ्क्तिबद्ध हुँदैन, जसले बाउन्डेड कन्टेक्स्टहरू निम्त्याउँछ जुन धेरै अन्तरनिर्भर हुन्छन् र जानकारीले भरिएका हुन्छन्। यसले विकास टोलीको लागि बारम्बार सन्दर्भ-स्विच गर्न नेतृत्व गर्दछ।

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

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

माटोको ठूलो बल

यो ढाँचा वा "एन्टि-प्याटर्न" ले कुनै पनि वास्तुकला बिना प्रणाली निर्माण गर्दछ। त्यहाँ कुनै नियमहरू छैनन्, कुनै सीमाहरू छैनन्, र अपरिहार्य बढ्दो जटिलतालाई कसरी नियन्त्रण गर्ने भन्ने बारे कुनै रणनीति छैन। सफ्टवेयर प्रणाली निर्माणको यात्रामा जटिलता सबैभन्दा ठूलो शत्रु हो।

यस प्रकारको प्रणाली निर्माण गर्नबाट बच्न, हामीले विशेष नियम र बाधाहरूको पालना गर्न आवश्यक छ।

प्रणाली वास्तुकला

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

सफ्टवेयर आर्किटेक्चर निर्णय र छनोटहरूको बारेमा हो जुन तपाईंले हरेक दिन गर्नुहुन्छ जसले निर्मित प्रणालीलाई असर गर्छ।

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

सफ्टवेयर आर्किटेक्चर स्टाइल सिद्धान्त र ढाँचाहरूको सेट हो जसले सफ्टवेयर कसरी निर्माण गर्ने भनेर निर्दिष्ट गर्दछ।

नियोजित वास्तुकलाको विभिन्न पक्षहरूमा केन्द्रित धेरै फरक वास्तुकला शैलीहरू छन्, र ती मध्ये धेरैलाई एकैचोटि लागू गर्नु सामान्य अवस्था हो।

उदाहरणका लागि, जस्तै:

1. मोनोलिथिक वास्तुकला

2. डोमेन-संचालित डिजाइन

3. कम्पोनेन्ट आधारित

4. सूक्ष्म सेवाहरू

5. पाइप र फिल्टर

6. घटना-संचालित

7. माइक्रोकर्नेल

8. सेवामुखी

   
   

र यस्तै…

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

यद्यपि, जटिल प्रणालीहरूलाई अक्सर जटिल र व्यापक वास्तुकला चाहिन्छ, जुन अपरिहार्य छ।

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

1. लगभग सधैं मोनोलिथिक वास्तुकला शैली संग सुरु हुन्छ किनभने यसले वितरित प्रणालीहरूको प्रकृतिको कारण उत्पन्न हुने अधिकांश समस्याहरूलाई हटाउँछ। यसले स्पष्ट सीमाहरूका साथ कम्पोनेन्टहरू निर्माणमा ध्यान केन्द्रित गर्न मोड्युलर मोनोलिथलाई पछ्याउन पनि अर्थ दिन्छ। कम्पोनेन्ट-आधारित दृष्टिकोण लागू गर्नाले उनीहरूलाई घटनाहरू प्रयोग गरेर एकअर्कासँग कुराकानी गर्न मद्दत गर्न सक्छ, तर प्रत्यक्ष कलहरू (उर्फ RPC) सुरुमा चीजहरू सरल बनाउँछ। यद्यपि, कम्पोनेन्टहरू बीचको निर्भरताहरू ट्र्याक गर्न महत्त्वपूर्ण छ किनकि यदि कम्पोनेन्ट A लाई कम्पोनेन्ट B बारे धेरै थाहा छ, सायद, यसले तिनीहरूलाई एकमा मर्ज गर्नको लागि अर्थ दिन्छ।
2. जब तपाइँ आफ्नो विकास र प्रणाली मापन गर्न आवश्यक पर्दा स्थितिको नजिक आउनुहुन्छ, तपाइँ बिस्तारै कम्पोनेन्टहरू निकाल्नको लागि Stangler ढाँचा पछ्याउन विचार गर्न सक्नुहुन्छ जुन स्वतन्त्र रूपमा तैनात गर्न वा विशेष आवश्यकताहरूको साथ मापन गर्न आवश्यक छ।
3. अब, यदि तपाइँसँग भविष्यको स्पष्ट दृष्टि छ, जुन अलि अविश्वसनीय भाग्य हो, तपाइँ इच्छित वास्तुकलामा निर्णय गर्न सक्नुहुन्छ। यस क्षणमा, तपाईं अर्केस्ट्रेशन र कोरियोग्राफी दृष्टिकोणहरू लागू गरेर, स्वतन्त्र स्केल राइट र रिड अपरेसनहरूको लागि CQRS ढाँचा समावेश गरेर, वा तपाईंको आवश्यकताहरू फिट भएमा मोनोलिथिक आर्किटेक्चरसँग टाँसिने निर्णय गरेर पनि माइक्रोसर्भिसेस आर्किटेक्चरतर्फ जाने निर्णय गर्न सक्नुहुन्छ।

DAU (दैनिक सक्रिय प्रयोगकर्ताहरू), MAU (मासिक सक्रिय प्रयोगकर्ताहरू), RPC (प्रति सेकेन्ड अनुरोध), र TPC (लेनदेन प्रति सेकेन्ड) जस्ता संख्याहरू र मेट्रिकहरू बुझ्न पनि महत्त्वपूर्ण छ किनभने यसले तपाईंलाई छनौट गर्न मद्दत गर्न सक्छ किनभने वास्तुकलाको लागि। 100 सक्रिय प्रयोगकर्ताहरू र 100 मिलियन सक्रिय प्रयोगकर्ताहरू फरक छन्।

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

टेक्नोलोजी स्ट्याक चयन

टेक्नोलोजी स्ट्याक चयन गर्नु पनि एक म्याक्रो-स्तर निर्णय हो किनभने यसले भर्ती, प्रणाली प्राकृतिक विकास परिप्रेक्ष्य, स्केलेबिलिटी, र प्रणाली प्रदर्शनलाई प्रभाव पार्छ।

यो टेक्नोलोजी स्ट्याक छनौट गर्नका लागि आधारभूत विचारहरूको सूची हो:

• परियोजना आवश्यकता र जटिलता। उदाहरणका लागि, यदि तपाइँका विकासकर्ताहरूसँग यसको अनुभव छ भने ब्लेजर फ्रेमवर्कसँग एक साधारण वेब अनुप्रयोग निर्माण गर्न सकिन्छ, तर WebAssembly को परिपक्वताको कमीको कारण, दीर्घकालीन सफलताको लागि प्रतिक्रिया र टाइपस्क्रिप्ट छनौट गर्नु राम्रो निर्णय हुन सक्छ।
• स्केलेबिलिटी र प्रदर्शन आवश्यकताहरू। यदि तपाईले ठूलो मात्रामा ट्राफिक प्राप्त गर्ने अनुमान गर्नुहुन्छ भने, ASP.NET Core on Django को लागि छनौट गर्नु एक बुद्धिमानी विकल्प हुन सक्छ यसको समवर्ती अनुरोधहरू ह्यान्डल गर्नमा उत्कृष्ट प्रदर्शनको कारण। यद्यपि, यो निर्णय तपाईले अपेक्षा गर्नुहुने ट्राफिकको मापनमा निर्भर गर्दछ। यदि तपाईंलाई कम विलम्बता संग सम्भावित अरबौं अनुरोधहरू व्यवस्थापन गर्न आवश्यक छ भने, फोहोर सङ्कलनको उपस्थिति चुनौती हुन सक्छ।
• भर्ती, विकास समय, र लागत। धेरै जसो अवस्थामा, यी कारकहरू हुन् जुन हामीले हेरचाह गर्न आवश्यक छ। बजारमा समय, मर्मतसम्भार लागत, र हायरिङ स्थिरताले तपाईंको व्यवसायको आवश्यकतालाई कुनै अवरोध बिना ड्राइभ गर्छ।
• टोली विशेषज्ञता र संसाधन। तपाईंको विकास टोलीको कौशल सेट एक महत्वपूर्ण कारक हो। नयाँ स्ट्याक सिक्नमा लगानी गर्ने बलियो कारण नभएसम्म तपाइँको टोली पहिले नै परिचित भएको प्रविधिहरू प्रयोग गर्न सामान्यतया बढी प्रभावकारी हुन्छ।
• परिपक्वता। एक बलियो समुदाय र पुस्तकालय र उपकरणहरूको समृद्ध इकोसिस्टमले विकास प्रक्रियालाई धेरै सहज बनाउन सक्छ। लोकप्रिय प्रविधिहरूसँग प्राय: राम्रो समुदाय समर्थन हुन्छ, जुन समस्याहरू समाधान गर्न र स्रोतहरू खोज्नको लागि अमूल्य हुन सक्छ। यसरी, तपाईं स्रोतहरू बचत गर्न सक्नुहुन्छ र मुख्य रूपमा उत्पादनमा ध्यान केन्द्रित गर्न सक्नुहुन्छ।
• दीर्घकालीन रखरखाव र समर्थन। प्रविधिको दीर्घकालीन व्यवहार्यतालाई विचार गर्नुहोस्। व्यापक रूपमा अपनाइएका र समर्थित प्रविधिहरू अप्रचलित हुने सम्भावना कम हुन्छ र सामान्यतया नियमित अपडेट र सुधारहरू प्राप्त हुन्छन्।

धेरै टेक्नोलोजी स्ट्याकहरूले कसरी व्यापार वृद्धिलाई असर गर्न सक्छ?

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

तर विशेष समस्याको लागि उत्तम उपकरण चयन गर्ने सिद्धान्तको बारेमा के हो?

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

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

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

असफलताको एकल बिन्दु (SPOF)

विफलताको एकल बिन्दु (SPOF) ले प्रणालीको कुनै पनि भागलाई बुझाउँछ, यदि यो असफल भयो भने, सम्पूर्ण प्रणालीले काम गर्न रोक्न सक्छ। उच्च उपलब्धता चाहिने कुनै पनि प्रणालीको लागि सबै तहमा SPOFs हटाउनु महत्त्वपूर्ण छ। ज्ञान, कर्मचारी, प्रणाली कम्पोनेन्टहरू, क्लाउड प्रदायकहरू, र इन्टरनेट केबलहरू सहित सबै कुरा असफल हुन सक्छ।

त्यहाँ धेरै आधारभूत प्रविधिहरू छन् जुन हामीले असफलताको एकल बिन्दुहरू हटाउन लागू गर्न सक्छौं:

1. अनावश्यकता। महत्वपूर्ण घटकहरूको लागि रिडन्डन्सी लागू गर्नुहोस्। यसको अर्थ ब्याकअप कम्पोनेन्टहरू हुनु हो जुन प्राथमिक कम्पोनेन्ट असफल भएमा लिन सक्छ। रिडन्डन्सी प्रणालीको विभिन्न तहहरूमा लागू गर्न सकिन्छ, हार्डवेयर (सर्भरहरू, डिस्कहरू), नेटवर्किङ (लिङ्कहरू, स्विचहरू), र सफ्टवेयर (डेटाबेसहरू, अनुप्रयोग सर्भरहरू) सहित। यदि तपाइँ एक क्लाउड प्रदायकमा सबै चीजहरू होस्ट गर्दै हुनुहुन्छ र त्यहाँ ब्याकअपहरू पनि राख्दै हुनुहुन्छ भने, प्रकोपको अवस्थामा तपाइँको हराएको लागत कम गर्न अर्कोमा नियमित अतिरिक्त ब्याकअप निर्माण गर्ने विचार गर्नुहोस्।
2. डाटा केन्द्रहरू। तपाईको प्रणालीलाई धेरै भौतिक स्थानहरूमा वितरण गर्नुहोस्, जस्तै डेटा केन्द्रहरू वा क्लाउड क्षेत्रहरू। यो दृष्टिकोणले तपाईंको प्रणालीलाई स्थान-विशिष्ट विफलताहरू जस्तै पावर आउटेज वा प्राकृतिक प्रकोपहरू विरुद्ध सुरक्षित गर्दछ।
3. फेलओभर। तपाईंका सबै कम्पोनेन्टहरू (DNS, CDN, लोड ब्यालेन्सरहरू, Kubernetes, API गेटवेहरू, र डाटाबेसहरू) को लागि फेलओभर दृष्टिकोण लागू गर्नुहोस्। समस्याहरू अप्रत्याशित रूपमा उत्पन्न हुनसक्ने हुनाले, कुनै पनि कम्पोनेन्टलाई यसको क्लोनसँग तुरुन्तै आवश्यकता अनुसार बदल्नको लागि ब्याकअप योजना हुनु महत्त्वपूर्ण छ।
4. उच्च उपलब्धता सेवाहरू। निश्चित गर्नुहोस् कि तपाइँका सेवाहरू तेर्सो रूपमा मापनयोग्य र सुरुदेखि नै उच्च रूपमा उपलब्ध हुनका लागि निम्न सिद्धान्तहरू पालना गरी निर्माण गरिएको छ:
   • सेवा राज्यविहीनता अभ्यास गर्नुहोस् र इन-मेमोरी क्यासहरूमा प्रयोगकर्ता सत्रहरू भण्डारण गर्नबाट जोगिन। यसको सट्टा, वितरित क्यास प्रणाली प्रयोग गर्नुहोस्, जस्तै Redis।
   • तर्क विकास गर्दा सन्देश उपभोगको कालानुक्रमिक क्रममा निर्भरताबाट बच्नुहोस्।
   • API उपभोक्ताहरूलाई अवरुद्ध हुनबाट रोक्नको लागि ब्रेकिङ परिवर्तनहरू कम गर्नुहोस्। जहाँ सम्भव छ, पछाडि-कम्प्याटिबल परिवर्तनहरूको लागि रोज्नुहोस्। साथै, कहिलेकाहीँ लागतलाई विचार गर्नुहोस्, ब्रेकिङ परिवर्तन लागू गर्दा बढी लागत-प्रभावी हुन सक्छ।
   • परिनियोजन पाइपलाइनमा माइग्रेसन कार्यान्वयन समावेश गर्नुहोस्।
   • समवर्ती अनुरोधहरू ह्यान्डल गर्न एक रणनीति स्थापना गर्नुहोस्।
   • सेवाको खोज, अनुगमन, र लगिङलाई विश्वसनीयता र पर्यवेक्षणीयता बढाउन कार्यान्वयन गर्नुहोस्।
   • सञ्जाल विफलताहरू अपरिहार्य छन् भनेर स्वीकार गर्दै, कमजोर हुन व्यापार तर्कको विकास गर्नुहोस्।
5. निर्भरता समीक्षा। नियमित रूपमा समीक्षा गर्नुहोस् र बाह्य निर्भरताहरू कम गर्नुहोस्। प्रत्येक बाह्य निर्भरताले सम्भावित SPOFs परिचय गराउन सक्छ, त्यसैले यी जोखिमहरू बुझ्न र कम गर्न आवश्यक छ।
6. नियमित ज्ञान आदान प्रदान। आफ्नो संगठन भित्र ज्ञान फैलाउने महत्वलाई कहिल्यै नबिर्सनुहोस्। मानिसहरू अप्रत्याशित हुन सक्छन्, र एकल व्यक्तिमा भर पर्नु जोखिमपूर्ण छ। टोलीका सदस्यहरूलाई कागजातहरू मार्फत आफ्नो ज्ञान डिजिटलाइज गर्न प्रोत्साहन दिनुहोस्। जे होस्, अति-कागजातिङमा ध्यान दिनुहोस्। यस प्रक्रियालाई सरल बनाउन विभिन्न AI उपकरणहरू प्रयोग गर्नुहोस्।

निष्कर्ष

यस लेखमा, हामीले धेरै प्रमुख म्याक्रो पक्षहरू र तिनीहरूको जटिलतासँग कसरी व्यवहार गर्न सक्छौं भनेर कभर गर्यौं।

पढ्नु भएकोमा धन्यवाद! अर्को पटक भेटौंला!