CodeGym/Java Course/মডিউল 3/ক্লায়েন্ট-সার্ভার আর্কিটেকচার

ক্লায়েন্ট-সার্ভার আর্কিটেকচার

বিদ্যমান

1.1 অ্যাপ্লিকেশন আর্কিটেকচার

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

বড় সার্ভার অ্যাপ্লিকেশনের জন্য জনপ্রিয় আর্কিটেকচারের উদাহরণ:

  • স্তরযুক্ত স্থাপত্য (স্তরযুক্ত স্থাপত্য)।
  • টায়ার্ড আর্কিটেকচার।
  • সার্ভিস ওরিয়েন্টেড আর্কিটেকচার (SOA)।
  • মাইক্রোসার্ভিস আর্কিটেকচার (মাইক্রোসার্ভিস আর্কিটেকচার)।

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

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

"প্রয়োজনে পরিবর্তন করা" মানে কি? এমন জায়গা আছে যেখানে আপনার পরিবর্তন করার দরকার নেই? হুবহু।

নির্দিষ্ট হওয়ার জন্য, ধরা যাক আপনি একটি মাঝারি ব্যাকএন্ড প্রকল্পে কাজ করছেন । এটি 5 বছর ধরে 20 জনের একটি দল লিখেছে। প্রকল্পটি 100 মানব-বছর নিয়েছিল এবং এতে প্রায় 100 হাজার লাইন কোড রয়েছে। মোট, এটি দুই হাজার ক্লাস নিয়ে গঠিত, যা বিভিন্ন আকারের 10 টি মডিউলে বিভক্ত।

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

এটা কোনো দুঃস্বপ্ন নয় যা আমি তোমাকে ভয় দেখানোর জন্য তৈরি করেছি। এটি একটি সাধারণ প্রকল্প। এটা আরও খারাপ হয়. ইহা কি জন্য ঘটিতেছে? যেকোন সংখ্যক কারণ থাকতে পারে, তবে প্রায় সবসময়ই এরকম থাকে:

  • অনেক লোক প্রকল্পে কাজ করে - তাদের প্রত্যেকে এটিকে একটু আলাদাভাবে দেখে।
  • 5 বছর ধরে, 10 জন প্রকল্পে পরিবর্তন হয়েছে, নতুনরা এটি খুব বেশি বুঝতে পারেনি।
  • সফ্টওয়্যার তৈরি করা হচ্ছে একটি ধ্রুবক পরিবর্তন যা ক্রমাগত সবকিছু পরিবর্তন করে।
  • পাঁচ বছর আগে, যখন আমরা স্থাপত্যের বিষয়ে সিদ্ধান্ত নিয়েছিলাম, তখন প্রকল্পটির ধারণা ছিল কিছুটা ভিন্ন।

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

1.2 ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশনের ধারণা

এখন আমরা ক্লায়েন্ট-সার্ভার আর্কিটেকচারের অন্তর্নিহিত ধারণাটি বুঝতে পারব এবং ইন্টারনেটে লক্ষ লক্ষ প্রোগ্রামের মিথস্ক্রিয়া কীভাবে সংগঠিত হয় তা আপনাকে আরও ভালভাবে বুঝতে অনুমতি দেবে।

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

নিম্নলিখিত উদাহরণ একটি সার্ভার হিসাবে দেওয়া যেতে পারে:

  • ওয়েব সার্ভার যেমন টমক্যাট।
  • ডাটাবেস সার্ভার যেমন মাইএসকিউএল।
  • স্ট্রাইপের মত পেমেন্ট গেটওয়ে।

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

প্রোটোকল সাধারণত সার্ভার প্রদান করা পরিষেবার ধরন অনুযায়ী নির্বাচন করা হয়। উদাহরণস্বরূপ, যদি এটি একটি ভিডিও কল হয়, তাহলে সাধারণত UDP ব্যবহার করা হয়।

মনে রাখবেন কিভাবে টমক্যাট এবং এর সার্লেট কাজ করে? সার্ভার একটি HTTP বার্তা পায়, এটিকে আনপ্যাক করে, সেখান থেকে সমস্ত প্রয়োজনীয় তথ্য বের করে এবং প্রক্রিয়াকরণের জন্য সার্লেটে প্রেরণ করে। তারপর প্রক্রিয়াকরণ ফলাফল একটি HTTP- প্রতিক্রিয়া মধ্যে প্যাকেজ করা হয় এবং ক্লায়েন্ট পাঠানো হয়.

এটি সাধারণ ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশন। ব্রাউজার হল ওয়েব ক্লায়েন্ট এবং টমক্যাট হল ওয়েব সার্ভার। Tomcat এমনকি একটি ওয়েব সার্ভার বলা হয়.

কিন্তু যদি আপনি এটি সম্পর্কে চিন্তা করেন, এটি গুরুত্বপূর্ণ নাম নয়, সারাংশ - প্রোগ্রামগুলির মধ্যে ভূমিকার বিতরণ। একটি HTML পৃষ্ঠায় চলমান আপনার JS স্ক্রিপ্টটিকে একটি ক্লায়েন্ট এবং আপনার servlet একটি সার্ভার বলা যেতে পারে । সর্বোপরি, তারা ক্লায়েন্ট-সার্ভার ধারণার কাঠামোর মধ্যে জোড়ায় কাজ করে ।

1.3 একটি গুরুত্বপূর্ণ সূক্ষ্মতা

এটাও লক্ষণীয় যে ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশন এই নীতির উপর ভিত্তি করে যে এই ধরনের মিথস্ক্রিয়া ক্লায়েন্ট দ্বারা শুরু হয় : সার্ভার শুধুমাত্র ক্লায়েন্টকে উত্তর দেয় এবং রিপোর্ট করে যে এটি ক্লায়েন্টকে পরিষেবা প্রদান করতে পারে কিনা এবং যদি তাই হয় তবে কোন শর্তে .

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

এই ধারণাটি একটি জটিল সিস্টেমকে সরল করার প্রথম পদক্ষেপ হিসাবে তৈরি করা হয়েছিল। তার এই শক্তি রয়েছে:

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

ক্লায়েন্ট এবং সার্ভারের মধ্যে মিথস্ক্রিয়াটির সবচেয়ে মৌলিক সংস্করণটি ছবিতে দেখানো হয়েছে:

ক্লায়েন্ট সার্ভার

এখানে দুটি বিবরণ উল্লেখ করা গুরুত্বপূর্ণ। প্রথমত, ছবিটি দেখায় যে অনেক ক্লায়েন্ট একটি সার্ভার অ্যাক্সেস করতে পারে। দ্বিতীয়ত, তারা একই সময়ে এটি অ্যাক্সেস করতে পারে। এটিও সার্ভারের একটি গুরুত্বপূর্ণ অংশ।

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

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

গুরুত্বপূর্ণ বস্তুর জীবনচক্র নিরীক্ষণ করা আবশ্যক:

আপনি শুধুমাত্র এর মাধ্যমে সার্ভারে একটি নতুন থ্রেড শুরু করতে পারবেন না new Thread().start()। পরিবর্তে, আপনার একটি থ্রেডপুল থাকতে হবে যা সমস্ত পরিষেবা থ্রেডের মধ্যে ভাগ করবে।

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

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

1.4 ক্লায়েন্ট-সার্ভার আর্কিটেকচার

আরেকটি গুরুত্বপূর্ণ পয়েন্ট। ক্লায়েন্ট-সার্ভার আর্কিটেকচার শুধুমাত্র কম্পিউটারের মধ্যে মিথস্ক্রিয়ার সাধারণ নীতিগুলিকে সংজ্ঞায়িত করে , মিথস্ক্রিয়াটির বিবরণ বিভিন্ন প্রোটোকল দ্বারা নির্ধারিত হয়।

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

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

ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশনের দ্বি-স্তরের আর্কিটেকচারের অপারেশনের নীতি হল যে একটি অনুরোধের প্রক্রিয়াকরণ এই প্রক্রিয়াকরণের প্রক্রিয়ায় অন্যান্য সার্ভারের উল্লেখ না করে একটি সার্ভারে ঘটে।

দ্বি-স্তরের ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশন মডেলটি একটি সাধারণ ডায়াগ্রাম হিসাবে আঁকা যেতে পারে।

দ্বি-স্তরের ক্লায়েন্ট-সার্ভার আর্কিটেকচার

এখানে আপনি দেখতে পাচ্ছেন যে প্রথম স্তরটি ক্লায়েন্টের সাথে সম্পর্কিত সমস্ত কিছু এবং দ্বিতীয় স্তরটি সার্ভারের সাথে সম্পর্কিত সমস্ত কিছু।

মন্তব্য
  • জনপ্রিয়
  • নতুন
  • পুরানো
মন্তব্য লেখার জন্য তোমাকে অবশ্যই সাইন ইন করতে হবে
এই পাতায় এখনও কোনো মন্তব্য নেই