ProHoster > Blog > Ma'muriyat > Elchi. 1.Kirish

Elchi. 1.Kirish

Salom! Bu "elchi nima?", "u nima uchun kerak?" Degan savollarga javob beradigan qisqa maqola. va "qayerdan boshlash kerak?".

Nima bu

Elchi - bu C++ tilida yozilgan, yuqori unumdorlik va mavjudlikka qaratilgan L4-L7 balanslagich. Bir tomondan, bu qaysidir ma'noda nginx va haproksi analogi bo'lib, ular bilan ishlash jihatidan solishtirish mumkin. Boshqa tomondan, u mikroservis arxitekturasiga ko'proq yo'naltirilgan va zuul yoki traefik kabi java va go balanslagichlaridan yomonroq bo'lmagan funksionallikka ega.

Haproxy/nginx/elchining taqqoslash jadvali, u mutlaq haqiqat deb da'vo qilmaydi, lekin umumiy rasmni beradi.

nginx
gproksiya
yuborilgan
trafik

githubdagi yulduzlar
11.2k/oyna
1.1k/oyna
12.4k
27.6k

ichida yozilgan
C
C
C ++
go

API
yo'q
faqat rozetka / surish
ma'lumotlar tekisligi/tortish
Torting

faol salomatlik tekshiruvi
yo'q
ha
ha
ha

Ochiq kuzatuv
tashqi plagin
yo'q
ha
ha

J.W.T.
tashqi plagin
yo'q
ha
yo'q

kengaytirish
Lua/C
Lua/C
Lua/C++
yo'q

Nima uchun

Bu yosh loyiha, ko'p narsa etishmayotgan, ba'zilari erta alfada. Lekin yuborilgan, shuningdek, yoshligi tufayli tez rivojlanmoqda va allaqachon ko'plab qiziqarli xususiyatlarga ega: dinamik konfiguratsiya, ko'plab tayyor filtrlar, o'z filtrlaringizni yozish uchun oddiy interfeys.
Qo'llash sohalari bundan kelib chiqadi, lekin birinchi navbatda ikkita antipattern mavjud:

  • Statik orqaga qaytish.

Gap shundaki, ayni paytda yuborilgan keshlashni qo'llab-quvvatlamaydi. Google yigitlari buni sinab ko'rishmoqda tuzatmoq. G'oya bir marta amalga oshiriladi yuborilgan RFC muvofiqligining barcha nozik tomonlari (hayvonot bog'i sarlavhalari) va maxsus ilovalar uchun interfeys yaratadi. Ammo hozircha bu hatto alfa emas, arxitektura muhokama qilinmoqda, PR ochiq (men PR maqolasini yozayotganimda, PR qotib qoldi, ammo bu nuqta hali ham dolzarbdir).

Hozircha statika uchun nginx dan foydalaning.

  • Statik konfiguratsiya.

Siz undan foydalanishingiz mumkin, lekin yuborilgan Buning uchun yaratilgan emas. Statik konfiguratsiyadagi funksiyalar oshkor etilmaydi. Ko'p daqiqalar bor:

Yaml-da konfiguratsiyani tahrirlashda siz adashasiz, ishlab chiquvchilarni mufassallik uchun tanqid qilasiz va nginx/haproxy konfiguratsiyasi kamroq tuzilgan bo'lsa ham, ixchamroq deb o'ylaysiz. Gap shundaki. Nginx va Haproxy konfiguratsiyasi qo'lda tahrirlash uchun yaratilgan va yuborilgan koddan yaratish uchun. Barcha konfiguratsiya maqolada tasvirlangan protobuf, uni proto-fayllardan yaratishda xato qilish ancha qiyin.

Canary, b/g joylashtirish stsenariylari va boshqalar odatda faqat dinamik konfiguratsiyada amalga oshiriladi. Men buni statik tarzda amalga oshirib bo'lmaydi, deb aytmayapman, biz hammamiz buni qilamiz. Ammo buning uchun siz har qanday muvozanatlashtirgichda tayoqchalarni qo'yishingiz kerak yuborilgan shu jumladan.

Elchi ajralmas bo'lgan vazifalar:

  • Murakkab va dinamik tizimlarda trafikni muvozanatlash. Bunga xizmat ko'rsatish tarmog'i kiradi, lekin bu yagona emas.
  • Taqsimlangan kuzatuv funksiyasi, murakkab avtorizatsiya yoki mavjud bo'lgan boshqa funksiyalarga bo'lgan ehtiyoj yuborilgan qutidan tashqarida yoki qulay tarzda amalga oshiriladi, lekin nginx/haproxy-da siz lua va shubhali plaginlar bilan o'ralgan bo'lishingiz kerak.

Agar kerak bo'lsa, ikkalasi ham yuqori ishlashni ta'minlaydi.

U qanday ishlaydi

Elchi ikkilik formatda faqat docker tasviri sifatida tarqatiladi. Rasmda allaqachon statik konfiguratsiya namunasi mavjud. Ammo biz uni faqat strukturani tushunish uchun qiziqtiramiz.

envoy.yaml statik konfiguratsiyasi

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 konfiguratsiya

Biz qanday muammoga yechim izlayapmiz? Siz yuk ostida faqat yuk balansi konfiguratsiyasini qayta yuklay olmaysiz, "kichik" muammolar paydo bo'ladi:

  • Konfiguratsiyani tekshirish.

Konfiguratsiya katta bo'lishi mumkin, u juda katta bo'lishi mumkin, agar biz uni bir vaqtning o'zida haddan tashqari yuklasak, biror joyda xatolik ehtimoli ortadi.

  • Uzoq muddatli aloqalar.

Yangi tinglovchini ishga tushirayotganda, siz eskisida ishlayotgan ulanishlar haqida g'amxo'rlik qilishingiz kerak; agar o'zgarishlar tez-tez sodir bo'lsa va uzoq muddatli ulanishlar mavjud bo'lsa, siz murosaga kelishingiz kerak bo'ladi. Salom, kubernetlar nginx-ga kirishmoqda.

  • Faol sog'liqni tekshirish.

Agar bizda faol sog'liq tekshiruvlari bo'lsa, trafikni yuborishdan oldin ularning barchasini yangi konfiguratsiyada ikki marta tekshirishimiz kerak. Yuqori oqimlar ko'p bo'lsa, bu vaqt talab etadi. Salom haproksi.

Bu qanday hal qilinadi yuborilganKonfiguratsiyani dinamik ravishda yuklash orqali, hovuz modeliga ko'ra, siz uni alohida qismlarga bo'lishingiz va o'zgarmagan qismini qayta ishga tushirmasligingiz mumkin. Masalan, qayta ishga tushirish qimmat va kamdan-kam o'zgarib turadigan tinglovchi.

Konfiguratsiya yuborilgan (yuqoridagi fayldan) quyidagi ob'ektlarga ega:

  • tinglovchi β€” ma'lum bir ip/portda osilgan tinglovchi
  • virtual xost - domen nomi bo'yicha virtual xost
  • yo'nalish - muvozanat qoidasi
  • Klaster β€” muvozanatlash parametrlari bilan yuqori oqimlar guruhi
  • so'nggi nuqta β€” yuqoridagi misol manzili

Ushbu ob'ektlarning har biri va boshqalar dinamik ravishda to'ldirilishi mumkin; buning uchun konfiguratsiya konfiguratsiya olinadigan xizmat manzilini belgilaydi. Xizmat REST yoki gRPC bo'lishi mumkin, gRPC afzalroqdir.

Xizmatlar mos ravishda nomlanadi: LDS, VHDS, RDS, CDS va EDS. Siz statik va dinamik konfiguratsiyani birlashtira olasiz, cheklov bilan dinamik resursni statikda ko'rsatib bo'lmaydi.

Aksariyat vazifalar uchun oxirgi uchta xizmatni amalga oshirish kifoya, ular ADS (Aggregated Discovery Service) deb ataladi. java va u erda gRPC ma'lumotlar tekisligining tayyor dasturi mavjud bo'lib, unda siz faqat manbadan ob'ektlarni to'ldirishingiz kerak.

Konfiguratsiya quyidagi shaklni oladi:

envoy.yaml dinamik konfiguratsiyasi

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

Ishga tushirishda yuborilgan ushbu konfiguratsiya bilan u boshqaruv tekisligiga ulanadi va RDS, CDS va EDS konfiguratsiyasini so'rashga harakat qiladi. O'zaro ta'sir jarayoni qanday sodir bo'lishi tasvirlangan shu yerda.

Qisqasi, yuborilgan so'ralayotgan resurs turini, tugunning versiyasi va parametrlarini ko'rsatuvchi so'rov yuboradi. Bunga javoban u resurs va versiyani oladi, agar boshqaruv tekisligidagi versiya o'zgarmagan bo'lsa, u javob bermaydi.
O'zaro ta'sirning 4 ta varianti mavjud:

  • Barcha turdagi resurslar uchun bitta gRPC oqimi, resursning to'liq holati yuboriladi.
  • Alohida oqimlar, to'liq holat.
  • Bitta oqim, incremental holat.
  • Alohida oqimlar, incremental holat.

Incremental xDS sizga boshqaruv tekisligi va orasidagi trafikni kamaytirish imkonini beradi yuborilgan, bu katta konfiguratsiyalar uchun tegishli. Ammo bu o'zaro aloqani murakkablashtiradi, so'rovda obunani bekor qilish va obuna bo'lish uchun resurslar ro'yxati mavjud.

Bizning misolimizda ADS qo'llaniladi - RDS, CDS, EDS va qo'shimcha bo'lmagan rejim uchun bitta oqim. Incremental rejimni yoqish uchun siz belgilashingiz kerak api_type: DELTA_GRPC

So'rov tugun parametrlarini o'z ichiga olganligi sababli, biz turli xil misollar uchun boshqaruv tekisligiga turli resurslarni yuborishimiz mumkin yuborilgan, bu xizmat ko'rsatish tarmog'ini qurish uchun qulay.

Qizdirish; isitish

ning yuborilgan ishga tushirilganda yoki boshqaruv tekisligidan yangi konfiguratsiyani olganda, resursni isitish jarayoni boshlanadi. U tinglovchilarni isitish va klasterni isitishga bo'linadi. Birinchisi RDS/LDSda o'zgarishlar bo'lganda ishga tushiriladi, ikkinchisi CDS/EDSda. Bu shuni anglatadiki, agar faqat yuqori oqimlar o'zgarsa, tinglovchi qayta yaratilmaydi.

Isitish jarayonida, vaqt tugashi vaqtida nazorat tekisligidan qaram resurslar kutiladi. Vaqt tugashi sodir bo'lsa, ishga tushirish muvaffaqiyatli bo'lmaydi va yangi tinglovchi portda tinglashni boshlamaydi.
Boshlash tartibi: EDS, CDS, faol sog'liqni tekshirish, RDS, LDS. Faol salomatlik tekshiruvi yoqilgan bo'lsa, tirbandlik faqat bitta muvaffaqiyatli tekshiruvdan so'ng yuqoriga yo'naltiriladi.

Agar tinglovchi qayta yaratilgan bo'lsa, eskisi DRAIN holatiga o'tadi va barcha ulanishlar yopilgandan yoki kutish muddati tugagandan so'ng o'chiriladi. --drain-time-s, standart 10 daqiqa.

Davomi bor.

Manba: www.habr.com

a Izoh qo'shish