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

(এবং এই নিবন্ধের শেষে, আমি মাইক্রোসার্ভিস আর্কিটেকচার বিশেষজ্ঞ ক্রিস রিচার্ডসনের তিন দিনের সেমিনারে অংশ নেওয়ার সুযোগ সম্পর্কে কথা বলব)।

আমরা কিভাবে মাইক্রোসার্ভিসে এসেছি

Avito হল বিশ্বের বৃহত্তম শ্রেণীবদ্ধ সাইটগুলির মধ্যে একটি; প্রতিদিন 15 মিলিয়নেরও বেশি নতুন বিজ্ঞাপন প্রকাশিত হয়। আমাদের ব্যাকএন্ড প্রতি সেকেন্ডে 20 হাজারের বেশি অনুরোধ গ্রহণ করে। আমাদের বর্তমানে কয়েকশ মাইক্রো সার্ভিস রয়েছে।

আমরা এখন বেশ কয়েক বছর ধরে একটি মাইক্রোসার্ভিস আর্কিটেকচার তৈরি করছি। ঠিক কিভাবে- বিস্তারিত আমাদের সহকর্মীরা বলেছে RIT++ 2017-এ আমাদের বিভাগে। CodeFest 2017-এ (দেখুন। видео), সের্গেই অরলভ এবং মিখাইল প্রোকোপচুক বিশদভাবে ব্যাখ্যা করেছেন কেন আমাদের মাইক্রোসার্ভিসে রূপান্তরের প্রয়োজন এবং এখানে কুবারনেটস কী ভূমিকা পালন করেছিলেন। ঠিক আছে, এখন আমরা এই ধরনের স্থাপত্যের অন্তর্নিহিত স্কেলিং খরচ কমানোর জন্য সবকিছু করছি।

প্রাথমিকভাবে, আমরা এমন একটি ইকোসিস্টেম তৈরি করিনি যা আমাদের মাইক্রোসার্ভিস বিকাশ এবং চালু করতে ব্যাপকভাবে সাহায্য করবে। তারা সহজভাবে বুদ্ধিমান ওপেন সোর্স সমাধান সংগ্রহ করেছে, সেগুলিকে বাড়িতে চালু করেছে এবং ডেভেলপারকে সেগুলি মোকাবেলা করার জন্য আমন্ত্রণ জানিয়েছে৷ ফলস্বরূপ, তিনি এক ডজন জায়গায় (ড্যাশবোর্ড, অভ্যন্তরীণ পরিষেবা) গিয়েছিলেন, তারপরে তিনি একটি মনোলিথে পুরানো উপায়ে কোড কাটার ইচ্ছায় আরও শক্তিশালী হয়ে ওঠেন। নীচের চিত্রের সবুজ রঙটি নির্দেশ করে যে বিকাশকারী তার নিজের হাতে এক বা অন্যভাবে কী করেন এবং হলুদ রঙটি অটোমেশন নির্দেশ করে।

এখন PaaS CLI ইউটিলিটিতে, একটি কমান্ড দিয়ে একটি নতুন পরিষেবা তৈরি করা হয়েছে, এবং আরও দুটির সাথে একটি নতুন ডাটাবেস যোগ করা হয়েছে এবং স্টেজে স্থাপন করা হয়েছে।

কীভাবে "মাইক্রোসার্ভিস ফ্র্যাগমেন্টেশন" এর যুগ কাটিয়ে উঠবেন

একটি মনোলিথিক আর্কিটেকচারের সাথে, পণ্যের পরিবর্তনের সামঞ্জস্যের জন্য, বিকাশকারীরা তাদের প্রতিবেশীদের সাথে কী ঘটছে তা নির্ধারণ করতে বাধ্য হয়েছিল। নতুন আর্কিটেকচারে কাজ করার সময়, পরিষেবা প্রসঙ্গে আর একে অপরের উপর নির্ভর করে না।

উপরন্তু, একটি মাইক্রোসার্ভিস আর্কিটেকচার কার্যকর হওয়ার জন্য, অনেকগুলি প্রক্রিয়া স্থাপন করতে হবে, যথা:

• লগিং;
• অনুরোধ ট্রেসিং (জেগার);
• ত্রুটি একত্রীকরণ (সেন্ট্রি);
• অবস্থা, বার্তা, কুবারনেটস থেকে ইভেন্ট (ইভেন্ট স্ট্রিম প্রসেসিং);
• রেস লিমিট / সার্কিট ব্রেকার (আপনি Hystrix ব্যবহার করতে পারেন);
• পরিষেবা সংযোগ নিয়ন্ত্রণ (আমরা নেট্রামেশ ব্যবহার করি);
• পর্যবেক্ষণ (Grafana);
• সমাবেশ (টিমসিটি);
• যোগাযোগ এবং বিজ্ঞপ্তি (স্ল্যাক, ইমেল);
টাস্ক ট্র্যাকিং; (জিরা)
• ডকুমেন্টেশন প্রস্তুতি.

সিস্টেমটি যাতে তার অখণ্ডতা হারায় না এবং এটি স্কেল করার সাথে সাথে কার্যকর থাকে তা নিশ্চিত করার জন্য, আমরা অ্যাভিটোতে মাইক্রোসার্ভিসের সংস্থার পুনর্বিবেচনা করেছি।

আমরা কিভাবে মাইক্রোসার্ভিস পরিচালনা করি

অনেকগুলি অ্যাভিটো মাইক্রোসার্ভিসের মধ্যে একটি ঐক্যবদ্ধ "পার্টি নীতি" বাস্তবায়নে নিম্নলিখিত সহায়তা:

• অবকাঠামোকে স্তরে ভাগ করা;
• একটি পরিষেবা (PaaS) ধারণা হিসাবে প্ল্যাটফর্ম;
• মাইক্রোসার্ভিসের সাথে যা ঘটছে তা পর্যবেক্ষণ করা।

অবকাঠামো বিমূর্তকরণ স্তর তিনটি স্তর অন্তর্ভুক্ত. এর উপর থেকে নীচে যান.

উ: শীর্ষ - পরিষেবা জাল। প্রথমে আমরা ইস্টিও চেষ্টা করেছি, কিন্তু দেখা গেল যে এটি অনেকগুলি সংস্থান ব্যবহার করে, যা আমাদের ভলিউমের জন্য খুব ব্যয়বহুল। অতএব, আর্কিটেকচার টিমের সিনিয়র প্রকৌশলী আলেকজান্ডার লুকিয়ানচেনকো তার নিজস্ব সমাধান তৈরি করেছেন - নেত্রমেশ (ওপেন সোর্সে উপলব্ধ), যা আমরা বর্তমানে উৎপাদনে ব্যবহার করি এবং যা ইস্টিওর তুলনায় কয়েকগুণ কম সম্পদ ব্যবহার করে (কিন্তু ইস্টিও গর্ব করতে পারে এমন সবকিছু করে না)।
B. মাধ্যম - কুবারনেটস। আমরা এটিতে মাইক্রোসার্ভিস স্থাপন ও পরিচালনা করি।
C. নীচে - খালি ধাতু। আমরা ক্লাউড বা ওপেনস্ট্যাকের মতো জিনিস ব্যবহার করি না, তবে সম্পূর্ণরূপে বেয়ার মেটালের উপর নির্ভর করি।

সমস্ত স্তর PaaS দ্বারা একত্রিত হয়। এবং এই প্ল্যাটফর্ম, ঘুরে, তিনটি অংশ গঠিত.

I. জেনারেটর, একটি CLI ইউটিলিটির মাধ্যমে নিয়ন্ত্রিত। তিনিই বিকাশকারীকে সঠিক উপায়ে এবং ন্যূনতম প্রচেষ্টার সাথে একটি মাইক্রোসার্ভিস তৈরি করতে সহায়তা করেন৷

২. একত্রিত সংগ্রাহক একটি সাধারণ ড্যাশবোর্ডের মাধ্যমে সমস্ত সরঞ্জামের নিয়ন্ত্রণ সহ।

III. স্টোরেজ. শিডিউলারের সাথে সংযোগ করে যা স্বয়ংক্রিয়ভাবে উল্লেখযোগ্য কর্মের জন্য ট্রিগার সেট করে। এই ধরনের সিস্টেমের জন্য ধন্যবাদ, জিরাতে কেউ একটি টাস্ক সেট আপ করতে ভুলে যাওয়ার কারণে একটিও কাজ মিস হয় না। আমরা এর জন্য Atlas নামক একটি অভ্যন্তরীণ টুল ব্যবহার করি।

অ্যাভিটোতে মাইক্রোসার্ভিসের বাস্তবায়নও একটি একক স্কিম অনুসারে পরিচালিত হয়, যা বিকাশ এবং প্রকাশের প্রতিটি পর্যায়ে তাদের উপর নিয়ন্ত্রণ সহজ করে।

একটি আদর্শ মাইক্রোসার্ভিস ডেভেলপমেন্ট পাইপলাইন কিভাবে কাজ করে?

সাধারণভাবে, মাইক্রোসার্ভিস তৈরির চেইনটি এইরকম দেখায়:

CLI-পুশ → কন্টিনিউয়াস ইন্টিগ্রেশন → বেক → ডিপ্লয় → কৃত্রিম পরীক্ষা → ক্যানারি পরীক্ষা → স্কুইজ টেস্টিং → উত্পাদন → রক্ষণাবেক্ষণ।

এর ঠিক এই ক্রমে এটি মাধ্যমে যান.

CLI-ধাক্কা

• একটি মাইক্রোসার্ভিস তৈরি করা.
প্রতিটি বিকাশকারীকে কীভাবে মাইক্রোসার্ভিস করতে হয় তা শেখানোর জন্য আমরা দীর্ঘ সময় ধরে সংগ্রাম করেছি। এর মধ্যে সঙ্গমে বিস্তারিত নির্দেশনা লেখা ছিল। কিন্তু স্কিম পরিবর্তিত হয়েছে এবং পরিপূরক ছিল। ফলাফল হল যে যাত্রার শুরুতে একটি বাধা দেখা দিয়েছে: মাইক্রোসার্ভিস চালু করতে অনেক বেশি সময় লেগেছে এবং এখনও তাদের তৈরির সময় প্রায়ই সমস্যা দেখা দেয়।

শেষ পর্যন্ত, আমরা একটি সাধারণ CLI ইউটিলিটি তৈরি করেছি যা একটি মাইক্রোসার্ভিস তৈরি করার সময় প্রাথমিক ধাপগুলিকে স্বয়ংক্রিয় করে। আসলে, এটি প্রথম গিট পুশ প্রতিস্থাপন করে। এখানে সে ঠিক কি করে।

— একটি টেমপ্লেট অনুযায়ী একটি পরিষেবা তৈরি করে — ধাপে ধাপে, "উইজার্ড" মোডে। আমাদের কাছে অ্যাভিটো ব্যাকএন্ডে প্রধান প্রোগ্রামিং ভাষার জন্য টেমপ্লেট রয়েছে: পিএইচপি, গোলং এবং পাইথন।

- এক সময়ে একটি কমান্ড একটি নির্দিষ্ট মেশিনে স্থানীয় উন্নয়নের জন্য একটি পরিবেশ স্থাপন করে - মিনিকুব চালু হয়, হেলম চার্টগুলি স্বয়ংক্রিয়ভাবে তৈরি হয় এবং স্থানীয় কুবারনেটে চালু হয়।

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

— এটা লাইভ সমাবেশ নিজেই সঞ্চালিত. ধরা যাক একজন ডেভেলপার তার IDE এর মাধ্যমে একটি মাইক্রোসার্ভিসে কিছু সংশোধন করেছেন। ইউটিলিটি ফাইল সিস্টেমের পরিবর্তনগুলি দেখে এবং তাদের উপর ভিত্তি করে, অ্যাপ্লিকেশনটি পুনর্নির্মাণ করে (গোলাংয়ের জন্য) এবং পুনরায় চালু করে। PHP-এর জন্য, আমরা কেবল কিউবের ভিতরে ডিরেক্টরিটি ফরোয়ার্ড করি এবং সেখানে লাইভ-রিলোড "স্বয়ংক্রিয়ভাবে" প্রাপ্ত হয়।

- অটোটেস্ট তৈরি করে। ফাঁকা আকারে, কিন্তু ব্যবহারের জন্য বেশ উপযুক্ত।

• মাইক্রোসার্ভিস স্থাপনা.

একটি মাইক্রোসার্ভিস স্থাপন করা আমাদের জন্য একটি বিট কাজ ছিল. নিম্নলিখিত প্রয়োজন ছিল:

I. ডকারফাইল।

২. কনফিগার
III. হেলম চার্ট, যা নিজেই কষ্টকর এবং এতে রয়েছে:

— চার্ট নিজেই;
— টেমপ্লেট;
- বিভিন্ন পরিবেশ বিবেচনা করে নির্দিষ্ট মান।

আমরা কুবারনেটস ম্যানিফেস্টের পুনরায় কাজ করার ব্যথাকে সরিয়ে নিয়েছি যাতে সেগুলি এখন স্বয়ংক্রিয়ভাবে তৈরি হয়। কিন্তু সবচেয়ে গুরুত্বপূর্ণ, তারা সীমাতে স্থাপনার সরলীকৃত করেছে। এখন থেকে আমাদের একটি Dockerfile আছে, এবং ডেভেলপার সম্পূর্ণ কনফিগারেশনটি একটি ছোট app.toml ফাইলে লেখেন।

হ্যাঁ, এবং app.toml-এ এক মিনিটের জন্য কিছুই করার নেই। পরিষেবার কোথায় এবং কতগুলি অনুলিপি (ডেভ সার্ভারে, স্টেজিং, উৎপাদনে) বাড়ানো হবে তা আমরা নির্দিষ্ট করি এবং এর নির্ভরতা নির্দেশ করি। [ইঞ্জিন] ব্লকে লাইনের আকার = "ছোট" লক্ষ্য করুন। Kubernetes-এর মাধ্যমে পরিষেবার জন্য এই সীমাটি বরাদ্দ করা হবে।

তারপর, কনফিগারেশনের উপর ভিত্তি করে, সমস্ত প্রয়োজনীয় হেলম চার্ট স্বয়ংক্রিয়ভাবে তৈরি হয় এবং ডেটাবেসের সাথে সংযোগ তৈরি করা হয়।

• মৌলিক বৈধতা। এই ধরনের চেকগুলিও স্বয়ংক্রিয়।
ট্র্যাক করতে হবে:
- একটি ডকারফাইল আছে;
— সেখানে কি app.toml;
- সেখানে কি ডকুমেন্টেশন পাওয়া যায়?
- নির্ভরতা কি ক্রমানুসারে?
— সতর্কতার নিয়ম সেট করা হয়েছে কিনা।
শেষ বিন্দুতে: পরিষেবার মালিক নিজেই নির্ধারণ করেন কোন পণ্যের মেট্রিকগুলি নিরীক্ষণ করতে হবে।

• ডকুমেন্টেশন প্রস্তুতি.
এখনও একটি সমস্যা এলাকা. এটি সবচেয়ে সুস্পষ্ট বলে মনে হচ্ছে, তবে একই সাথে এটি একটি রেকর্ড "প্রায়শই ভুলে যাওয়া" এবং সেইজন্য চেইনের একটি দুর্বল লিঙ্ক।
প্রতিটি মাইক্রোসার্ভিসের জন্য ডকুমেন্টেশন থাকা আবশ্যক। এটি নিম্নলিখিত ব্লক অন্তর্ভুক্ত.

I. পরিষেবার সংক্ষিপ্ত বিবরণ. এটি কী করে এবং কেন এটি প্রয়োজন সে সম্পর্কে আক্ষরিকভাবে কয়েকটি বাক্য।

২. আর্কিটেকচার ডায়াগ্রাম লিঙ্ক. এটি গুরুত্বপূর্ণ যে এটির দিকে দ্রুত নজর দিলে এটি বোঝা সহজ, উদাহরণস্বরূপ, আপনি ক্যাশিংয়ের জন্য রেডিস ব্যবহার করছেন নাকি স্থায়ী মোডে প্রধান ডেটা স্টোর হিসাবে ব্যবহার করছেন। আভিটোতে আপাতত এটি সঙ্গমের একটি লিঙ্ক।

III. রানবুক. পরিষেবা শুরু করার জন্য একটি সংক্ষিপ্ত নির্দেশিকা এবং এটি পরিচালনার জটিলতা।

IV FAQ, যেখানে পরিষেবাটির সাথে কাজ করার সময় আপনার সহকর্মীরা যে সমস্যার সম্মুখীন হতে পারে তা অনুমান করা ভাল।

V. API-এর জন্য শেষ পয়েন্টের বিবরণ. যদি হঠাৎ করে আপনি গন্তব্যগুলি নির্দিষ্ট না করেন তবে সহকর্মীরা যাদের মাইক্রোসার্ভিসগুলি আপনার সাথে সম্পর্কিত তারা প্রায় অবশ্যই এটির জন্য অর্থ প্রদান করবে৷ এখন আমরা Swagger ব্যবহার করি এবং আমাদের সমাধানকে এর জন্য সংক্ষিপ্ত বলা হয়।

VI. লেবেল. অথবা মার্কার যা দেখায় যে পরিষেবাটি কোন পণ্য, কার্যকারিতা বা কোম্পানির কাঠামোগত বিভাগ এর অন্তর্গত। তারা আপনাকে দ্রুত বুঝতে সাহায্য করে, উদাহরণস্বরূপ, আপনি কার্যকারিতা কাটাচ্ছেন কিনা যা আপনার সহকর্মীরা এক সপ্তাহ আগে একই ব্যবসায়িক ইউনিটের জন্য চালু করেছিলেন।

VII. সেবার মালিক বা মালিকরা. বেশিরভাগ ক্ষেত্রে, এটি — বা সেগুলি — PaaS ব্যবহার করে স্বয়ংক্রিয়ভাবে নির্ধারণ করা যেতে পারে, কিন্তু নিরাপদে থাকার জন্য, আমাদের বিকাশকারীকে সেগুলি ম্যানুয়ালি নির্দিষ্ট করতে হবে।

অবশেষে, কোড পর্যালোচনার মতো ডকুমেন্টেশন পর্যালোচনা করা একটি ভাল অভ্যাস।

ক্রমাগত ইন্টিগ্রেশন

• সংগ্রহস্থল প্রস্তুত করা হচ্ছে।
• টিমসিটিতে একটি পাইপলাইন তৈরি করা হচ্ছে।
• অধিকার নির্ধারণ.
• পরিষেবা মালিকদের জন্য অনুসন্ধান করুন. এখানে একটি হাইব্রিড স্কিম রয়েছে - ম্যানুয়াল মার্কিং এবং PaaS থেকে ন্যূনতম অটোমেশন। একটি সম্পূর্ণ স্বয়ংক্রিয় স্কিম ব্যর্থ হয় যখন পরিষেবাগুলি অন্য ডেভেলপমেন্ট টিমের সমর্থনের জন্য স্থানান্তর করা হয় বা, উদাহরণস্বরূপ, যদি পরিষেবা বিকাশকারী প্রস্থান করে।
• অ্যাটলাসে একটি পরিষেবা নিবন্ধন করা (উপরে দেখুন). এর সমস্ত মালিক এবং নির্ভরতা সহ।
• মাইগ্রেশন চেক করা হচ্ছে। আমরা তাদের মধ্যে কোন সম্ভাব্য বিপজ্জনক কিনা পরীক্ষা. উদাহরণস্বরূপ, তাদের মধ্যে একটিতে একটি পরিবর্তন টেবিল বা অন্য কিছু পপ আপ হয় যা পরিষেবার বিভিন্ন সংস্করণের মধ্যে ডেটা স্কিমার সামঞ্জস্যকে ভেঙে দিতে পারে। তারপরে মাইগ্রেশন করা হয় না, তবে একটি সাবস্ক্রিপশনে রাখা হয় - PaaS অবশ্যই পরিষেবার মালিককে সংকেত দিতে হবে যখন এটি ব্যবহার করা নিরাপদ।

সেকা

পরবর্তী পর্যায়ে স্থাপনার আগে প্যাকেজিং পরিষেবা।

• আবেদন বিল্ডিং. ক্লাসিক অনুসারে - একটি ডকার ইমেজে।
• পরিষেবার জন্য এবং সংশ্লিষ্ট সংস্থানগুলির জন্য হেলম চার্ট তৈরি করা। ডাটাবেস এবং ক্যাশে সহ। এগুলি অ্যাপ.toml কনফিগারেশন অনুসারে স্বয়ংক্রিয়ভাবে তৈরি হয় যা CLI-পুশ পর্যায়ে তৈরি হয়েছিল।
• পোর্ট খোলার জন্য অ্যাডমিনদের জন্য টিকিট তৈরি করা (যখন দরকার).
• ইউনিট পরীক্ষা চালানো এবং কোড কভারেজ গণনা করা. যদি কোড কভারেজ নির্দিষ্ট থ্রেশহোল্ডের নীচে থাকে, তাহলে সম্ভবত পরিষেবাটি আরও বেশি যাবে না - স্থাপনার জন্য। যদি এটি গ্রহণযোগ্য হওয়ার দ্বারপ্রান্তে থাকে, তবে পরিষেবাটিকে একটি "হতাশাজনক" গুণাঙ্ক বরাদ্দ করা হবে: তারপরে, সময়ের সাথে সাথে সূচকে কোন উন্নতি না হলে, বিকাশকারী একটি বিজ্ঞপ্তি পাবেন যে পরীক্ষার ক্ষেত্রে কোন অগ্রগতি নেই ( এবং এটি সম্পর্কে কিছু করা দরকার)।
• মেমরি এবং CPU সীমাবদ্ধতার জন্য অ্যাকাউন্টিং. আমরা মূলত গোলং-এ মাইক্রোসার্ভিস লিখি এবং কুবারনেটসে চালাই। তাই গোলং ভাষার অদ্ভুততার সাথে একটি সূক্ষ্মতা যুক্ত: ডিফল্টরূপে, শুরু করার সময়, মেশিনের সমস্ত কোর ব্যবহার করা হয়, যদি আপনি স্পষ্টভাবে GOMAXPROCS ভেরিয়েবল সেট না করেন, এবং যখন একই মেশিনে এই জাতীয় একাধিক পরিষেবা চালু করা হয়, তখন সেগুলি শুরু হয় সম্পদের জন্য প্রতিযোগিতা করা, একে অপরের সাথে হস্তক্ষেপ করা। নীচের গ্রাফগুলি দেখায় যে আপনি যদি বিবাদ ছাড়াই অ্যাপ্লিকেশনটি চালান এবং সংস্থান মোডের জন্য দৌড়ে যান তাহলে কীভাবে সম্পাদনের সময় পরিবর্তিত হয়। (গ্রাফের উত্স হল এখানে).

এক্সিকিউশন সময়, কম ভাল. সর্বোচ্চ: 643ms, সর্বনিম্ন: 42ms। ছবিটি ক্লিকযোগ্য।

অস্ত্রোপচারের জন্য সময় কম, ভাল। সর্বাধিক: 14091 এনএস, সর্বনিম্ন: 151 এনএস। ছবিটি ক্লিকযোগ্য।

সমাবেশ প্রস্তুতি পর্যায়ে, আপনি এই পরিবর্তনশীলটি স্পষ্টভাবে সেট করতে পারেন বা আপনি লাইব্রেরি ব্যবহার করতে পারেন automaxprocs উবার থেকে ছেলেদের কাছ থেকে।

স্থাপন করুন

• কনভেনশন চেক করা। আপনি আপনার উদ্দিষ্ট পরিবেশে পরিষেবা সমাবেশগুলি সরবরাহ করা শুরু করার আগে, আপনাকে নিম্নলিখিতগুলি পরীক্ষা করতে হবে:
- API এন্ডপয়েন্ট।
— স্কিমার সাথে API এন্ডপয়েন্ট প্রতিক্রিয়াগুলির সম্মতি।
- লগ বিন্যাস।
— পরিষেবাতে অনুরোধের জন্য শিরোনাম সেট করা (এখন এটি নেট্রামেশ দ্বারা করা হয়)
— ইভেন্ট বাসে বার্তা পাঠানোর সময় মালিকের টোকেন সেট করা। বাস জুড়ে পরিষেবাগুলির সংযোগ ট্র্যাক করার জন্য এটি প্রয়োজন৷ আপনি বাসে উভয়ই ইমপোটেন্ট ডেটা পাঠাতে পারেন, যা পরিষেবাগুলির সংযোগ বাড়ায় না (যা ভাল), এবং ব্যবসার ডেটা যা পরিষেবাগুলির সংযোগকে শক্তিশালী করে (যা খুব খারাপ!)। এবং যখন এই কানেক্টিভিটি একটি সমস্যা হয়ে দাঁড়ায়, তখন বাসটি কে লেখে এবং পড়ে তা বোঝা পরিষেবাগুলিকে সঠিকভাবে আলাদা করতে সাহায্য করে৷

আভিটোতে এখনও খুব বেশি সম্মেলন নেই, তবে তাদের পুল প্রসারিত হচ্ছে। দলটি বুঝতে এবং বুঝতে পারে এমন ফর্মে এই জাতীয় চুক্তিগুলি যত বেশি পাওয়া যায়, মাইক্রোসার্ভিসের মধ্যে সামঞ্জস্য বজায় রাখা তত সহজ।

সিন্থেটিক পরীক্ষা

• ক্লোজড লুপ টেস্টিং। এর জন্য আমরা এখন ওপেন সোর্স ব্যবহার করছি Hoverfly.io. প্রথমত, এটি পরিষেবাতে প্রকৃত লোড রেকর্ড করে, তারপর - শুধুমাত্র একটি বন্ধ লুপে - এটি অনুকরণ করে।

• চাপ পরীক্ষা. আমরা সর্বোত্তম কর্মক্ষমতা সব সেবা আনার চেষ্টা. এবং প্রতিটি পরিষেবার সমস্ত সংস্করণ অবশ্যই লোড পরীক্ষার বিষয় হতে হবে - এইভাবে আমরা পরিষেবাটির বর্তমান কার্যকারিতা এবং একই পরিষেবার পূর্ববর্তী সংস্করণগুলির সাথে পার্থক্য বুঝতে পারি৷ যদি, একটি পরিষেবা আপডেটের পরে, এর কার্যকারিতা দেড় গুণ কমে যায়, এটি এর মালিকদের জন্য একটি স্পষ্ট সংকেত: আপনাকে কোডটি খনন করতে হবে এবং পরিস্থিতি সংশোধন করতে হবে।
আমরা সংগৃহীত ডেটা ব্যবহার করি, উদাহরণস্বরূপ, অটো স্কেলিং সঠিকভাবে বাস্তবায়ন করতে এবং শেষ পর্যন্ত, পরিষেবাটি কতটা মাপযোগ্য তা সাধারণত বুঝতে পারি।

লোড পরীক্ষার সময়, আমরা রিসোর্স খরচ সেট সীমা পূরণ করে কিনা তা পরীক্ষা করি। এবং আমরা প্রাথমিকভাবে চরম উপর ফোকাস.

ক) আমরা মোট লোড দেখি।
- খুব ছোট - লোড হঠাৎ কয়েকবার কমে গেলে সম্ভবত কিছু কাজ করে না।
- খুব বড় - অপ্টিমাইজেশন প্রয়োজন.

খ) আমরা RPS অনুযায়ী কাটঅফ দেখি।
এখানে আমরা বর্তমান সংস্করণ এবং পূর্ববর্তী সংস্করণ এবং মোট পরিমাণের মধ্যে পার্থক্য দেখি। উদাহরণস্বরূপ, যদি কোনও পরিষেবা 100 আরপিএস উত্পাদন করে, তবে এটি হয় খারাপভাবে লেখা হয়, বা এটি তার নির্দিষ্টতা, তবে যে কোনও ক্ষেত্রে, এটি পরিষেবাটিকে খুব ঘনিষ্ঠভাবে দেখার একটি কারণ।
যদি, বিপরীতে, অনেক বেশি RPS থাকে, তাহলে সম্ভবত কিছু ধরণের বাগ আছে এবং কিছু শেষ পয়েন্ট পেলোড চালানো বন্ধ করে দিয়েছে এবং অন্য কিছু সহজভাবে ট্রিগার হয়েছে return true;

ক্যানারি পরীক্ষা

আমরা সিন্থেটিক পরীক্ষায় উত্তীর্ণ হওয়ার পরে, আমরা অল্প সংখ্যক ব্যবহারকারীর উপর মাইক্রোসার্ভিস পরীক্ষা করি। আমরা যত্ন সহকারে শুরু করি, পরিষেবার উদ্দিষ্ট শ্রোতাদের একটি ক্ষুদ্র অংশ দিয়ে - 0,1%-এর কম৷ এই পর্যায়ে, এটি অত্যন্ত গুরুত্বপূর্ণ যে সঠিক প্রযুক্তিগত এবং পণ্যের মেট্রিকগুলি পর্যবেক্ষণে অন্তর্ভুক্ত করা হয়েছে যাতে তারা যত তাড়াতাড়ি সম্ভব পরিষেবাতে সমস্যাটি দেখায়। ক্যানারি পরীক্ষার জন্য সর্বনিম্ন সময় 5 মিনিট, প্রধানটি 2 ঘন্টা। জটিল পরিষেবাগুলির জন্য, আমরা ম্যানুয়ালি সময় সেট করি।
আমরা বিশ্লেষণ করি:
— ভাষা-নির্দিষ্ট মেট্রিক্স, বিশেষ করে, php-fpm কর্মীরা;
- সেন্ট্রিতে ত্রুটি;
- প্রতিক্রিয়া স্থিতি;
- প্রতিক্রিয়া সময়, সঠিক এবং গড়;
— বিলম্ব;
- ব্যতিক্রম, প্রক্রিয়াকৃত এবং আন-হ্যান্ডেল করা;
- পণ্যের পরিমাপ।

স্কুইজ টেস্টিং

স্কুইজ টেস্টিংকে "স্কুইজিং" টেস্টিংও বলা হয়। টেকনিকের নাম Netflix এ চালু করা হয়েছিল। এর সারমর্ম হল যে প্রথমে আমরা ব্যর্থতার বিন্দুতে আসল ট্র্যাফিক দিয়ে একটি উদাহরণ পূরণ করি এবং এইভাবে এর সীমা সেট করি। তারপরে আমরা আরেকটি উদাহরণ যোগ করি এবং এই জোড়াটি লোড করি - আবার সর্বোচ্চ পর্যন্ত; আমরা তাদের সিলিং এবং ডেল্টা দেখতে পাই প্রথম "নিচু" দিয়ে। এবং তাই আমরা একটি সময়ে একটি দৃষ্টান্ত সংযুক্ত করি এবং পরিবর্তনের প্যাটার্ন গণনা করি।
"স্কুইজিং" এর মাধ্যমে পরীক্ষার ডেটাও একটি সাধারণ মেট্রিক্স ডাটাবেসে প্রবাহিত হয়, যেখানে আমরা হয় সেগুলির সাথে কৃত্রিম লোডের ফলাফলগুলিকে সমৃদ্ধ করি বা এমনকি "সিনথেটিকস" এর সাথে প্রতিস্থাপন করি।

উৎপাদন

• স্কেলিং। যখন আমরা একটি পরিষেবা উৎপাদনের জন্য রোল আউট করি, তখন আমরা নিরীক্ষণ করি যে এটি কীভাবে স্কেল করে। আমাদের অভিজ্ঞতায়, শুধুমাত্র CPU সূচকগুলি পর্যবেক্ষণ করা অকার্যকর। RPS বেঞ্চমার্কিং এর বিশুদ্ধ আকারে অটো স্কেলিং কাজ করে, কিন্তু শুধুমাত্র কিছু নির্দিষ্ট পরিষেবার জন্য, যেমন অনলাইন স্ট্রিমিং। তাই আমরা অ্যাপ্লিকেশন-নির্দিষ্ট পণ্য মেট্রিক্স প্রথম তাকান.

ফলস্বরূপ, স্কেলিং করার সময় আমরা বিশ্লেষণ করি:
- CPU এবং RAM সূচক,
- সারিতে থাকা অনুরোধের সংখ্যা,
- প্রতিক্রিয়া সময়,
— সংগৃহীত ঐতিহাসিক তথ্যের উপর ভিত্তি করে পূর্বাভাস।

একটি পরিষেবা স্কেল করার সময়, এটির নির্ভরতা নিরীক্ষণ করাও গুরুত্বপূর্ণ যাতে আমরা চেইনের প্রথম পরিষেবাটি স্কেল না করি এবং এটি যেগুলি অ্যাক্সেস করে সেগুলি লোডের অধীনে ব্যর্থ হয়। পরিষেবাগুলির সম্পূর্ণ পুলের জন্য একটি গ্রহণযোগ্য লোড স্থাপন করতে, আমরা "নিকটতম" নির্ভরশীল পরিষেবার ঐতিহাসিক ডেটা দেখি (সিপিইউ এবং RAM সূচকগুলির সংমিশ্রণের উপর ভিত্তি করে, অ্যাপ-নির্দিষ্ট মেট্রিক্সের সাথে মিলিত) এবং ঐতিহাসিক ডেটার সাথে তাদের তুলনা করি। প্রারম্ভিক পরিষেবার, এবং তাই "নির্ভরতা শৃঙ্খল" জুড়ে, উপরে থেকে নীচে।

সেবা

মাইক্রোসার্ভিস চালু হওয়ার পর, আমরা এতে ট্রিগার সংযুক্ত করতে পারি।

এখানে সাধারণ পরিস্থিতি রয়েছে যেখানে ট্রিগারগুলি ঘটে।
- সম্ভাব্য বিপজ্জনক স্থানান্তর সনাক্ত করা হয়েছে।
— নিরাপত্তা আপডেট প্রকাশিত হয়েছে।
- পরিষেবাটি নিজেই দীর্ঘদিন ধরে আপডেট করা হয়নি।
— পরিষেবার লোড লক্ষণীয়ভাবে হ্রাস পেয়েছে বা এর কিছু পণ্যের মেট্রিক্স স্বাভাবিক সীমার বাইরে।
— পরিষেবাটি আর নতুন প্ল্যাটফর্মের প্রয়োজনীয়তা পূরণ করে না।

কিছু ট্রিগার অপারেশনের স্থিতিশীলতার জন্য দায়ী, কিছু - সিস্টেম রক্ষণাবেক্ষণের একটি ফাংশন হিসাবে - উদাহরণস্বরূপ, কিছু পরিষেবা দীর্ঘ সময়ের জন্য স্থাপন করা হয়নি এবং এর বেস ইমেজ নিরাপত্তা পরীক্ষা পাস করা বন্ধ করে দিয়েছে।

ড্যাশবোর্ড

সংক্ষেপে, ড্যাশবোর্ড হল আমাদের সম্পূর্ণ PaaS-এর কন্ট্রোল প্যানেল।

• পরিষেবা সম্পর্কে তথ্যের একক পয়েন্ট, এর পরীক্ষার কভারেজের ডেটা, এর চিত্রের সংখ্যা, উত্পাদন কপির সংখ্যা, সংস্করণ ইত্যাদি।
• পরিষেবা এবং লেবেল দ্বারা ডেটা ফিল্টার করার জন্য একটি টুল (ব্যবসায়িক ইউনিট, পণ্য কার্যকারিতা, ইত্যাদির অন্তর্গত চিহ্নিতকারী)
• ট্রেসিং, লগিং এবং পর্যবেক্ষণের জন্য অবকাঠামো সরঞ্জামগুলির সাথে একীকরণের জন্য একটি সরঞ্জাম।
• সেবা ডকুমেন্টেশন একটি একক পয়েন্ট.
• পরিষেবা জুড়ে সমস্ত ইভেন্টের একক দৃষ্টিকোণ।

মোটে

PaaS চালু করার আগে, একজন নতুন ডেভেলপার প্রোডাকশনে মাইক্রোসার্ভিস চালু করার জন্য প্রয়োজনীয় সমস্ত টুল বুঝতে কয়েক সপ্তাহ ব্যয় করতে পারে: Kubernetes, Helm, আমাদের অভ্যন্তরীণ TeamCity বৈশিষ্ট্য, ডাটাবেস এবং ক্যাশেগুলির সাথে একটি ত্রুটি-সহনশীল পদ্ধতিতে সংযোগ স্থাপন করা ইত্যাদি। কুইকস্টার্ট পড়তে এবং নিজেই পরিষেবা তৈরি করতে কয়েক ঘন্টা সময় লাগে।

আমি HighLoad++ 2018 এর জন্য এই বিষয়ে একটি প্রতিবেদন দিয়েছি, আপনি এটি দেখতে পারেন видео и উপস্থাপনা.

যারা শেষ পর্যন্ত পড়বেন তাদের জন্য বোনাস ট্র্যাক

আমরা Avito এ থেকে বিকাশকারীদের জন্য একটি অভ্যন্তরীণ তিন দিনের প্রশিক্ষণের আয়োজন করছি ক্রিস রিচার্ডসন, মাইক্রোসার্ভিস আর্কিটেকচারে বিশেষজ্ঞ। আমরা এই পোস্টের পাঠকদের একজনকে এতে অংশ নেওয়ার সুযোগ দিতে চাই। এটা হল প্রশিক্ষণ কর্মসূচী পোস্ট করা হয়েছে.

মস্কোতে ৫ থেকে ৭ আগস্ট এই প্রশিক্ষণ অনুষ্ঠিত হবে। এই কর্মদিবস যা সম্পূর্ণরূপে দখল করা হবে. দুপুরের খাবার এবং প্রশিক্ষণ আমাদের অফিসে হবে, এবং নির্বাচিত অংশগ্রহণকারী নিজেই ভ্রমণ এবং বাসস্থানের জন্য অর্থ প্রদান করবেন।

আপনি অংশগ্রহণের জন্য আবেদন করতে পারেন এই গুগল ফর্মে. আপনার কাছ থেকে - আপনাকে কেন প্রশিক্ষণে অংশগ্রহণ করতে হবে এই প্রশ্নের উত্তর এবং আপনার সাথে কীভাবে যোগাযোগ করবেন সে সম্পর্কে তথ্য। ইংরেজিতে উত্তর দিন, কারণ ক্রিস সেই অংশগ্রহণকারীকে বেছে নেবেন যিনি নিজে প্রশিক্ষণে যোগ দেবেন।
আমরা এই পোস্টের একটি আপডেটে এবং ডেভেলপারদের জন্য অ্যাভিটো সামাজিক নেটওয়ার্কগুলিতে প্রশিক্ষণ অংশগ্রহণকারীর নাম ঘোষণা করব (এভিটোটেক ইন ফেসবুক, Вконтакте, টুইটার) 19 জুলাইয়ের পরে নয়।

উত্স: www.habr.com