ایلچی 1. تعارف

سلام! یہ ایک مختصر مضمون ہے جو ان سوالات کا جواب دیتا ہے: "ایلچی کیا ہے؟"، "اس کی ضرورت کیوں ہے؟" اور "کہاں سے شروع کرنا ہے؟"۔

یہ کیا ہے

Envoy ایک L4-L7 بیلنس ہے جو C++ میں لکھا گیا ہے، جو اعلی کارکردگی اور دستیابی پر مرکوز ہے۔ ایک طرف، یہ ایک طرح سے nginx اور haproxy کا ایک ینالاگ ہے، جو ان کی کارکردگی میں موازنہ ہے۔ دوسری طرف، یہ مائیکرو سروس آرکیٹیکچر کی طرف زیادہ پر مبنی ہے اور اس کی فعالیت جاوا اور گو بیلنسرز، جیسے زوول یا ٹریفیک سے بدتر نہیں ہے۔

haproxy/nginx/envoy کی موازنہ کی میز، یہ مطلق سچائی ہونے کا دعویٰ نہیں کرتی، لیکن ایک عمومی تصویر پیش کرتی ہے۔

نگنکس
ہپروکسی
بھیجا
ٹریفک

گیتھب پر ستارے
11.2k/آئینہ
1.1k/آئینہ
12.4k
27.6k

میں لکھا ہوا
C
C
C ++
go

API
нет
صرف ساکٹ/دھکا
ڈیٹا پلین/پل
ھیںچو

فعال صحت کی جانچ
нет
جی ہاں
جی ہاں
جی ہاں

اوپن ٹریسنگ
بیرونی پلگ ان
нет
جی ہاں
جی ہاں

جے ڈبلیو ٹی
بیرونی پلگ ان
нет
جی ہاں
нет

توسیع
Lua/C
Lua/C
Lua/C++
нет

کیوں؟

یہ ایک نوجوان پروجیکٹ ہے، بہت سی چیزیں غائب ہیں، کچھ ابتدائی الفا میں۔ لیکن بھیجااپنی جوانی کی وجہ سے بھی تیزی سے ترقی کر رہا ہے اور اس میں پہلے سے ہی بہت سی دلچسپ خصوصیات ہیں: متحرک کنفیگریشن، بہت سے ریڈی میڈ فلٹرز، اپنے فلٹرز لکھنے کے لیے ایک سادہ انٹرفیس۔
درخواست کے علاقے اس سے چلتے ہیں، لیکن پہلے 2 اینٹی پیٹرن ہیں:

• جامد پیچھے ہٹنا۔

حقیقت یہ ہے کہ اس وقت میں بھیجا کوئی کیشنگ سپورٹ نہیں۔ گوگل والے یہ کوشش کر رہے ہیں۔ ٹھیک کریں. خیال ایک بار میں لاگو کیا جائے گا بھیجا RFC کی تعمیل کی تمام باریکیوں (zoo headers) اور مخصوص نفاذ کے لیے ایک انٹرفیس بناتا ہے۔ لیکن ابھی یہ الفا بھی نہیں ہے، فن تعمیر زیر بحث ہے، PR کھولیں (جب میں PR مضمون لکھ رہا تھا، PR منجمد ہو گیا، لیکن یہ نکتہ اب بھی متعلقہ ہے)۔

ابھی کے لیے، statics کے لیے nginx استعمال کریں۔

• جامد ترتیب۔

آپ اسے استعمال کر سکتے ہیں، لیکن بھیجا یہ اس کے لیے نہیں بنایا گیا تھا۔ جامد ترتیب میں خصوصیات کو سامنے نہیں لایا جائے گا۔ بہت سے لمحات ہیں:

yaml میں کنفیگریشن میں ترمیم کرتے وقت، آپ سے غلطی ہو جائے گی، ڈیولپرز کو لفظوں کے لیے ڈانٹیں گے اور سوچیں گے کہ nginx/haproxy کنفیگریشنز، اگرچہ کم ساختہ ہیں، زیادہ جامع ہیں۔ یہی تو بات ہے. Nginx اور Haproxy کی ترتیب ہاتھ سے ترمیم کے لیے بنائی گئی تھی۔ بھیجا کوڈ سے نسل کے لیے۔ پوری ترتیب میں بیان کیا گیا ہے۔ protobuf، اسے پروٹو فائلوں سے بنانا غلطی کرنا زیادہ مشکل ہے۔

کینری، 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 پر داخل ہو رہے ہیں۔

• فعال صحت کی جانچ۔

اگر ہمارے پاس صحت کے فعال معائنے ہیں، تو ہمیں ٹریفک بھیجنے سے پہلے ان سب کو نئی ترتیب میں دوبارہ چیک کرنے کی ضرورت ہے۔ اگر بہت سارے اوپری سلسلے ہیں، تو اس میں وقت لگتا ہے۔ ہیلو ہاپروکسی۔

اس میں کیسے حل ہوتا ہے۔ بھیجاترتیب کو متحرک طور پر لوڈ کر کے، پول ماڈل کے مطابق، آپ اسے الگ الگ حصوں میں تقسیم کر سکتے ہیں اور اس حصے کو دوبارہ شروع نہیں کر سکتے جو تبدیل نہیں ہوا ہے۔ مثال کے طور پر، ایک سننے والا، جسے دوبارہ شروع کرنا مہنگا ہے اور شاذ و نادر ہی تبدیل ہوتا ہے۔

تشکیل بھیجا (اوپر کی فائل سے) درج ذیل ادارے ہیں:

• سننے والا - سننے والا ایک مخصوص آئی پی/پورٹ پر لٹک رہا ہے۔
• مجازی میزبان - ڈومین نام کے ذریعہ ورچوئل میزبان
• راستہ - توازن کا اصول
• کلسٹر - توازن کے پیرامیٹرز کے ساتھ upstreams کا ایک گروپ
• آخر پوائنٹ - اپ اسٹریم مثال کا پتہ

ان اداروں میں سے ہر ایک کے علاوہ کچھ دیگر کو متحرک طور پر بھرا جا سکتا ہے؛ اس کے لیے، کنفیگریشن سروس کا پتہ بتاتی ہے جہاں سے کنفیگریشن وصول کی جائے گی۔ سروس 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