NDC लन्डन सम्मेलन। माइक्रो सेवा प्रकोप रोकथाम। भाग 1

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

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

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

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

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

प्रारम्भिक डिजाइन धेरै राम्रो देखिन्थ्यो र शीर्ष-स्तर साइट bell.com र व्यक्तिगत अनुप्रयोगहरूको लागि धेरै उप डोमेनहरू समावेश गरिएको थियो: catalog.bell.com, accounts.bell.com, orders.bell.com, उत्पादन खोज search.bell। com। प्रत्येक सबडोमेनले ASP.Net 1.0 फ्रेमवर्क र यसको आफ्नै डाटाबेसहरू प्रयोग गर्यो, र तिनीहरू सबैले प्रणाली ब्याकइन्डमा कुरा गरे। जे होस्, सबै आदेशहरू एकल विशाल मेनफ्रेम भित्र प्रशोधन र कार्यान्वयन गर्न जारी रह्यो, जसमा सबै फोहोर रह्यो, तर अगाडिको छेउमा व्यक्तिगत अनुप्रयोगहरू र छुट्टै डाटाबेसहरूको साथ छुट्टै वेबसाइटहरू थिए।

त्यसैले प्रणालीको डिजाइन व्यवस्थित र तार्किक देखिन्थ्यो, तर वास्तविक प्रणाली अर्को स्लाइडमा देखाइएको थियो।

सबै तत्वहरूले एक-अर्कालाई कलहरू सम्बोधन गरे, पहुँच गरिएका एपीआईहरू, इम्बेडेड तेस्रो-पक्ष dlls, र यस्तै। यो प्रायः भयो कि संस्करण नियन्त्रण प्रणालीहरूले अरू कसैको कोड समात्नेछ, यसलाई परियोजना भित्र धकेल्नेछ, र त्यसपछि सबै बिग्रन्छ। MS SQL Server 2005 ले लिङ्क सर्भरको अवधारणा प्रयोग गर्‍यो, र यद्यपि मैले स्लाइडमा तीरहरू देखाएको छैन, प्रत्येक डाटाबेसले पनि एकअर्कासँग कुरा गर्यो, किनभने धेरै डाटाबेसहरूबाट प्राप्त डाटामा आधारित तालिकाहरू निर्माण गर्नमा केहि गलत छैन।

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

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

अवस्थित अनुप्रयोग 15 वर्षको लागि उत्पादनमा थियो, जुन ASP.Net-आधारित अनुप्रयोगहरूको लागि रेकर्ड हो। सेवाले संसारभरबाट अर्डरहरू स्वीकार गर्यो, र यस एकल अनुप्रयोगबाट वार्षिक राजस्व एक अरब डलर पुग्यो। लाभ को एक महत्वपूर्ण भाग bell.com वेबसाइट द्वारा उत्पन्न भएको थियो। ब्ल्याक फ्राइडेमा, साइट मार्फत राखिएको अर्डरको संख्या लाखौं पुग्यो। यद्यपि, अवस्थित वास्तुकलाले कुनै पनि विकासलाई अनुमति दिँदैन, किनकि प्रणाली तत्वहरूको कठोर अन्तरसम्बन्धले व्यावहारिक रूपमा सेवामा कुनै परिवर्तन गर्न अनुमति दिँदैन।

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

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

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

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

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

त्यस पछि, वर्तमान अवस्थालाई गहन विश्लेषणको आवश्यकता छ भनी उनीहरूलाई थाहा भयो, र उनीहरूले हामीलाई आमन्त्रित गरे। हामीले पत्ता लगाएको पहिलो कुरा यो थियो कि सबै 18 महिनाको विकासको दौडान, एउटा पनि वास्तविक "माइक्रो" सिर्जना गरिएको थिएन - सबै कुरा मात्र ठूलो भयो। यसपछि, हामीले प्रकोपको कारण बुझ्नको लागि पोस्टमार्टम लेख्न थाल्यौं, जसलाई "रेट्रोस्पेक्टिभ" वा "साड रिट्रोस्पेक्टिभ" पनि भनिन्छ, जसलाई "ब्लेम स्ट्रम" पनि भनिन्छ, जसलाई "ब्रेन स्ट्रम" पनि भनिन्छ।

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

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

हामीले केही गणित गर्यौं। प्रत्येक API कलमा 150 ms भन्दा बढीको SLA र 99,9% अपटाइम थियो। एउटा अनुरोधले 200 फरक कलहरू निम्त्यायो, र उत्तम अवस्थामा, पृष्ठ 200 x 150 ms = 30 सेकेन्डमा देखाउन सकिन्छ। स्वाभाविक रूपमा, यो राम्रो थिएन। 99,9 द्वारा 200% अपटाइम गुणन गर्दै, हामीले 0% उपलब्धता पायौं। यो बाहिर जान्छ कि यो वास्तुकला धेरै सुरु देखि विफलता को लागि बर्बाद भएको थियो।

हामीले विकासकर्ताहरूलाई सोध्यौं कि तिनीहरूले 18 महिनाको काम पछि यो समस्या कसरी पहिचान गर्न सकेनन्? यो बाहिरियो कि तिनीहरूले चलाएको कोडको लागि मात्र SLA गणना गरे, तर यदि तिनीहरूको सेवाले अर्को सेवा बोलाए, तिनीहरूले त्यो समय तिनीहरूको SLA मा गणना गरेनन्। एक प्रक्रिया भित्र सुरु गरिएको सबै कुरा 150 ms को मूल्यमा पालना गरियो, तर अन्य सेवा प्रक्रियाहरूमा पहुँचले कुल ढिलाइ धेरै पटक बढ्यो। पहिलो पाठ सिकाइएको थियो: "के तपाइँ तपाइँको SLA को नियन्त्रणमा हुनुहुन्छ, वा SLA तपाइँको नियन्त्रणमा छ?" हाम्रो मामला मा, यो पछिल्लो थियो।

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

यदि तपाइँ अघिल्लो चित्रमा सेवा सीमाहरू हेर्नुभयो भने, तपाइँ देख्न सक्नुहुन्छ कि ती सबै गलत छन्। त्यहाँ धेरै स्रोतहरू छन् जसले सेवा सीमाहरू कसरी परिभाषित गर्ने भनेर सल्लाह दिन्छ, र धेरै जसो गलत गर्छ, जस्तै अर्को स्लाइडमा Microsoft।

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

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

निम्न चित्रले देखाउँछ कि कसरी MS ले मोनोलिथबाट माइक्रोसर्भिसेसमा सर्ने सिफारिस गर्दछ - प्रत्येक मुख्य सेवाहरूलाई अलग-अलग माइक्रोसर्भिसेसमा विभाजित गर्नुहोस्। यो योजनाको कार्यान्वयनको क्रममा बेलले गल्ती गर्यो।

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

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

तिनीहरू विश्वास गर्थे कि माइक्रोसर्भिसेसहरूमा सर्नु तिनीहरूको आन्तरिक एन-टियर भौतिक तह पूर्वाधार लिनु र यसमा डकर टाँस्नु जत्तिकै सजिलो थियो। परम्परागत N-tier वास्तुकला कस्तो देखिन्छ भनेर हेरौं।

यसले 4 स्तरहरू समावेश गर्दछ: UI प्रयोगकर्ता इन्टरफेस स्तर, व्यापार तर्क स्तर, डाटा पहुँच स्तर र डाटाबेस। थप प्रगतिशील DDD (डोमेन-संचालित डिजाइन), वा सफ्टवेयर-उन्मुख वास्तुकला हो, जहाँ दुई मध्य स्तरहरू डोमेन वस्तुहरू र भण्डार हुन्।

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

यस योजनाको विशेषता यो हो कि परिवर्तनका यी क्षेत्रहरूको सीमाहरूले व्यापार तर्क स्तरलाई मात्र असर गर्दैन, तर डाटाबेसमा पनि विस्तार गर्दछ।

सेवा हुनुको अर्थ के हो हेरौं। त्यहाँ सेवा परिभाषाको 6 विशेषता गुणहरू छन् - यो सफ्टवेयर हो जुन:

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

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

अब microservices को परिभाषा हेरौं:

• एक माइक्रोसर्भिस आकारमा सानो छ र एक विशेष समस्या समाधान गर्न डिजाइन गरिएको छ;
• माइक्रोसेवा स्वायत्त छ;
• माइक्रोसर्भिस आर्किटेक्चर सिर्जना गर्दा, टाउन प्लानिङ मेटाफर प्रयोग गरिन्छ। यो सैम न्यूम्यानको पुस्तक, बिल्डिंग माइक्रोसर्भिसेसको परिभाषा हो।

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

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

त्यसैले, Bounded Context ले भन्छ कि यदि हामीले हाम्रा सेवाहरूको उपभोक्ता के हो भन्ने स्पष्ट परिभाषा दिन सक्दैनौं भने, हामी यस शब्दको अर्थको बारेमा कुरा गर्न सक्ने सीमाहरू परिभाषित गरौं, र त्यसपछि यी फरक परिभाषाहरू बीचको संक्रमण बिन्दुहरू परिभाषित गरौं। त्यो हो, यदि हामी अर्डर राख्ने दृष्टिकोणबाट ग्राहकको बारेमा कुरा गर्दैछौं, यसको मतलब यो र त्यो हो, र यदि बिक्रीको दृष्टिकोणबाट, यसको मतलब यो र त्यो हो।

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

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

२४:३५ मिनेट

छिट्टै जारी राख्ने...

एक सानो विज्ञापन

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com