ਰਾਜਦੂਤ. 1. ਜਾਣ - ਪਛਾਣ

ਨਮਸਕਾਰ! ਇਹ ਇੱਕ ਛੋਟਾ ਲੇਖ ਹੈ ਜੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: "ਦੂਤ ਕੀ ਹੈ?", "ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?" ਅਤੇ "ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ?".

ਇਹ ਕੀ ਹੈ?

ਦੂਤ ਇੱਕ L4-L7 ਬੈਲੇਂਸਰ ਹੈ ਜੋ C++ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਉਪਲਬਧਤਾ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਇੱਕ ਪਾਸੇ, ਇਹ ਕਿਸੇ ਤਰ੍ਹਾਂ nginx ਅਤੇ haproxy ਦਾ ਇੱਕ ਐਨਾਲਾਗ ਹੈ, ਉਹਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਤੁਲਨਾਤਮਕ। ਦੂਜੇ ਪਾਸੇ, ਇਹ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਵਧੇਰੇ ਕੇਂਦਰਿਤ ਹੈ ਅਤੇ ਇਸਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਜਾਵਾ ਅਤੇ ਗੋ ਬੈਲੇਂਸਰਾਂ, ਜਿਵੇਂ ਕਿ ਜ਼ੁਲ ਜਾਂ ਟ੍ਰੈਫਿਕ ਨਾਲੋਂ ਮਾੜੀ ਨਹੀਂ ਹੈ।

haproxy/nginx/envoy ਦੀ ਤੁਲਨਾ ਸਾਰਣੀ, ਇਹ ਪੂਰਨ ਸੱਚ ਹੋਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦੀ, ਪਰ ਇੱਕ ਆਮ ਤਸਵੀਰ ਦਿੰਦੀ ਹੈ।

nginx
ਹਾਪਰੋਕਸ
ਭੇਜਿਆ
ਟ੍ਰੈਫਿਕ

github 'ਤੇ ਤਾਰੇ
11.2k/ਸ਼ੀਸ਼ਾ
1.1k/ਸ਼ੀਸ਼ਾ
12.4k
27.6k

ਵਿੱਚ ਲਿਖਿਆ
C
C
C ++
go

API
ਕੋਈ ਵੀ
ਸਿਰਫ ਸਾਕਟ/ਪੁਸ਼
ਡੈਟਾਪਲੇਨ/ਖਿੱਚੋ
ਖਿੱਚੋ

ਸਰਗਰਮ ਸਿਹਤ ਜਾਂਚ
ਕੋਈ ਵੀ
ਜੀ
ਜੀ
ਜੀ

ਓਪਨ ਟਰੇਸਿੰਗ
ਬਾਹਰੀ ਪਲੱਗਇਨ
ਕੋਈ ਵੀ
ਜੀ
ਜੀ

ਜੇਡਬਲਯੂਟੀ
ਬਾਹਰੀ ਪਲੱਗਇਨ
ਕੋਈ ਵੀ
ਜੀ
ਕੋਈ ਵੀ

ਐਕਸ਼ਟੇਸ਼ਨ
ਲੁਆ/ਸੀ
ਲੁਆ/ਸੀ
Lua/C++
ਕੋਈ ਵੀ

ਕਿਉਂ

ਇਹ ਇੱਕ ਨੌਜਵਾਨ ਪ੍ਰੋਜੈਕਟ ਹੈ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਗੁੰਮ ਹਨ, ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਅਲਫ਼ਾ ਵਿੱਚ। ਪਰ ਭੇਜਿਆ, ਆਪਣੀ ਜਵਾਨੀ ਦੇ ਕਾਰਨ, ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ: ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ, ਬਹੁਤ ਸਾਰੇ ਤਿਆਰ ਫਿਲਟਰ, ਤੁਹਾਡੇ ਆਪਣੇ ਫਿਲਟਰ ਲਿਖਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਇੰਟਰਫੇਸ।
ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਖੇਤਰ ਇਸ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਪਰ ਪਹਿਲਾਂ 2 ਐਂਟੀਪੈਟਰਨ ਹਨ:

• ਸਥਿਰ ਰੀਕੋਇਲ।

ਤੱਥ ਇਹ ਹੈ ਕਿ ਇਸ ਸਮੇਂ ਵਿਚ ਭੇਜਿਆ ਕੋਈ ਕੈਸ਼ਿੰਗ ਸਹਾਇਤਾ ਨਹੀਂ। ਗੂਗਲ ਵਾਲੇ ਇਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ ਠੀਕ ਕਰੋ. ਇਸ ਵਿਚਾਰ ਨੂੰ ਇੱਕ ਵਾਰ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ ਭੇਜਿਆ RFC ਅਨੁਪਾਲਨ ਦੀਆਂ ਸਾਰੀਆਂ ਸੂਖਮਤਾਵਾਂ (ਜ਼ੂ ਸਿਰਲੇਖ), ਅਤੇ ਖਾਸ ਲਾਗੂਕਰਨਾਂ ਲਈ ਇੱਕ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦੇ ਹਨ। ਪਰ ਫਿਲਹਾਲ ਇਹ ਅਲਫਾ ਵੀ ਨਹੀਂ ਹੈ, ਆਰਕੀਟੈਕਚਰ ਚਰਚਾ ਅਧੀਨ ਹੈ, PR ਓਪਨ (ਜਦੋਂ ਮੈਂ PR ਲੇਖ ਲਿਖ ਰਿਹਾ ਸੀ, PR ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ ਸੀ, ਪਰ ਇਹ ਬਿੰਦੂ ਅਜੇ ਵੀ ਢੁਕਵਾਂ ਹੈ)।

ਹੁਣ ਲਈ, ਸਟੈਟਿਕਸ ਲਈ nginx ਦੀ ਵਰਤੋਂ ਕਰੋ.

• ਸਥਿਰ ਸੰਰਚਨਾ।

ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤ ਸਕਦੇ ਹੋ, ਪਰ ਭੇਜਿਆ ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ. ਇੱਕ ਸਥਿਰ ਸੰਰਚਨਾ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉਜਾਗਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ। ਬਹੁਤ ਸਾਰੇ ਪਲ ਹਨ:

yaml ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਗਲਤ ਹੋਵੋਗੇ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਵਰਬੋਸਿਟੀ ਲਈ ਝਿੜਕੋਗੇ ਅਤੇ ਸੋਚੋ ਕਿ nginx/haproxy ਸੰਰਚਨਾ, ਹਾਲਾਂਕਿ ਘੱਟ ਢਾਂਚਾਗਤ ਹੈ, ਵਧੇਰੇ ਸੰਖੇਪ ਹਨ। ਇਹ ਗੱਲ ਹੈ। Nginx ਅਤੇ Haproxy ਦੀ ਸੰਰਚਨਾ ਹੱਥ ਦੁਆਰਾ ਸੰਪਾਦਿਤ ਕਰਨ ਲਈ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਭੇਜਿਆ ਕੋਡ ਤੋਂ ਪੀੜ੍ਹੀ ਲਈ। ਪੂਰੀ ਸੰਰਚਨਾ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ protobuf, ਇਸ ਨੂੰ ਪ੍ਰੋਟੋ ਫਾਈਲਾਂ ਤੋਂ ਤਿਆਰ ਕਰਨਾ ਗਲਤੀ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ।

ਕੈਨਰੀ, b/g ਤੈਨਾਤੀ ਦ੍ਰਿਸ਼ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ ਇੱਕ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਿ ਰਿਹਾ ਹਾਂ ਕਿ ਇਹ ਸਥਿਰ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਅਸੀਂ ਸਾਰੇ ਇਹ ਕਰਦੇ ਹਾਂ. ਪਰ ਇਸਦੇ ਲਈ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਬੈਲੈਂਸਰ ਵਿੱਚ, ਬੈਸਾਖੀਆਂ ਪਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਭੇਜਿਆ ਸਮੇਤ

ਕਾਰਜ ਜਿਨ੍ਹਾਂ ਲਈ ਰਾਜਦੂਤ ਲਾਜ਼ਮੀ ਹੈ:

• ਗੁੰਝਲਦਾਰ ਅਤੇ ਗਤੀਸ਼ੀਲ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਸੰਤੁਲਨ। ਇਸ ਵਿੱਚ ਸੇਵਾ ਜਾਲ ਸ਼ਾਮਲ ਹੈ, ਪਰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਹੋਵੇ।
• ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਕਾਰਜਕੁਸ਼ਲਤਾ, ਗੁੰਝਲਦਾਰ ਅਧਿਕਾਰ ਜਾਂ ਹੋਰ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਲੋੜ ਜੋ ਕਿ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਭੇਜਿਆ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਜਾਂ ਸੁਵਿਧਾਜਨਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ nginx/haproxy ਵਿੱਚ ਤੁਹਾਨੂੰ ਲੂਆ ਅਤੇ ਸ਼ੱਕੀ ਪਲੱਗਇਨਾਂ ਨਾਲ ਘਿਰਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੋਵੇਂ, ਜੇ ਲੋੜ ਹੋਵੇ, ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ.

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ

ਦੂਤ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਬਾਈਨਰੀ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਚਿੱਤਰ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਥਿਰ ਸੰਰਚਨਾ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ। ਪਰ ਅਸੀਂ ਸਿਰਫ ਢਾਂਚੇ ਨੂੰ ਸਮਝਣ ਲਈ ਇਸ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ.

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 ਤਰਜੀਹੀ ਹੈ।

ਸੇਵਾਵਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ: LDS, VHDS, RDS, CDS ਅਤੇ EDS। ਤੁਸੀਂ ਸਥਿਰ ਅਤੇ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹੋ, ਇਸ ਸੀਮਾ ਦੇ ਨਾਲ ਕਿ ਇੱਕ ਗਤੀਸ਼ੀਲ ਸਰੋਤ ਇੱਕ ਸਥਿਰ ਵਿੱਚ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਕੰਮਾਂ ਲਈ, ਆਖਰੀ ਤਿੰਨ ਸੇਵਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਏਡੀਐਸ (ਐਗਰੀਗੇਟਿਡ ਡਿਸਕਵਰੀ ਸਰਵਿਸ) ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਲਈ java ਅਤੇ ਜਾਓ ਜੀਆਰਪੀਸੀ ਡੇਟਾਪਲੇਨ ਦਾ ਇੱਕ ਤਿਆਰ-ਬਣਾਇਆ ਲਾਗੂਕਰਨ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਰੋਤ ਤੋਂ ਵਸਤੂਆਂ ਨੂੰ ਭਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸੰਰਚਨਾ ਹੇਠ ਲਿਖੇ ਰੂਪ ਨੂੰ ਲੈਂਦੀ ਹੈ:

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-time-s, ਡਿਫਾਲਟ 10 ਮਿੰਟ।

ਜਾਰੀ ਰੱਖਣ ਲਈ

ਸਰੋਤ: www.habr.com