लेखको अनुवाद: दूत थ्रेडिङ मोडेल - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

थ्रेडिङ सिंहावलोकन

राजदूतले तीन फरक प्रकारका स्ट्रिमहरू प्रयोग गर्दछ:

• मुख्य: यस थ्रेडले प्रक्रिया स्टार्टअप र समाप्ति, XDS (xDiscovery सेवा) API को सबै प्रशोधन, DNS, स्वास्थ्य जाँच, सामान्य क्लस्टर र रनटाइम व्यवस्थापन, तथ्याङ्क रिसेट, प्रशासन र सामान्य प्रक्रिया व्यवस्थापन - लिनक्स संकेतहरू सहित नियन्त्रण गर्दछ। तातो पुन: सुरु, आदि। यस थ्रेडमा हुन्छ एसिन्क्रोनस र "नन-ब्लकिङ"। सामान्यतया, मुख्य थ्रेडले सबै महत्वपूर्ण कार्यक्षमता प्रक्रियाहरूलाई समन्वय गर्दछ जसलाई चलाउनको लागि CPU को ठूलो मात्रा आवश्यक पर्दैन। यसले धेरै नियन्त्रण कोडलाई एकल थ्रेड गरिएको जस्तै लेख्न अनुमति दिन्छ।
• कामदार: पूर्वनिर्धारित रूपमा, दूतले प्रणालीमा प्रत्येक हार्डवेयर थ्रेडको लागि कार्यकर्ता थ्रेड सिर्जना गर्दछ, यो विकल्प प्रयोग गरेर नियन्त्रण गर्न सकिन्छ। --concurrency। प्रत्येक कार्यकर्ता थ्रेडले "नन-ब्लकिङ" घटना लुप चलाउँछ, जुन प्रत्येक श्रोतालाई सुन्नको लागि जिम्मेवार हुन्छ; लेखनको समयमा (जुलाई 29, 2017) त्यहाँ श्रोताको कुनै शर्डिङ छैन, नयाँ जडानहरू स्वीकार गर्दै, फिल्टर स्ट्याक इन्स्ट्यान्टियट गर्दै। जडान, र जडानको जीवनकालमा सबै इनपुट/आउटपुट (IO) सञ्चालनहरू प्रशोधन गर्दै। फेरि, यसले धेरै जसो जडान ह्यान्डलिंग कोडलाई एकल थ्रेड गरिएको जस्तो लेख्न अनुमति दिन्छ।
• फाइल फ्लशर: प्रत्येक फाइल जुन दूतले लेख्छ, मुख्य रूपमा लगहरू पहुँच गर्दछ, हाल एक स्वतन्त्र ब्लकिङ थ्रेड छ। यो प्रयोग गर्दा पनि फाइल प्रणाली द्वारा क्यास फाइलहरूमा लेख्नु तथ्यको कारण हो O_NONBLOCK कहिलेकाहीं अवरुद्ध हुन सक्छ (सास)। जब कार्यकर्ता थ्रेडहरूले फाइलमा लेख्न आवश्यक हुन्छ, डाटा वास्तवमा मेमोरीको बफरमा सारिन्छ जहाँ यो अन्ततः थ्रेड मार्फत फ्लश हुन्छ। फाइल फ्लश। यो कोडको एउटा क्षेत्र हो जहाँ प्राविधिक रूपमा सबै कार्यकर्ता थ्रेडहरूले मेमोरी बफर भर्ने प्रयास गर्दा समान लक ब्लक गर्न सक्छन्।

जडान ह्यान्डलिङ

माथि छोटकरीमा छलफल गरिएझैं, सबै कार्यकर्ता थ्रेडहरूले सबै श्रोताहरूलाई कुनै पनि शार्डिङ बिना सुन्छन्। यसरी, कर्नेललाई कार्यकर्ता थ्रेडहरूमा स्वीकृत सकेटहरू पठाउन प्रयोग गरिन्छ। आधुनिक कर्नेलहरू सामान्यतया यसमा धेरै राम्रा हुन्छन्, तिनीहरूले समान सकेटमा सुन्ने अन्य थ्रेडहरू प्रयोग गर्न सुरु गर्नु अघि, र राउन्ड रोबिन प्रयोग नगरी काममा थ्रेड भर्न प्रयास गर्न इनपुट/आउटपुट (IO) प्राथमिकता बूस्टिङ जस्ता सुविधाहरू प्रयोग गर्छन्। प्रत्येक अनुरोध प्रशोधन गर्न लक (Spinlock)।
एक पटक कार्यकर्ता थ्रेडमा जडान स्वीकृत भएपछि, यसले त्यो थ्रेडलाई कहिल्यै छोड्दैन। जडानको सबै थप प्रशोधन कुनै पनि फर्वार्डिङ व्यवहार सहित, कार्यकर्ता थ्रेडमा पूर्ण रूपमा ह्यान्डल गरिन्छ।

यसले धेरै महत्त्वपूर्ण परिणामहरू छन्:

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

नन ब्लकिङ भनेको के हो?

मुख्य र कार्यकर्ता थ्रेडहरूले कसरी काम गर्छ भनेर छलफल गर्दा "नन-ब्लकिङ" शब्द धेरै पटक प्रयोग गरिएको छ। सबै कोडहरू यो धारणामा लेखिएको छ कि केहि पनि रोकिएको छैन। यद्यपि, यो पूर्ण रूपमा सत्य होइन (के पूर्ण रूपमा सत्य होइन?)

दूतले धेरै लामो प्रक्रिया लकहरू प्रयोग गर्दछ:

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

थ्रेड स्थानीय भण्डारण

दूतले मुख्य थ्रेडको जिम्मेवारीलाई कार्यकर्ता थ्रेडको जिम्मेवारीबाट अलग गर्ने तरिकाले गर्दा, मुख्य थ्रेडमा जटिल प्रशोधन गर्न सकिन्छ र त्यसपछि प्रत्येक कार्यकर्ता थ्रेडलाई अत्यधिक समवर्ती रूपमा प्रदान गर्न सकिन्छ। यो खण्डले उच्च स्तरमा Envoy Thread Local Storage (TLS) लाई वर्णन गर्दछ। अर्को खण्डमा म यसलाई क्लस्टर व्यवस्थापन गर्न कसरी प्रयोग गरिन्छ भनेर वर्णन गर्नेछु।


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

राजदूतको TLS (थ्रेड स्थानीय भण्डारण) प्रणाली निम्नानुसार काम गर्दछ:

• मुख्य थ्रेडमा चलिरहेको कोडले सम्पूर्ण प्रक्रियाको लागि TLS स्लट आवंटित गर्न सक्छ। यद्यपि यो अमूर्त छ, व्यवहारमा यो एक भेक्टरमा अनुक्रमणिका हो, O(1) पहुँच प्रदान गर्दछ।
• मुख्य थ्रेडले यसको स्लटमा मनमानी डाटा स्थापना गर्न सक्छ। जब यो गरिन्छ, डाटा प्रत्येक कार्यकर्ता थ्रेडमा सामान्य घटना लुप घटनाको रूपमा प्रकाशित हुन्छ।
• कार्यकर्ता थ्रेडहरूले तिनीहरूको TLS स्लटबाट पढ्न र त्यहाँ उपलब्ध कुनै पनि थ्रेड-स्थानीय डेटा पुन: प्राप्त गर्न सक्छन्।

यद्यपि यो एक धेरै सरल र अविश्वसनीय रूपमा शक्तिशाली प्रतिमान हो, यो RCU (पढ्नुहोस्-प्रतिलिपि-अपडेट) अवरुद्धको अवधारणासँग धेरै मिल्दोजुल्दो छ। अनिवार्य रूपमा, कामदार थ्रेडहरूले काम चलिरहेको बेला TLS स्लटहरूमा कुनै पनि डेटा परिवर्तनहरू देख्दैनन्। परिवर्तन कार्य घटनाहरू बीचको बाँकी अवधिमा मात्र हुन्छ।

दूतले यसलाई दुई फरक तरिकामा प्रयोग गर्दछ:

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

क्लस्टर अपडेट थ्रेडिङ

यस खण्डमा, म क्लस्टर व्यवस्थापन गर्न TLS (थ्रेड स्थानीय भण्डारण) कसरी प्रयोग गरिन्छ भनेर वर्णन गर्नेछु। क्लस्टर व्यवस्थापनले xDS API र/वा DNS प्रशोधन, साथै स्वास्थ्य जाँच समावेश गर्दछ।


क्लस्टर प्रवाह व्यवस्थापनले निम्न अवयव र चरणहरू समावेश गर्दछ:

1. क्लस्टर प्रबन्धक दूत भित्रको एउटा कम्पोनेन्ट हो जसले सबै ज्ञात क्लस्टर अपस्ट्रिमहरू, क्लस्टर डिस्कवरी सर्भिस (CDS) API, Secret Discovery Service (SDS) र Endpoint Discovery Service (EDS) APIs, DNS, र सक्रिय बाह्य जाँचहरू प्रबन्ध गर्दछ। स्वास्थ्य जाँच। यो प्रत्येक अपस्ट्रीम क्लस्टरको "अन्ततः लगातार" दृश्य सिर्जना गर्न जिम्मेवार छ, जसमा पत्ता लगाइएका होस्टहरू साथै स्वास्थ्य स्थिति समावेश छ।
2. स्वास्थ्य परीक्षकले सक्रिय स्वास्थ्य जाँच गर्दछ र क्लस्टर प्रबन्धकलाई स्वास्थ्य स्थिति परिवर्तनहरू रिपोर्ट गर्दछ।
3. CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS क्लस्टर सदस्यता निर्धारण गर्न गरिन्छ। राज्य परिवर्तन क्लस्टर प्रबन्धकमा फर्काइन्छ।
4. प्रत्येक कार्यकर्ता थ्रेडले लगातार घटना लुप कार्यान्वयन गर्दछ।
5. जब क्लस्टर प्रबन्धकले क्लस्टरको लागि राज्य परिवर्तन भएको छ भनेर निर्धारण गर्दछ, यसले क्लस्टरको अवस्थाको नयाँ पढ्न-मात्र स्न्यापसट सिर्जना गर्दछ र यसलाई प्रत्येक कार्यकर्ता थ्रेडमा पठाउँछ।
6. अर्को शान्त अवधिमा, कार्यकर्ता थ्रेडले आवंटित TLS स्लटमा स्न्यापसट अपडेट गर्नेछ।
7. ब्यालेन्स लोड गर्न होस्टलाई निर्धारण गर्ने I/O घटनाको समयमा, लोड ब्यालेन्सरले होस्टको बारेमा जानकारी प्राप्त गर्न TLS (थ्रेड स्थानीय भण्डारण) स्लट अनुरोध गर्नेछ। यसका लागि तालाहरू आवश्यक पर्दैन। यो पनि नोट गर्नुहोस् कि TLS ले अद्यावधिक घटनाहरू ट्रिगर गर्न सक्छ ताकि लोड ब्यालेन्सरहरू र अन्य कम्पोनेन्टहरूले क्यासहरू, डेटा संरचनाहरू, आदि पुन: गणना गर्न सक्छन्। यो यस पोष्टको दायरा बाहिर छ, तर कोडमा विभिन्न ठाउँहरूमा प्रयोग गरिन्छ।

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

TLS को प्रयोग गर्ने अन्य उपप्रणालीहरू

TLS (थ्रेड लोकल स्टोरेज) र RCU (Read Copy Update) दूतमा व्यापक रूपमा प्रयोग गरिन्छ।

प्रयोगका उदाहरणहरू:

• कार्यान्वयनको क्रममा कार्यक्षमता परिवर्तन गर्ने संयन्त्र: सक्षम गरिएको कार्यक्षमताको हालको सूची मुख्य थ्रेडमा गणना गरिएको छ। प्रत्येक कार्यकर्ता थ्रेडलाई RCU सिमान्टिक्स प्रयोग गरेर पढ्न मात्र मिल्ने स्न्यापसट दिइन्छ।
• मार्ग तालिकाहरू प्रतिस्थापन गर्दै: RDS (Route Discovery Service) द्वारा उपलब्ध गराइएका मार्ग तालिकाहरूका लागि, मुख्य थ्रेडमा रूट तालिकाहरू सिर्जना गरिएका छन्। RCU (Read Copy Update) सिमान्टिक्स प्रयोग गरेर प्रत्येक कार्यकर्ता थ्रेडमा पढ्ने मात्रको स्न्यापसट पछि उपलब्ध गराइनेछ। यसले मार्ग तालिकाहरू परिवर्तन गर्न परमाणु रूपमा कुशल बनाउँछ।
• HTTP हेडर क्यासिङ: यो बाहिर जान्छ, प्रत्येक अनुरोधको लागि HTTP हेडर गणना (~ 25K + RPS प्रति कोर चलिरहेको बेला) धेरै महँगो छ। दूतले केन्द्रीय रूपमा लगभग हरेक आधा सेकेन्डमा हेडर गणना गर्दछ र TLS र RCU मार्फत प्रत्येक कार्यकर्तालाई प्रदान गर्दछ।

त्यहाँ अन्य केसहरू छन्, तर अघिल्लो उदाहरणहरूले TLS के प्रयोग गरिन्छ भन्ने राम्रो बुझाइ प्रदान गर्नुपर्छ।

ज्ञात प्रदर्शन त्रुटिहरू

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

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

निष्कर्ष

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

कोडमा लिङ्कहरू

यस पोस्टमा छलफल गरिएको इन्टरफेस र हेडर कार्यान्वयनका साथ फाइलहरूको लिङ्कहरू:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

स्रोत: www.habr.com