পরিষেবা মেশ: প্রতিটি সফ্টওয়্যার প্রকৌশলীকে হটেস্ট প্রযুক্তি সম্পর্কে যা জানা দরকার

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

থেকে কমিক সেবাস্তিয়ান ক্যাসেরেস

ভূমিকা

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

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

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

আমি কি?

হাই সব! আমার নাম উইলিয়াম মরগান. আমি সৃষ্টিকর্তাদের একজন লিংকার্ড - একেবারে প্রথম পরিষেবা জাল প্রকল্প এবং শব্দের উপস্থিতির জন্য দায়ী করা প্রকল্প সেবা জাল যেমন (দুঃখিত বলছি!) (নোট অনুবাদ.: যাইহোক, 2,5 বছরেরও বেশি আগে এই শব্দটির আবির্ভাবের প্রথম দিকে, আমরা ইতিমধ্যে "" নামে একই লেখকের প্রাথমিক উপাদান অনুবাদ করেছি।একটি পরিষেবা জাল কি এবং কেন আমার এটি প্রয়োজন [মাইক্রোসার্ভিস সহ একটি ক্লাউড অ্যাপ্লিকেশনের জন্য]?"।) আমিও নেতৃত্ব দিই বুয়্যান্ট একটি স্টার্টআপ যা লিংকার্ড এবং এর মতো দুর্দান্ত পরিষেবা জাল তৈরি করে ডুব.

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

ঠিক আছে, এটা ট্রিট এগিয়ে যাওয়ার সময়.

একটি পরিষেবা জাল কি?

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

এই প্রক্সি কি? এটি "লেয়ার 7-সচেতন" বিভাগের একটি TCP প্রক্সি৷ (অর্থাৎ ওএসআই মডেলের 7 তম স্তরটিকে "বিবেচনায় নেওয়া") HAProxy এবং NGINX এর মত। আপনি আপনার পছন্দ অনুযায়ী একটি প্রক্সি চয়ন করতে পারেন; Linkerd একটি মরিচা প্রক্সি ব্যবহার করে, যার নাম জটিলভাবে linkerd-proxy. আমরা এটি বিশেষভাবে পরিষেবা জালের জন্য সংকলন করেছি। অন্যান্য মেশ অন্যান্য প্রক্সি পছন্দ করে (দূত একটি সাধারণ পছন্দ)। যাইহোক, একটি প্রক্সি নির্বাচন শুধুমাত্র বাস্তবায়নের বিষয়।

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

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

নীচে Linkerd-এ কন্ট্রোল প্লেন এবং ডেটা প্লেনের একটি ডায়াগ্রাম রয়েছে। আপনি দেখতে পাচ্ছেন, কন্ট্রোল প্লেনে বিভিন্ন উপাদান রয়েছে, যার মধ্যে রয়েছে একটি প্রমিথিউস উদাহরণ যা প্রক্সি সার্ভার থেকে মেট্রিক্স সংগ্রহ করে, সেইসাথে অন্যান্য উপাদান যেমন destination (পরিষেবা আবিষ্কার), identity (শংসাপত্র কর্তৃপক্ষ, CA) এবং public-api (ওয়েব এবং CLI এর জন্য শেষ পয়েন্ট)। বিপরীতে, ডেটা প্লেনটি অ্যাপ্লিকেশন উদাহরণের পাশে একটি সহজ লিঙ্কার্ড-প্রক্সি। এটি একটি লজিক ডায়াগ্রাম মাত্র; একটি বাস্তব বিশ্বের স্থাপনায়, আপনার কাছে প্রতিটি কন্ট্রোল প্লেন উপাদানের তিনটি প্রতিলিপি এবং ডেটা প্লেনে শত শত বা হাজার হাজার প্রক্সি থাকতে পারে।

(এই চিত্রের নীল বাক্সগুলি কুবারনেটস পডগুলির সীমানাগুলিকে উপস্থাপন করে৷ আপনি দেখতে পাচ্ছেন যে লিঙ্কারড-প্রক্সি সহ কন্টেইনারগুলি অ্যাপ্লিকেশন কন্টেইনারগুলির মতো একই পডে রয়েছে৷ এই স্কিমটি হিসাবে পরিচিত সাইডকার ধারক.)

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

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

1. ডেটা সমতলে প্রক্সি থাকা উচিত দ্রুত, কারণ প্রতিটি কলের জন্য প্রক্সিতে কয়েকটি কল রয়েছে: একটি ক্লায়েন্টের দিকে, একটি সার্ভারের দিকে।
2. এছাড়াও, প্রক্সি হতে হবে ছোট и লাইটওয়েট. প্রতিটি মেমরি এবং CPU সম্পদ ব্যবহার করবে, এবং এই খরচ অ্যাপ্লিকেশনের সাথে রৈখিকভাবে বৃদ্ধি পাবে।
3. প্রচুর সংখ্যক প্রক্সি স্থাপন এবং আপডেট করার জন্য আপনার একটি প্রক্রিয়ার প্রয়োজন হবে। এটি ম্যানুয়ালি করা একটি বিকল্প নয়।

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

এটা প্রশ্নের জন্য সময় "কেন?"

জন্য একটি পরিষেবা জাল কি?

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

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

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

উদাহরণস্বরূপ, Linkerd-এ (অধিকাংশ মেশের মতো) কার্যকারিতা প্রাথমিকভাবে HTTP/2 এবং gRPC* সহ HTTP কলগুলিতে ফোকাস করা হয়। কার্যকারিতা বেশ সমৃদ্ধ - এটি তিনটি শ্রেণীতে বিভক্ত করা যেতে পারে:

1. সম্পর্কিত বৈশিষ্ট্য নির্ভরযোগ্যতা. অনুরোধ, টাইমআউট, ক্যানারি অ্যাপ্রোচ (ট্রাফিক স্প্লিট/রিডাইরেক্ট) ইত্যাদি পুনঃচেষ্টা করুন।
2. সম্পর্কিত বৈশিষ্ট্য পর্যবেক্ষণ. প্রতিটি পরিষেবা বা পৃথক গন্তব্যের জন্য সাফল্যের হার, বিলম্ব এবং অনুরোধের পরিমাণের সমষ্টি; পরিষেবার টপোলজিকাল মানচিত্র তৈরি করা, ইত্যাদি
3. সম্পর্কিত বৈশিষ্ট্য সুরক্ষা. পারস্পরিক TLS, অ্যাক্সেস নিয়ন্ত্রণ, ইত্যাদি

* Linkerd এর দৃষ্টিকোণ থেকে, gRPC কার্যত HTTP/2 থেকে আলাদা নয়: এটি শুধু পেলোডে প্রোটোবাফ ব্যবহার করে। বিকাশকারীর দৃষ্টিকোণ থেকে, এই দুটি জিনিস অবশ্যই আলাদা।

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

প্রক্সিগুলি সংযোগ স্তরেও "কিছু করতে পারে"। উদাহরণস্বরূপ, Foo পাশের একটি লিঙ্কারড-প্রক্সি একটি TLS সংযোগ শুরু করতে পারে, এবং বারের পাশে একটি লিঙ্কারড-প্রক্সি এটিকে বন্ধ করতে পারে এবং উভয় পক্ষ একে অপরের TLS শংসাপত্র যাচাই করতে পারে*। এটি কেবল পরিষেবাগুলির মধ্যে এনক্রিপশনই নয়, পরিষেবাগুলি সনাক্ত করার একটি ক্রিপ্টোগ্রাফিকভাবে সুরক্ষিত উপায়ও প্রদান করে: Foo এবং বার "প্রমাণ" করতে পারে যে তারা যা বলে তারাই।

* "একজন বন্ধুর বন্ধু" মানে ক্লায়েন্টের শংসাপত্রও যাচাই করা হয়েছে (পারস্পরিক TLS)। "ক্লাসিক" TLS-এ, উদাহরণস্বরূপ, একটি ব্রাউজার এবং একটি সার্ভারের মধ্যে, শুধুমাত্র একটি দিকের (সার্ভার) শংসাপত্র সাধারণত যাচাই করা হয়।

সেগুলি অনুরোধ বা সংযোগ স্তরে কাজ করুক না কেন, এটি জোর দেওয়া গুরুত্বপূর্ণ যে সমস্ত পরিষেবা জাল বৈশিষ্ট্যগুলি কর্মক্ষম চরিত্র Linkerd পেলোডের শব্দার্থকে রূপান্তর করতে অক্ষম, যেমন একটি JSON ফ্র্যাগমেন্টে ক্ষেত্র যোগ করা বা একটি প্রোটোবাফে পরিবর্তন করা। আমরা এই গুরুত্বপূর্ণ বৈশিষ্ট্য সম্পর্কে পরে কথা বলব যখন আমরা ESB এবং মিডলওয়্যার সম্পর্কে কথা বলব।

এটি এমন বৈশিষ্ট্যগুলির সেট যা পরিষেবা জাল অফার করে। প্রশ্ন উঠেছে: কেন সরাসরি প্রয়োগে তাদের বাস্তবায়ন করা হচ্ছে না? এবং কেন সব এ একটি প্রক্সি সঙ্গে জগাখিচুড়ি?

কেন একটি পরিষেবা জাল একটি ভাল ধারণা

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

আসুন এই প্রস্তাব বিশ্লেষণ করা যাক.

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

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

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

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

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

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

পরিষেবা জাল কাকে সাহায্য করে?

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

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

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

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

প্ল্যাটফর্ম এবং পরিষেবাগুলির মালিকদের মধ্যে এই জাতীয় বিভাজনের সাংগঠনিক মূল্যকে অত্যধিক মূল্যায়ন করা যায় না। আমি মনে করি সে অবদান রাখে প্রধান সেবা জালের মান অবদান.

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

সংক্ষেপে, পরিষেবা জাল, বরং, একটি প্রযুক্তিগত সমাধান নয়, কিন্তু সামাজিক-প্রযুক্তিগত সমস্যা। (ধন্যবাদ সিন্ডি শ্রীধরন এই শব্দটি চালু করার জন্য।

সার্ভিস মেশ কি আমার সব সমস্যার সমাধান করবে?

হ্যাঁ. মানে, না!

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

পরিষেবা জাল দ্বারা দেওয়া এই এলাকায় বৈশিষ্ট্যগুলির একটি উপসেট সম্পর্কিত প্ল্যাটফর্ম বৈশিষ্ট্য. এর দ্বারা আমি ফাংশন বলতে চাচ্ছি:

1. ব্যবসায়িক যুক্তি থেকে স্বাধীন. যেভাবে ফু এবং বারের মধ্যে কল হিস্টোগ্রামগুলি তৈরি করা হয় তা সম্পূর্ণরূপে স্বাধীন কিনা কেন Foo বার কল.
2. সঠিকভাবে বাস্তবায়ন করা কঠিন. Linkerd-এ, পুনঃপ্রচারগুলিকে সমস্ত ধরণের অভিনব জিনিস যেমন পুনঃপ্রচার বাজেটের সাথে প্যারামিটারাইজ করা হয়। (বাজেট পুনরায় চেষ্টা করুন), যেহেতু এই জাতীয় জিনিসগুলি বাস্তবায়নের জন্য একটি সরল-মনের পদ্ধতি অবশ্যই তথাকথিত "অনুরোধের তুষারপাত" এর উত্থানের দিকে পরিচালিত করবে। (ঝড় পুনরায় চেষ্টা করুন) এবং বিতরণ সিস্টেমের জন্য নির্দিষ্ট অন্যান্য সমস্যা।
3. ধারাবাহিকভাবে প্রয়োগ করা হলে সবচেয়ে কার্যকর. TLS মেকানিজম শুধুমাত্র সব জায়গায় প্রয়োগ করলেই বোঝা যায়।

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

পরিষেবা জাল ক্ষমতা উদাহরণ

সংক্ষেপে, একটি পরিষেবা জাল নির্ভরযোগ্যতা, পর্যবেক্ষণযোগ্যতা বা নিরাপত্তার জন্য একটি সম্পূর্ণ সমাধান নয়। এই ক্ষেত্রগুলির পরিধি পরিষেবার মালিকদের বাধ্যতামূলক অংশগ্রহণকে বোঝায়, Ops/SRE টিম এবং অন্যান্য কোম্পানি স্টেকহোল্ডারদের৷ পরিষেবা জাল শুধুমাত্র এই প্রতিটি এলাকার জন্য প্ল্যাটফর্ম স্তরে একটি "স্লাইস" প্রদান করে।

কেন পরিষেবা জাল এই মুহূর্তে জনপ্রিয় হয়ে উঠেছে?

আপনি সম্ভবত এখনই ভাবছেন: ঠিক আছে, যদি পরিষেবা জালটি এত ভাল হয়, তাহলে আমরা দশ বছর আগে স্ট্যাকে লক্ষ লক্ষ প্রক্সি স্থাপন করা শুরু করিনি কেন?

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

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

Netflix এর Hysterix ছিল, Google এর Stubby ছিল, Twitter এর Finagle লাইব্রেরি ছিল। উদাহরণস্বরূপ, টুইটারে প্রতিটি নতুন পরিষেবার জন্য ফিনাগল বাধ্যতামূলক করা হয়েছে। এটি সংযোগগুলির ক্লায়েন্ট এবং সার্ভার উভয় দিকই পরিচালনা করে, বারবার অনুরোধের জন্য অনুমোদিত, সমর্থিত অনুরোধ রাউটিং, লোড ব্যালেন্সিং এবং মিটারিং। এটি সম্পূর্ণ টুইটার স্ট্যাক জুড়ে নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার একটি ধারাবাহিক স্তর প্রদান করেছে, পরিষেবা যাই করুক না কেন। অবশ্যই, এটি শুধুমাত্র JVM ভাষার জন্য কাজ করেছিল এবং এটি একটি প্রোগ্রামিং মডেলের উপর ভিত্তি করে ছিল যা সম্পূর্ণ অ্যাপ্লিকেশনের জন্য ব্যবহার করতে হয়েছিল। যাইহোক, এর কার্যকারিতা প্রায় সার্ভিস মেশের মতই ছিল। (আসলে, লিংকার্ডের প্রথম সংস্করণটি প্রক্সি আকারে ফিনাগলে মোড়ানো ছিল।)

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

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

চলুন বর্তমানের দিকে যাওয়া যাক। আজ এমন কিছু স্টার্টআপ আছে যেখানে মাইক্রোসার্ভিসেস এবং ডেভেলপারদের অনুপাত 5:1 (বা এমনকি 10:1), এবং তদ্ব্যতীত, তারা সফলভাবে তাদের সাথে মানিয়ে নেয়! যদি 5 জনের একটি স্টার্টআপ চাপ ছাড়াই 50টি মাইক্রোসার্ভিস পরিচালনা করতে সক্ষম হয়, তাহলে কিছু স্পষ্টভাবে তাদের বাস্তবায়নের খরচ কমিয়ে দেয়।

মঞ্জোতে 1500টি মাইক্রোসার্ভিস; প্রতিটি লাইন একটি নির্ধারিত নেটওয়ার্ক নিয়ম যা ট্রাফিকের অনুমতি দেয়

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

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

কুবারনেটস সবকিছুকে পরবর্তী স্তরে নিয়ে যায়। এখন যেহেতু "এক্সিকিউটেবল জিনিস" এর গুচ্ছ এবং সেগুলি চালানোর জন্য অনেকগুলি মেশিন রয়েছে, সেখানে একটি টুলের প্রয়োজন যা একে অপরের সাথে মেলে। একটি বিস্তৃত অর্থে, আপনি কুবারনেটসকে অনেকগুলি কন্টেইনার এবং অনেকগুলি মেশিন দেন এবং এটি একে অপরের সাথে মিলে যায় (অবশ্যই, এটি একটি গতিশীল এবং ক্রমাগত পরিবর্তনশীল প্রক্রিয়া: নতুন কন্টেইনারগুলি সিস্টেমের চারপাশে ঘোরাফেরা করে, মেশিনগুলি শুরু হয় এবং থামে, ইত্যাদি৷ যাইহোক, Kubernetes এই সব অ্যাকাউন্টে নেয়)।

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

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

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

সেবার জাল নিয়ে এত কথা কেন?

প্রতিরোধ: এই বিভাগে, আমি সমস্ত ধরণের অনুমান, অনুমান, বানোয়াট এবং ভিতরের তথ্য অবলম্বন করি।

"পরিষেবা জাল" অনুসন্ধান করা একগুচ্ছ পুনর্ব্যবহৃত, কম-ক্যালোরি সামগ্রী, বিজোড় প্রকল্প, এবং একটি ইকো চেম্বারের যোগ্য বিকৃতির ক্যালিডোস্কোপ তৈরি করবে। যেকোন ট্রেন্ডি নতুন প্রযুক্তিতে এটি রয়েছে, তবে পরিষেবা জালের ক্ষেত্রে সমস্যাটি বিশেষত তীব্র। কেন?

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

(এই তিনটি কোম্পানির খুব আলাদা ভূমিকা রয়েছে: লিফটের সম্পৃক্ততা শুধুমাত্র নামের মধ্যে সীমাবদ্ধ বলে মনে হচ্ছে; তারা দূত লেখক কিন্তু ইস্টিওর উন্নয়নে ব্যবহার করে না বা জড়িত নয়। আইবিএম ইস্টিওর বিকাশের সাথে জড়িত এবং এটি ব্যবহার করে। Google ব্যাপকভাবে Istio এর উন্নয়নে জড়িত, কিন্তু যতদূর আমি বলতে পারি, আসলে এটি ব্যবহার করে না।)

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

(অভ্যাসে, Istio শুধুমাত্র জটিলতা এবং UX নিয়েই নয়, কর্মক্ষমতা নিয়েও সমস্যা আছে বলে মনে হয়। উদাহরণস্বরূপ, সময় Linkerd কর্মক্ষমতা মূল্যায়নতৃতীয় পক্ষের দ্বারা পরিচালিত, বিশেষজ্ঞরা এমন পরিস্থিতিতে খুঁজে পেয়েছেন যেখানে ইস্টিওর লেজের লেটেন্সি Linkerd এর তুলনায় 100 গুণ বেশি ছিল, সেইসাথে সম্পদের অভাব সহ পরিস্থিতি, যখন Linkerd সফলভাবে কাজ করতে থাকে, এবং Istio সম্পূর্ণরূপে কাজ করা বন্ধ করে দেয়।)

কেন এটি ঘটেছে সে সম্পর্কে আমার তত্ত্বগুলিকে বাদ দিয়ে, আমি বিশ্বাস করি যে পরিষেবা জালের চারপাশে অফ-স্কেল হাইপ গুগলের জড়িত থাকার কারণে। যথা, নিম্নলিখিত তিনটি কারণের সংমিশ্রণ:

1. Google দ্বারা Istio এর আবেশী প্রচার;
2. প্রকল্পের প্রতি যথাযথ অস্বীকৃতি, সমালোচনামূলক মনোভাব;
3. কুবারনেটসের সাম্প্রতিক আকাশচুম্বী জনপ্রিয়তা, যার স্মৃতি এখনও তাজা।

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

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

Linkerd এর দিক থেকে, আমাদের কৌশল হল গোলমাল উপেক্ষা করা, সম্প্রদায়ের প্রকৃত সমস্যাগুলি সমাধানের উপর ফোকাস করা এবং মূলত হাইপ কমার জন্য অপেক্ষা করা। অবশেষে হাইপ কমে যাবে এবং আমরা শান্তিতে কাজ চালিয়ে যেতে পারব।

ততক্ষণ পর্যন্ত আমাদের সবাইকে ধৈর্য ধরতে হবে।

একটি বিনয়ী সফ্টওয়্যার ইঞ্জিনিয়ার, পরিষেবা জাল আমার জন্য দরকারী হবে?

নিম্নলিখিত প্রশ্নাবলী এই প্রশ্নের উত্তর সাহায্য করবে:

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

আপনি কি এমন একটি কোম্পানিতে একটি প্ল্যাটফর্ম বজায় রাখেন যা কুবারনেটস ব্যবহার করে? হ্যাঁ, এই ক্ষেত্রে আপনার একটি পরিষেবা জাল প্রয়োজন (অবশ্যই, যদি আপনি শুধুমাত্র একটি মনোলিথ বা ব্যাচ প্রক্রিয়াকরণ চালানোর জন্য K8s ব্যবহার না করেন - তবে আমি জিজ্ঞাসা করতে চাই কেন আপনার K8s দরকার)। সম্ভবত, আপনি নিজেকে বিভিন্ন লোকের দ্বারা লিখিত অনেক মাইক্রোসার্ভিসের সাথে একটি পরিস্থিতিতে খুঁজে পাবেন। তারা সবাই একে অপরের সাথে ইন্টারঅ্যাক্ট করে এবং রানটাইম নির্ভরতার একটি জট বেঁধে থাকে এবং আপনাকে এই সবের সাথে মোকাবিলা করার উপায় খুঁজে বের করতে হবে। Kubernetes ব্যবহার আপনি "নিজের জন্য" একটি পরিষেবা জাল চয়ন করতে পারবেন। এটি করার জন্য, তাদের ক্ষমতা এবং বৈশিষ্ট্যগুলির সাথে নিজেকে পরিচিত করুন এবং উপলব্ধ প্রকল্পগুলির মধ্যে কোনটি আপনার জন্য উপযুক্ত কিনা এই প্রশ্নের উত্তর দিন (আমি লিঙ্কার্ডের সাথে আপনার গবেষণা শুরু করার পরামর্শ দিই)।

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

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

উপসংহার

সম্ভবত, পরিষেবা জালকে এখনও "বিশ্বের সর্বাধিক হাইপড প্রযুক্তি" বলা উচিত নয় - এই সন্দেহজনক সম্মান সম্ভবত বিটকয়েন বা এআই-এর অন্তর্গত। হয়তো সে সেরা পাঁচে আছে। কিন্তু আপনি যদি কোলাহল এবং ডিনের স্তরগুলি ভেঙ্গে ফেলেন তবে এটি পরিষ্কার হয়ে যায় যে পরিষেবা জাল তাদের জন্য প্রকৃত সুবিধা নিয়ে আসে যারা কুবারনেটে অ্যাপ্লিকেশন তৈরি করে।

আমি চাই আপনি Linkerd চেষ্টা করুন - এটি একটি Kubernetes ক্লাস্টারে ইনস্টল করা (বা এমনকি একটি ল্যাপটপে Minikube) প্রায় 60 সেকেন্ড সময় লাগেএবং আপনি নিজেই দেখতে পারেন আমি কি সম্পর্কে কথা বলছি।

FAQ

- আমি পরিষেবা জাল উপেক্ষা করলে, এটি অদৃশ্য হয়ে যাবে?
- আমি আপনাকে অবশ্যই হতাশ করব: পরিষেবা জাল দীর্ঘ সময়ের জন্য আমাদের সাথে রয়েছে।

— কিন্তু আমি একটি পরিষেবা জাল ব্যবহার করতে চাই না!
- আচ্ছা, এটার দরকার নেই! আপনার অন্তত এর মূল বিষয়গুলির সাথে নিজেকে পরিচিত করা উচিত কিনা তা দেখতে উপরের আমার প্রশ্নাবলী পড়ুন।

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

- কিভাবে একটি পরিষেবা জাল API গেটওয়ে থেকে আলাদা?
এই বিষয়ে এক মিলিয়ন নিবন্ধ আছে. শুধু গুগল.

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

- নেটওয়ার্ক সার্ভিস মেশ - এটা কি সার্ভিস মেশ?
- না। নাম সত্ত্বেও, এটি একটি পরিষেবা জাল নয় (আপনি কীভাবে বিপণনের বিস্ময় পছন্দ করেন?)।

- পরিষেবা জাল কি বার্তা সারির উপর ভিত্তি করে আমার প্রতিক্রিয়াশীল অ্যাসিঙ্ক্রোনাস সিস্টেমে সাহায্য করবে?
- না, সার্ভিস মেশ আপনাকে সাহায্য করবে না।

- আমি কোন পরিষেবা জাল ব্যবহার করা উচিত?
- লিংকার্ড, কোন ব্রেইনার

- নিবন্ধটি খারাপ! লেখক - সাবানের উপর!
— অনুগ্রহ করে আপনার সমস্ত বন্ধুদের সাথে এটির লিঙ্কটি শেয়ার করুন যাতে তারা এটি সম্পর্কে নিশ্চিত হতে পারে!

স্বীকৃতি

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

যদিও আমি নিজেকে "লিঙ্কার্ড ডেভেলপার" বলতে পছন্দ করি, বাস্তবতা হল আমি একটি প্রকল্পে README.md ফাইলের রক্ষণাবেক্ষণকারী। আজ Linkerd এ কাজ করছি খুব, খুব, খুব много মানুষ, এবং এই প্রকল্পটি অবদানকারী এবং ব্যবহারকারীদের আশ্চর্যজনক সম্প্রদায় ছাড়া সম্ভব হত না।

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

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

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

• «একটি পরিষেবা জাল কি এবং কেন আমার এটি প্রয়োজন [মাইক্রোসার্ভিস সহ একটি ক্লাউড অ্যাপ্লিকেশনের জন্য]?";
• «Traefik 2.0: TCP সমর্থন এবং নতুন ওয়েব ইন্টারফেসের সাথে পরিষেবা জাল আপডেট";
• «Maesh - Traefik এর লেখকদের থেকে Kubernetes-এর জন্য একটি নতুন সাধারণ পরিষেবা জাল";
• «Istio এর সাথে মাইক্রোসার্ভিসে ফিরে যান। অংশ 1";
• «নালী - Kubernetes জন্য হালকা পরিষেবা জাল».

উত্স: www.habr.com