मायक्रोसर्व्हिसेस: तुमच्याकडे कुबर्नेट्स असले तरीही आकार महत्त्वाचा

मॉस्कोमध्ये 19 सप्टेंबर जागा घेतली पहिली थीमॅटिक मीटिंग HUG (हायलोड++ यूजर ग्रुप), जी मायक्रो सर्व्हिसेसला समर्पित होती. "ऑपरेटिंग मायक्रोसर्व्हिसेस: साइज मॅटर, तुमच्याकडे कुबर्नेट्स असले तरीही" असे सादरीकरण होते, ज्यामध्ये आम्ही फ्लॅंटचा मायक्रोसर्व्हिस आर्किटेक्चरसह ऑपरेटिंग प्रोजेक्ट्सचा व्यापक अनुभव शेअर केला. सर्वप्रथम, हे सर्व विकासकांसाठी उपयुक्त ठरेल जे त्यांच्या वर्तमान किंवा भविष्यातील प्रकल्पात हा दृष्टिकोन वापरण्याचा विचार करत आहेत.

परिचय देत आहे अहवालाचा व्हिडिओ (50 मिनिटे, लेखापेक्षा अधिक माहितीपूर्ण), तसेच त्यातील मुख्य अर्क मजकूर स्वरूपात.

NB: या पोस्टच्या शेवटी व्हिडिओ आणि सादरीकरण देखील उपलब्ध आहे.

परिचय

सहसा चांगल्या कथेची सुरुवात, मुख्य कथानक आणि संकल्प असतो. हा अहवाल प्रस्तावनासारखाच आहे आणि त्यातही एक दुःखद आहे. हे लक्षात घेणे देखील महत्त्वाचे आहे की ते मायक्रोसर्व्हिसेसबद्दल बाहेरील व्यक्तीचे दृश्य प्रदान करते. ऑपरेटिंग.

मी या आलेखाने सुरुवात करेन, ज्याचा लेखक (2015 मध्ये) झाले आहे मार्टिन फॉलर:

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

कुबर्नेट्स वापरण्याच्या बाबतीत मी या आलेखामध्ये जोडेल:

मायक्रोसर्व्हिसेस असलेले अॅप्लिकेशन चांगले का आहे? कारण अशी वास्तुकला आर्किटेक्चरसाठी गंभीर आवश्यकता पुढे ठेवते, जी यामधून कुबर्नेट्सच्या क्षमतांनी पूर्णपणे व्यापलेली असते. दुसरीकडे, यापैकी काही कार्यक्षमता एका मोनोलिथसाठी उपयुक्त ठरतील, विशेषत: कारण आजचे ठराविक मोनोलिथ अचूकपणे मोनोलिथ नाही (तपशील नंतर अहवालात येईल).

तुम्ही बघू शकता, अंतिम आलेख (जेव्हा दोन्ही मोनोलिथिक आणि मायक्रोसर्व्हिस ऍप्लिकेशन्स कुबर्नेट्ससह पायाभूत सुविधांमध्ये असतात) मूळ ग्राफपेक्षा फारसा वेगळा नाही. पुढे आपण Kubernetes वापरून ऑपरेट केलेल्या ऍप्लिकेशन्सबद्दल बोलू.

उपयुक्त आणि हानिकारक सूक्ष्म सेवा

आणि येथे मुख्य कल्पना आहे:

काय आहे सामान्य मायक्रोसर्व्हिस आर्किटेक्चर? यामुळे तुमची कार्य क्षमता वाढवून तुम्हाला खरे फायदे मिळायला हवेत. जर आपण आलेखाकडे परत गेलो तर ते येथे आहे:

तिला फोन केला तर उपयुक्त, नंतर आलेखाच्या दुसऱ्या बाजूला असेल हानिकारक सूक्ष्म सेवा (कामात व्यत्यय आणते):

"मुख्य कल्पना" वर परत येत आहे: मी माझ्या अनुभवावर अजिबात विश्वास ठेवू नये? या वर्षाच्या सुरुवातीपासून मी पाहिले आहे 85 प्रकल्प. ते सर्व मायक्रोसर्व्हिसेस नव्हते (त्यांच्यापैकी सुमारे एक तृतीयांश ते अर्ध्या भागात अशी वास्तुकला होती), परंतु तरीही ही संख्या मोठी आहे. आऊटसोर्सर म्हणून आम्ही (फ्लँट कंपनी) छोट्या कंपन्यांमध्ये (5 विकासकांसह) आणि मोठ्या कंपन्यांमध्ये (~500 विकासकांसह) विकसित केलेले विविध प्रकारचे ऍप्लिकेशन पाहण्यास व्यवस्थापित करतो. एक अतिरिक्त फायदा हा आहे की आम्ही हे अनुप्रयोग लाइव्ह आणि वर्षानुवर्षे विकसित होत असल्याचे पाहतो.

मायक्रो सर्व्हिसेस का?

मायक्रोसर्व्हिसेसच्या फायद्यांबद्दल प्रश्न आहे अतिशय विशिष्ट उत्तर आधीच नमूद केलेल्या मार्टिन फॉलरकडून:

1. मॉड्यूलरिटीच्या स्पष्ट सीमा;
2. स्वतंत्र तैनाती;
3. तंत्रज्ञान निवडण्याचे स्वातंत्र्य.

मी सॉफ्टवेअर आर्किटेक्ट्स आणि डेव्हलपर्सशी खूप बोललो आणि त्यांना मायक्रो सर्व्हिसेसची गरज का आहे हे विचारले. आणि मी त्यांच्या अपेक्षांची यादी तयार केली. काय झाले ते येथे आहे:

जर आपण काही मुद्द्यांचे "संवेदनांमध्ये" वर्णन केले तर:

• मॉड्यूल्सच्या स्पष्ट सीमा: येथे आमच्याकडे एक भयानक मोनोलिथ आहे आणि आता सर्व काही गिट रेपॉजिटरीजमध्ये व्यवस्थित केले जाईल, ज्यामध्ये सर्वकाही "शेल्फवर" आहे, उबदार आणि मऊ मिसळलेले नाहीत;
• उपयोजन स्वातंत्र्य: आम्ही स्वतंत्रपणे सेवा आणण्यास सक्षम होऊ जेणेकरून विकास जलद होईल (समांतर नवीन वैशिष्ट्ये प्रकाशित करा);
• विकास स्वातंत्र्य: आम्ही ही मायक्रो सर्व्हिस एका टीम/डेव्हलपरला देऊ शकतो आणि ती दुसऱ्या टीमला देऊ शकतो, ज्यामुळे आम्ही जलद विकास करू शकतो;
• боअधिक विश्वासार्हता: जर आंशिक ऱ्हास झाला (20 पैकी एक मायक्रोसर्व्हिस फॉल्स), तर फक्त एक बटण कार्य करणे थांबवेल आणि संपूर्ण प्रणाली कार्य करणे सुरू ठेवेल.

ठराविक (हानीकारक) मायक्रोसर्व्हिस आर्किटेक्चर

वास्तविकता आपल्या अपेक्षेप्रमाणे का नाही हे स्पष्ट करण्यासाठी, मी मांडतो सामूहिक विविध प्रकल्पांच्या अनुभवावर आधारित मायक्रोसर्व्हिस आर्किटेक्चरची प्रतिमा.

एक उदाहरण म्हणजे एक अमूर्त ऑनलाइन स्टोअर जे Amazon किंवा किमान OZON शी स्पर्धा करणार आहे. त्याची मायक्रोसर्व्हिस आर्किटेक्चर असे दिसते:

कारणांच्या संयोजनासाठी, या मायक्रोसर्व्हिसेस वेगवेगळ्या प्लॅटफॉर्मवर लिहिलेल्या आहेत:

प्रत्येक मायक्रोसर्व्हिसला स्वायत्तता असणे आवश्यक असल्याने, त्यापैकी अनेकांना त्यांचा स्वतःचा डेटाबेस आणि कॅशे आवश्यक आहे. अंतिम आर्किटेक्चर खालीलप्रमाणे आहे:

त्याचे परिणाम काय आहेत?

फॉलरकडेही हे आहे एक लेख आहे - मायक्रो सर्व्हिसेस वापरण्यासाठी "पेमेंट" बद्दल:

आणि आमच्या अपेक्षा पूर्ण झाल्या की नाही ते पाहू.

मॉड्यूल्सच्या सीमा साफ करा...

पण आम्हाला प्रत्यक्षात किती मायक्रोसर्व्हिसेस दुरुस्त करायच्या आहेत?बदल रोल आउट करण्यासाठी? वितरित ट्रेसरशिवाय सर्व काही कसे कार्य करते हे आपण शोधू शकतो (अखेर, कोणत्याही विनंतीवर अर्ध्या मायक्रो सर्व्हिसेसद्वारे प्रक्रिया केली जाते)?

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

उपयोजन स्वातंत्र्य...

तांत्रिकदृष्ट्या, हे साध्य झाले आहे: आम्ही प्रत्येक मायक्रो सर्व्हिस स्वतंत्रपणे रोल आउट करू शकतो. परंतु सराव मध्ये आपल्याला हे लक्षात घेणे आवश्यक आहे की ते नेहमी रोल आउट होते अनेक सूक्ष्म सेवा, आणि आम्ही खात्यात घेणे आवश्यक आहे त्यांच्या रोलआउटचा क्रम. चांगल्या प्रकारे, आम्ही रिलीझ योग्य क्रमाने रोल आउट करत आहोत की नाही हे सामान्यतः वेगळ्या सर्किटमध्ये तपासावे लागेल.

तंत्रज्ञान निवडण्याचे स्वातंत्र्य...

ती आहे. फक्त लक्षात ठेवा की स्वातंत्र्य बहुतेक वेळा अधर्मावर अवलंबून असते. तंत्रज्ञान फक्त त्यांच्यासोबत "खेळण्यासाठी" निवडू नये हे येथे खूप महत्वाचे आहे.

विकासाचे स्वातंत्र्य...

संपूर्ण ऍप्लिकेशनसाठी चाचणी लूप कसा बनवायचा (अनेक घटकांसह)? परंतु तरीही तुम्हाला ते अद्ययावत ठेवणे आवश्यक आहे. हे सर्व वस्तुस्थितीकडे नेत आहे चाचणी सर्किट्सची वास्तविक संख्या, ज्यामध्ये आपण तत्वतः समाविष्ट करू शकतो, किमान असल्याचे बाहेर वळते.

हे सर्व स्थानिक पातळीवर कसे उपयोजित करायचे?... असे दिसून आले की अनेकदा विकासक त्याचे काम स्वतंत्रपणे करतो, परंतु "यादृच्छिकपणे", कारण त्याला सर्किट चाचणीसाठी मोकळे होईपर्यंत प्रतीक्षा करण्यास भाग पाडले जाते.

वेगळे स्केलिंग...

होय, परंतु ते वापरलेल्या DBMS च्या क्षेत्रामध्ये मर्यादित आहे. दिलेल्या आर्किटेक्चरच्या उदाहरणात, कॅसॅन्ड्राला समस्या येणार नाहीत, परंतु MySQL आणि PostgreSQL.

Боजास्त विश्वासार्हता...

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

लोड मापनक्षमता...

हे खरोखर चांगले आहे.

मायक्रो सर्व्हिसेसचा "हलकापणा"...

आमच्याकडे केवळ प्रचंड नाही नेटवर्क ओव्हरहेड (DNS साठी विनंत्या गुणाकार होत आहेत, इ.), परंतु आम्ही सुरू केलेल्या अनेक सबक्वेरीजमुळे देखील प्रतिकृती डेटा (स्टोअर कॅशे), ज्यामुळे मोठ्या प्रमाणात स्टोरेज होते.

आणि आमच्या अपेक्षा पूर्ण केल्याचा परिणाम येथे आहे:

पण ते सर्व नाही!

कारण:

• बहुधा आम्हाला संदेश बसची आवश्यकता असेल.
• योग्य वेळी सातत्यपूर्ण बॅकअप कसा घ्यावा? फक्त एक वास्तविक यासाठी वाहतूक बंद करण्याचा पर्याय आहे. पण उत्पादनात हे कसे करायचे?
• जर आपण अनेक क्षेत्रांना समर्थन देण्याबद्दल बोलत आहोत, तर त्या प्रत्येकामध्ये टिकाऊपणा आयोजित करणे हे खूप श्रम-केंद्रित कार्य आहे.
• केंद्रीकृत बदल करण्याची समस्या उद्भवते. उदाहरणार्थ, जर आम्हाला PHP आवृत्ती अद्यतनित करायची असेल, तर आम्हाला प्रत्येक भांडारासाठी वचनबद्ध करणे आवश्यक आहे (आणि त्यापैकी डझनभर आहेत).
• ऑपरेशनल क्लिष्टतेतील वाढ, अप्रचलित, घातांकीय आहे.

या सगळ्याचं काय करायचं?

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

आणखी एक मौल्यवान विचार असा आहे की मायक्रोसर्व्हिस आर्किटेक्चरसह प्रकल्प यशस्वी होण्यासाठी, तुम्हाला चांगले माहित असणे आवश्यक आहे आणि विषय क्षेत्र आणि सूक्ष्म सेवा कशी बनवायची. आणि विषय क्षेत्र शिकण्याचा सर्वोत्तम मार्ग म्हणजे मोनोलिथ बनवणे.

पण आपण आधीच या परिस्थितीत आहोत तर?

कोणतीही समस्या सोडवण्याची पहिली पायरी म्हणजे त्याच्याशी सहमत असणे आणि ती एक समस्या आहे हे समजून घेणे, आपल्याला यापुढे त्रास सहन करायचा नाही.

जर, अतिवृद्ध मोनोलिथच्या बाबतीत (जेव्हा आमच्याकडे त्यासाठी अतिरिक्त संसाधने खरेदी करण्याची संधी संपली असेल), आम्ही ते कापले, तर या प्रकरणात उलट कथा बाहेर वळते: जेव्हा जास्त मायक्रोसर्व्हिसेस यापुढे मदत करत नाहीत, परंतु अडथळा आणतात - जादा कापून मोठे करा!

उदाहरणार्थ, वर चर्चा केलेल्या सामूहिक प्रतिमेसाठी...

सर्वात शंकास्पद मायक्रोसर्व्हिसेसपासून मुक्त व्हा:

फ्रंटएंड जनरेशनसाठी जबाबदार असलेल्या सर्व मायक्रोसर्व्हिसेस एकत्र करा:

... एका मायक्रोसर्व्हिसमध्ये, एका भाषेत लिहिलेली (आधुनिक आणि सामान्य, जसे तुम्हाला वाटते) भाषा/फ्रेमवर्क:

यात एक ORM (एक DBMS) आणि प्रथम काही ऍप्लिकेशन्स असतील:

... परंतु सर्वसाधारणपणे आपण तेथे बरेच काही हस्तांतरित करू शकता, पुढील परिणाम मिळवून:

शिवाय, Kubernetes मध्ये आम्ही हे सर्व स्वतंत्र उदाहरणांमध्ये चालवतो, याचा अर्थ असा की आम्ही अजूनही लोड मोजू शकतो आणि त्यांना स्वतंत्रपणे मोजू शकतो.

सारांश करणे

मोठे चित्र पहा. बर्‍याचदा, मायक्रोसर्व्हिसेसमधील या सर्व समस्या उद्भवतात कारण कोणीतरी त्यांचे कार्य स्वीकारले होते, परंतु "मायक्रोसर्व्हिसेससह खेळू" इच्छित होते.

"मायक्रोसर्व्हिसेस" या शब्दात "मायक्रो" भाग निरर्थक आहे.. ते "मायक्रो" आहेत कारण ते एका विशाल मोनोलिथपेक्षा लहान आहेत. पण त्यांना लहान समजू नका.

आणि अंतिम विचारासाठी, मूळ तक्त्याकडे परत येऊ:

त्यावर लिहिलेली चिठ्ठी (वर उजवीकडे) त्या वस्तुस्थितीवर उकळते तुमचा प्रकल्प बनवणाऱ्या संघाची कौशल्ये नेहमीच प्राथमिक असतात — मायक्रोसर्व्हिसेस आणि मोनोलिथमधील तुमच्या निवडीमध्ये ते महत्त्वाची भूमिका बजावतील. जर संघाकडे पुरेसे कौशल्य नसेल, परंतु ते मायक्रोसर्व्हिसेस बनवू लागले, तर कथा नक्कीच घातक असेल.

व्हिडिओ आणि स्लाइड्स

भाषणातील व्हिडिओ (~50 मिनिटे; दुर्दैवाने, तो अभ्यागतांच्या असंख्य भावना व्यक्त करत नाही, ज्याने अहवालाचा मूड निश्चित केला आहे, परंतु ते असे आहे):

अहवालाचे सादरीकरण:

PS

आमच्या ब्लॉगवरील इतर अहवाल:

• «देखरेख आणि Kubernetes» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 28 मे 2018);
• «कुबर्नेट्स आणि गिटलॅबसह CI/CD सर्वोत्तम पद्धती» (दिमित्री स्टोल्यारोव्ह; 7 नोव्हेंबर, 2017 HighLoad++ वर);
• «लहान प्रकल्पांमध्ये कुबर्नेट्ससोबतचा आमचा अनुभव» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 6 जून 2017);
• «आम्ही CI/CD साठी डॉकर प्रतिमा जलद आणि सोयीस्करपणे डॅपसह तयार करतो» (दिमित्री स्टोल्यारोव्ह; 8 नोव्हेंबर, 2016 HighLoad++ वर);
• «डॉकरसह सतत वितरण सराव» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 31 मे 2016).

तुम्हाला खालील प्रकाशनांमध्ये देखील स्वारस्य असू शकते:

• «2018 मध्ये मायक्रोसर्व्हिस वेडेपणाचा मृत्यू";
• «Google नुसार कंटेनर वापरण्यासाठी 7 सर्वोत्तम पद्धती";
• «कुबर्नेट्सची अंमलबजावणी करण्याच्या आव्हानांवर द न्यू स्टॅकची आकडेवारी».

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