হে হাবর!

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

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

অনুভূমিক স্কেলিং

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

উদাহরণস্বরূপ, আমি অ্যাবস্ট্রাক্ট ক্লাউড ফাইল স্টোরেজ নেব, অর্থাৎ OwnCloud, OneDrive এর কিছু অ্যানালগ এবং আরও অনেক কিছু।

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

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

সিকিউআরএস

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

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

1. ক্লায়েন্ট সার্ভারে একটি অনুরোধ পাঠিয়েছে।
2. সার্ভার একটি দীর্ঘ প্রক্রিয়াকরণ সময় শুরু.
3. সার্ভার ফলাফল সহ ক্লায়েন্টকে সাড়া দিয়েছে।

আসুন কল্পনা করি যে পয়েন্ট 2-এ সংযোগটি ভেঙে গেছে (বা নেটওয়ার্কটি পুনরায় সংযুক্ত হয়েছে, বা ব্যবহারকারী অন্য পৃষ্ঠায় গিয়ে সংযোগটি ভেঙেছে)। এই ক্ষেত্রে, সার্ভারের পক্ষে ঠিক কী প্রক্রিয়া করা হয়েছিল সে সম্পর্কে তথ্য সহ ব্যবহারকারীকে প্রতিক্রিয়া পাঠানো কঠিন হবে। CQRS ব্যবহার করে, ক্রমটি কিছুটা ভিন্ন হবে:

1. ক্লায়েন্ট আপডেট সাবস্ক্রাইব করেছে.
2. ক্লায়েন্ট সার্ভারে একটি অনুরোধ পাঠিয়েছে।
3. সার্ভার উত্তর দিয়েছে "অনুরোধ গৃহীত হয়েছে।"
4. সার্ভার "1" পয়েন্ট থেকে চ্যানেলের মাধ্যমে ফলাফলের সাথে প্রতিক্রিয়া জানায়।

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

মজার ব্যাপার হল, ইনকামিং মেসেজ প্রসেস করার কোড একই হয়ে যায় (100% নয়) উভয় ইভেন্টের জন্য যেগুলি ক্লায়েন্ট নিজেই দ্বারা প্রভাবিত হয়েছিল এবং অন্যান্য ইভেন্টগুলির জন্য, যার মধ্যে অন্যান্য ক্লায়েন্টদের থেকেও রয়েছে৷

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

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

ইভেন্ট সোর্সিং

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

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

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

যাইহোক, মূল কাজে ফিরে আসা যাক। যদি সিস্টেমের অংশ দিয়ে তৈরি করা যায় চূড়ান্ত ঐক্য, তাহলে আমরা নিম্নলিখিত চিত্রটি তৈরি করতে পারি।

এই পদ্ধতির গুরুত্বপূর্ণ বৈশিষ্ট্য:

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

আমি আপনাকে মনে করিয়ে দিই যে আমরা অনলাইন ফাইল স্টোরেজের ক্ষেত্রে বিবেচনা করছি। এই ক্ষেত্রে, সিস্টেমটি এরকম কিছু দেখাবে:

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

এবং দুই ব্যবহারকারীর জন্য চিত্রটি এইরকম দেখাবে (বিভিন্ন ব্যবহারকারীদের জন্য অভিপ্রেত পরিষেবাগুলি বিভিন্ন রঙে নির্দেশিত হয়):

এই ধরনের সংমিশ্রণ থেকে বোনাস:

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

যাইহোক, অসুবিধাগুলি অবিলম্বে দৃশ্যমান হয়:

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

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

ফলস্বরূপ:

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

ভাগ করে নেওয়া

উপরে বর্ণিত হিসাবে, ইভেন্ট সোর্সিং সিস্টেমে কঠোর ধারাবাহিকতার অভাব রয়েছে। এর মানে আমরা তাদের মধ্যে কোনো সিঙ্ক্রোনাইজেশন ছাড়াই বেশ কয়েকটি স্টোরেজ ব্যবহার করতে পারি। আমাদের সমস্যার কাছে গিয়ে, আমরা করতে পারি:

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

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

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

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

এইভাবে, ফাইলগুলির জন্য অনলাইন স্টোরেজ সম্পর্কে আমাদের উদাহরণ চালিয়ে যাওয়া, এই ধরনের একটি আর্কিটেকচার ইতিমধ্যেই আমাদের অনেকগুলি বোনাস দেয়:

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

স্ট্যাটিক কন্টেন্ট হোস্টিং

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

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

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

• সার্ভার একটি ডাউনলোড URL প্রদান করে। এটি ফাইল_আইডি + কী ফর্মের হতে পারে, যেখানে কী একটি মিনি-ডিজিটাল স্বাক্ষর যা পরবর্তী XNUMX ঘন্টার জন্য সংস্থান অ্যাক্সেস করার অধিকার দেয়।
• ফাইলটি নিম্নলিখিত বিকল্পগুলির সাথে সাধারণ nginx দ্বারা বিতরণ করা হয়:
  • বিষয়বস্তু ক্যাশিং। যেহেতু এই পরিষেবাটি একটি পৃথক সার্ভারে অবস্থিত হতে পারে, তাই আমরা সমস্ত সর্বশেষ ডাউনলোড করা ফাইলগুলি ডিস্কে সংরক্ষণ করার ক্ষমতা সহ ভবিষ্যতের জন্য একটি রিজার্ভ রেখেছি।
  • সংযোগ তৈরির সময় কী পরীক্ষা করা হচ্ছে
• ঐচ্ছিক: স্ট্রিমিং কন্টেন্ট প্রসেসিং। উদাহরণস্বরূপ, যদি আমরা পরিষেবার সমস্ত ফাইল কম্প্রেস করি, তাহলে আমরা এই মডিউলে সরাসরি আনজিপ করতে পারি। ফলস্বরূপ: IO ক্রিয়াকলাপগুলি যেখানে তারা অন্তর্গত সেখানে করা হয়। জাভাতে একটি আর্কাইভার সহজেই প্রচুর অতিরিক্ত মেমরি বরাদ্দ করবে, কিন্তু ব্যবসায়িক যুক্তি সহ একটি পরিষেবাকে মরিচা/সি++ শর্তসাপেক্ষে পুনরায় লেখাও অকার্যকর হতে পারে। আমাদের ক্ষেত্রে, বিভিন্ন প্রক্রিয়া (বা এমনকি পরিষেবা) ব্যবহার করা হয়, এবং সেইজন্য আমরা ব্যবসায়িক যুক্তি এবং IO অপারেশনগুলিকে বেশ কার্যকরভাবে আলাদা করতে পারি।

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

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

যাইহোক, যদি আমরা আমাদের সিস্টেমে ফিরে আসি, আমরা একটি অনুরূপ চিত্র পাই:

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

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

উপসংহার

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

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

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

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

উত্স: www.habr.com