QCon सम्मेलन। Mastering Chaos: The Netflix Guide to Microservices। भाग ४

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

QCon सम्मेलन। Mastering Chaos: The Netflix Guide to Microservices। भाग ४
QCon सम्मेलन। Mastering Chaos: The Netflix Guide to Microservices। भाग ४
QCon सम्मेलन। Mastering Chaos: The Netflix Guide to Microservices। भाग ४

परिचालन बहावको विपरीत, सेवा अन्तर्राष्ट्रियकरणको लागि नयाँ भाषाहरूको परिचय र कन्टेनरहरू जस्ता नयाँ प्रविधिहरू वातावरणमा नयाँ जटिलता थप्न सचेत निर्णयहरू हुन्। मेरो अपरेशन टोलीले Netflix को लागि उत्कृष्ट टेक्नोलोजी रोडम्यापमा मानकीकृत गर्यो, जुन Java र EC2 मा आधारित पूर्वनिर्धारित उत्तम अभ्यासहरूमा बेक गरिएको थियो, तर व्यापार बढ्दै जाँदा, विकासकर्ताहरूले Python, Ruby, Node-JS, र Docker जस्ता नयाँ कम्पोनेन्टहरू थप्न थाले।

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

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

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

यी अन्तिम बिन्दुहरू लिन र तिनीहरूलाई API सेवाबाट बाहिर निकाल्नु तार्किक थियो। यो गर्नको लागि, हामीले Node.js कम्पोनेन्टहरू सिर्जना गर्यौं जुन डकर कन्टेनरहरूमा साना अनुप्रयोगहरूको रूपमा चल्यो। यसले हामीलाई यी नोड एप्लिकेसनहरूबाट हुने कुनै पनि समस्या र क्र्यासहरूलाई अलग गर्न अनुमति दियो।

यी परिवर्तनहरूको लागत धेरै ठूलो छ र निम्न कारकहरू समावेश छन्:

• उत्पादकता उपकरण। नयाँ प्रविधिहरू प्रबन्ध गर्न नयाँ उपकरणहरू चाहिन्छ किनभने UI टोलीले, एक कुशल मोडेल सिर्जना गर्न धेरै राम्रो स्क्रिप्टहरू प्रयोग गरेर, पूर्वाधार व्यवस्थापन गर्न धेरै समय खर्च गर्नुपर्दैन, तिनीहरूले केवल स्क्रिप्टहरू लेख्न र तिनीहरूको कार्यक्षमता जाँच गर्नुपर्थ्यो।
  अवसर अन्तरदृष्टि र क्रमबद्ध - एक प्रमुख उदाहरण प्रदर्शन चालक जानकारी उजागर गर्न आवश्यक नयाँ उपकरण हो। प्रोसेसरले कति ओगटेको छ, मेमोरी कसरी प्रयोग भइरहेको छ भन्ने जान्न आवश्यक थियो र यो जानकारी सङ्कलन गर्न विभिन्न उपकरणहरू चाहिन्छ।
• आधार छविहरूको खण्डीकरण - साधारण आधार AMI अधिक खण्डित र विशेष भएको छ।
• नोड व्यवस्थापन। त्यहाँ कुनै अफ-द-शेल्फ वास्तुकला वा प्रविधि उपलब्ध छैन जसले तपाईंलाई क्लाउडमा नोडहरू व्यवस्थापन गर्न अनुमति दिन्छ, त्यसैले हामीले Titus निर्माण गरेका छौं, कन्टेनर व्यवस्थापन प्लेटफर्म जसले स्केलेबल र भरपर्दो कन्टेनर डिप्लोइमेन्ट र Amazon AWS सँग क्लाउड एकीकरण प्रदान गर्दछ।
• पुस्तकालय वा प्लेटफर्मको नक्कल। प्लेटफर्मको एउटै कोर कार्यक्षमताको साथ नयाँ प्रविधिहरू प्रदान गर्न यसलाई क्लाउड-आधारित Node.js विकासकर्ता उपकरणहरूमा नक्कल गर्न आवश्यक छ।
• सिक्ने वक्र र औद्योगिक अनुभव। नयाँ प्रविधिको परिचयले अपरिहार्य रूपमा नयाँ चुनौतीहरू सिर्जना गर्दछ जुन पार गर्न र सिक्नु पर्छ।

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

हामी निरन्तर रूपमा प्रमाणित प्रविधिहरू प्रयोग गर्ने अवसरहरू खोजिरहेका थियौं जसले आफूलाई एक ठाउँमा र अन्य समान परिस्थितिहरूमा प्रमाणित गरेका थिए।

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

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

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

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

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

कुराकानीको अन्त्यमा, म नेटफ्लिक्सको संगठन र वास्तुकलाको बारेमा छोटकरीमा कुरा गर्नेछु। सुरुमा हामीसँग इलेक्ट्रोनिक डेलिभरी भनिने योजना थियो, जुन NRDP 1.x मिडिया स्ट्रिमिङको पहिलो संस्करण थियो। "ब्याकस्ट्रीम" शब्द यहाँ प्रयोग गर्न सकिन्छ किनभने सुरुमा प्रयोगकर्ताले उपकरणमा पछि प्लेब्याकको लागि मात्र सामग्री डाउनलोड गर्न सक्थे। Netflix को पहिलो डिजिटल डेलिभरी प्लेटफर्म, 2009 मा फिर्ता, केहि यस्तो देखिन्थ्यो।

प्रयोगकर्ता यन्त्रमा नेटफ्लिक्स एप्लिकेसन समावेश थियो, जसमा UI इन्टरफेस, सुरक्षा मोड्युलहरू, सेवा सक्रियता र प्लेब्याक समावेश थियो, NRDP प्लेटफर्ममा आधारित - Netflix रेडी डिभाइस प्लेटफर्म।

त्यो समयमा प्रयोगकर्ता इन्टरफेस धेरै सरल थियो। यसमा Queque Reader भनिने कुरा समावेश थियो, र प्रयोगकर्ताले Queque मा केहि थप्न साइटमा जानेछन् र त्यसपछि उनीहरूको उपकरणमा थपिएको सामग्री हेर्नेछन्। सकारात्मक कुरा यो थियो कि फ्रन्ट एन्ड टोली र पछाडिको टोली एउटै इलेक्ट्रोनिक डेलिभरी संगठनका थिए र घनिष्ठ कार्य सम्बन्ध थियो। पेलोड XML मा आधारित बनाइएको थियो। एकै समयमा, DVD व्यवसायको लागि Netflix API सिर्जना गरिएको थियो, जसले तेस्रो-पक्ष अनुप्रयोगहरूलाई हाम्रो सेवामा ट्राफिक निर्देशित गर्न प्रोत्साहित गर्‍यो।

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

ट्रान्जिसनको समस्या खण्डीकरण थियो, किनकि अब हाम्रो प्रणालीले सञ्चालनका पूर्ण भिन्न सिद्धान्तहरूमा आधारित दुई सेवाहरू सञ्चालन गर्‍यो - एउटा Rest, JSON र OAuth मा, अर्को RPC, XML र NTBA टोकन प्रणालीमा आधारित प्रयोगकर्ता सुरक्षा संयन्त्र। यो पहिलो हाइब्रिड वास्तुकला थियो।

हाम्रा दुई टोलीहरू बीच अनिवार्य रूपमा फायरवाल थियो किनभने सुरुमा एपीआईले NCCP सँग धेरै राम्रो मापन गरेन र यसले टोलीहरू बीच घर्षण निम्त्यायो। भिन्नताहरू सेवाहरू, प्रोटोकलहरू, सर्किटहरू, सुरक्षा मोड्युलहरूमा थिए, र विकासकर्ताहरूले प्रायः पूर्ण रूपमा फरक सन्दर्भहरू बीच स्विच गर्नुपर्थ्यो।

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

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

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

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

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $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