🥇 اسٹیو کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 2

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

ہم آپ کو یہ بھی یاد دلاتے ہیں کہ مضمون ریپوزٹری سے کنفیگریشنز (Kubernetes اور Istio کے لیے ظاہر) کا استعمال کرتا ہے۔ istio-mastery.

ٹریفک مینجمنٹ

Istio کے ساتھ، کلسٹر میں نئی صلاحیتیں فراہم کرنے کے لیے ظاہر ہوتی ہیں:

متحرک درخواست کی روٹنگ: کینری رول آؤٹ، A/B ٹیسٹنگ؛
وزن کو متوازن کرنا: سادہ اور مستقل، ہیش پر مبنی؛
زوال کے بعد بحالی: ٹائم آؤٹ، دوبارہ کوششیں، سرکٹ بریکر؛
نقائص داخل کرنا: تاخیر، درخواستیں چھوڑنا وغیرہ۔

جیسا کہ مضمون جاری ہے، ان صلاحیتوں کو بطور مثال منتخب ایپلیکیشن کا استعمال کرتے ہوئے دکھایا جائے گا اور راستے میں نئے تصورات متعارف کرائے جائیں گے۔ پہلا ایسا تصور ہوگا۔ DestinationRules (یعنی ٹریفک/درخواستوں کے وصول کنندہ کے بارے میں قواعد - تقریباً ترجمہ)، جس کی مدد سے ہم A/B ٹیسٹنگ کو چالو کرتے ہیں۔

A/B ٹیسٹنگ: عملی طور پر منزل کے اصول

A/B ٹیسٹنگ کا استعمال ان صورتوں میں کیا جاتا ہے جہاں ایپلیکیشن کے دو ورژن ہوتے ہیں (عام طور پر وہ بصری طور پر مختلف ہوتے ہیں) اور ہمیں 100% یقین نہیں ہے کہ کون سا صارف کے تجربے کو بہتر بنائے گا۔ لہذا، ہم دونوں ورژن ایک ساتھ چلاتے ہیں اور میٹرکس جمع کرتے ہیں۔

فرنٹ اینڈ کے دوسرے ورژن کو تعینات کرنے کے لیے، A/B ٹیسٹنگ کا مظاہرہ کرنے کے لیے ضروری ہے، درج ذیل کمانڈ کو چلائیں:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

گرین ورژن کے لیے تعیناتی مینی فیسٹ دو جگہوں پر مختلف ہے:

تصویر ایک مختلف ٹیگ پر مبنی ہے - istio-green,
پھلیوں کا ایک لیبل ہوتا ہے۔ version: green.

چونکہ دونوں تعیناتیوں کا ایک لیبل ہے۔ app: sa-frontendورچوئل سروس کے ذریعے بھیجی گئی درخواستیں۔ sa-external-services خدمت کے لیے sa-frontend, اس کی تمام مثالوں پر ری ڈائریکٹ کیا جائے گا اور بوجھ کے ذریعے تقسیم کیا جائے گا۔ راؤنڈ رابن الگورتھم، جو درج ذیل صورت حال کا باعث بنے گا:

مطلوبہ فائلیں نہیں ملیں۔

یہ فائلیں نہیں ملیں کیونکہ ایپلیکیشن کے مختلف ورژن میں ان کا نام مختلف ہے۔ آئیے اس بات کو یقینی بنائیں:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

اس کا مطلب یہ ہے کہ index.html, جامد فائلوں کے ایک ورژن کی درخواست کرتے ہوئے، لوڈ بیلنسر کے ذریعے ان پوڈز کو بھیجا جا سکتا ہے جن کا ورژن مختلف ہے، جہاں واضح وجوہات کی بناء پر ایسی فائلیں موجود نہیں ہیں۔ لہذا، درخواست کے کام کرنے کے لیے، ہمیں ایک پابندی لگانے کی ضرورت ہے:ایپلیکیشن کا وہی ورژن جس نے index.html پیش کیا تھا اسے بعد کی درخواستیں پیش کرنی چاہئیں'.

ہم مسلسل ہیش پر مبنی لوڈ بیلنسنگ کے ساتھ وہاں پہنچیں گے۔ (مسلسل ہیش لوڈ بیلنسنگ). اس معاملے میں ایک ہی کلائنٹ کی درخواستیں اسی بیک اینڈ مثال کو بھیجی جاتی ہیں۔، جس کے لیے پہلے سے طے شدہ پراپرٹی استعمال کی جاتی ہے - مثال کے طور پر، ایک HTTP ہیڈر۔ Destination Rules کا استعمال کرتے ہوئے لاگو کیا گیا۔

منزل کے اصول

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

Istio وسائل کے ساتھ ٹریفک کا انتظام

نوٹ: نیٹ ورک ٹریفک پر Istio وسائل کے اثرات کو یہاں اس انداز میں پیش کیا گیا ہے جسے سمجھنا آسان ہے۔ واضح طور پر، درخواست کو کس مثال پر بھیجنا ہے، یہ فیصلہ سی آر ڈی میں تشکیل شدہ انگریس گیٹ وے میں ایلچی کرتا ہے۔

ڈیسٹینیشن رولز کے ساتھ، ہم مسلسل ہیشز استعمال کرنے کے لیے لوڈ بیلنسنگ کو ترتیب دے سکتے ہیں اور اس بات کو یقینی بنا سکتے ہیں کہ ایک ہی سروس مثال ایک ہی صارف کو جواب دیتی ہے۔ درج ذیل ترتیب آپ کو یہ حاصل کرنے کی اجازت دیتی ہے (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP ہیڈر کے مواد کی بنیاد پر ہیش تیار کی جائے گی۔ version.

مندرجہ ذیل کمانڈ کے ساتھ ترتیب کو لاگو کریں:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

اب نیچے دی گئی کمانڈ کو چلائیں اور اس بات کو یقینی بنائیں کہ جب آپ ہیڈر کی وضاحت کرتے ہیں تو آپ کو صحیح فائلیں ملتی ہیں۔ version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

نوٹ: ہیڈر میں مختلف قدریں شامل کرنے اور نتائج کو براہ راست براؤزر میں جانچنے کے لیے، آپ استعمال کر سکتے ہیں۔ یہ توسیع کروم کو (یا اس کے ساتھ فائر فاکس کے لیے - تقریبا ترجمہ).

عام طور پر، Destination Rules میں لوڈ بیلنسنگ کے شعبے میں زیادہ صلاحیتیں ہیں - تفصیلات کے لیے سرکاری دستاویزات.

ورچوئل سروس کا مزید مطالعہ کرنے سے پہلے، آئیے درج ذیل کمانڈز کو چلا کر ایپلیکیشن کے "گرین ورژن" اور متعلقہ ٹریفک سمت کے اصول کو حذف کر دیں۔

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

عکس بندی: پریکٹس میں ورچوئل سروسز

سایہ ("شیلنگ") یا آئینہ دار ("عکس") ان صورتوں میں استعمال کیا جاتا ہے جہاں ہم اختتامی صارفین کو متاثر کیے بغیر پیداوار میں تبدیلی کی جانچ کرنا چاہتے ہیں: ایسا کرنے کے لیے، ہم دوسری مثال کے لیے ("عکس") درخواستوں کو نقل کرتے ہیں جہاں مطلوبہ تبدیلیاں کی گئی ہوں، اور نتائج کو دیکھیں۔ سیدھے الفاظ میں، یہ تب ہوتا ہے جب آپ کا ساتھی سب سے اہم مسئلہ کو چنتا ہے اور گندگی کے اتنے بڑے ڈھیر کی شکل میں پل کی درخواست کرتا ہے کہ کوئی بھی حقیقت میں اس کا جائزہ نہیں لے سکتا۔

اس منظرنامے کو عملی طور پر جانچنے کے لیے، آئیے کیڑے کے ساتھ SA-Logic کی دوسری مثال بنائیں (buggy) درج ذیل کمانڈ کو چلا کر:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

اور اب اس بات کو یقینی بنانے کے لیے کمانڈ چلاتے ہیں کہ تمام مثالیں اس کے ساتھ ہیں۔ app=sa-logic ان کے پاس متعلقہ ورژن کے ساتھ لیبل بھی ہیں:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

سروس sa-logic ایک لیبل کے ساتھ پھلیوں کو نشانہ بناتا ہے۔ app=sa-logic، لہذا تمام درخواستوں کو تمام مثالوں میں تقسیم کیا جائے گا:

... لیکن ہم چاہتے ہیں کہ درخواستیں v1 مثالوں کو بھیجی جائیں اور v2 مثالوں میں عکس بند کی جائیں:

ہم اسے VirtualService کے ذریعے DestinationRule کے ساتھ مل کر حاصل کریں گے، جہاں قواعد ایک مخصوص ذیلی سیٹ کے لیے VirtualService کے سب سیٹ اور روٹس کا تعین کریں گے۔

منزل کے قواعد میں ذیلی سیٹوں کی وضاحت کرنا

ذیلی سیٹ (سب سیٹ) مندرجہ ذیل ترتیب کے ذریعہ طے کیا جاتا ہے (sa-logic-subset-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

میزبان (host) وضاحت کرتا ہے کہ یہ اصول صرف ان صورتوں پر لاگو ہوتا ہے جب راستہ سروس کی طرف جاتا ہے۔ sa-logic;
عنوانات (name) سب سیٹ استعمال کیے جاتے ہیں جب سب سیٹ مثالوں کو روٹ کرتے ہیں۔
لیبل (label) کلیدی قدر کے جوڑوں کی وضاحت کرتا ہے جو سب سیٹ کا حصہ بننے کے لیے مثالوں کا مماثل ہونا چاہیے۔

مندرجہ ذیل کمانڈ کے ساتھ ترتیب کو لاگو کریں:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

اب جب کہ ذیلی سیٹوں کی وضاحت ہو گئی ہے، ہم آگے بڑھ سکتے ہیں اور ورچوئل سروس کو ترتیب دے سکتے ہیں تاکہ sa-logic کی درخواستوں پر قواعد لاگو کر سکیں تاکہ وہ:

ایک ذیلی سیٹ پر بھیج دیا گیا۔ v1,
ایک ذیلی سیٹ پر عکس بند v2.

درج ذیل منشور آپ کو اپنے منصوبوں کو حاصل کرنے کی اجازت دیتا ہے (sa-logic-subset-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

یہاں کسی وضاحت کی ضرورت نہیں ہے، تو آئیے اسے عمل میں دیکھتے ہیں:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

آئیے درج ذیل کمانڈ کو کال کرکے بوجھ شامل کریں:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

آئیے گرافانا کے نتائج کو دیکھتے ہیں، جہاں آپ دیکھ سکتے ہیں کہ کیڑے کے ساتھ ورژن (buggy) کے نتیجے میں ~60% درخواستوں میں ناکامی ہوتی ہے، لیکن ان میں سے کوئی بھی ناکامی آخری صارفین کو متاثر کرتی ہے کیونکہ انہیں چلتی ہوئی سروس کے ذریعے جواب دیا جاتا ہے۔

sa-logic سروس کے مختلف ورژن کے کامیاب جوابات

یہاں ہم نے پہلے دیکھا کہ ہماری خدمات کے ایلچی پر ورچوئل سروس کا اطلاق کس طرح ہوتا ہے: کب sa-web-app سے درخواست کرتا ہے sa-logic، یہ سائڈکار اینوائے سے گزرتا ہے، جو - ورچوئل سروس کے ذریعے - درخواست کو v1 سبسیٹ پر روٹ کرنے اور سروس کے v2 سب سیٹ پر درخواست کا عکس دینے کے لیے ترتیب دیا گیا ہے۔ sa-logic.

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

کینری رول آؤٹ

Canary Deployment ایک ایپلیکیشن کے نئے ورژن کو صارفین کی ایک چھوٹی تعداد تک پہنچانے کا عمل ہے۔ اس کا استعمال اس بات کو یقینی بنانے کے لیے کیا جاتا ہے کہ ریلیز میں کوئی دشواری نہ ہو اور اس کے بعد ہی، اس کے (ریلیز کے) معیار پر پہلے سے ہی یقین رکھتے ہوئے، اسے دوسرے صارفین میں تقسیم کریں۔оزیادہ سامعین.

کینری رول آؤٹ کو ظاہر کرنے کے لیے، ہم سب سیٹ کے ساتھ کام جاری رکھیں گے۔ buggy у sa-logic.

آئیے چھوٹی چھوٹی باتوں پر وقت ضائع نہ کریں اور فوری طور پر 20% صارفین کو بگز والے ورژن میں بھیجیں (یہ ہمارے کینری رول آؤٹ کی نمائندگی کرے گا) اور بقیہ 80% کو نارمل سروس میں بھیج دیں۔ ایسا کرنے کے لیے درج ذیل ورچوئل سروس (sa-logic-subset-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 وزن ہے (weight)، جو درخواستوں کا فیصد بتاتا ہے جو وصول کنندہ یا وصول کنندہ کے ذیلی سیٹ کو بھیجی جائیں گی۔

آئیے اس کے لیے پچھلی ورچوئل سروس کنفیگریشن کو اپ ڈیٹ کرتے ہیں۔ sa-logic درج ذیل کمانڈ کے ساتھ:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... اور ہم فوری طور پر دیکھیں گے کہ کچھ درخواستیں ناکامی کا باعث بنتی ہیں:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

ورچوئل سروسز کینری رول آؤٹ کو فعال کرتی ہیں: اس معاملے میں، ہم نے مسائل کے ممکنہ اثرات کو صارف کی بنیاد کے 20% تک محدود کر دیا ہے۔ کمال ہے! اب، ہر معاملے میں جب ہمیں اپنے کوڈ کے بارے میں یقین نہیں ہے (دوسرے لفظوں میں - ہمیشہ...)، ہم آئینہ دار اور کینری رول آؤٹ استعمال کر سکتے ہیں۔

ٹائم آؤٹ اور دوبارہ کوششیں

لیکن کیڑے ہمیشہ کوڈ میں ختم نہیں ہوتے ہیں۔ فہرست میں سے "تقسیم شدہ کمپیوٹنگ کے بارے میں 8 غلط فہمیاں"پہلی جگہ یہ غلط عقیدہ ہے کہ "نیٹ ورک قابل اعتماد ہے۔" حقیقت میں نیٹ ورک کوئی قابل اعتماد، اور اس وجہ سے ہمیں ٹائم آؤٹ کی ضرورت ہے۔ (ٹائم آؤٹ) اور دوبارہ کوشش کرتا ہے۔ (دوبارہ کوششیں).

مظاہرے کے لیے ہم وہی مسئلہ ورژن استعمال کرتے رہیں گے۔ sa-logic (buggy)، اور ہم بے ترتیب ناکامیوں کے ساتھ نیٹ ورک کی ناقابل اعتباریت کی نقالی کریں گے۔

کیڑے کے ساتھ ہماری سروس کو جواب دینے میں بہت زیادہ وقت لگنے کا 1/3 موقع، اندرونی سرور کی خرابی کے ساتھ ختم ہونے کا 1/3 موقع، اور صفحہ کو کامیابی سے واپس کرنے کا 1/3 موقع ہونے دیں۔

اس طرح کے مسائل کے اثرات کو کم کرنے اور صارفین کی زندگی کو بہتر بنانے کے لیے، ہم یہ کر سکتے ہیں:

اگر سروس کو جواب دینے میں 8 سیکنڈ سے زیادہ وقت لگتا ہے تو ٹائم آؤٹ شامل کریں،
درخواست ناکام ہونے پر دوبارہ کوشش کریں۔

عمل درآمد کے لیے، ہم درج ذیل وسائل کی تعریف استعمال کریں گے (sa-logic-retry-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

درخواست کا ٹائم آؤٹ 8 سیکنڈ پر سیٹ کیا گیا ہے۔
درخواستوں کی 3 بار دوبارہ کوشش کی جاتی ہے۔
اور ہر کوشش کو ناکام سمجھا جاتا ہے اگر جواب کا وقت 3 سیکنڈ سے زیادہ ہو جائے۔

یہ ایک اصلاح ہے کیونکہ صارف کو 8 سیکنڈ سے زیادہ انتظار نہیں کرنا پڑے گا اور ہم ناکامی کی صورت میں جواب حاصل کرنے کے لیے تین نئی کوششیں کریں گے، جس سے کامیاب جواب کا امکان بڑھ جائے گا۔

مندرجہ ذیل کمانڈ کے ساتھ اپ ڈیٹ کردہ ترتیب کو لاگو کریں:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

اور گرافانا گراف میں چیک کریں کہ کامیاب جوابات کی تعداد اوپر بڑھ گئی ہے:

ٹائم آؤٹ اور دوبارہ کوششوں کو شامل کرنے کے بعد کامیاب جوابی اعدادوشمار میں بہتری

اگلے حصے پر جانے سے پہلے (یا بلکہ، مضمون کے اگلے حصے میں، کیونکہ اس میں مزید عملی تجربات نہیں ہوں گے - تقریباً ترجمہ۔)، حذف کریں۔ sa-logic-buggy اور ورچوئل سروس درج ذیل کمانڈز چلا کر:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

سرکٹ بریکر اور بلک ہیڈ پیٹرن

ہم مائیکرو سرویس فن تعمیر میں دو اہم نمونوں کے بارے میں بات کر رہے ہیں جو آپ کو خود بحالی حاصل کرنے کی اجازت دیتے ہیں۔ (خود علاج) خدمات

سرکٹ بریکر ("سرکٹ بریکر") کسی خدمت کی مثال پر آنے والی درخواستوں کو ختم کرنے اور اسے بحال کرنے کے لیے استعمال کیا جاتا ہے جب کہ کلائنٹ کی درخواستوں کو اس سروس کی صحت مند مثالوں پر بھیج دیا جاتا ہے (جو کامیاب جوابات کا فیصد بڑھاتا ہے)۔ (نوٹ: پیٹرن کی مزید تفصیلی وضاحت مل سکتی ہے، مثال کے طور پر، یہاں.)

بلک ہیڈ ("تقسیم") سروس کی ناکامیوں کو پورے نظام کو متاثر کرنے سے الگ کرتا ہے۔ مثال کے طور پر، سروس B ٹوٹ گئی ہے اور ایک اور سروس (سروس B کا کلائنٹ) سروس B سے درخواست کرتی ہے، جس کی وجہ سے وہ اپنے تھریڈ پول کو ختم کر دیتی ہے اور دوسری درخواستوں کی خدمت کرنے سے قاصر رہتی ہے (چاہے وہ سروس B سے نہ ہوں)۔ (نوٹ: پیٹرن کی مزید تفصیلی وضاحت مل سکتی ہے، مثال کے طور پر، یہاں.)

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

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

"استیو کے ساتھ مائیکرو سروسز پر واپس جائیں": حصہ 1 (اہم خصوصیات کا تعارف), حصہ 3 (تصدیق اور اجازت);
«نالی - Kubernetes کے لیے ہلکا پھلکا سروس میش؛ "
«سروس میش کیا ہے اور مجھے اس کی ضرورت کیوں ہے [مائیکرو سروسز کے ساتھ کلاؤڈ ایپلیکیشن کے لیے]؟'.

ماخذ: www.habr.com

Istio کے ساتھ مائیکرو سروسز پر واپس جائیں۔ حصہ 2