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

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

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

एनवॉय के बारे में मुझे मिलने वाले सबसे आम तकनीकी प्रश्नों में से एक उसके द्वारा उपयोग किए जाने वाले थ्रेडिंग मॉडल का निम्न-स्तरीय विवरण मांगना है। इस पोस्ट में, मैं वर्णन करूंगा कि कैसे एन्वॉय थ्रेड्स से कनेक्शन मैप करता है, साथ ही थ्रेड लोकल स्टोरेज सिस्टम का उपयोग करता है जो कोड को अधिक समानांतर और उच्च-प्रदर्शन बनाने के लिए आंतरिक रूप से उपयोग करता है।

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

दूत तीन अलग-अलग प्रकार की धाराओं का उपयोग करता है:

• मुख्य: यह थ्रेड प्रक्रिया स्टार्टअप और समाप्ति को नियंत्रित करता है, एक्सडीएस (एक्सडिस्कवरी सर्विस) एपीआई की सभी प्रोसेसिंग, जिसमें डीएनएस, स्वास्थ्य जांच, सामान्य क्लस्टर और रनटाइम प्रबंधन, सांख्यिकी रीसेट, प्रशासन और सामान्य प्रक्रिया प्रबंधन - लिनक्स सिग्नल। हॉट रीस्टार्ट इत्यादि शामिल हैं। इस थ्रेड में होता है अतुल्यकालिक और "गैर-अवरुद्ध"। सामान्य तौर पर, मुख्य थ्रेड सभी महत्वपूर्ण कार्यक्षमता प्रक्रियाओं का समन्वय करता है जिन्हें चलाने के लिए बड़ी मात्रा में सीपीयू की आवश्यकता नहीं होती है। यह अधिकांश नियंत्रण कोड को ऐसे लिखने की अनुमति देता है जैसे कि वह सिंगल थ्रेडेड हो।
• कार्यकर्ता: डिफ़ॉल्ट रूप से, एन्वॉय सिस्टम में प्रत्येक हार्डवेयर थ्रेड के लिए एक वर्कर थ्रेड बनाता है, इसे विकल्प का उपयोग करके नियंत्रित किया जा सकता है --concurrency. प्रत्येक कार्यकर्ता थ्रेड एक "नॉन-ब्लॉकिंग" इवेंट लूप चलाता है, जो प्रत्येक श्रोता को सुनने के लिए जिम्मेदार है; लेखन के समय (29 जुलाई, 2017) श्रोता की कोई शार्डिंग नहीं है, नए कनेक्शन स्वीकार करना, फ़िल्टर स्टैक को इंस्टेंट करना कनेक्शन, और कनेक्शन के जीवनकाल के दौरान सभी इनपुट/आउटपुट (आईओ) संचालन को संसाधित करना। फिर, यह अधिकांश कनेक्शन हैंडलिंग कोड को ऐसे लिखने की अनुमति देता है जैसे कि वह सिंगल थ्रेडेड हो।
• फ़ाइल फ़्लशर: प्रत्येक फ़ाइल जो दूत लिखता है, मुख्य रूप से एक्सेस लॉग में, वर्तमान में एक स्वतंत्र अवरोधक थ्रेड होता है। यह इस तथ्य के कारण है कि उपयोग करते समय भी फ़ाइल सिस्टम द्वारा कैश की गई फ़ाइलों को लिखना O_NONBLOCK कभी-कभी अवरुद्ध हो सकता है (आह)। जब वर्कर थ्रेड को किसी फ़ाइल में लिखने की आवश्यकता होती है, तो डेटा वास्तव में मेमोरी में एक बफर में ले जाया जाता है जहां अंततः इसे थ्रेड के माध्यम से फ्लश किया जाता है फ़ाइल फ्लश. यह कोड का एक क्षेत्र है जहां तकनीकी रूप से सभी वर्कर थ्रेड मेमोरी बफर को भरने का प्रयास करते समय एक ही लॉक को ब्लॉक कर सकते हैं।

कनेक्शन संचालन

जैसा कि ऊपर संक्षेप में चर्चा की गई है, सभी कार्यकर्ता सूत्र बिना किसी खंडन के सभी श्रोताओं को सुनते हैं। इस प्रकार, कर्नेल का उपयोग वर्कर थ्रेड्स को स्वीकृत सॉकेट भेजने के लिए किया जाता है। आधुनिक कर्नेल आम तौर पर इसमें बहुत अच्छे होते हैं, वे अन्य थ्रेड का उपयोग शुरू करने से पहले एक थ्रेड को काम से भरने की कोशिश करने के लिए इनपुट/आउटपुट (आईओ) प्राथमिकता बढ़ाने जैसी सुविधाओं का उपयोग करते हैं जो एक ही सॉकेट पर सुन रहे हैं, और राउंड रॉबिन का उपयोग भी नहीं करते हैं। प्रत्येक अनुरोध को संसाधित करने के लिए लॉकिंग (स्पिनलॉक)।
एक बार जब कोई कनेक्शन वर्कर थ्रेड पर स्वीकार कर लिया जाता है, तो वह उस थ्रेड को कभी नहीं छोड़ता है। कनेक्शन की सभी आगे की प्रक्रिया पूरी तरह से वर्कर थ्रेड में नियंत्रित की जाती है, जिसमें कोई भी अग्रेषण व्यवहार भी शामिल है।

इसके कई महत्वपूर्ण परिणाम हैं:

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

नॉन-ब्लॉकिंग का क्या मतलब है?

मुख्य और वर्कर थ्रेड कैसे काम करते हैं, इस पर चर्चा करते समय "नॉन-ब्लॉकिंग" शब्द का उपयोग अब तक कई बार किया गया है। सभी कोड इस धारणा पर लिखे गए हैं कि कुछ भी कभी अवरुद्ध नहीं होता है। हालाँकि, यह पूरी तरह सच नहीं है (क्या पूरी तरह सच नहीं है?)।

दूत कई लंबी प्रक्रिया ताले का उपयोग करता है:

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

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

जिस तरह से दूत मुख्य धागे की जिम्मेदारियों को कार्यकर्ता धागे की जिम्मेदारियों से अलग करता है, उसके कारण एक आवश्यकता है कि जटिल प्रसंस्करण मुख्य धागे पर किया जा सकता है और फिर प्रत्येक कार्यकर्ता धागे को अत्यधिक समवर्ती तरीके से प्रदान किया जा सकता है। यह अनुभाग उच्च स्तर पर एन्वॉय थ्रेड लोकल स्टोरेज (टीएलएस) का वर्णन करता है। अगले भाग में मैं बताऊंगा कि क्लस्टर को प्रबंधित करने के लिए इसका उपयोग कैसे किया जाता है।


जैसा कि पहले ही बताया गया है, मुख्य थ्रेड दूत प्रक्रिया में वस्तुतः सभी प्रबंधन और नियंत्रण विमान कार्यक्षमता को संभालता है। यहां नियंत्रण विमान थोड़ा अतिभारित है, लेकिन जब आप इसे दूत प्रक्रिया के भीतर ही देखते हैं और इसकी तुलना कार्यकर्ता थ्रेड द्वारा किए जाने वाले अग्रेषण से करते हैं, तो यह समझ में आता है। सामान्य नियम यह है कि मुख्य थ्रेड प्रक्रिया कुछ कार्य करती है, और फिर उसे प्रत्येक वर्कर थ्रेड को उस कार्य के परिणाम के अनुसार अद्यतन करने की आवश्यकता होती है। इस मामले में, वर्कर थ्रेड को प्रत्येक एक्सेस पर लॉक प्राप्त करने की आवश्यकता नहीं है.

दूत की टीएलएस (थ्रेड लोकल स्टोरेज) प्रणाली निम्नानुसार काम करती है:

• मुख्य थ्रेड पर चलने वाला कोड पूरी प्रक्रिया के लिए एक टीएलएस स्लॉट आवंटित कर सकता है। यद्यपि यह अमूर्त है, व्यवहार में यह एक वेक्टर में एक सूचकांक है, जो O(1) पहुंच प्रदान करता है।
• मुख्य थ्रेड अपने स्लॉट में मनमाना डेटा इंस्टॉल कर सकता है। जब यह किया जाता है, तो डेटा प्रत्येक वर्कर थ्रेड पर एक सामान्य इवेंट लूप इवेंट के रूप में प्रकाशित किया जाता है।
• वर्कर थ्रेड अपने टीएलएस स्लॉट से पढ़ सकते हैं और वहां उपलब्ध किसी भी थ्रेड-स्थानीय डेटा को पुनः प्राप्त कर सकते हैं।

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

दूत इसका उपयोग दो अलग-अलग तरीकों से करता है:

• प्रत्येक वर्कर थ्रेड पर अलग-अलग डेटा संग्रहीत करके, डेटा को बिना किसी अवरोध के एक्सेस किया जा सकता है।
• प्रत्येक वर्कर थ्रेड पर रीड-ओनली मोड में वैश्विक डेटा के लिए एक साझा पॉइंटर बनाए रखकर। इस प्रकार, प्रत्येक कार्यकर्ता थ्रेड में एक डेटा संदर्भ गणना होती है जिसे कार्य चलने के दौरान कम नहीं किया जा सकता है। जब सभी कर्मचारी शांत हो जाएंगे और नया साझा डेटा अपलोड करेंगे तभी पुराना डेटा नष्ट हो जाएगा। यह आरसीयू के समान है।

क्लस्टर अद्यतन थ्रेडिंग

इस अनुभाग में, मैं वर्णन करूंगा कि क्लस्टर को प्रबंधित करने के लिए टीएलएस (थ्रेड लोकल स्टोरेज) का उपयोग कैसे किया जाता है। क्लस्टर प्रबंधन में एक्सडीएस एपीआई और/या डीएनएस प्रोसेसिंग के साथ-साथ स्वास्थ्य जांच भी शामिल है।


क्लस्टर प्रवाह प्रबंधन में निम्नलिखित घटक और चरण शामिल हैं:

1. क्लस्टर मैनेजर एन्वॉय के भीतर एक घटक है जो सभी ज्ञात क्लस्टर अपस्ट्रीम, क्लस्टर डिस्कवरी सर्विस (सीडीएस) एपीआई, सीक्रेट डिस्कवरी सर्विस (एसडीएस) और एंडपॉइंट डिस्कवरी सर्विस (ईडीएस) एपीआई, डीएनएस और सक्रिय बाहरी जांच का प्रबंधन करता है। स्वास्थ्य जांच। यह प्रत्येक अपस्ट्रीम क्लस्टर का "अंततः सुसंगत" दृश्य बनाने के लिए ज़िम्मेदार है, जिसमें खोजे गए होस्ट के साथ-साथ स्वास्थ्य स्थिति भी शामिल है।
2. स्वास्थ्य जांचकर्ता एक सक्रिय स्वास्थ्य जांच करता है और क्लस्टर प्रबंधक को स्वास्थ्य स्थिति में बदलाव की रिपोर्ट करता है।
3. क्लस्टर सदस्यता निर्धारित करने के लिए सीडीएस (क्लस्टर डिस्कवरी सर्विस) / एसडीएस (सीक्रेट डिस्कवरी सर्विस) / ईडीएस (एंडपॉइंट डिस्कवरी सर्विस) / डीएनएस का प्रदर्शन किया जाता है। स्थिति परिवर्तन क्लस्टर प्रबंधक को वापस कर दिया जाता है।
4. प्रत्येक वर्कर थ्रेड लगातार एक इवेंट लूप निष्पादित करता है।
5. जब क्लस्टर प्रबंधक यह निर्धारित करता है कि क्लस्टर की स्थिति बदल गई है, तो वह क्लस्टर की स्थिति का एक नया रीड-ओनली स्नैपशॉट बनाता है और इसे प्रत्येक वर्कर थ्रेड को भेजता है।
6. अगली शांत अवधि के दौरान, वर्कर थ्रेड आवंटित टीएलएस स्लॉट में स्नैपशॉट को अपडेट करेगा।
7. I/O इवेंट के दौरान, जो होस्ट को लोड बैलेंस निर्धारित करने के लिए माना जाता है, लोड बैलेंसर होस्ट के बारे में जानकारी प्राप्त करने के लिए टीएलएस (थ्रेड लोकल स्टोरेज) स्लॉट का अनुरोध करेगा। इसमें ताले की आवश्यकता नहीं है. यह भी ध्यान दें कि टीएलएस अद्यतन घटनाओं को भी ट्रिगर कर सकता है ताकि लोड बैलेंसर और अन्य घटक कैश, डेटा संरचनाओं आदि की पुनर्गणना कर सकें। यह इस पोस्ट के दायरे से बाहर है, लेकिन कोड में विभिन्न स्थानों पर इसका उपयोग किया जाता है।

उपरोक्त प्रक्रिया का उपयोग करते हुए, दूत प्रत्येक अनुरोध को बिना किसी अवरोध के संसाधित कर सकता है (पहले वर्णित को छोड़कर)। टीएलएस कोड की जटिलता के अलावा, अधिकांश कोड को यह समझने की आवश्यकता नहीं है कि मल्टीथ्रेडिंग कैसे काम करती है और इसे सिंगल-थ्रेडेड लिखा जा सकता है। इससे बेहतर प्रदर्शन के अलावा अधिकांश कोड लिखना आसान हो जाता है।

अन्य उपप्रणालियाँ जो टीएलएस का उपयोग करती हैं

एनवॉय में टीएलएस (थ्रेड लोकल स्टोरेज) और आरसीयू (रीड कॉपी अपडेट) का व्यापक रूप से उपयोग किया जाता है।

उपयोग करने के उदाहरण:

• निष्पादन के दौरान कार्यक्षमता बदलने का तंत्र: सक्षम कार्यक्षमता की वर्तमान सूची की गणना मुख्य थ्रेड में की जाती है। फिर प्रत्येक वर्कर थ्रेड को RCU शब्दार्थ का उपयोग करके केवल-पढ़ने के लिए स्नैपशॉट दिया जाता है।
• रूट तालिकाओं को बदलना: आरडीएस (रूट डिस्कवरी सर्विस) द्वारा प्रदान की गई रूट टेबल के लिए, रूट टेबल मुख्य थ्रेड पर बनाई जाती हैं। बाद में आरसीयू (रीड कॉपी अपडेट) शब्दार्थ का उपयोग करके प्रत्येक कार्यकर्ता थ्रेड को केवल-पढ़ने के लिए स्नैपशॉट प्रदान किया जाएगा। यह बदलते रूट टेबल को परमाणु रूप से कुशल बनाता है।
• HTTP हेडर कैशिंग: जैसा कि पता चला है, प्रत्येक अनुरोध के लिए HTTP हेडर की गणना करना (प्रति कोर ~25K+ RPS चलाते समय) काफी महंगा है। दूत केंद्रीय रूप से लगभग हर आधे सेकंड में हेडर की गणना करता है और इसे टीएलएस और आरसीयू के माध्यम से प्रत्येक कार्यकर्ता को प्रदान करता है।

अन्य मामले भी हैं, लेकिन पिछले उदाहरणों से यह अच्छी समझ मिलनी चाहिए कि टीएलएस का उपयोग किस लिए किया जाता है।

ज्ञात प्रदर्शन हानियाँ

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

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

निष्कर्ष

एन्वॉय का थ्रेडिंग मॉडल सही तरीके से कॉन्फ़िगर न किए जाने पर संभावित रूप से बेकार मेमोरी और कनेक्शन की कीमत पर प्रोग्रामिंग में आसानी और बड़े पैमाने पर समानता प्रदान करने के लिए डिज़ाइन किया गया है। यह मॉडल इसे बहुत अधिक थ्रेड गिनती और थ्रूपुट पर बहुत अच्छा प्रदर्शन करने की अनुमति देता है।
जैसा कि मैंने ट्विटर पर संक्षेप में उल्लेख किया है, डिज़ाइन डीपीडीके (डेटा प्लेन डेवलपमेंट किट) जैसे पूर्ण उपयोगकर्ता-मोड नेटवर्किंग स्टैक के शीर्ष पर भी चल सकता है, जिसके परिणामस्वरूप पारंपरिक सर्वर पूर्ण एल 7 प्रोसेसिंग के साथ प्रति सेकंड लाखों अनुरोधों को संभाल सकते हैं। यह देखना बहुत दिलचस्प होगा कि अगले कुछ वर्षों में क्या बनेगा।
एक आखिरी त्वरित टिप्पणी: मुझसे कई बार पूछा गया है कि हमने एन्वॉय के लिए 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