🥇 Istio এর সাথে মাইক্রোসার্ভিসে ফিরে যান। পর্ব 2

বিঃদ্রঃ. অনুবাদ: প্রথম অংশ এই সিরিজটি 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 শিরোনাম। DestinationRules ব্যবহার করে বাস্তবায়িত।

গন্তব্যের নিয়ম

পরে ভার্চুয়াল সার্ভিস কাঙ্খিত পরিষেবাতে একটি অনুরোধ পাঠানো হয়েছে, গন্তব্য নিয়মগুলি ব্যবহার করে আমরা নীতিগুলি সংজ্ঞায়িত করতে পারি যা এই পরিষেবার উদাহরণগুলির জন্য নির্ধারিত ট্র্যাফিকের জন্য প্রয়োগ করা হবে:

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

মন্তব্য: হেডারে বিভিন্ন মান যোগ করতে এবং ব্রাউজারে সরাসরি ফলাফল পরীক্ষা করতে, আপনি ব্যবহার করতে পারেন এই এক্সটেনশন ক্রোমের কাছে (বা এর সাথে ফায়ারফক্সের জন্য - প্রায়। অনুবাদ।).

সাধারণভাবে, লোড ব্যালেন্সিং এর ক্ষেত্রে DestinationRules এর আরো ক্ষমতা আছে - বিস্তারিত জানতে দেখুন অফিসিয়াল ডকুমেন্টেশন.

ভার্চুয়ালসার্ভিস আরও অধ্যয়ন করার আগে, আসুন নিম্নলিখিত কমান্ডগুলি চালিয়ে অ্যাপ্লিকেশনটির "সবুজ সংস্করণ" এবং সংশ্লিষ্ট ট্র্যাফিক দিক নির্দেশনাটি মুছে ফেলি:

$ 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 দৃষ্টান্তে মিরর করা হোক:

আমরা DestinationRule এর সংমিশ্রণে VirtualService এর মাধ্যমে এটি অর্জন করব, যেখানে নিয়মগুলি একটি নির্দিষ্ট উপসেটের জন্য 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

এখন যেহেতু উপসেটগুলি সংজ্ঞায়িত করা হয়েছে, আমরা সা-লজিকের অনুরোধগুলিতে নিয়ম প্রয়োগ করতে ভার্চুয়াল সার্ভিসকে এগিয়ে যেতে এবং কনফিগার করতে পারি যাতে তারা:

একটি উপসেটে রুট করা হয়েছে৷ v1,
একটি উপসেটে মিরর করা হয়েছে v2.

নিম্নলিখিত ঘোষণাপত্র আপনাকে আপনার পরিকল্পনাগুলি অর্জন করতে দেয় (sa-লজিক-উপসেট-শ্যাডোয়িং-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

আসুন Grafana এর ফলাফলগুলি দেখি, যেখানে আপনি দেখতে পাবেন যে বাগ সহ সংস্করণ (buggy).

সা-লজিক পরিষেবার বিভিন্ন সংস্করণের সফল প্রতিক্রিয়া

এখানে আমরা প্রথমে দেখেছি কীভাবে ভার্চুয়াল সার্ভিস আমাদের পরিষেবার দূতদের জন্য প্রয়োগ করা হয়: কখন sa-web-app একটি অনুরোধ করে sa-logic, এটি সাইডকার এনভয়-এর মাধ্যমে যায়, যা - ভার্চুয়াল সার্ভিসের মাধ্যমে - অনুরোধটিকে v1 সাবসেটে রুট করতে এবং অনুরোধটিকে পরিষেবার v2 উপসেটে মিরর করতে কনফিগার করা হয় sa-logic.

আমি জানি, আপনি ইতিমধ্যেই ভাবতে পারেন যে ভার্চুয়াল পরিষেবাগুলি সহজ। পরবর্তী বিভাগে, আমরা এটিকে প্রসারিত করব এই বলে যে তারা সত্যিই দুর্দান্ত।

ক্যানারি রোলআউটস

ক্যানারি ডিপ্লয়মেন্ট হল অল্প সংখ্যক ব্যবহারকারীর কাছে একটি অ্যাপ্লিকেশনের একটি নতুন সংস্করণ রোল আউট করার প্রক্রিয়া। এটি নিশ্চিত করতে ব্যবহৃত হয় যে রিলিজে কোনও সমস্যা নেই এবং শুধুমাত্র তার পরে, ইতিমধ্যেই এর (রিলিজের) গুণমানে আত্মবিশ্বাসী হয়ে এটি অন্যান্য ব্যবহারকারীদের কাছে বিতরণ করা হয়।оবৃহত্তর দর্শক।

ক্যানারি রোলআউটগুলি প্রদর্শন করতে, আমরা একটি উপসেট নিয়ে কাজ চালিয়ে যাব buggy у sa-logic.

আসুন তুচ্ছ কাজে সময় নষ্ট না করে অবিলম্বে 20% ব্যবহারকারীকে বাগ সহ সংস্করণে পাঠাই (এটি আমাদের ক্যানারি রোলআউটকে প্রতিনিধিত্ব করবে), এবং বাকি 80%কে স্বাভাবিক পরিষেবায় পাঠাই। এটি করার জন্য, নিম্নলিখিত ভার্চুয়াল সার্ভিস ব্যবহার করুন (sa-লজিক-উপসেট-ক্যানারি-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-যুক্তি-পুনরায়-সময় শেষ-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

এবং Grafana গ্রাফে পরীক্ষা করে দেখুন যে উপরে সফল প্রতিক্রিয়ার সংখ্যা বেড়েছে:

টাইমআউট এবং পুনরায় চেষ্টা যোগ করার পরে সফল প্রতিক্রিয়া পরিসংখ্যানে উন্নতি

পরবর্তী বিভাগে যাওয়ার আগে (অথবা বরং, নিবন্ধের পরবর্তী অংশে, কারণ এতে আর কোন ব্যবহারিক পরীক্ষা-নিরীক্ষা হবে না - প্রায় অনুবাদ।), মুছে ফেলা 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 থেকে না হয়)। (দ্রষ্টব্য: প্যাটার্নের আরও বিশদ বিবরণ পাওয়া যাবে, উদাহরণস্বরূপ, এখানে.)

আমি এই নিদর্শনগুলির বাস্তবায়নের বিবরণ বাদ দেব কারণ সেগুলি খুঁজে পাওয়া সহজ৷ অফিসিয়াল ডকুমেন্টেশন, এবং আমি সত্যই প্রমাণীকরণ এবং অনুমোদন দেখাতে চাই, যা নিবন্ধের পরবর্তী অংশে আলোচনা করা হবে।

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

"ইসটিও সহ মাইক্রোসার্ভিসে ফিরে যান": অংশ 1 (প্রধান বৈশিষ্ট্যের ভূমিকা), পার্ট 3 (প্রমাণিকরণ এবং অনুমোদন);
«নালী - Kubernetes জন্য হালকা পরিষেবা জাল";
«একটি পরিষেবা জাল কি এবং কেন আমার এটি প্রয়োজন [মাইক্রোসার্ভিস সহ একটি ক্লাউড অ্যাপ্লিকেশনের জন্য]?».

উত্স: www.habr.com

Istio এর সাথে মাইক্রোসার্ভিসে ফিরে যান। অংশ 2