نماینده. 1. معرفی

با درود! این مقاله کوتاهی است که به این سؤالات پاسخ می دهد: "فرستاده چیست؟"، "چرا به آن نیاز است؟" و "از کجا شروع کنیم؟"

این چیست؟

Envoy یک متعادل کننده L4-L7 است که به زبان C++ نوشته شده است و بر عملکرد و در دسترس بودن بالا تمرکز دارد. از یک طرف، این به نوعی مشابه nginx و هاپروکسی است که از نظر عملکرد با آنها قابل مقایسه است. از طرف دیگر، بیشتر به سمت معماری میکروسرویس گرایش دارد و عملکردی بدتر از متعادل کننده های java و go مانند zuul یا traefik ندارد.

جدول مقایسه هاپروکسی / nginx / فرستاده، ادعا نمی کند که حقیقت مطلق است، اما یک تصویر کلی ارائه می دهد.

انجیناکس
هاپروکسی
فرستاده
صفت

ستاره در github
11.2k/آینه
1.1k/آینه
12.4k
27.6k

نوشته شده در
C
C
++C
go

API
هیچ
فقط سوکت/فشار
هواپیمای دیتا/کشش
کشیدن

چک سلامت فعال
هیچ
بله
بله
بله

ردیابی باز
افزونه خارجی
هیچ
بله
بله

J.W.T.
افزونه خارجی
هیچ
بله
هیچ

گسترش
Lua/C
Lua/C
Lua/C++
هیچ

برای چه؟

این یک پروژه جوان است، چیزهای زیادی از دست رفته است، برخی در اوایل آلفا. ولی فرستاده، همچنین به دلیل جوانی خود، به سرعت در حال توسعه است و در حال حاضر دارای بسیاری از ویژگی های جالب است: پیکربندی پویا، بسیاری از فیلترهای آماده، یک رابط کاربری ساده برای نوشتن فیلترهای خود.
حوزه های کاربردی از این نتیجه می گیرند، اما ابتدا 2 ضد الگو وجود دارد:

• پس زدن استاتیک.

واقعیت این است که در حال حاضر در فرستاده بدون پشتیبانی کش بچه های گوگل این را امتحان می کنند برای رفع. این ایده یک بار اجرا خواهد شد فرستاده تمام ظرافت‌ها (سرصفحه‌های باغ‌وحش) مطابقت RFC، و برای پیاده‌سازی‌های خاص یک رابط ایجاد کنید. اما در حال حاضر حتی آلفا نیست، معماری در حال بحث است، PR باز کردن (زمانی که من مقاله روابط عمومی را می نوشتم، روابط عمومی متوقف شد، اما این نکته همچنان مرتبط است).

در حال حاضر، از nginx برای استاتیک استفاده کنید.

• پیکربندی استاتیک

می توانید از آن استفاده کنید، اما فرستاده این چیزی نیست که برای آن ایجاد شده است. ویژگی‌های یک پیکربندی استاتیک در معرض نمایش قرار نخواهند گرفت. لحظات زیادی وجود دارد:

هنگام ویرایش پیکربندی در yaml، اشتباه می‌کنید، توسعه‌دهندگان را به خاطر پرحرفی سرزنش می‌کنید و فکر می‌کنید که پیکربندی‌های nginx/haproxy، اگرچه ساختار کمتری دارند، اما مختصرتر هستند. نکته همین است. پیکربندی Nginx و Haproxy برای ویرایش با دست ایجاد شده است و فرستاده برای تولید از کد. کل پیکربندی در شرح داده شده است پروتوبوف، اشتباه کردن آن از فایل های پروتو بسیار دشوارتر است.

سناریوهای استقرار Canary، b/g و موارد دیگر معمولاً فقط در یک پیکربندی پویا اجرا می شوند. من نمی گویم که این کار را نمی توان به صورت ایستا انجام داد، همه ما این کار را انجام می دهیم. اما برای این کار باید عصا را در هر یک از متعادل کننده ها در داخل بپوشید فرستاده شامل.

وظایفی که فرستاده برای آنها ضروری است:

• تعادل ترافیک در سیستم های پیچیده و پویا این شامل مش سرویس نیز می شود، اما لزوما تنها یکی نیست.
• نیاز به عملکرد ردیابی توزیع شده، مجوز پیچیده یا سایر عملکردهایی که در آن موجود است فرستاده خارج از جعبه یا به راحتی پیاده سازی شده است، اما در nginx/haproxy باید توسط lua و پلاگین های مشکوک احاطه شوید.

هر دو، در صورت لزوم، عملکرد بالایی را ارائه می دهند.

چطور کار می کند؟

Envoy در باینری ها فقط به عنوان یک تصویر داکر توزیع می شود. تصویر قبلاً حاوی نمونه ای از پیکربندی استاتیک است. اما ما فقط برای درک ساختار به آن علاقه مندیم.

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.

• بررسی های سلامت فعال

اگر چک‌های سلامت فعال داریم، باید قبل از ارسال ترافیک، همه آنها را در پیکربندی جدید بررسی کنیم. اگر بالادستی های زیادی وجود داشته باشد، این زمان می برد. سلام هاپروکسی.

چگونه این در حل می شود فرستادهبا بارگذاری کانفیگ به صورت پویا، با توجه به مدل pool، می توانید آن را به قسمت های جداگانه تقسیم کنید و بخشی را که تغییر نکرده است، دوباره مقدار دهی اولیه نکنید. به عنوان مثال، شنونده، که برای شروع مجدد هزینه بر است و به ندرت تغییر می کند.

پیکربندی فرستاده (از فایل بالا) دارای موجودیت های زیر است:

• شنونده - شنونده در یک ip/port خاص معلق است
• میزبان مجازی - میزبان مجازی با نام دامنه
• مسیر - قانون تعادل
• خوشه - گروهی از بالادست ها با پارامترهای متعادل کننده
• نقطه پایانی - آدرس نمونه بالادست

هر یک از این موجودات به اضافه تعدادی دیگر را می توان به صورت پویا پر کرد؛ برای این، پیکربندی آدرس سرویس را مشخص می کند که پیکربندی از آنجا دریافت می شود. سرویس می تواند REST یا gRPC باشد، gRPC ترجیح داده می شود.

سرویس ها به ترتیب به نام های LDS، VHDS، RDS، CDS و EDS نامگذاری می شوند. شما می توانید پیکربندی استاتیک و پویا را با این محدودیت ترکیب کنید که یک منبع پویا را نمی توان در یک منبع استاتیک مشخص کرد.

برای اکثر وظایف، اجرای سه سرویس آخر کافی است، آنها ADS (سرویس کشف جمعی) نامیده می شوند. جاوه و یک پیاده سازی آماده از gRPC dataplane وجود دارد که در آن فقط باید اشیاء را از منبع خود پر کنید.

پیکربندی به شکل زیر است:

پیکربندی پویا 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