মাইক্রোসার্ভিস: আপনার কুবারনেটস থাকলেও আকার গুরুত্বপূর্ণ

19 সেপ্টেম্বর মস্কোতে স্থান দখল করেছে প্রথম থিম্যাটিক মিটিং HUG (Highload++ User Group), যা মাইক্রোসার্ভিসেসের জন্য নিবেদিত ছিল। একটি উপস্থাপনা ছিল "অপারেটিং মাইক্রোসার্ভিসেস: সাইজ ম্যাটারস, এমনকি যদি আপনার কাছে কুবারনেটস থাকে" যেখানে আমরা মাইক্রোসার্ভিস আর্কিটেকচারের সাথে অপারেটিং প্রকল্পগুলিতে ফ্লান্টের বিস্তৃত অভিজ্ঞতা শেয়ার করেছি। প্রথমত, এটি সমস্ত ডেভেলপারদের জন্য উপযোগী হবে যারা তাদের বর্তমান বা ভবিষ্যতের প্রকল্পে এই পদ্ধতিটি ব্যবহার করার কথা ভাবছেন।

পরিচয় করিয়ে দিচ্ছে প্রতিবেদনের ভিডিও (50 মিনিট, নিবন্ধের চেয়ে অনেক বেশি তথ্যপূর্ণ), পাশাপাশি পাঠ্য আকারে এটি থেকে মূল নির্যাস।

NB: এই পোস্টের শেষে ভিডিও এবং উপস্থাপনাও পাওয়া যাবে।

ভূমিকা

সাধারণত একটি ভাল গল্পের একটি শুরু, একটি মূল প্লট এবং একটি রেজোলিউশন থাকে। এই প্রতিবেদনটি একটি ভূমিকার মতো, এবং এটি একটি দুঃখজনক। এটাও মনে রাখা গুরুত্বপূর্ণ যে এটি মাইক্রোসার্ভিসেস সম্পর্কে বহিরাগতদের দৃষ্টিভঙ্গি প্রদান করে। অপারেটিং.

আমি এই গ্রাফ দিয়ে শুরু করব, যার লেখক (2015 সালে) আমি ওঠে মার্টিন ফাউলার:

এটি দেখায় কিভাবে, একটি একচেটিয়া প্রয়োগের ক্ষেত্রে যা একটি নির্দিষ্ট মূল্যে পৌঁছায়, উত্পাদনশীলতা হ্রাস পেতে শুরু করে। মাইক্রোসার্ভিসগুলি ভিন্ন যে তাদের সাথে প্রাথমিক উত্পাদনশীলতা কম, কিন্তু জটিলতা বৃদ্ধির সাথে সাথে দক্ষতার অবনতি তাদের জন্য তেমন লক্ষণীয় নয়।

Kubernetes ব্যবহার করার ক্ষেত্রে আমি এই গ্রাফে যোগ করব:

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

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

দরকারী এবং ক্ষতিকারক মাইক্রোসার্ভিস

এবং এখানে মূল ধারণা:

এটা কি সাধারণ মাইক্রোসার্ভিস আর্কিটেকচার? এটি আপনার কাজের দক্ষতা বাড়াতে, আপনাকে সত্যিকারের সুবিধা নিয়ে আসবে। যদি আমরা গ্রাফে ফিরে যাই, এটি এখানে:

আপনি যদি তাকে ডাকেন দরকারী, তারপর গ্রাফের অন্য পাশে থাকবে ক্ষতিকর মাইক্রোসার্ভিস (কাজে হস্তক্ষেপ):

"মূল ধারণা" এ ফিরে যাচ্ছি: আমার কি আমার অভিজ্ঞতাকে আদৌ বিশ্বাস করা উচিত? এই বছরের শুরু থেকেই আমি তাকিয়ে আছি 85টি প্রকল্প. তাদের সকলেই মাইক্রোসার্ভিস ছিল না (তাদের মধ্যে প্রায় এক তৃতীয়াংশ থেকে অর্ধেকের এমন একটি স্থাপত্য ছিল), তবে এটি এখনও একটি বড় সংখ্যা। আমরা (ফ্লান্ট কোম্পানি) আউটসোর্সার হিসেবে ছোট কোম্পানিতে (5 জন ডেভেলপার সহ) এবং বড় কোম্পানিতে (~500 ডেভেলপারদের সাথে) বিভিন্ন ধরনের অ্যাপ্লিকেশন ডেভেলপ করা দেখতে পারি। একটি অতিরিক্ত সুবিধা হল যে আমরা এই অ্যাপ্লিকেশনগুলিকে বছরের পর বছর ধরে লাইভ এবং বিকশিত দেখতে পাই।

মাইক্রো সার্ভিস কেন?

মাইক্রোসার্ভিসের সুবিধা নিয়ে প্রশ্ন আছে খুব নির্দিষ্ট উত্তর ইতিমধ্যে উল্লিখিত মার্টিন ফাউলার থেকে:

1. মডুলারিটির স্পষ্ট সীমানা;
2. স্বাধীন স্থাপনা;
3. প্রযুক্তি বেছে নেওয়ার স্বাধীনতা।

আমি সফ্টওয়্যার আর্কিটেক্ট এবং বিকাশকারীদের সাথে অনেক কথা বলেছি এবং জিজ্ঞাসা করেছি কেন তাদের মাইক্রোসার্ভিস দরকার। এবং আমি তাদের প্রত্যাশার তালিকা তৈরি করেছি। এখানে যা ঘটেছে:

যদি আমরা কিছু বিষয় "সংবেদনশীলতায়" বর্ণনা করি, তাহলে:

• মডিউলগুলির পরিষ্কার সীমানা: এখানে আমাদের একটি ভয়ানক মনোলিথ রয়েছে এবং এখন সবকিছু সুন্দরভাবে গিট রিপোজিটরিতে সাজানো হবে, যেখানে সবকিছু "তাকগুলিতে", উষ্ণ এবং নরম মিশ্রিত হয় না;
• স্থাপনার স্বাধীনতা: আমরা স্বাধীনভাবে পরিষেবাগুলি রোল আউট করতে সক্ষম হব যাতে উন্নয়ন দ্রুত হয় (সমান্তরালে নতুন বৈশিষ্ট্যগুলি প্রকাশ করুন);
• উন্নয়নের স্বাধীনতা: আমরা এই মাইক্রোসার্ভিসটি একটি দল/ডেভেলপারকে দিতে পারি এবং সেটি অন্যটিকে, ধন্যবাদ যার ফলে আমরা দ্রুত বিকাশ করতে পারি;
• боবৃহত্তর নির্ভরযোগ্যতা: যদি আংশিক অবক্ষয় ঘটে (20 টির মধ্যে একটি মাইক্রোসার্ভিস পড়ে), তবে শুধুমাত্র একটি বোতাম কাজ করা বন্ধ করবে এবং সামগ্রিকভাবে সিস্টেমটি কাজ করতে থাকবে।

সাধারণ (ক্ষতিকারক) মাইক্রোসার্ভিস আর্কিটেকচার

বাস্তবতা কেন আমরা আশা করি না তা ব্যাখ্যা করার জন্য, আমি উপস্থাপন করব সমষ্টিগত বিভিন্ন প্রকল্পের অভিজ্ঞতার ভিত্তিতে একটি মাইক্রোসার্ভিস আর্কিটেকচারের একটি চিত্র।

একটি উদাহরণ হবে একটি বিমূর্ত অনলাইন স্টোর যা Amazon বা অন্তত OZON এর সাথে প্রতিদ্বন্দ্বিতা করতে যাচ্ছে। এর মাইক্রোসার্ভিস আর্কিটেকচারটি এইরকম দেখাচ্ছে:

বিভিন্ন কারণে, এই মাইক্রোসার্ভিসগুলি বিভিন্ন প্ল্যাটফর্মে লেখা হয়:

যেহেতু প্রতিটি মাইক্রোসার্ভিসের স্বায়ত্তশাসন থাকতে হবে, তাদের অনেকের নিজস্ব ডাটাবেস এবং ক্যাশে প্রয়োজন। চূড়ান্ত স্থাপত্য নিম্নরূপ:

এর পরিণতি কি?

ফাউলারেরও এটা আছে একটি নিবন্ধ আছে — মাইক্রোসার্ভিস ব্যবহার করার জন্য "পেমেন্ট" সম্পর্কে:

এবং আমরা দেখব আমাদের প্রত্যাশা পূরণ হয়েছে কিনা।

মডিউলগুলির সীমানা পরিষ্কার করুন...

এখনো আমাদের আসলে কতগুলি মাইক্রোসার্ভিস ঠিক করতে হবে?পরিবর্তন রোল আউট? আমরা কি এমনকি একটি বিতরণ ট্রেসার ছাড়া সবকিছু কিভাবে কাজ করে তা বের করতে পারি (সর্বশেষে, মাইক্রোসার্ভিসের অর্ধেক দ্বারা কোন অনুরোধ প্রক্রিয়া করা হয়)?

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

স্থাপনার স্বাধীনতা...

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

প্রযুক্তি বেছে নেওয়ার স্বাধীনতা...

সে. শুধু মনে রাখবেন যে স্বাধীনতা প্রায়শই অনাচারের সাথে সীমাবদ্ধ থাকে। শুধুমাত্র তাদের সাথে "খেলতে" প্রযুক্তি বেছে না নেওয়া এখানে খুবই গুরুত্বপূর্ণ।

উন্নয়নের স্বাধীনতা...

কিভাবে সম্পূর্ণ অ্যাপ্লিকেশনের জন্য একটি পরীক্ষা লুপ তৈরি করবেন (অনেকগুলি উপাদান সহ)? কিন্তু আপনাকে এখনও এটি আপ টু ডেট রাখতে হবে। এই সব সত্য যে বাড়ে পরীক্ষার সার্কিটের প্রকৃত সংখ্যা, যা আমরা নীতিগতভাবে ধারণ করতে পারি, সর্বনিম্ন হতে সক্রিয় আউট.

এই সমস্ত স্থানীয়ভাবে স্থাপন করার বিষয়ে কীভাবে?... দেখা যাচ্ছে যে প্রায়শই বিকাশকারী তার কাজ স্বাধীনভাবে করেন, তবে "এলোমেলোভাবে", কারণ সার্কিটটি পরীক্ষার জন্য বিনামূল্যে না হওয়া পর্যন্ত তাকে অপেক্ষা করতে বাধ্য করা হয়।

আলাদা স্কেলিং...

হ্যাঁ, তবে এটি ব্যবহার করা DBMS এর ক্ষেত্রে সীমিত। প্রদত্ত আর্কিটেকচারের উদাহরণে, ক্যাসান্দ্রার সমস্যা হবে না, তবে MySQL এবং PostgreSQL হবে।

Боবৃহত্তর নির্ভরযোগ্যতা...

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

লোড পরিমাপযোগ্যতা...

এটা সত্যই খুব ভালো.

মাইক্রোসার্ভিসের "হালকা"...

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

এবং এখানে আমাদের প্রত্যাশা পূরণের ফলাফল:

কিন্তু এখানেই শেষ নয়!

কারণ:

• খুব সম্ভবত আমরা একটি বার্তা বাস প্রয়োজন হবে.
• কিভাবে সঠিক সময়ে একটি ধারাবাহিক ব্যাকআপ করা যায়? একমাত্র реальный বিকল্প এই জন্য ট্রাফিক বন্ধ করা হয়. কিন্তু উৎপাদনে এটা কিভাবে করবেন?
• আমরা যদি বেশ কয়েকটি অঞ্চলকে সমর্থন করার কথা বলি, তবে তাদের প্রতিটিতে স্থায়িত্ব সংগঠিত করা একটি অত্যন্ত শ্রম-নিবিড় কাজ।
• কেন্দ্রীভূত পরিবর্তন করার সমস্যা দেখা দেয়। উদাহরণস্বরূপ, যদি আমাদের পিএইচপি সংস্করণ আপডেট করার প্রয়োজন হয় তবে আমাদের প্রতিটি সংগ্রহস্থলে প্রতিশ্রুতিবদ্ধ হতে হবে (এবং সেগুলির কয়েক ডজন আছে)।
• কর্মক্ষম জটিলতা বৃদ্ধি, অফহ্যান্ড, সূচকীয়।

এই সব দিয়ে কি করবেন?

একটি মনোলিথিক অ্যাপ্লিকেশন দিয়ে শুরু করুন. ফাউলারের অভিজ্ঞতা সে বলে যে প্রায় সমস্ত সফল মাইক্রোসার্ভিস অ্যাপ্লিকেশনগুলি একটি মনোলিথ হিসাবে শুরু হয়েছিল যা খুব বড় হয়ে গিয়েছিল এবং তারপর ভেঙে গিয়েছিল। একই সময়ে, প্রথম থেকেই মাইক্রোসার্ভিস হিসাবে নির্মিত প্রায় সমস্ত সিস্টেমই শীঘ্র বা পরে গুরুতর সমস্যার সম্মুখীন হয়।

আরেকটি মূল্যবান চিন্তা হল যে একটি মাইক্রোসার্ভিস আর্কিটেকচার সহ একটি প্রকল্প সফল হওয়ার জন্য, আপনাকে অবশ্যই ভালভাবে জানতে হবে এবং বিষয় এলাকা, এবং কিভাবে microservices করা. এবং একটি বিষয় এলাকা শেখার সর্বোত্তম উপায় একটি মনোলিথ করা হয়.

কিন্তু আমরা যদি ইতিমধ্যে এই পরিস্থিতিতে পড়ে থাকি?

যেকোন সমস্যা সমাধানের প্রথম ধাপ হল এর সাথে একমত হওয়া এবং বোঝা যে এটি একটি সমস্যা, আমরা আর কষ্ট পেতে চাই না।

যদি, একটি অত্যধিক বৃদ্ধিপ্রাপ্ত মনোলিথের ক্ষেত্রে (যখন আমাদের এটির জন্য অতিরিক্ত সংস্থান কেনার সুযোগ ফুরিয়ে যায়), আমরা এটি কেটে ফেলি, তবে এই ক্ষেত্রে বিপরীত গল্পটি পরিণত হয়: যখন অত্যধিক মাইক্রোসার্ভিস আর সাহায্য করে না, তবে বাধা দেয় - অতিরিক্ত কেটে ফেলুন এবং বড় করুন!

উদাহরণস্বরূপ, উপরে আলোচনা করা যৌথ চিত্রের জন্য...

সবচেয়ে সন্দেহজনক মাইক্রোসার্ভিস থেকে মুক্তি পান:

ফ্রন্টএন্ড প্রজন্মের জন্য দায়ী সমস্ত মাইক্রোসার্ভিস একত্রিত করুন:

... একটি মাইক্রোসার্ভিসে, একটিতে লিখিত (আধুনিক এবং স্বাভাবিক, যেমন আপনি মনে করেন) ভাষা/ফ্রেমওয়ার্ক:

এটিতে একটি ORM (একটি DBMS) এবং প্রথমে কয়েকটি অ্যাপ্লিকেশন থাকবে:

... তবে সাধারণভাবে আপনি নিম্নলিখিত ফলাফল পেয়ে সেখানে আরও অনেক কিছু স্থানান্তর করতে পারেন:

তাছাড়া, Kubernetes-এ আমরা এই সবগুলিকে আলাদাভাবে চালাই, যার মানে হল যে আমরা এখনও লোড পরিমাপ করতে পারি এবং আলাদাভাবে স্কেল করতে পারি।

সংক্ষিপ্তসার

বড় ছবি তাকান. খুব প্রায়ই, মাইক্রোসার্ভিসের সাথে এই সমস্ত সমস্যাগুলি দেখা দেয় কারণ কেউ তাদের কাজটি নিয়েছে, কিন্তু "মাইক্রোসার্ভিসের সাথে খেলতে" চেয়েছিল।

"মাইক্রোসার্ভিসেস" শব্দে "মাইক্রো" অংশটি অপ্রয়োজনীয়।. তারা "মাইক্রো" শুধুমাত্র কারণ তারা একটি বিশাল মনোলিথ থেকে ছোট। তবে তাদের ছোট কিছু মনে করবেন না।

এবং একটি চূড়ান্ত চিন্তার জন্য, আসুন মূল চার্টে ফিরে আসি:

তাতে লেখা একটি নোট (উপরের ডানে) সত্য যে নিচে boils আপনার প্রকল্প তৈরি করে এমন দলের দক্ষতা সবসময় প্রাথমিক — তারা মাইক্রোসার্ভিস এবং একটি মনোলিথের মধ্যে আপনার পছন্দে একটি মূল ভূমিকা পালন করবে। যদি দলটির যথেষ্ট দক্ষতা না থাকে তবে এটি মাইক্রোসার্ভিস তৈরি করতে শুরু করে, গল্পটি অবশ্যই মারাত্মক হবে।

ভিডিও এবং স্লাইড

বক্তৃতা থেকে ভিডিও (~50 মিনিট; দুর্ভাগ্যবশত, এটি দর্শকদের অসংখ্য আবেগ প্রকাশ করে না, যা মূলত প্রতিবেদনের মেজাজ নির্ধারণ করে, তবে এটি এমনই হয়):

প্রতিবেদনের উপস্থাপনা:

দ্রষ্টব্য

আমাদের ব্লগে অন্যান্য প্রতিবেদন:

• «মনিটরিং এবং কুবারনেটস» (দিমিত্রি স্টোলিয়ারভ; রুটকনফে 28 মে, 2018);
• «কুবারনেটস এবং গিটল্যাবের সাথে সিআই/সিডি সেরা অনুশীলন» (দিমিত্রি স্টোলিয়ারভ; 7 নভেম্বর, 2017 হাইলোড++ এ);
• «ছোট প্রকল্পে Kubernetes সঙ্গে আমাদের অভিজ্ঞতা» (দিমিত্রি স্টোলিয়ারভ; জুন 6, 2017 রুটকনফে);
• «আমরা CI/CD-এর জন্য দ্রুত এবং সুবিধাজনকভাবে ড্যাপ দিয়ে ডকার ইমেজ তৈরি করি» (দিমিত্রি স্টোলিয়ারভ; 8 নভেম্বর, 2016 হাইলোড++ এ);
• «ডকারের সাথে ক্রমাগত ডেলিভারি অনুশীলন» (দিমিত্রি স্টোলিয়ারভ; রুটকনফে 31 মে, 2016).

আপনি নিম্নলিখিত প্রকাশনাগুলিতে আগ্রহী হতে পারেন:

• «2018 সালে মাইক্রোসার্ভিস উন্মাদনার মৃত্যু";
• «Google-এর 7টি কন্টেইনার সেরা অভ্যাস";
• «Kubernetes বাস্তবায়নের চ্যালেঞ্জগুলির উপর The New Stack থেকে পরিসংখ্যান».

উত্স: www.habr.com