NDC लंडन परिषद. मायक्रोसर्व्हिस आपत्ती रोखणे. भाग 1

तुम्ही तुमचे मोनोलिथ मायक्रोसर्व्हिसेसमध्ये पुन्हा डिझाइन करण्यात महिने घालवले आहेत आणि शेवटी स्विच फ्लिप करण्यासाठी सर्वजण एकत्र आले आहेत. तुम्ही पहिल्या वेब पेजवर जा... आणि काहीही होत नाही. आपण ते रीलोड करा - आणि पुन्हा काहीही चांगले नाही, साइट इतकी मंद आहे की ती काही मिनिटांसाठी प्रतिसाद देत नाही. काय झालं?

त्याच्या भाषणात, जिमी बोगार्ड वास्तविक जीवनातील मायक्रोसर्व्हिस आपत्तीवर "पोस्टमॉर्टम" करेल. त्याने शोधलेल्या मॉडेलिंग, विकास आणि उत्पादनाच्या समस्या आणि त्याच्या टीमने नवीन वितरित मोनोलिथला विवेकाच्या अंतिम चित्रात कसे बदलले हे तो दाखवेल. डिझाईनमधील त्रुटी पूर्णपणे रोखणे अशक्य असले तरी, अंतिम उत्पादन विश्वसनीय वितरण प्रणाली बनते याची खात्री करण्यासाठी तुम्ही किमान डिझाइन प्रक्रियेच्या सुरुवातीला समस्या ओळखू शकता.

सर्वांना नमस्कार, मी जिमी आहे आणि आज तुम्ही ऐकणार आहात की मायक्रोसर्व्हिसेस तयार करताना तुम्ही मेगा आपत्ती कशा टाळू शकता. ही गोष्ट आहे एका कंपनीची ज्या कंपनीत मी सुमारे दीड वर्ष काम केले ते त्यांच्या जहाजाला हिमखंडाशी टक्कर होण्यापासून रोखण्यासाठी. ही कथा योग्यरित्या सांगण्यासाठी, आम्हाला वेळेत परत जावे लागेल आणि ही कंपनी कोठून सुरू झाली आणि कालांतराने तिची आयटी पायाभूत सुविधा कशी विकसित झाली याबद्दल बोलले पाहिजे. या आपत्तीत निष्पापांच्या नावांचे रक्षण करण्यासाठी मी या कंपनीचे नाव बदलून बेल कॉम्प्युटर्स केले आहे. पुढील स्लाईड 90 च्या दशकाच्या मध्यात अशा कंपन्यांची IT इन्फ्रास्ट्रक्चर कशी होती ते दाखवते. हे कॉम्प्युटर हार्डवेअर स्टोअर ऑपरेट करण्यासाठी मोठ्या सार्वत्रिक फॉल्ट-सहिष्णु एचपी टँडम मेनफ्रेम सर्व्हरचे वैशिष्ट्यपूर्ण आर्किटेक्चर आहे.

त्यांना सर्व ऑर्डर, विक्री, परतावा, उत्पादन कॅटलॉग आणि ग्राहक आधार व्यवस्थापित करण्यासाठी एक प्रणाली तयार करणे आवश्यक होते, म्हणून त्यांनी त्या वेळी सर्वात सामान्य मेनफ्रेम समाधान निवडले. या महाकाय प्रणालीमध्ये कंपनीबद्दलची प्रत्येक माहिती, शक्य तितकी सर्व काही आणि प्रत्येक व्यवहार या मेनफ्रेमद्वारे केला जात असे. त्यांनी त्यांची सर्व अंडी एका टोपलीत ठेवली आणि त्यांना ते सामान्य वाटले. मेल ऑर्डर कॅटलॉग आणि फोनद्वारे ऑर्डर देणे ही एकमेव गोष्ट येथे समाविष्ट नाही.

कालांतराने, यंत्रणा मोठी आणि मोठी होत गेली आणि त्यात मोठ्या प्रमाणात कचरा जमा झाला. तसेच, COBOL ही जगातील सर्वात अभिव्यक्त भाषा नाही, त्यामुळे ही प्रणाली रद्दीचा एक मोठा, मोनोलिथिक तुकडा बनली आहे. 2000 पर्यंत, त्यांनी पाहिले की बऱ्याच कंपन्यांकडे वेबसाइट्स आहेत ज्याद्वारे त्यांनी त्यांचे सर्व व्यवसाय चालवले, आणि त्यांची पहिली व्यावसायिक डॉट-कॉम वेबसाइट तयार करण्याचा निर्णय घेतला.

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

त्यामुळे प्रणालीची रचना सुव्यवस्थित आणि तार्किक दिसत होती, परंतु पुढील स्लाइडमध्ये दर्शविल्याप्रमाणे वास्तविक प्रणाली होती.

सर्व घटक एकमेकांना संबोधित केलेले कॉल, ऍक्सेस केलेले API, एम्बेड केलेले तृतीय-पक्ष dlls आणि यासारखे. असे बऱ्याचदा घडले की आवृत्ती नियंत्रण प्रणाली दुसऱ्याचा कोड हस्तगत करतील, तो प्रकल्पाच्या आत ढकलतील आणि नंतर सर्वकाही खंडित होईल. एमएस एसक्यूएल सर्व्हर 2005 ने लिंक सर्व्हरची संकल्पना वापरली आणि जरी मी स्लाइडवर बाण दाखवले नाहीत, तरीही प्रत्येक डेटाबेस एकमेकांशी बोलला, कारण अनेक डेटाबेसमधून मिळवलेल्या डेटावर आधारित टेबल तयार करण्यात काहीही चूक नाही.

त्यांच्याकडे आता सिस्टमच्या वेगवेगळ्या तार्किक क्षेत्रांमध्ये काही वेगळेपणा असल्याने, हे घाणीचे वितरीत केलेले ब्लॉब बनले, ज्यामध्ये कचऱ्याचा सर्वात मोठा तुकडा अजूनही मेनफ्रेम बॅकएंडमध्ये शिल्लक आहे.

गंमत म्हणजे ही मेनफ्रेम बेल कॉम्प्युटर्सच्या स्पर्धकांनी बनवली होती आणि तरीही त्यांच्या तांत्रिक सल्लागारांनी त्याची देखभाल केली होती. आपल्या ऍप्लिकेशन्सच्या असमाधानकारक कामगिरीबद्दल खात्री पटल्याने, कंपनीने त्यांच्यापासून मुक्त होण्याचा आणि सिस्टमची पुनर्रचना करण्याचा निर्णय घेतला.

विद्यमान ऍप्लिकेशन 15 वर्षांपासून उत्पादनात होते, जे ASP.Net-आधारित ऍप्लिकेशन्ससाठी रेकॉर्ड आहे. सेवेने जगभरातून ऑर्डर स्वीकारल्या आणि या एकाच अनुप्रयोगातून वार्षिक महसूल एक अब्ज डॉलर्सवर पोहोचला. नफ्याचा महत्त्वपूर्ण भाग bell.com वेबसाइटद्वारे व्युत्पन्न केला गेला. ब्लॅक फ्रायडेस, साइटद्वारे दिलेल्या ऑर्डरची संख्या अनेक दशलक्षांपर्यंत पोहोचली. तथापि, विद्यमान आर्किटेक्चरने कोणत्याही विकासास परवानगी दिली नाही, कारण सिस्टम घटकांच्या कठोर आंतरकनेक्शनने व्यावहारिकपणे सेवेमध्ये कोणतेही बदल करण्याची परवानगी दिली नाही.

जागतिक कंपन्यांमध्ये अशी ट्रेडिंग योजना खूप सामान्य आहे हे असूनही, एका देशाकडून ऑर्डर देणे, दुसऱ्या देशात पैसे देणे आणि तिसऱ्याला पाठवणे ही सर्वात गंभीर समस्या होती. विद्यमान वेबसाइटने असे काहीही करण्याची परवानगी दिली नाही, म्हणून त्यांना या ऑर्डर स्वीकारून फोनवर द्याव्या लागल्या. यामुळे कंपनी आर्किटेक्चर बदलण्याचा विचार करू लागली, विशेषत: मायक्रो सर्व्हिसेसवर स्विच करण्याबद्दल.

त्यांनी अशाच प्रकारची समस्या कशी सोडवली हे पाहण्यासाठी इतर कंपन्यांकडे पाहून स्मार्ट गोष्ट केली. यापैकी एक उपाय म्हणजे नेटफ्लिक्स सर्व्हिस आर्किटेक्चर, ज्यामध्ये एपीआय आणि बाह्य डेटाबेसद्वारे कनेक्ट केलेल्या मायक्रोसर्व्हिसेसचा समावेश आहे.

बेल कॉम्प्युटर्स व्यवस्थापनाने काही मूलभूत तत्त्वांचे पालन करून अशी वास्तू तयार करण्याचा निर्णय घेतला. प्रथम, त्यांनी सामायिक डेटाबेस दृष्टिकोन वापरून डेटा डुप्लिकेशन काढून टाकले. त्याउलट कोणताही डेटा पाठविला गेला नाही, ज्यांना त्याची आवश्यकता होती त्यांना केंद्रीकृत स्त्रोताकडे जावे लागले. यानंतर अलगाव आणि स्वायत्तता आली - प्रत्येक सेवा इतरांपेक्षा स्वतंत्र होती. त्यांनी अगदी प्रत्येक गोष्टीसाठी वेब API वापरण्याचे ठरवले - जर तुम्हाला डेटा मिळवायचा असेल किंवा दुसऱ्या सिस्टममध्ये बदल करायचे असतील तर ते सर्व वेब API द्वारे केले गेले. शेवटची मोठी गोष्ट म्हणजे स्पर्धकांच्या हार्डवेअरवर आधारित "बेल" मेनफ्रेमच्या विरूद्ध "बेल ऑन बेल" नावाची नवीन मेनफ्रेम होती.

म्हणून, 18 महिन्यांच्या कालावधीत, त्यांनी या मुख्य तत्त्वांभोवती प्रणाली तयार केली आणि ती पूर्व-उत्पादनात आणली. आठवड्याच्या शेवटी कामावर परत आल्यावर, विकसक एकत्र आले आणि नवीन सिस्टम कनेक्ट केलेले सर्व सर्व्हर चालू केले. 18 महिने काम, शेकडो विकासक, सर्वात आधुनिक बेल हार्डवेअर - आणि कोणताही सकारात्मक परिणाम नाही! यामुळे बऱ्याच लोकांची निराशा झाली आहे कारण त्यांनी ही प्रणाली त्यांच्या लॅपटॉपवर अनेकदा चालवली आहे आणि सर्व काही ठीक आहे.

या समस्येचे निराकरण करण्यासाठी त्यांचे सर्व पैसे टाकण्यात ते हुशार होते. त्यांनी स्विचसह सर्वात आधुनिक सर्व्हर रॅक स्थापित केले, गीगाबिट ऑप्टिकल फायबर वापरले, सर्वात शक्तिशाली सर्व्हर हार्डवेअर RAM च्या विलक्षण प्रमाणासह, ते सर्व कनेक्ट केले, कॉन्फिगर केले - आणि पुन्हा, काहीही नाही! मग त्यांना शंका वाटू लागली की याचे कारण कालबाह्य असू शकते, म्हणून त्यांनी सर्व वेब सेटिंग्ज, सर्व API सेटिंग्जमध्ये जाऊन संपूर्ण टाइमआउट कॉन्फिगरेशन कमाल मूल्यांमध्ये अपडेट केले, जेणेकरून ते बसून काहीतरी होण्याची प्रतीक्षा करू शकतील. साइटवर. त्यांनी प्रतीक्षा केली आणि प्रतीक्षा केली आणि शेवटी वेबसाइट लोड होईपर्यंत साडेनऊ मिनिटे वाट पाहिली.

त्यानंतर, त्यांच्या लक्षात आले की सध्याच्या परिस्थितीचे सखोल विश्लेषण करणे आवश्यक आहे आणि त्यांनी आम्हाला आमंत्रित केले. आम्हाला आढळलेली पहिली गोष्ट म्हणजे सर्व 18 महिन्यांच्या विकासादरम्यान, एकही वास्तविक "मायक्रो" तयार झाला नाही - सर्वकाही फक्त मोठे झाले. यानंतर, आपत्तीचे कारण समजून घेण्यासाठी आम्ही पोस्टमॉर्टम लिहायला सुरुवात केली, ज्याला “रेट्रोस्पेक्टिव्ह” किंवा “दुखी रीट्रोस्पेक्टिव्ह” असेही म्हणतात, ज्याला “ब्लेम स्टॉर्म” असेही म्हणतात, “ब्रेन स्टॉर्म” प्रमाणेच.

आमच्याकडे अनेक संकेत होते, त्यापैकी एक API कॉलच्या वेळी संपूर्ण रहदारी संपृक्तता होता. जेव्हा तुम्ही मोनोलिथिक सर्व्हिस आर्किटेक्चर वापरता, तेव्हा नेमके काय चुकले ते तुम्ही लगेच समजू शकता कारण तुमच्याकडे एकच स्टॅक ट्रेस आहे जो अपयशास कारणीभूत असलेल्या सर्व गोष्टींचा अहवाल देतो. अशा परिस्थितीत जेथे अनेक सेवा एकाच वेळी समान API मध्ये प्रवेश करतात, तेथे WireShark सारखी अतिरिक्त नेटवर्क मॉनिटरिंग साधने वापरण्याशिवाय ट्रेसचा मागोवा घेण्याचा कोणताही मार्ग नाही, ज्यामुळे तुम्ही एकाच विनंतीचे परीक्षण करू शकता आणि त्याच्या अंमलबजावणीदरम्यान काय झाले हे शोधू शकता. म्हणून आम्ही एक वेब पृष्ठ घेतले आणि जवळजवळ 2 आठवडे कोडेचे तुकडे एकत्र ठेवले, त्यावर विविध कॉल केले आणि त्या प्रत्येकामुळे काय झाले याचे विश्लेषण केले.
हे चित्र पहा. हे दर्शविते की एक बाह्य विनंती सेवेला अनेक अंतर्गत कॉल करण्यासाठी प्रॉम्प्ट करते जे परत येतात. असे दिसून आले की प्रत्येक अंतर्गत कॉल स्वतंत्रपणे या विनंतीची सेवा करण्यास सक्षम होण्यासाठी अतिरिक्त हॉप्स बनवते, कारण आवश्यक माहिती मिळविण्यासाठी ते इतरत्र वळू शकत नाही. हे चित्र कॉल्सच्या निरर्थक कॅस्केडसारखे दिसते, कारण बाह्य विनंती अतिरिक्त सेवांना कॉल करते, जे इतर अतिरिक्त सेवांना कॉल करते आणि असेच, जवळजवळ जाहिरात अनंत.

या चित्रातील हिरवा रंग एक अर्धवर्तुळ दर्शवितो ज्यामध्ये सेवा एकमेकांना कॉल करतात - सेवा A कॉल करते सेवा B, सेवा B सेवा C कॉल करते आणि परिणामी, आम्हाला "वितरित डेडलॉक" मिळते. एका विनंतीने हजार नेटवर्क 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 ब्लॉगचे आहे. हे एक साधे वेब ऍप्लिकेशन, व्यवसाय लॉजिकचा ब्लॉक आणि डेटाबेस दर्शवते. विनंती थेट येते, वेबसाठी एक सर्व्हर, व्यवसायासाठी एक सर्व्हर आणि डेटाबेससाठी एक सर्व्हर आहे. रहदारी वाढवली तर चित्र थोडे बदलेल.

येथे दोन वेब सर्व्हर दरम्यान रहदारी वितरीत करण्यासाठी एक लोड बॅलन्सर येतो, वेब सेवा आणि व्यवसाय लॉजिक दरम्यान स्थित एक कॅशे आणि व्यवसाय लॉजिक आणि डेटाबेस दरम्यान दुसरा कॅशे. 2000 च्या दशकाच्या मध्यात लोड बॅलेंसिंग आणि ब्लू/ग्रीन डिप्लॉयमेंट ऍप्लिकेशनसाठी वापरण्यात आलेली हीच आर्किटेक्चर बेल आहे. काही काळापर्यंत सर्व काही व्यवस्थित चालले होते, कारण ही योजना एका मोनोलिथिक संरचनेसाठी होती.

खालील चित्र दाखवते की MS एका मोनोलिथमधून मायक्रोसर्व्हिसेसकडे जाण्याची शिफारस कशी करते - प्रत्येक मुख्य सेवा स्वतंत्र मायक्रोसर्व्हिसेसमध्ये विभाजित करणे. या योजनेच्या अंमलबजावणीदरम्यानच बेलची चूक झाली.

त्यांनी त्यांच्या सर्व सेवा वेगवेगळ्या स्तरांमध्ये विभागल्या, ज्या प्रत्येकामध्ये अनेक वैयक्तिक सेवांचा समावेश आहे. उदाहरणार्थ, वेब सेवेमध्ये सामग्री प्रस्तुतीकरण आणि प्रमाणीकरणासाठी मायक्रोसर्व्हिसेस समाविष्ट आहेत, व्यवसाय लॉजिक सेवेमध्ये ऑर्डर आणि खाते माहितीवर प्रक्रिया करण्यासाठी मायक्रो सर्व्हिसेसचा समावेश आहे, डेटाबेस विशिष्ट डेटासह मायक्रोसर्व्हिसेसच्या समूहामध्ये विभागला गेला आहे. वेब, बिझनेस लॉजिक आणि डेटाबेस या दोन्ही स्टेटलेस सेवा होत्या.

तथापि, हे चित्र पूर्णपणे चुकीचे होते कारण त्यात कंपनीच्या IT क्लस्टरच्या बाहेरील कोणत्याही व्यवसाय युनिट्सचा नकाशा तयार केलेला नाही. या योजनेने बाह्य जगाशी कोणताही संबंध विचारात घेतला नाही, म्हणून हे स्पष्ट नव्हते की, उदाहरणार्थ, तृतीय-पक्षाचे व्यवसाय विश्लेषण कसे मिळवायचे. मी लक्षात घेतो की त्यांच्याकडे वैयक्तिक कर्मचाऱ्यांचे करिअर विकसित करण्यासाठी अनेक सेवांचा शोध लावला होता ज्यांनी अधिक पैसे मिळविण्यासाठी शक्य तितक्या लोकांचे व्यवस्थापन करण्याचा प्रयत्न केला.

त्यांचा असा विश्वास होता की मायक्रोसर्व्हिसेसमध्ये जाणे त्यांच्या अंतर्गत एन-टियर फिजिकल लेयर इन्फ्रास्ट्रक्चर घेणे आणि त्यावर डॉकर चिकटविणे तितके सोपे आहे. पारंपारिक एन-टियर आर्किटेक्चर कसे दिसते ते पाहू या.

यात 4 स्तर आहेत: UI वापरकर्ता इंटरफेस स्तर, व्यवसाय तर्क स्तर, डेटा प्रवेश स्तर आणि डेटाबेस. अधिक प्रगतीशील DDD (डोमेन-चालित डिझाइन), किंवा सॉफ्टवेअर-देणारं आर्किटेक्चर आहे, जेथे दोन मध्यम स्तर डोमेन ऑब्जेक्ट्स आणि एक भांडार आहेत.

मी या वास्तूमध्ये बदलाची वेगवेगळी क्षेत्रे, जबाबदारीची वेगवेगळी क्षेत्रे पाहण्याचा प्रयत्न केला. सामान्य एन-टियर ऍप्लिकेशनमध्ये, बदलाच्या विविध क्षेत्रांचे वर्गीकरण केले जाते जे रचना वरपासून खालपर्यंत अनुलंबपणे झिरपते. हे कॅटलॉग, वैयक्तिक संगणकांवर केलेल्या कॉन्फिग सेटिंग्ज आणि चेकआउट तपासण्या आहेत, ज्या माझ्या टीमने हाताळल्या होत्या.

या योजनेचे वैशिष्ठ्य हे आहे की बदलाच्या या क्षेत्रांच्या सीमा केवळ व्यवसायाच्या तर्कशास्त्राच्या स्तरावरच प्रभाव टाकत नाहीत तर डेटाबेसपर्यंत विस्तारित होतात.

सेवा म्हणजे काय ते पाहू. सेवा व्याख्येचे 6 वैशिष्ट्यपूर्ण गुणधर्म आहेत - ते सॉफ्टवेअर आहे जे:

• विशिष्ट संस्थेद्वारे तयार आणि वापरले;
• सिस्टममधील विशिष्ट प्रकारच्या माहितीची सामग्री, प्रक्रिया आणि/किंवा तरतुदीसाठी जबाबदार आहे;
• विशिष्ट ऑपरेशनल गरजा पूर्ण करण्यासाठी स्वतंत्रपणे बांधले, तैनात केले आणि चालवले जाऊ शकते;
• ग्राहक आणि इतर सेवांशी संप्रेषण करते, करार किंवा कराराच्या हमींवर आधारित माहिती प्रदान करते;
• अनाधिकृत प्रवेशापासून स्वतःचे संरक्षण करते, आणि त्याची माहिती हानीपासून;
• अयशस्वी अशा प्रकारे हाताळते की त्यामुळे माहितीचे नुकसान होणार नाही.

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

आता मायक्रो सर्व्हिसेसची व्याख्या पाहू.

• मायक्रोसर्व्हिस आकाराने लहान आहे आणि एका विशिष्ट समस्येचे निराकरण करण्यासाठी डिझाइन केलेली आहे;
• मायक्रो सर्व्हिस स्वायत्त आहे;
• मायक्रोसर्व्हिस आर्किटेक्चर तयार करताना, शहर नियोजन रूपक वापरले जाते. सॅम न्यूमनच्या बिल्डिंग मायक्रोसर्व्हिसेस या पुस्तकातील ही व्याख्या आहे.

बाउंडेड कॉन्टेक्स्टची व्याख्या एरिक इव्हान्सच्या डोमेन-ड्राइव्हन डिझाइन या पुस्तकातून घेतली आहे. हा DDD मधील एक कोर पॅटर्न आहे, एक आर्किटेक्चर डिझाइन सेंटर जे व्हॉल्यूमेट्रिक आर्किटेक्चरल मॉडेल्ससह कार्य करते, त्यांना वेगवेगळ्या बाउंडेड संदर्भांमध्ये विभाजित करते आणि त्यांच्यातील परस्परसंवाद स्पष्टपणे परिभाषित करते.

सोप्या भाषेत सांगायचे तर, एक बाउंडेड कॉन्टेक्स्ट हे स्कोप दर्शवते ज्यामध्ये विशिष्ट मॉड्यूल वापरले जाऊ शकते. या संदर्भात तार्किकदृष्ट्या युनिफाइड मॉडेल आहे जे पाहिले जाऊ शकते, उदाहरणार्थ, तुमच्या व्यवसाय डोमेनमध्ये. जर तुम्ही ऑर्डरमध्ये गुंतलेल्या कर्मचाऱ्यांना “क्लायंट कोण आहे” असे विचारले तर तुम्हाला एक व्याख्या मिळेल, जर तुम्ही विक्रीमध्ये गुंतलेल्यांना विचारले तर तुम्हाला दुसरी मिळेल आणि कलाकार तुम्हाला तिसरी व्याख्या देतील.

म्हणून, बाउंडेड कॉन्टेक्स्ट म्हणते की जर आपण आपल्या सेवांचा ग्राहक म्हणजे काय याची स्पष्ट व्याख्या देऊ शकत नसाल, तर आपण या संज्ञेच्या अर्थाबद्दल बोलू शकणाऱ्या सीमा परिभाषित करूया आणि नंतर या भिन्न व्याख्यांमधील संक्रमण बिंदू परिभाषित करूया. म्हणजेच, जर आपण ऑर्डर देण्याच्या दृष्टिकोनातून क्लायंटबद्दल बोलत असाल, तर याचा अर्थ हा आणि तो आहे आणि जर विक्रीच्या दृष्टिकोनातून, याचा अर्थ हा आणि तो असा आहे.

मायक्रोसर्व्हिसची पुढील व्याख्या म्हणजे कोणत्याही प्रकारच्या अंतर्गत ऑपरेशन्सचे एन्कॅप्स्युलेशन, कामाच्या प्रक्रियेतील घटकांचे वातावरणात "गळती" रोखणे. पुढे "बाह्य परस्परसंवादासाठी किंवा बाह्य संप्रेषणांसाठी स्पष्ट करारांची व्याख्या" येते, जी SLAs कडून परत येणाऱ्या करारांच्या कल्पनेद्वारे दर्शविली जाते. शेवटची व्याख्या सेल किंवा सेलचे रूपक आहे, ज्याचा अर्थ मायक्रोसर्व्हिसमधील ऑपरेशन्सच्या संचाचे संपूर्ण एन्कॅप्सुलेशन आणि बाह्य जगाशी संवाद साधण्यासाठी रिसेप्टर्सची उपस्थिती.

म्हणून आम्ही बेल कॉम्प्युटर्सच्या लोकांना म्हणालो, “तुम्ही निर्माण केलेली कोणतीही अराजकता आम्ही दूर करू शकत नाही कारण तुमच्याकडे ते करण्यासाठी पैसे नाहीत, परंतु आम्ही फक्त एक सेवा निश्चित करू जेणेकरून ते सर्व घडेल. अर्थ." या टप्प्यावर, मी तुम्हाला सांगून सुरुवात करेन की आम्ही आमची एकमेव सेवा कशी निश्चित केली जेणेकरून ती विनंत्यांना साडेनऊ मिनिटांपेक्षा जलद प्रतिसाद देईल.

22:30 मि

लवकरच सुरू ठेवणार आहे...

थोडी जाहिरात

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

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com