elçi. 1. Giriş

salamlar! Bu, "elçi nədir?", "niyə lazımdır?" suallarına cavab verən kiçik bir məqalədir. və "haradan başlamaq lazımdır?".

Bu nədir?

Elçi, C++ dilində yazılmış, yüksək performansa və əlçatanlığa yönəlmiş L4-L7 balanslaşdırıcısıdır. Bir tərəfdən, bu, hansısa şəkildə nginx və haproksinin analoqudur, performans baxımından onlarla mütənasibdir. Digər tərəfdən, o, daha çox mikroservis arxitekturasına diqqət yetirir və zuul və ya traefik kimi java və go balanslaşdırıcıları ilə eyni funksionallığa malikdir.

Haproxy / nginx / elçi müqayisə cədvəli, mütləq həqiqət olduğunu iddia etmir, lakin ümumi bir şəkil verir.

nginx
haproksi
göndərdi
traefik

github-da ulduzlar
11.2k/güzgü
1.1k/güzgü
12.4k
27.6k

-də yazılmışdır
C
C
C + +
go

API
нет
yalnız rozetka/push
məlumat müstəvisi/çəkin
dartmaq

aktiv sağlamlıq müayinəsi
нет
bəli
bəli
bəli

açıq izləmə
xarici plagin
нет
bəli
bəli

J.W.T.
xarici plagin
нет
bəli
нет

artırma
Lua/C
Lua/C
Lua/C++
нет

Nə üçün

Bu gənc bir layihədir, orada çox şey çatışmır, erkən alfada bir şey var. Amma göndərdi, o cümlədən gəncliyinə görə sürətlə inkişaf edir və artıq bir çox maraqlı xüsusiyyətlərə malikdir: dinamik konfiqurasiya, çoxlu hazır filtrlər, öz filtrlərinizi yazmaq üçün sadə interfeys.
Bu, tətbiq sahələrinə səbəb olur, lakin birincisi, 2 anti-naxış:

• Statikin qaytarılması.

Məsələ ondadır ki, hazırda göndərdi keşləmə dəstəyi yoxdur. Google adamları bunu sınayırlar düzeltmek. Bir dəfə həyata keçiriləcək ideya göndərdi RFC uyğunluğunun bütün incəlikləri (başlıqlar zooparkı) və interfeys yaratmaq üçün xüsusi tətbiqlər üçün. Ancaq hətta alfa olmasa da, memarlıq müzakirə olunur, PR açıq (mən PR məqaləsini yazarkən ilişib qaldılar, amma bu maddə hələ də aktualdır).

Bu arada, statik üçün nginx istifadə edin.

• statik konfiqurasiya.

İstifadə edə bilərsiniz, amma göndərdi bunun üçün yaradılmamışdır. Statik konfiqurasiyada imkanlar açıqlanmayacaq. Çox anlar:

Yaml-da konfiqurasiyanı redaktə edərkən, siz səhvlər edəcəksiniz, tərtibatçıları təfərrüatlara görə lənətləyəcəksiniz və nginx / haproxy konfiqurasiyalarının daha az strukturlaşdırılmış, lakin daha qısa olduğunu düşünəcəksiniz. Məsələ bundadır. Nginx və Haproxy konfiqurasiyası əl ilə redaktə üçün yaradılmışdır və göndərdi koddan nəsil üçün. Bütün konfiqurasiya aşağıda təsvir edilmişdir protobuf, onu proto fayllardan yaratmaq səhv etmək daha çətindir.

Canary, b/g deploy və daha çox skriptlər adətən yalnız dinamik konfiqurasiyada həyata keçirilir. Mən demirəm ki, bunu statik şəkildə etmək olmaz, hamımız bunu edirik. Ancaq bunun üçün balanslaşdırıcılardan hər hansı birində qoltuqağacı taxmaq lazımdır göndərdi o cümlədən

Elçinin əvəzolunmaz olduğu vəzifələr:

• Mürəkkəb və dinamik sistemlərdə trafikin balanslaşdırılması. Xidmət şəbəkəsi buraya gəlir, lakin bu, mütləq tək deyil.
• Paylanmış izləmə funksiyasına, kompleks icazəyə və ya başqa bir şeyə ehtiyac göndərdi qutudan kənarda və ya rahat şəkildə həyata keçirilir, lakin nginx / haproxy-də lua və şübhəli plaginləri örtmək lazımdır.

Hər ikisi, lazım gələrsə, yüksək performans təmin etmək üçün.

Bu necə işləyir

Elçi ikili formatda yalnız docker şəkli kimi paylanır. Şəkildə artıq statik konfiqurasiya nümunəsi var. Ancaq biz yalnız strukturu anlamaqda maraqlıyıq.

envoy.yaml statik konfiqurasiya

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

Dinamik Konfiqurasiya

Hansı problemi həll etmək axtarırıq? Yük altında balanslaşdırıcı konfiqurasiyanı götürüb yenidən yükləyə bilməzsiniz, "kiçik" problemlər olacaq:

• Konfiqurasiyanın yoxlanılması.

Konfiqurasiya böyük ola bilər, çox böyük ola bilər, əgər hamısını birdən çox yükləsək, haradasa xəta olma ehtimalı artır.

• Uzunmüddətli əlaqələr.

Yeni dinləyicini işə salarkən, köhnə ilə işləyən bağlantılara diqqət yetirməlisiniz, əgər dəyişikliklər tez-tez baş verirsə və uzun ömürlü bağlantılar varsa, bir kompromis tapılmalı olacaq. Hey kubernetlər nginx-ə daxil olurlar.

• Aktiv yoxlamalar.

Əgər aktiv sağlamlıq yoxlamalarımız varsa, trafik göndərməzdən əvvəl onların hamısını yeni konfiqurasiyada iki dəfə yoxlamalıyıq. Çoxlu yuxarı axınlar varsa, bu, vaxt tələb edir. Hey haproxy.

Bu necə həll olunur göndərdiKonfiqurasiyanı model hovuzuna uyğun olaraq dinamik şəkildə yükləyərək, onu ayrı-ayrı hissələrə ayıra və dəyişməmiş hissəni yenidən işə salmaya bilərsiniz. Məsələn, yenidən işə salmaq baha başa gələn və nadir hallarda dəyişən dinləyici.

Konfiqurasiya göndərdi (yuxarıdakı fayldan) aşağıdakı obyektlərə malikdir:

• dinləyici - müəyyən bir ip / portda asılan dinləyici
• virtual host - domen adına görə virtual host
• marşrut - balanslaşdırma qaydası
• qrup — balanslaşdırma parametrləri olan yuxarı axınlar qrupu
• son nöqtə — yuxarı instansiya ünvanı

Bu obyektlərin hər biri və digərləri dinamik şəkildə doldurula bilər, bunun üçün konfiqurasiya konfiqurasiyanın alınacağı xidmətin ünvanını müəyyən edir. Xidmət REST və ya gRPC ola bilər, gRPC istifadəsinə üstünlük verilir.

Xidmətlər müvafiq olaraq adlanır: LDS, VHDS, RDS, CDS və EDS. Statik və dinamik konfiqurasiyanı birləşdirmək mümkündür, lakin məhdudiyyətlə dinamik resursun statikdə göstərilə bilməz.

Əksər tapşırıqlar üçün ADS (Aggregated Discovery Service) adlanan son üç xidməti həyata keçirmək kifayətdir. Java və go yalnız mənbənizdən obyektləri doldurmağınız lazım olan gRPC dataplane-nin hazır tətbiqinə malikdir.

Konfiqurasiya aşağıdakı formanı alır:

envoy.yaml dinamik konfiqurasiya

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

Başlanğıcda göndərdi bu konfiqurasiya ilə o, idarəetmə müstəvisinə qoşulacaq və RDS, CDS və EDS konfiqurasiyasını sorğulamağa çalışacaq. Qarşılıqlı təsir prosesi necə təsvir olunur burada.

Qısa, göndərdi tələb olunan resursun növünü, qovşağın versiyasını və parametrlərini göstərən sorğu göndərir. Cavab olaraq resurs və versiyanı alır, əgər idarəetmə müstəvisindəki versiya dəyişməyibsə, cavab vermir.
4 qarşılıqlı əlaqə variantı var:

• Bütün növ resurslar üçün bir gRPC axını, resursun tam vəziyyəti göndərilir.
• Ayri-ayri veziyyetdedir.
• Bir axın, artımlı vəziyyət.
• Ayrı axınlar, artımlı vəziyyət.

Artan xDS sizə idarəetmə müstəvisi və arasında trafiki azaltmağa imkan verir göndərdi, bu böyük konfiqurasiyalar üçün doğrudur. Lakin bu, qarşılıqlı əlaqəni çətinləşdirir, sorğu abunəlikdən çıxmaq və abunə olmaq üçün resursların siyahısını ötürür.

Bizim nümunəmizdə ADS istifadə olunur - RDS, CDS, EDS və artımsız rejim üçün bir axın. Artan rejimi aktivləşdirmək üçün müəyyən etməlisiniz api_type: DELTA_GRPC

Sorğuda qovşaq parametrləri olduğundan, biz müxtəlif instansiyalar üçün idarəetmə müstəvisinə müxtəlif resurslar göndərə bilərik göndərdi, bu xidmət şəbəkəsi qurmaq üçün əlverişlidir.

İsti

Haqqında göndərdi işə salındıqda və ya idarəetmə müstəvisindən yeni konfiqurasiya qəbul edildikdə, resursun istiləşməsi prosesi başlayır. O, dinləyicinin istiləşməsinə və klasterin istiləşməsinə bölünür. Birincisi RDS/LDS-dəki dəyişikliklərlə, ikincisi isə CDS/EDS-də baş verən dəyişikliklərlə tetiklenir. Bu o deməkdir ki, yalnız yuxarı axınlar dəyişirsə, dinləyici yenidən yaradılmır.

İstiləşmə zamanı nəzarət müstəvisindən asılı resursların bir müddət gözlənildiyi gözlənilir. Taym-aut müddəti başa çatmışsa, işəsalma uğurlu olmayacaq, yeni dinləyici portda dinləməyə başlamayacaq.
Başlama qaydası: EDS, CDS, aktiv sağlamlıq yoxlaması, RDS, LDS. Aktiv sağlamlıq yoxlamaları aktiv olduqda, trafik yalnız bir uğurlu sağlamlıq yoxlanışından sonra yuxarı axın edəcək.

Dinləyici yenidən yaradılıbsa, köhnəsi DRAIN vəziyyətinə keçir və bütün bağlantılar bağlandıqdan və ya fasilə müddəti bitdikdən sonra silinəcək. --drain-time-s, standart 10 dəqiqə.

Davam etmək.

Mənbə: www.habr.com