दूत. 1 परिचय

अभिवादन! यह एक संक्षिप्त लेख है जो इन प्रश्नों का उत्तर देता है: "दूत क्या है?", "इसकी आवश्यकता क्यों है?" और "कहां से शुरू करें?"

यह क्या है

एन्वॉय एक L4-L7 बैलेंसर है जो C++ में लिखा गया है, जो उच्च प्रदर्शन और उपलब्धता पर केंद्रित है। एक ओर, यह किसी तरह से nginx और haproxy का एक एनालॉग है, जो प्रदर्शन में उनके तुलनीय है। दूसरी ओर, यह माइक्रोसर्विस आर्किटेक्चर की ओर अधिक उन्मुख है और इसकी कार्यक्षमता जावा और गो बैलेंसर्स, जैसे ज़ूल या ट्रैफ़िक से भी बदतर नहीं है।

haproxy/nginx/envoy की तुलना तालिका, यह पूर्ण सत्य होने का दावा नहीं करती है, लेकिन एक सामान्य तस्वीर देती है।

nginx
haproxy
भेजा
ट्रैफ़िक

जीथब पर सितारे
11.2k/मिरर
1.1k/मिरर
12.4k
27.6k

इसमें लिखा हुआ
C
C
सी + +
go

API
नहीं
केवल सॉकेट/पुश
डेटाप्लेन/पुल
खींच

सक्रिय स्वास्थ्य जांच
नहीं
हां
हां
हां

अनुरेखण खोलें
बाहरी प्लगइन
नहीं
हां
हां

जेडब्ल्यूटी
बाहरी प्लगइन
नहीं
हां
नहीं

विस्तार
लुआ/सी
लुआ/सी
लुआ/सी++
नहीं

क्या के लिए

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

• स्थैतिक पुनरावृत्ति.

तथ्य यह है कि इस समय भेजा कोई कैशिंग समर्थन नहीं. गूगल वाले यह कोशिश कर रहे हैं तय करने के लिए. इस विचार को एक बार क्रियान्वित किया जाएगा भेजा आरएफसी अनुपालन की सभी सूक्ष्मताएं (चिड़ियाघर हेडर), और विशिष्ट कार्यान्वयन के लिए एक इंटरफ़ेस बनाएं। लेकिन अभी यह अल्फ़ा भी नहीं है, वास्तुकला पर चर्चा चल रही है, PR खुला (जब मैं पीआर लेख लिख रहा था, पीआर रुक गया, लेकिन यह बिंदु अभी भी प्रासंगिक है)।

अभी के लिए, स्टैटिक्स के लिए nginx का उपयोग करें।

• स्थैतिक विन्यास.

आप इसका उपयोग कर सकते हैं, लेकिन भेजा यह वह नहीं है जिसके लिए इसे बनाया गया था। स्थिर कॉन्फ़िगरेशन में सुविधाएँ उजागर नहीं की जाएंगी. ऐसे कई क्षण हैं:

YAML में कॉन्फ़िगरेशन को संपादित करते समय, आप गलत होंगे, डेवलपर्स को शब्दाडंबर के लिए डांटेंगे और सोचेंगे कि nginx/haproxy कॉन्फ़िगरेशन, हालांकि कम संरचित हैं, अधिक संक्षिप्त हैं। यही तो बात है। Nginx और Haproxy का कॉन्फ़िगरेशन हाथ से संपादन के लिए बनाया गया था, और भेजा कोड से पीढ़ी के लिए. संपूर्ण कॉन्फ़िगरेशन का वर्णन किया गया है Protobuf, इसे प्रोटो फ़ाइलों से उत्पन्न करना गलती करना अधिक कठिन है।

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

वे कार्य जिनके लिए दूत अपरिहार्य है:

• जटिल और गतिशील प्रणालियों में यातायात संतुलन। इसमें सर्विस मेश शामिल है, लेकिन जरूरी नहीं कि यह एकमात्र हो।
• वितरित ट्रेसिंग कार्यक्षमता, जटिल प्राधिकरण या अन्य कार्यक्षमता की आवश्यकता जो उपलब्ध है भेजा बॉक्स से बाहर या आसानी से लागू किया गया, लेकिन nginx/haproxy में आपको lua और संदिग्ध प्लगइन्स से घिरा होना चाहिए।

दोनों, यदि आवश्यक हो, उच्च प्रदर्शन प्रदान करते हैं।

Как это работает

दूत को बायनेरिज़ में केवल डॉकर छवि के रूप में वितरित किया जाता है। छवि में पहले से ही स्थिर कॉन्फ़िगरेशन का एक उदाहरण मौजूद है। लेकिन हमारी रुचि इसमें केवल संरचना को समझने के लिए है।

envoy.yaml स्थिर विन्यास

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

गतिशील विन्यास

हम किस समस्या का समाधान ढूंढ रहे हैं? आप लोड के तहत लोड बैलेंसर कॉन्फ़िगरेशन को फिर से लोड नहीं कर सकते; "छोटी" समस्याएं उत्पन्न होंगी:

• कॉन्फ़िगरेशन सत्यापन.

कॉन्फ़िगरेशन बड़ा हो सकता है, यह बहुत बड़ा हो सकता है, अगर हम इसे एक साथ ओवरलोड करते हैं, तो कहीं न कहीं त्रुटि की संभावना बढ़ जाती है।

• लंबे समय तक रहने वाले संबंध.

नए श्रोता को आरंभ करते समय, आपको पुराने पर चल रहे कनेक्शन का ध्यान रखना होगा; यदि परिवर्तन बार-बार होते हैं और लंबे समय तक चलने वाले कनेक्शन हैं, तो आपको एक समझौते की तलाश करनी होगी। नमस्ते, कुबेरनेट्स ने nginx पर प्रवेश किया है।

• सक्रिय स्वास्थ्य जांच।

यदि हमारे पास सक्रिय स्वास्थ्य जांच है, तो हमें ट्रैफ़िक भेजने से पहले नई कॉन्फ़िगरेशन में उन सभी को दोबारा जांचना होगा। यदि बहुत अधिक अपस्ट्रीम हैं, तो इसमें समय लगता है। हेलो हैप्रोक्सी।

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

विन्यास भेजा (उपरोक्त फ़ाइल से) में निम्नलिखित इकाइयाँ हैं:

• श्रोता - श्रोता एक विशिष्ट आईपी/पोर्ट पर लटका हुआ है
• आभासी मेजबान - डोमेन नाम से वर्चुअल होस्ट
• मार्ग - संतुलन नियम
• समूह - संतुलन मापदंडों के साथ अपस्ट्रीम का एक समूह
• समापन बिंदु - अपस्ट्रीम इंस्टेंस पता

इनमें से प्रत्येक इकाई और कुछ अन्य को गतिशील रूप से भरा जा सकता है; इसके लिए, कॉन्फ़िगरेशन उस सेवा का पता निर्दिष्ट करता है जहां से कॉन्फ़िगरेशन प्राप्त किया जाएगा। सेवा REST या gRPC हो सकती है, gRPC बेहतर है।

सेवाओं के नाम क्रमशः हैं: एलडीएस, वीएचडीएस, आरडीएस, सीडीएस और ईडीएस। आप स्थैतिक और गतिशील कॉन्फ़िगरेशन को जोड़ सकते हैं, इस सीमा के साथ कि एक गतिशील संसाधन को स्थैतिक में निर्दिष्ट नहीं किया जा सकता है।

अधिकांश कार्यों के लिए, अंतिम तीन सेवाओं को लागू करना पर्याप्त है, उन्हें ADS (एग्रीगेटेड डिस्कवरी सर्विस) कहा जाता है, जावा और वहां जीआरपीसी डेटाप्लेन का एक तैयार कार्यान्वयन है जिसमें आपको बस अपने स्रोत से ऑब्जेक्ट भरने की आवश्यकता है।

कॉन्फ़िगरेशन निम्न रूप लेता है:

envoy.yaml गतिशील विन्यास

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

जब आप चलाने भेजा इस कॉन्फ़िगरेशन के साथ, यह कंट्रोल-प्लेन से कनेक्ट होगा और आरडीएस, सीडीएस और ईडीएस कॉन्फ़िगरेशन का अनुरोध करने का प्रयास करेगा। अंतःक्रिया प्रक्रिया कैसे होती है इसका वर्णन किया गया है यहां.

संक्षेप में, भेजा अनुरोध किए जा रहे संसाधन के प्रकार, नोड के संस्करण और मापदंडों को दर्शाते हुए एक अनुरोध भेजता है। प्रतिक्रिया में, इसे एक संसाधन और एक संस्करण प्राप्त होता है; यदि नियंत्रण-तल पर संस्करण नहीं बदला है, तो यह प्रतिक्रिया नहीं देता है।
4 इंटरैक्शन विकल्प हैं:

• सभी प्रकार के संसाधनों के लिए एक gRPC स्ट्रीम, संसाधन की पूरी स्थिति भेजी जाती है।
• अलग-अलग धाराएँ, पूरी स्थिति।
• एक धारा, वृद्धिशील स्थिति.
• अलग-अलग धाराएँ, वृद्धिशील स्थिति।

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

हमारा उदाहरण एडीएस का उपयोग करता है - आरडीएस, सीडीएस, ईडीएस और गैर-वृद्धिशील मोड के लिए एक स्ट्रीम। वृद्धिशील मोड को सक्षम करने के लिए, आपको निर्दिष्ट करना होगा api_type: DELTA_GRPC

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

जोश में आना

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

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

यदि श्रोता को पुनः बनाया गया था, तो पुराना DRAIN स्थिति में चला जाता है और सभी कनेक्शन बंद होने या टाइमआउट समाप्त होने के बाद हटा दिया जाएगा --drain-time-s, डिफ़ॉल्ट 10 मिनट।

को जारी रखा जाएगा.

स्रोत: www.habr.com