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

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

ভূমিকা

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

ইতিহাস একটি বিট

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

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

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

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

মনোলিথ

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

আয়তন

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

সংযোগ

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

মোতায়েন

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

মাপযোগ্যতা

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

আরেকটি উদাহরণ (আরও ক্লাসিক): পরিষেবা A পরিষেবা B এর চেয়ে অনেক বেশি জনপ্রিয়, তাই আপনি 100টি পরিষেবা A এবং 10টি পরিষেবা B থাকতে চান। আবার, দুটি বিকল্প: হয় আমরা 100টি পূর্ণাঙ্গ মনোলিথ স্থাপন করি, অথবা কিছুতে পরিষেবা বি ম্যানুয়ালি নিষ্ক্রিয় করতে হবে।

বিশ্বাসযোগ্যতা

যেহেতু সমস্ত পরিষেবাগুলি একসাথে অবস্থিত, যদি মনোলিথ পড়ে যায়, তবে সমস্ত পরিষেবা একবারে পড়ে যায়। প্রকৃতপক্ষে, এটি এতটা খারাপ নাও হতে পারে, অন্তত একটি বিতরণ করা সিস্টেমে কোনও আংশিক ব্যর্থতা থাকবে না, তবে অন্যদিকে, 0.001% ব্যবহারকারীদের দ্বারা ব্যবহৃত কার্যকারিতার একটি ত্রুটির কারণে, আপনি সমস্ত ব্যবহারকারীকে হারাতে পারেন আপনার সিস্টেমের।

জড়তা

মনোলিথের আকারের কারণে, নতুন প্রযুক্তিতে স্যুইচ করা কঠিন। ফলে ওই একই সিনিয়রকে ধরে রাখা আলাদা কাজ। একটি প্রকল্পের শুরুতে নির্বাচিত প্রযুক্তি স্ট্যাক একটি ব্লক হয়ে উঠতে পারে যা পণ্যের বিকাশকে বাধা দেয়।

উপসংহার

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

আরও পড়ুন:

• কেন SQL সার্ভার ORDER BY ছাড়া ফলাফল বাছাই করার গ্যারান্টি দেয় না
• বিকাশকারী এবং প্রশাসকদের জন্য আর্কিটেকচার: কার কী দক্ষতা প্রয়োজন?

উত্স: www.habr.com