लेखाचे भाषांतर: दूत थ्रेडिंग मॉडेल - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

मला हा लेख खूपच मनोरंजक वाटला आणि दूत बहुतेकदा “इस्टिओ” चा भाग म्हणून किंवा कुबर्नेट्सचा “इनग्रेस कंट्रोलर” म्हणून वापरला जात असल्याने, बहुतेक लोकांचा त्याच्याशी समान थेट संवाद नसतो, उदाहरणार्थ, सामान्य Nginx किंवा Haproxy प्रतिष्ठापन. तथापि, काहीतरी खंडित झाल्यास, ते आतून कसे कार्य करते हे समजून घेणे चांगले होईल. मी विशेष शब्दांसह जास्तीत जास्त मजकूर रशियन भाषेत अनुवादित करण्याचा प्रयत्न केला; ज्यांना हे पाहणे वेदनादायक वाटते त्यांच्यासाठी मी मूळ कंसात सोडले. मांजर मध्ये आपले स्वागत आहे.

दूत कोडबेससाठी निम्न-स्तरीय तांत्रिक दस्तऐवजीकरण सध्या खूपच विरळ आहे. यावर उपाय म्हणून, मी दूताच्या विविध उपप्रणालींबद्दल ब्लॉग पोस्ट्सची मालिका करण्याची योजना आखत आहे. हा पहिला लेख असल्याने, कृपया मला कळवा की तुम्हाला काय वाटते आणि भविष्यातील लेखांमध्ये तुम्हाला काय स्वारस्य असेल.

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

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

दूत तीन वेगवेगळ्या प्रकारचे प्रवाह वापरतात:

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

कनेक्शन हाताळणी

वर थोडक्यात चर्चा केल्याप्रमाणे, सर्व कामगार थ्रेड्स कोणत्याही शार्डिंगशिवाय सर्व श्रोत्यांना ऐकतात. अशाप्रकारे, कर्नलचा वापर कामगार थ्रेड्सवर स्वीकारलेले सॉकेट्स कृपापूर्वक पाठवण्यासाठी केला जातो. आधुनिक कर्नल सामान्यत: यामध्ये खूप चांगले असतात, ते समान सॉकेटवर ऐकणारे इतर थ्रेड्स वापरणे सुरू करण्यापूर्वी आणि राऊंड रॉबिन न वापरता थ्रेडला कामासह भरण्याचा प्रयत्न करण्यासाठी इनपुट/आउटपुट (IO) प्रायोरिटी बूस्टिंग सारख्या वैशिष्ट्यांचा वापर करतात. प्रत्येक विनंतीवर प्रक्रिया करण्यासाठी लॉकिंग (स्पिनलॉक).
वर्कर थ्रेडवर एकदा कनेक्शन स्वीकारले की ते तो धागा सोडत नाही. कोणत्याही फॉरवर्डिंग वर्तनासह कनेक्शनची पुढील सर्व प्रक्रिया पूर्णपणे वर्कर थ्रेडमध्ये हाताळली जाते.

याचे अनेक महत्त्वपूर्ण परिणाम आहेत:

• Envoy मधील सर्व कनेक्शन पूल वर्कर थ्रेडला नियुक्त केले आहेत. म्हणून, जरी HTTP/2 कनेक्शन पूल एका वेळी प्रत्येक अपस्ट्रीम होस्टला फक्त एक कनेक्शन बनवतात, जर चार वर्कर थ्रेड्स असतील, तर स्थिर स्थितीत प्रत्येक अपस्ट्रीम होस्टवर चार HTTP/2 कनेक्शन असतील.
• दूत अशा प्रकारे कार्य करण्याचे कारण म्हणजे सर्वकाही एकाच वर्कर थ्रेडवर ठेवून, जवळजवळ सर्व कोड ब्लॉक न करता लिहिता येतात आणि जणू ते एकच थ्रेड केलेले असतात. हे डिझाइन जवळजवळ अमर्यादित कामगार थ्रेड्सवर बरेच कोड आणि स्केल लिहिणे सोपे करते.
• तथापि, मुख्य उपायांपैकी एक म्हणजे मेमरी पूल आणि कनेक्शन कार्यक्षमतेच्या दृष्टिकोनातून, कॉन्फिगर करणे खरोखर खूप महत्वाचे आहे. --concurrency. आवश्‍यकतेपेक्षा अधिक वर्कर थ्रेड असल्‍याने स्‍मृती वाया जाईल, अधिक निष्क्रिय कनेक्‍शन तयार होतील आणि कनेक्‍शन पूलिंगचा दर कमी होईल. Lyft येथे, आमचे दूत साइडकार कंटेनर्स अतिशय कमी संयोगाने चालतात जेणेकरुन कार्यप्रदर्शन त्यांच्या शेजारी बसलेल्या सेवांशी जुळते. आम्ही एंवॉयला एज प्रॉक्सी म्हणून फक्त जास्तीत जास्त समांतरतेवर चालवतो.

नॉन-ब्लॉकिंग म्हणजे काय?

मुख्य आणि कार्यकर्ता धागे कसे कार्य करतात यावर चर्चा करताना "नॉन-ब्लॉकिंग" हा शब्द आतापर्यंत अनेक वेळा वापरला गेला आहे. सर्व कोड असे गृहित धरून लिहिलेले आहे की काहीही कधीही अवरोधित केले जात नाही. तथापि, हे पूर्णपणे सत्य नाही (काय संपूर्णपणे सत्य नाही?).

दूत अनेक लांब प्रक्रिया लॉक वापरतात:

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

थ्रेड स्थानिक स्टोरेज

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


आधीच वर्णन केल्याप्रमाणे, मुख्य धागा दूत प्रक्रियेतील अक्षरशः सर्व व्यवस्थापन आणि नियंत्रण विमान कार्यक्षमता हाताळतो. कंट्रोल प्लेन येथे थोडे ओव्हरलोड केलेले आहे, परंतु जेव्हा तुम्ही एंवॉय प्रक्रियेमध्येच ते पाहता आणि वर्कर थ्रेड्स करत असलेल्या फॉरवर्डिंगशी त्याची तुलना करता तेव्हा त्याचा अर्थ होतो. सामान्य नियम असा आहे की मुख्य थ्रेड प्रक्रिया काही कार्य करते आणि नंतर त्या कामाच्या परिणामानुसार प्रत्येक कार्यकर्ता थ्रेड अद्यतनित करणे आवश्यक आहे. या प्रकरणात, वर्कर थ्रेडला प्रत्येक प्रवेशावर लॉक घेण्याची आवश्यकता नाही.

दूताची TLS (थ्रेड लोकल स्टोरेज) प्रणाली खालीलप्रमाणे कार्य करते:

• मुख्य थ्रेडवर चालणारा कोड संपूर्ण प्रक्रियेसाठी TLS स्लॉट देऊ शकतो. जरी हे अ‍ॅब्स्ट्रॅक्ट केलेले असले तरी, व्यवहारात हे वेक्टरमध्ये निर्देशांक आहे, जे O(1) प्रवेश प्रदान करते.
• मुख्य थ्रेड त्याच्या स्लॉटमध्ये अनियंत्रित डेटा स्थापित करू शकतो. हे पूर्ण झाल्यावर, डेटा प्रत्येक कामगार थ्रेडवर सामान्य इव्हेंट लूप इव्हेंट म्हणून प्रकाशित केला जातो.
• वर्कर थ्रेड्स त्यांच्या TLS स्लॉटमधून वाचू शकतात आणि तेथे उपलब्ध असलेला कोणताही थ्रेड-स्थानिक डेटा पुनर्प्राप्त करू शकतात.

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

दूत हे दोन वेगवेगळ्या प्रकारे वापरतात:

• प्रत्येक वर्कर थ्रेडवर वेगवेगळा डेटा संग्रहित करून, कोणत्याही ब्लॉकिंगशिवाय डेटा ऍक्सेस केला जाऊ शकतो.
• प्रत्येक वर्कर थ्रेडवर केवळ-वाचनीय मोडमध्ये जागतिक डेटासाठी सामायिक पॉइंटर राखून. अशा प्रकारे, प्रत्येक कामगार थ्रेडमध्ये डेटा संदर्भ संख्या असते जी काम चालू असताना कमी करता येत नाही. जेव्हा सर्व कामगार शांत होतील आणि नवीन सामायिक डेटा अपलोड करतील तेव्हाच जुना डेटा नष्ट होईल. हे RCU सारखेच आहे.

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

या विभागात, मी क्लस्टर व्यवस्थापित करण्यासाठी TLS (थ्रेड लोकल स्टोरेज) कसे वापरले जाते याचे वर्णन करेन. क्लस्टर व्यवस्थापनामध्ये xDS API आणि/किंवा DNS प्रक्रिया, तसेच आरोग्य तपासणी समाविष्ट आहे.


क्लस्टर प्रवाह व्यवस्थापनामध्ये खालील घटक आणि पायऱ्यांचा समावेश होतो:

1. क्लस्टर मॅनेजर हा दूतमधील एक घटक आहे जो सर्व ज्ञात क्लस्टर अपस्ट्रीम, क्लस्टर डिस्कव्हरी सर्व्हिस (CDS) API, सिक्रेट डिस्कव्हरी सर्व्हिस (SDS) आणि एंडपॉइंट डिस्कव्हरी सर्व्हिस (EDS) API, DNS आणि सक्रिय बाह्य तपासणी व्यवस्थापित करतो. आरोग्य तपासणी. प्रत्येक अपस्ट्रीम क्लस्टरचे "शेवटी सातत्यपूर्ण" दृश्य तयार करण्यासाठी ते जबाबदार आहे, ज्यामध्ये शोधलेल्या यजमानांचा तसेच आरोग्य स्थितीचा समावेश आहे.
2. आरोग्य तपासक सक्रिय आरोग्य तपासणी करतो आणि आरोग्य स्थितीतील बदलांचा अहवाल क्लस्टर व्यवस्थापकाला देतो.
3. CDS (क्लस्टर डिस्कव्हरी सर्व्हिस) / SDS (गुप्त शोध सेवा) / EDS (एंडपॉइंट डिस्कव्हरी सर्व्हिस) / DNS क्लस्टर सदस्यत्व निश्चित करण्यासाठी केले जातात. राज्य बदल क्लस्टर व्यवस्थापकाकडे परत केला जातो.
4. प्रत्येक वर्कर थ्रेड सतत इव्हेंट लूप कार्यान्वित करतो.
5. जेव्हा क्लस्टर मॅनेजर निर्धारित करतो की क्लस्टरची स्थिती बदलली आहे, तेव्हा तो क्लस्टरच्या स्थितीचा एक नवीन-वाचनीय स्नॅपशॉट तयार करतो आणि तो प्रत्येक वर्कर थ्रेडला पाठवतो.
6. पुढील शांत कालावधीत, कार्यकर्ता थ्रेड वाटप केलेल्या TLS स्लॉटमध्ये स्नॅपशॉट अपडेट करेल.
7. आय/ओ इव्हेंट दरम्यान जे होस्टने बॅलन्स लोड करण्यासाठी निर्धारित केले पाहिजे, लोड बॅलन्सर होस्टबद्दल माहिती मिळविण्यासाठी TLS (थ्रेड लोकल स्टोरेज) स्लॉटची विनंती करेल. यासाठी लॉकची आवश्यकता नाही. हे देखील लक्षात घ्या की TLS अपडेट इव्हेंट्स देखील ट्रिगर करू शकते जेणेकरून लोड बॅलन्सर आणि इतर घटक कॅशे, डेटा स्ट्रक्चर्स इत्यादीची पुनर्गणना करू शकतात. हे या पोस्टच्या व्याप्तीच्या पलीकडे आहे, परंतु कोडमध्ये विविध ठिकाणी वापरले जाते.

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

इतर उपप्रणाली जी TLS चा वापर करतात

TLS (थ्रेड लोकल स्टोरेज) आणि RCU (रीड कॉपी अपडेट) एन्वॉयमध्ये मोठ्या प्रमाणावर वापरले जातात.

वापराची उदाहरणे:

• अंमलबजावणी दरम्यान कार्यक्षमता बदलण्याची यंत्रणा: सक्षम कार्यक्षमतेची वर्तमान सूची मुख्य थ्रेडमध्ये मोजली जाते. प्रत्येक वर्कर थ्रेडला RCU शब्दार्थ वापरून केवळ-वाचनीय स्नॅपशॉट दिला जातो.
• मार्ग सारण्या बदलत आहे: RDS (Route Discovery Service) द्वारे प्रदान केलेल्या मार्ग सारण्यांसाठी, मुख्य थ्रेडवर रूट टेबल तयार केले जातात. RCU (Read Copy Update) शब्दार्थ वापरून प्रत्येक वर्कर थ्रेडला नंतर केवळ-वाचनीय स्नॅपशॉट प्रदान केले जाईल. यामुळे मार्ग सारण्या बदलणे अणुदृष्ट्या कार्यक्षम बनते.
• HTTP शीर्षलेख कॅशिंग: असे दिसून आले की, प्रत्येक विनंतीसाठी HTTP शीर्षलेख मोजणे (~25K+ RPS प्रति कोर चालू असताना) खूप महाग आहे. दूत मध्यवर्तीपणे प्रत्येक अर्ध्या सेकंदाला शीर्षलेखाची गणना करतो आणि प्रत्येक कामगाराला TLS आणि RCU द्वारे प्रदान करतो.

इतर प्रकरणे आहेत, परंतु मागील उदाहरणांनी TLS कशासाठी वापरला जातो याची चांगली समज दिली पाहिजे.

ज्ञात कामगिरी तोटे

दूत एकंदरीत चांगली कामगिरी करत असताना, काही उल्लेखनीय क्षेत्रे आहेत ज्याकडे लक्ष देणे आवश्यक आहे जेव्हा ते खूप उच्च समांतरता आणि थ्रूपुटसह वापरले जाते:

• या लेखात वर्णन केल्याप्रमाणे, सध्या सर्व वर्कर थ्रेड्स ऍक्सेस लॉग मेमरी बफरवर लिहिताना लॉक प्राप्त करतात. उच्च समरूपता आणि उच्च थ्रूपुटवर, अंतिम फाइलवर लिहिताना तुम्हाला प्रत्येक कामगार थ्रेडसाठी अ‍ॅक्सेस लॉग बॅच करणे आवश्यक आहे. वैकल्पिकरित्या, तुम्ही प्रत्येक वर्कर थ्रेडसाठी स्वतंत्र प्रवेश लॉग तयार करू शकता.
• जरी आकडेवारी अत्यंत ऑप्टिमाइझ केली गेली असली तरी, खूप उच्च समांतरता आणि थ्रूपुटमध्ये वैयक्तिक आकडेवारीवर अणु विवाद होण्याची शक्यता आहे. या समस्येचे निराकरण म्हणजे मध्यवर्ती काउंटरच्या नियतकालिक रीसेटसह प्रति कामगार थ्रेड काउंटर. यावर पुढील पोस्टमध्ये चर्चा केली जाईल.
• दूताला अशा परिस्थितीत तैनात केले असल्यास सध्याचे आर्किटेक्चर चांगले कार्य करणार नाही जेथे महत्त्वपूर्ण प्रक्रिया संसाधने आवश्यक असलेले फारच कमी कनेक्शन आहेत. कामगार थ्रेड्समध्ये कनेक्शन समान रीतीने वितरीत केले जातील याची कोणतीही हमी नाही. हे कार्यकर्ता कनेक्शन संतुलन लागू करून सोडवले जाऊ शकते, जे कामगार थ्रेड्समधील कनेक्शनची देवाणघेवाण करण्यास अनुमती देईल.

निष्कर्ष

एंवॉयचे थ्रेडिंग मॉडेल योग्यरित्या कॉन्फिगर केले नसल्यास संभाव्य अपव्यय मेमरी आणि कनेक्शनच्या खर्चावर प्रोग्रामिंग सुलभता आणि मोठ्या प्रमाणात समांतरता प्रदान करण्यासाठी डिझाइन केले आहे. हे मॉडेल खूप उच्च थ्रेड संख्या आणि थ्रूपुटवर खूप चांगले कार्य करण्यास अनुमती देते.
मी Twitter वर थोडक्यात नमूद केल्याप्रमाणे, डिझाईन 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