Microservices: साइजको महत्व हुन्छ, यदि तपाईंसँग Kubernetes छ भने पनि

मस्को मा सेप्टेम्बर 19 भयो पहिलो विषयगत बैठक HUG (Highload++ User Group), जुन माइक्रोसर्भिसेसलाई समर्पित थियो। त्यहाँ एउटा प्रस्तुति थियो "अपरेटिङ माइक्रोसर्भिसेस: साइज म्याटर्स, यदि तपाईसँग कुबर्नेट्स छ भने पनि," जसमा हामीले माइक्रोसर्भिस आर्किटेक्चरको साथ सञ्चालन परियोजनाहरूमा फ्ल्यान्टको व्यापक अनुभव साझा गर्यौं। सबैभन्दा पहिले, यो सबै विकासकर्ताहरूको लागि उपयोगी हुनेछ जसले आफ्नो वर्तमान वा भविष्यको परियोजनामा ​​यो दृष्टिकोण प्रयोग गर्ने बारे सोचिरहेका छन्।

परिचय दिँदै रिपोर्ट को भिडियो (50 मिनेट, लेख भन्दा धेरै जानकारीपूर्ण), साथै पाठ फारम मा यसको मुख्य उद्धरण।

NB: यस पोस्टको अन्त्यमा भिडियो र प्रस्तुतीकरण पनि उपलब्ध छ।

परिचय

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

म यो ग्राफबाट सुरु गर्नेछु, जसको लेखक (२०१५ मा) भएको छ मार्टिन फाउलर:

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

म Kubernetes प्रयोगको मामलाको लागि यो ग्राफमा थप्नेछु:

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

तपाईले देख्न सक्नुहुने रूपमा, अन्तिम ग्राफ (जब दुबै मोनोलिथिक र माइक्रोसर्भिस अनुप्रयोगहरू कुबर्नेट्सको साथ पूर्वाधारमा हुन्छन्) मूल ग्राफ भन्दा धेरै फरक हुँदैन। अर्को हामी Kubernetes प्रयोग गरेर संचालित अनुप्रयोगहरूको बारेमा कुरा गर्नेछौं।

उपयोगी र हानिकारक सूक्ष्म सेवाहरू

र यहाँ मुख्य विचार छ:

के हो सामान्य microservice वास्तुकला? यसले तपाईलाई वास्तविक लाभहरू ल्याउनुपर्छ, तपाईको कार्य क्षमता बढाउनुपर्छ। यदि हामी ग्राफमा फर्कियौं भने, यो यहाँ छ:

उसलाई बोलाउनु भयो भने उपयोगी, त्यसपछि ग्राफको अर्को छेउमा हुनेछ हानिकारक microservices (काम मा हस्तक्षेप):

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

किन माइक्रो सेवाहरू?

माइक्रो सर्भिसेसको फाइदाको बारेमा प्रश्न छ धेरै विशिष्ट जवाफ पहिले नै उल्लेख गरिएको मार्टिन फाउलरबाट:

1. मोडुलरिटी को स्पष्ट सीमाहरु;
2. स्वतन्त्र तैनाती;
3. प्रविधिहरू छनौट गर्ने स्वतन्त्रता।

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

यदि हामीले केही बिन्दुहरूलाई "संवेदनामा" वर्णन गर्छौं भने:

• मोड्युलहरूको स्पष्ट सीमाहरू: यहाँ हामीसँग डरलाग्दो मोनोलिथ छ, र अब सबै चीजहरू Git भण्डारहरूमा राम्ररी व्यवस्थित गरिनेछ, जसमा सबै चीजहरू "तलखमा" छन्, न्यानो र नरम मिश्रित छैनन्;
• परिनियोजन स्वतन्त्रता: हामी स्वतन्त्र रूपमा सेवाहरू रोल आउट गर्न सक्षम हुनेछौं ताकि विकास छिटो हुन्छ (समानान्तरमा नयाँ सुविधाहरू प्रकाशित गर्नुहोस्);
• विकास स्वतन्त्रता: हामी यो माइक्रोसर्भिस एक टोली/विकासकर्तालाई दिन सक्छौं, र त्यो अर्कोलाई, जसको कारण हामी छिटो विकास गर्न सक्छौं;
• боअधिक विश्वसनीयता: यदि आंशिक ह्रास हुन्छ (२० मध्ये एउटा माइक्रोसर्भिस घट्छ), तब मात्र एउटा बटनले काम गर्न छोड्छ, र प्रणालीले समग्र रूपमा काम गर्न जारी राख्छ।

विशिष्ट (हानिकारक) माइक्रोसेवा वास्तुकला

किन वास्तविकता हामीले अपेक्षा गरेजस्तो छैन भनेर व्याख्या गर्न, म प्रस्तुत गर्नेछु सामूहिक धेरै फरक परियोजनाहरु को अनुभव मा आधारित एक microservice वास्तुकला को एक छवि।

एउटा उदाहरण एक सार अनलाइन स्टोर हुनेछ जुन Amazon वा कम्तिमा OZON सँग प्रतिस्पर्धा गर्न जाँदैछ। यसको microservice वास्तुकला यस्तो देखिन्छ:

कारणहरूको संयोजनको लागि, यी माइक्रोसेवाहरू विभिन्न प्लेटफर्महरूमा लेखिएका छन्:

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

यसका परिणामहरू के हुन्?

फाउलरसँग पनि यो छ त्यहाँ एक लेख छ - माइक्रो सेवाहरू प्रयोग गर्नको लागि "भुक्तानी" बारे:

र हामी हेर्नेछौं कि हाम्रा अपेक्षाहरू पूरा भए।

मोड्युलहरूको सीमाहरू खाली गर्नुहोस्...

तर हामीले वास्तवमा कतिवटा माइक्रोसर्भिसहरू ठीक गर्न आवश्यक छ?परिवर्तन रोल आउट गर्न? के हामी यो पनि पत्ता लगाउन सक्छौं कि वितरित ट्रेसर बिना सबै कुरा कसरी काम गर्दछ (यसपछि, कुनै पनि अनुरोध माइक्रोसर्भिसेसको आधाद्वारा प्रशोधन गरिन्छ)?

त्यहाँ एउटा ढाँचा छ "फोहोरको ठूलो थुप्रो", र यहाँ यो फैलिएको फोहोरको थुप्रो भयो। यो पुष्टि गर्नको लागि, यहाँ अनुरोधहरू कसरी जान्छन् भन्ने अनुमानित दृष्टान्त छ:

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

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

प्रविधि छनोट गर्ने स्वतन्त्रता...

उनी हुन्। याद गर्नुहोस् कि स्वतन्त्रता अक्सर अराजकता मा सीमाना छ। तिनीहरूसँग "खेल" गर्न मात्र प्रविधिहरू छनौट नगर्नु यहाँ धेरै महत्त्वपूर्ण छ।

विकासको स्वाधीनता...

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

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

अलग मापन...

हो, तर यो प्रयोग गरिएको DBMS को क्षेत्रमा सीमित छ। दिइएको वास्तुकला उदाहरणमा, क्यासान्ड्रालाई समस्या हुनेछैन, तर MySQL र PostgreSQL ले गर्नेछ।

Боअधिक विश्वसनीयता...

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

लोड मापन योग्यता...

यो साँच्चै राम्रो छ।

माइक्रो सर्भिसको "हल्कापन"...

हामीसँग ठूलो मात्र होइन नेटवर्क ओभरहेड (DNS को लागि अनुरोधहरू गुणा भइरहेका छन्, आदि), तर हामीले सुरु गरेका धेरै सबक्वेरीहरूको कारणले पनि डाटा प्रतिकृति (स्टोर क्यासहरू), जसले भण्डारणको महत्त्वपूर्ण मात्रामा नेतृत्व गर्यो।

र यहाँ हाम्रा अपेक्षाहरू पूरा गर्ने परिणाम हो:

तर त्यो सबै होइन!

किनभने:

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

यो सबै संग के गर्ने?

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

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

तर के हुन्छ यदि हामी पहिले नै यो अवस्थामा छौं?

कुनै पनि समस्या समाधानको पहिलो चरण भनेको यसमा सहमत हुनु हो र यो समस्या हो भनेर बुझ्नु हो, जुन हामी अब भोग्न चाहँदैनौं।

यदि, अत्यधिक बढेको मोनोलिथको अवस्थामा (जब हामीले यसको लागि थप स्रोतहरू खरीद गर्ने अवसर गुमायौं), हामीले यसलाई काट्छौं, तब यस अवस्थामा विपरित कथा बाहिर निस्कन्छ: जब अत्यधिक माइक्रोसेवाहरूले मद्दत गर्दैन, तर बाधा - अतिरिक्त काट्नुहोस् र विस्तार गर्नुहोस्!

उदाहरण को लागी, माथि छलफल गरिएको सामूहिक छवि को लागी ...

सबैभन्दा शंकास्पद माइक्रोसेवाहरूबाट छुटकारा पाउनुहोस्:

फ्रन्टएन्ड जेनरेशनका लागि जिम्मेवार सबै माइक्रोसेवाहरू मिलाउनुहोस्:

... एउटै माइक्रोसर्भिसमा, एउटामा लेखिएको (आधुनिक र सामान्य, जसरी तपाई आफैले सोच्नुहुन्छ) भाषा/ढाँचा:

यसमा एउटा ORM (एउटा DBMS) र पहिले केही अनुप्रयोगहरू हुनेछन्:

... तर सामान्यतया तपाईले त्यहाँ धेरै स्थानान्तरण गर्न सक्नुहुन्छ, निम्न परिणाम प्राप्त गर्दै:

यसबाहेक, Kubernetes मा हामी यी सबै अलग-अलग उदाहरणहरूमा चलाउँछौं, जसको मतलब हामी अझै पनि लोड मापन गर्न र तिनीहरूलाई अलग मापन गर्न सक्छौं।

संक्षिप्त गर्न

ठूलो तस्वीर हेर्नुहोस्। धेरै पटक, माइक्रोसर्भिसेसहरूसँग यी सबै समस्याहरू उत्पन्न हुन्छन् किनभने कसैले आफ्नो काम लियो, तर "माइक्रोसर्भिसेसहरूसँग खेल्न" चाहन्थे।

"microservices" शब्दमा "micro" भाग अनावश्यक छ।। तिनीहरू "माइक्रो" मात्र हुन् किनभने तिनीहरू ठूलो मोनोलिथ भन्दा सानो छन्। तर तिनीहरूलाई सानो कुराको रूपमा सोच्नुहोस्।

र अन्तिम विचारको लागि, मूल चार्टमा फर्कौं:

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

भिडियो र स्लाइडहरू

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

प्रतिवेदन प्रस्तुति:

PS

हाम्रो ब्लगमा अन्य रिपोर्टहरू:

• «निगरानी र Kubernetes» (दिमित्री स्टोल्यारोभ; मे २८, २०१८ रूटकन्फमा);
• «Kubernetes र GitLab संग CI/CD उत्तम अभ्यासहरू» (दिमित्री स्टोल्यारोभ; नोभेम्बर 7, 2017 HighLoad++ मा);
• «साना परियोजनाहरूमा Kubernetes संग हाम्रो अनुभव» (दिमित्री Stolyarov; जुन 6, 2017 RootConf मा);
• «हामी CI/CD को लागि डकर छविहरू छिटो र सहज रूपमा dapp मार्फत निर्माण गर्छौं» (दिमित्री स्टोल्यारोभ; नोभेम्बर 8, 2016 HighLoad++ मा);
• «डकरको साथ निरन्तर डेलिभरी अभ्यासहरू» (दिमित्री स्टोल्यारोभ; मे २८, २०१८ रूटकन्फमा).

तपाइँ निम्न प्रकाशनहरूमा पनि रुचि राख्न सक्नुहुन्छ:

• «2018 मा microservice पागलपन को मृत्यु»;
• «गुगल अनुसार कन्टेनरहरू प्रयोग गर्नका लागि 7 उत्तम अभ्यासहरू»;
• «Kubernetes लागू गर्ने चुनौतीहरूमा नयाँ स्ट्याकबाट तथ्याङ्कहरू"।

स्रोत: www.habr.com