একটি স্থাপত্য শৈলী নির্বাচন করা (অংশ 2)

হ্যালো, হাবর। আজ আমি একটি ধারাবাহিক প্রকাশনা চালিয়ে যাচ্ছি যা আমি বিশেষভাবে কোর্সের একটি নতুন স্ট্রিম শুরু করার জন্য লিখেছিলাম। "সফটওয়্যার স্থপতি".

ভূমিকা

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

В গত বার আমরা মনোলিথের সাথে মোকাবিলা করেছি এবং এই সিদ্ধান্তে পৌঁছেছি যে মনোলিথের বেশ কয়েকটি সমস্যা রয়েছে: আকার, সংযোগ, স্থাপনা, স্কেলেবিলিটি, নির্ভরযোগ্যতা এবং অনমনীয়তা।

এইবার আমি মডিউল/লাইব্রেরি (কম্পোনেন্ট-ভিত্তিক আর্কিটেকচার) বা পরিষেবা (পরিষেবা-ভিত্তিক আর্কিটেকচার) সেট হিসাবে একটি সিস্টেম সংগঠিত করার সম্ভাবনা সম্পর্কে কথা বলার প্রস্তাব করছি।

উপাদান-ভিত্তিক আর্কিটেকচার

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

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

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

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

"আদর্শ" মনোলিথ হল যৌক্তিকভাবে পৃথক করা মডিউলগুলির একটি সেট, যার প্রতিটি তার নিজস্ব ডাটাবেসের মধ্যে দেখায়।

সেবা ভিত্তিক স্থাপত্য

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

পরিষেবা-ভিত্তিক আর্কিটেকচার (SOA = পরিষেবা ভিত্তিক আর্কিটেকচার) একটি মনোলিথের সমস্ত চিহ্নিত সমস্যা সমাধান করে: একটি পরিবর্তন ঘটলে শুধুমাত্র একটি পরিষেবা প্রভাবিত হয় এবং একটি সু-সংজ্ঞায়িত API উপাদানগুলির ভাল এনক্যাপসুলেশন সমর্থন করে৷

কিন্তু সবকিছু এত মসৃণ নয়: SOA নতুন সমস্যা তৈরি করে। দূরবর্তী কলগুলি স্থানীয় কলগুলির চেয়ে বেশি ব্যয়বহুল, এবং উপাদানগুলির মধ্যে দায়িত্বগুলি পুনরায় বিতরণ করা উল্লেখযোগ্যভাবে আরও ব্যয়বহুল হয়ে উঠেছে৷

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

পরিষেবা-ভিত্তিক স্থাপত্যটি স্থাপত্য সম্প্রদায় এবং বিক্রেতাদের দ্বারা সমর্থিত। এটি অনেক কোর্স এবং সার্টিফিকেশনের উপস্থিতি বোঝায়, ভাল-উন্নত নিদর্শন। পরেরটির মধ্যে রয়েছে, উদাহরণস্বরূপ, সুপরিচিত এন্টারপ্রাইজ সার্ভিস বাস (ESB = এন্টারপ্রাইজ সার্ভিস বাস)। একই সময়ে, ESB বিক্রেতাদের থেকে একটি লাগেজ; এটি অগত্যা SOA-তে ব্যবহার করতে হবে না।

পরিষেবা-ভিত্তিক স্থাপত্যের জনপ্রিয়তা 2008 সালের দিকে শীর্ষে পৌঁছেছিল, তারপরে এটি হ্রাস পেতে শুরু করে, যা মাইক্রোসার্ভিসেস (~2015) এর আবির্ভাবের পরে উল্লেখযোগ্যভাবে আরও নাটকীয় হয়ে ওঠে।

উপসংহার

আমরা পরিষেবা এবং মডিউলগুলির আকারে তথ্য সিস্টেমগুলি সংগঠিত করার সম্ভাবনাগুলি নিয়ে আলোচনা করার পরে, আমি অবশেষে মাইক্রোসার্ভিস আর্কিটেকচারের নীতিগুলিতে এগিয়ে যাওয়ার এবং পরবর্তী অংশে মাইক্রোসার্ভিস আর্কিটেকচার এবং পরিষেবা-ভিত্তিক আর্কিটেকচারের মধ্যে পার্থক্যের দিকে বিশেষ মনোযোগ দেওয়ার প্রস্তাব করছি৷

উত্স: www.habr.com