రాయబారి. 1. పరిచయం

శుభాకాంక్షలు! “దూత అంటే ఏమిటి?”, “ఎందుకు అవసరం?” అనే ప్రశ్నలకు సమాధానమిచ్చే చిన్న కథనం ఇది. మరియు "ఎక్కడ ప్రారంభించాలి?".

ఇది ఏమిటి

ఎన్వాయ్ అనేది C++లో వ్రాయబడిన L4-L7 బ్యాలెన్సర్, ఇది అధిక పనితీరు మరియు లభ్యతపై దృష్టి పెట్టింది. ఒక వైపు, ఇది ఒక విధంగా nginx మరియు haproxy యొక్క అనలాగ్, పనితీరుతో పోల్చదగినది. మరోవైపు, ఇది మైక్రోసర్వీస్ ఆర్కిటెక్చర్ వైపు ఎక్కువగా దృష్టి సారించింది మరియు జుల్ లేదా ట్రాఫిక్ వంటి జావా మరియు గో బ్యాలెన్సర్‌ల కంటే అధ్వాన్నంగా కార్యాచరణను కలిగి ఉంది.

హాప్రాక్సీ/nginx/దూత యొక్క పోలిక పట్టిక, ఇది సంపూర్ణ సత్యమని చెప్పుకోదు, కానీ సాధారణ చిత్రాన్ని ఇస్తుంది.

వికీపీడియా
HAProxy
పంపిన
ట్రాఫిక్

గితుబ్‌లో నక్షత్రాలు
11.2k/అద్దం
1.1k/అద్దం
12.4k
27.6k

లో వ్రాయబడింది
C
C
C ++
go

API
ఏ
సాకెట్ మాత్రమే/పుష్
డేటాప్లేన్/పుల్
పుల్

క్రియాశీల ఆరోగ్య తనిఖీ
ఏ
అవును
అవును
అవును

ట్రేసింగ్ తెరవండి
బాహ్య ప్లగ్ఇన్
ఏ
అవును
అవును

J.W.T.
బాహ్య ప్లగ్ఇన్
ఏ
అవును
ఏ

పొడిగింపు
లువా/సి
లువా/సి
Lua/C++
ఏ

ఎందుకు

ఇది యువ ప్రాజెక్ట్, చాలా విషయాలు లేవు, కొన్ని ప్రారంభ ఆల్ఫాలో ఉన్నాయి. కానీ పంపిన, దాని యవ్వనం కారణంగా, వేగంగా అభివృద్ధి చెందుతోంది మరియు ఇప్పటికే అనేక ఆసక్తికరమైన లక్షణాలను కలిగి ఉంది: డైనమిక్ కాన్ఫిగరేషన్, అనేక రెడీమేడ్ ఫిల్టర్‌లు, మీ స్వంత ఫిల్టర్‌లను వ్రాయడానికి ఒక సాధారణ ఇంటర్‌ఫేస్.
అప్లికేషన్ యొక్క ప్రాంతాలు దీని నుండి అనుసరిస్తాయి, అయితే మొదట 2 యాంటీప్యాటర్న్‌లు ఉన్నాయి:

• స్టాటిక్ రీకోయిల్.

వాస్తవం ఏమిటంటే ప్రస్తుతానికి పంపిన కాషింగ్ మద్దతు లేదు. Google అబ్బాయిలు దీన్ని ప్రయత్నిస్తున్నారు పరిష్కారము. ఆలోచన ఒకసారి అమలు చేయబడుతుంది పంపిన RFC సమ్మతి యొక్క అన్ని సూక్ష్మబేధాలు (జూ హెడర్‌లు), మరియు నిర్దిష్ట అమలుల కోసం ఇంటర్‌ఫేస్‌ను తయారు చేస్తాయి. కానీ ప్రస్తుతానికి ఇది ఆల్ఫా కూడా కాదు, ఆర్కిటెక్చర్ చర్చలో ఉంది, PR ఓపెన్ (నేను PR కథనాన్ని వ్రాస్తున్నప్పుడు, PR స్తంభింపజేసింది, కానీ ఈ పాయింట్ ఇప్పటికీ సంబంధితంగా ఉంది).

ప్రస్తుతానికి, స్టాటిక్స్ కోసం nginxని ఉపయోగించండి.

• స్టాటిక్ కాన్ఫిగరేషన్.

మీరు దానిని ఉపయోగించవచ్చు, కానీ పంపిన అది సృష్టించబడినది కాదు. స్టాటిక్ కాన్ఫిగరేషన్‌లోని ఫీచర్‌లు బహిర్గతం చేయబడవు. చాలా క్షణాలు ఉన్నాయి:

yamlలో కాన్ఫిగరేషన్‌ని ఎడిట్ చేస్తున్నప్పుడు, మీరు పొరబడతారు, డెవలపర్‌లను వెర్బోసిటీ కోసం తిట్టండి మరియు nginx/haproxy configs, తక్కువ నిర్మాణాత్మకంగా ఉన్నప్పటికీ, మరింత సంక్షిప్తంగా ఉన్నాయని భావిస్తారు. అదీ విషయం. Nginx మరియు Haproxy యొక్క కాన్ఫిగరేషన్ చేతితో సవరించడం కోసం సృష్టించబడింది మరియు పంపిన కోడ్ నుండి తరం కోసం. మొత్తం కాన్ఫిగరేషన్ వివరించబడింది ప్రోటోబుఫ్, ప్రోటో ఫైల్స్ నుండి దీన్ని రూపొందించడం పొరపాటు చేయడం చాలా కష్టం.

కానరీ, b/g విస్తరణ దృశ్యాలు మరియు మరిన్ని సాధారణంగా డైనమిక్ కాన్ఫిగరేషన్‌లో మాత్రమే అమలు చేయబడతాయి. ఇది స్థిరంగా చేయలేమని నేను చెప్పడం లేదు, మనమందరం దీన్ని చేస్తాము. కానీ దీని కోసం మీరు ఏదైనా బ్యాలెన్సర్‌లలో, క్రచెస్ ధరించాలి పంపిన సహా.

రాయబారి అనివార్యమైన పనులు:

• సంక్లిష్టమైన మరియు డైనమిక్ సిస్టమ్‌లలో ట్రాఫిక్ బ్యాలెన్సింగ్. ఇందులో సర్వీస్ మెష్ ఉంటుంది, కానీ ఇది ఒక్కటే కాదు.
• పంపిణీ చేయబడిన ట్రేసింగ్ ఫంక్షనాలిటీ, కాంప్లెక్స్ ఆథరైజేషన్ లేదా అందుబాటులో ఉన్న ఇతర ఫంక్షనాలిటీ అవసరం పంపిన పెట్టె వెలుపల లేదా సౌకర్యవంతంగా అమలు చేయబడింది, కానీ 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లో kubernetes ప్రవేశిస్తున్నారు.

• క్రియాశీల ఆరోగ్య తనిఖీలు.

మేము యాక్టివ్ హెల్త్ చెక్‌లను కలిగి ఉన్నట్లయితే, ట్రాఫిక్‌ను పంపే ముందు మేము వాటిని కొత్త కాన్ఫిగరేషన్‌లో ఒకటికి రెండుసార్లు తనిఖీ చేయాలి. చాలా అప్‌స్ట్రీమ్‌లు ఉంటే, దీనికి సమయం పడుతుంది. హలో హాప్రాక్సీ.

ఇది ఎలా పరిష్కరించబడుతుంది పంపినకాన్ఫిగరేషన్‌ను డైనమిక్‌గా లోడ్ చేయడం ద్వారా, పూల్ మోడల్ ప్రకారం, మీరు దానిని ప్రత్యేక భాగాలుగా విభజించవచ్చు మరియు మారని భాగాన్ని మళ్లీ ప్రారంభించకూడదు. ఉదాహరణకు, వినేవారు, ఇది తిరిగి ప్రారంభించడం ఖరీదైనది మరియు అరుదుగా మారుతుంది.

ఆకృతీకరణ పంపిన (పై ఫైల్ నుండి) కింది ఎంటిటీలను కలిగి ఉంది:

• వినేవారు — ఒక నిర్దిష్ట ip/పోర్ట్‌లో వ్రేలాడుతున్న శ్రోత
• వర్చువల్ హోస్ట్ - డొమైన్ పేరు ద్వారా వర్చువల్ హోస్ట్
• మార్గం - బ్యాలెన్సింగ్ నియమం
• క్లస్టర్ - బ్యాలెన్సింగ్ పారామితులతో అప్‌స్ట్రీమ్‌ల సమూహం
• తుది స్థానం - అప్‌స్ట్రీమ్ ఉదాహరణ చిరునామా

ఈ ఎంటిటీలలో ప్రతి ఒక్కటి మరియు మరికొన్నింటిని డైనమిక్‌గా పూరించవచ్చు; దీని కోసం, కాన్ఫిగరేషన్ ఎక్కడ నుండి కాన్ఫిగరేషన్ స్వీకరించబడుతుందో సేవ యొక్క చిరునామాను నిర్దేశిస్తుంది. సేవ REST లేదా gRPC కావచ్చు, gRPC ఉత్తమం.

సేవలకు వరుసగా పేర్లు పెట్టారు: LDS, VHDS, RDS, CDS మరియు EDS. మీరు స్టాటిక్ మరియు డైనమిక్ కాన్ఫిగరేషన్‌ను మిళితం చేయవచ్చు, డైనమిక్ రిసోర్స్‌ను స్టాటిక్‌లో పేర్కొనలేము.

చాలా పనుల కోసం, చివరి మూడు సేవలను అమలు చేస్తే సరిపోతుంది, వాటిని ADS (అగ్రిగేటెడ్ డిస్కవరీ సర్వీస్) అంటారు. జావా మరియు అక్కడ gRPC డేటాప్లేన్ యొక్క రెడీమేడ్ ఇంప్లిమెంటేషన్ ఉంది, దీనిలో మీరు మీ మూలం నుండి వస్తువులను పూరించాలి.

కాన్ఫిగరేషన్ క్రింది రూపాన్ని తీసుకుంటుంది:

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

ప్రారంభంలో పంపిన ఈ కాన్ఫిగరేషన్‌తో, ఇది కంట్రోల్-ప్లేన్‌కి కనెక్ట్ అవుతుంది మరియు RDS, CDS మరియు EDS కాన్ఫిగరేషన్‌ను అభ్యర్థించడానికి ప్రయత్నిస్తుంది. పరస్పర చర్య ఎలా జరుగుతుందో వివరించబడింది ఇక్కడ.

సంక్షిప్తంగా, పంపిన అభ్యర్థించిన వనరు రకం, నోడ్ యొక్క సంస్కరణ మరియు పారామితులను సూచించే అభ్యర్థనను పంపుతుంది. ప్రతిస్పందనగా, ఇది వనరు మరియు సంస్కరణను అందుకుంటుంది; నియంత్రణ-విమానంలోని సంస్కరణ మారకపోతే, అది ప్రతిస్పందించదు.
4 పరస్పర ఎంపికలు ఉన్నాయి:

• అన్ని రకాల వనరుల కోసం ఒక gRPC స్ట్రీమ్, వనరు యొక్క పూర్తి స్థితి పంపబడుతుంది.
• ప్రత్యేక ప్రవాహాలు, పూర్తి స్థితి.
• ఒక ప్రవాహం, పెరుగుతున్న స్థితి.
• ప్రత్యేక ప్రవాహాలు, పెరుగుతున్న స్థితి.

పెరుగుతున్న xDS నియంత్రణ-విమానం మరియు మధ్య ట్రాఫిక్‌ను తగ్గించడానికి మిమ్మల్ని అనుమతిస్తుంది పంపిన, ఇది పెద్ద కాన్ఫిగరేషన్‌లకు సంబంధించినది. కానీ ఇది పరస్పర చర్యను క్లిష్టతరం చేస్తుంది; అభ్యర్థనలో అన్‌సబ్‌స్క్రయిబ్ మరియు సబ్‌స్క్రయిబ్ కోసం వనరుల జాబితా ఉంటుంది.

మా ఉదాహరణ ADSని ఉపయోగిస్తుంది - RDS, CDS, EDS మరియు నాన్-ఇంక్రిమెంటల్ మోడ్ కోసం ఒక స్ట్రీమ్. ఇంక్రిమెంటల్ మోడ్‌ను ఎనేబుల్ చేయడానికి, మీరు పేర్కొనాలి api_type: DELTA_GRPC

అభ్యర్థన నోడ్ పారామితులను కలిగి ఉన్నందున, మేము వివిధ సందర్భాల్లో వివిధ వనరులను నియంత్రణ-విమానానికి పంపవచ్చు పంపిన, సేవా మెష్‌ను నిర్మించడానికి ఇది సౌకర్యవంతంగా ఉంటుంది.

వేడెక్కేలా

ఆఫ్ పంపిన ప్రారంభంలో లేదా కంట్రోల్-ప్లేన్ నుండి కొత్త కాన్ఫిగరేషన్‌ను స్వీకరించినప్పుడు, రిసోర్స్ వార్మప్ ప్రక్రియ ప్రారంభించబడుతుంది. ఇది వినేవారు వార్మప్ మరియు క్లస్టర్ వార్మప్‌గా విభజించబడింది. మొదటిది RDS/LDSలో మార్పులు వచ్చినప్పుడు, రెండవది CDS/EDSలో ఉన్నప్పుడు ప్రారంభించబడుతుంది. దీనర్థం కేవలం అప్‌స్ట్రీమ్‌లు మారితే, శ్రోతలు మళ్లీ సృష్టించబడరు.

సన్నాహక ప్రక్రియ సమయంలో, సమయం ముగిసిన సమయంలో నియంత్రణ-విమానం నుండి ఆధారిత వనరులు ఆశించబడతాయి. గడువు ముగిసినట్లయితే, ప్రారంభించడం విజయవంతం కాదు మరియు కొత్త శ్రోత పోర్ట్‌లో వినడం ప్రారంభించదు.
ప్రారంభ క్రమం: EDS, CDS, క్రియాశీల ఆరోగ్య తనిఖీ, RDS, LDS. క్రియాశీల ఆరోగ్య తనిఖీలు ప్రారంభించబడితే, ఒక విజయవంతమైన ఆరోగ్య తనిఖీ తర్వాత మాత్రమే ట్రాఫిక్ పైకి వెళ్తుంది.

వినేవారు పునఃసృష్టి చేయబడితే, పాతది DRAIN స్థితికి వెళుతుంది మరియు అన్ని కనెక్షన్‌లు మూసివేయబడిన తర్వాత లేదా గడువు ముగిసిన తర్వాత తొలగించబడుతుంది --drain-time-s, డిఫాల్ట్ 10 నిమిషాలు.

కొనసాగించాలి.

మూలం: www.habr.com