ডেটা সদৃশ ছাড়াই মাইক্রোসার্ভেসিস


20

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

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

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

এটি বাস্তবায়নের সঠিক / সর্বোত্তম উপায় কী?


5
মাইক্রো-পরিষেবাগুলির প্যারাডক্সে স্বাগতম। জিনিসগুলি সহজ করে তোলে যা আসলে জিনিসগুলিকে আরও জটিল করে তোলে।
রবার্ট হার্ভে

"সঠিক" উপায়টি সর্বদা যেমন ছিল তেমন: আপনার নির্দিষ্ট উদ্দেশ্যগুলির পক্ষে সর্বাধিক উপযুক্ত জিনিসগুলি করার একটি উপায় বের করুন।
রবার্ট হার্ভে

1
@ রবার্টহারভে এটি সর্বদা ক্ষেত্রে তবে আমি পাঠ্যপুস্তকের মাইক্রোসার্ভেসিগুলি বোঝার চেষ্টা করছি। একবার আমি বুঝতে পারি কীভাবে এটি একটি আদর্শ বিশ্বে কাজ করা উচিত আমি আমার ব্যবহারের ক্ষেত্রে এটি ফিট করে আনতে খুশি।
জেরেন্ট অ্যান্ডারসন

1
তবে দক্ষতার দিক থেকে আপনার প্রশ্নটি ফ্রেম করা যা একটি অ-কার্যকরী সফ্টওয়্যার প্রয়োজনীয়তা। দক্ষতার সমস্যার সমাধান করার উপায়টি হ'ল সরাসরি ডাটাবেস জিজ্ঞাসা করা।
রবার্ট হার্ভে

1
আমি ঠিক আপনার হিসাবে একটি প্রশ্ন লিখতে চলেছিলাম I আমি এখনও এমএসএ তে যুক্তিসঙ্গত সহজ ওয়েব অ্যাপ্লিকেশনগুলির জন্য সুবিধা দেখতে পাচ্ছি না। আমি মনে করি অনেক ক্ষেত্রে জিনিসকে এত জটিল না করে মডুলারিটি অর্জন করা যেতে পারে।
গ্ল্যাসনোস্ট

উত্তর:


10

আমি যেখানে আপনাকে নকল করার প্রয়োজন হচ্ছে তা পুরোপুরি মিস করেছি।

মাইক্রো পরিষেবাদির একটি কেন্দ্রীয় নীতি হল পরিষেবাটি একক কর্তৃত্ব হওয়া। তার মানে ইনভেন্টরি এবং ইউজার ম্যানেজমেন্ট সম্পূর্ণ আলাদা হতে পারে। আমি ব্যবহারকারীর ব্যবস্থাপনার নকশা করব যাতে এটি এমনকি আবিষ্কারের সিস্টেমের উপস্থিতি না জানে।

তবে আমি ইনভেন্টরি সিস্টেমটি ডিজাইন করব যাতে এটি ব্যবহারকারী আইডি অন্য কোনও ব্যবহারকারীদের সম্পর্কে কখনই সঞ্চয় না করে। এটি আপনার ব্যবহারকারীর তথ্য পরিবর্তনের প্রচারের সমস্যার যত্ন নেয়।

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

সুতরাং প্রতিটি ক্ষেত্রে, আপনি সর্বশেষ ব্যবহারকারীর তথ্য চাইলে আপনি ব্যবহারকারী তথ্য পরিষেবাটি জিজ্ঞাসা করেন।


@ জেরিন্ট: আপনার সিস্টেমে কী ধরনের সদৃশ ঘটছে সে সম্পর্কে আপনি আরও নির্দিষ্ট করে বলতে পারেন?
রবার্ট হার্ভে

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

এটি উভয়ই পরিচালনা করতে ডিবি একই কৌশল ব্যবহার করবে। আপনি তালিকা সারণীতে ব্যবহারকারীর তথ্য অনুলিপি করেন না। আপনি এটি একটি বিদেশী চাবি দিন। ব্যবহারকারী আইডি পরিষেবা জুড়ে একই কাজ করছে। শুধু এটি অনন্য করুন।
candied_orange

It seems counter-intuitive to move from a single relational database where I could get the inventory data and the user data with a joinমনে রাখবেন যে "আদর্শভাবে" পরিষেবা প্রতি এক স্টোর (বা আরও!) আছে। সুতরাং, "সীমানা" এর মধ্যে "যোগদান" এর মতো কিছুই নেই। কারণটি সহজ, ডিবি পরিষেবাগুলির মধ্যে সংযোগ তৈরি করে। @ ক্যান্ডিড ওরেঞ্জের প্রস্তাবের বিপরীতে, আমি মনে করি আমরা এক পরিষেবা থেকে অন্য পরিষেবাতে ন্যূনতম ডেটা নকল করতে পারি। আমি ডেটা উল্লেখ করছি যা পরিবর্তনের সম্ভাবনা নেই। যদি এই দ্বিধা দক্ষতা এবং কর্মক্ষমতা উন্নত করে (এবং উভয় প্রয়োজন হয়) তবে "পেশাদাররা" সম্ভবত "কনস" অফ-সেট করবে
লাইভ

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

11

আমি ডেটা সদৃশ এড়াতে কঠিন মনে হচ্ছে ....

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

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


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

1
@ অ্যালানসারিব এটি বজায় রাখা আরও কঠিন, তবে বিষয়টি কখনও কখনও আপনার অন্য কোনও পছন্দ থাকে না। উদাহরণস্বরূপ, যদি আপনার দুটি ডাটাবেসে থাকা অবজেক্টের মধ্যে এফকে করা দরকার? স্থানীয় ডিবিতে অনুসন্ধান করার সময় ধারাবাহিকতা নিশ্চিত করার একমাত্র উপায়, একটি তথ্য প্রতিলিপি থাকে। একবার দেখুন: stackoverflow.com/a/4452586/2255491
ডেভিড ডি

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

4

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

হ্যাঁ, হ্যাঁ

মঞ্জুর, একঘেয়ে মধ্যে আপনার কাছে এমন কোনও ইনভেন্টরি-মডেল থাকতে পারে যা আপনি সম্পর্কিত আইটেমগুলির জন্য অনুসন্ধান করেন, এটি একটি ব্যবহারকারী-মডেল হিসাবে খাওয়ান এবং একই ডেটা পান data

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

কিভাবে আপনি এটা করবেন না কেন, কোথাও হবে যে কোডটি মূলত জায় সিস্টেম থেকে ব্যবহারকারীর ID- র একটি তালিকা নিয়ে আসে, ব্যবহারকারী সিস্টেমের মধ্যে তাদের ফিড এবং তথ্য একটি তালিকা প্রনয়ন করা।

আপনার যে প্রশ্নের উত্তর দিতে হবে তা হ'ল পারফরম্যান্স এবং রক্ষণাবেক্ষণ এবং অন্যান্য "নরম" গুণাবলী about

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

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

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

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

এবং আপনি কোনও রিলেশনাল ডাটাবেস (*) -র চেয়ে মাইক্রোসার্ভেসিসে ডেটা নকল করবেন না । একটি সম্পর্কিত সম্পর্কিত ডাটাবেসে আপনি একটি যোগদান করতে পারেন , এবং সমতুল্য বর্ণিত কোডগুলিতে তালিকাগুলিকে মার্জ করা।

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

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

(*) যদি কোনও মাইক্রোসারওয়াইস জলাশয়ে ডেটা ডুপ্লিকেট করা বোধগম্য হয় তবে সম্ভবত এটির সমতুল্য সম্পর্কিত সম্পর্কিত ডাটাবেসটি বোধগম্য হবে।


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

1
@ পিটারপম্পেই আমি এই ক্যাচিংয়ে ফোন করব, ডেটা ডুপ্লিকেশন নয়। ডেটা ডুপ্লিকেশন হ'ল যখন আপনার একটি ডেটুমের জন্য আপডেট করার জন্য দুটি জায়গা থাকে, সেখানে এক জায়গা থাকে এবং যখন অন্য জায়গায় স্বয়ংক্রিয় প্রচার হয় propag এছাড়াও আমি সম্পর্কের চেয়েও বেশি বলেছি। যদি এটি কোনও অনুরূপ ডেটাতে ডুপ্লিকেট করার জন্য ডেটাবেস করে তোলে তবে এটি একটি মাইক্রোসারওয়াইসে বোঝায়। আমি মনে করি আমরা সম্মত হই এবং সেই অংশটি আরও পরিষ্কার হতে পারে তবে এখনই আমার কাছে কেবল একটি ফোন রয়েছে তাই এখনই পাঠ্যটি আপডেট করা হবে না।
ওডাল্রিক

@ পিটারপম্পেই আশা করি ক্যাশে সম্পর্কিত যোগ করা অংশটি আপনার উদ্বেগের কয়েকটি সমাধান করে।
ওডাল্রিক 6'19

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

1
@ ব্র্যান্ডন প্রতিলিপি এবং ক্যাশিংয়ের মধ্যে আরেকটি পার্থক্য হ'ল কোনও পার্থক্য দেখা দিলে আপনি কীভাবে কোনও ডেটা ভুল তা কীভাবে জানেন। প্রতিলিপি কীভাবে ডেটা মার্জ করতে হবে সে সম্পর্কে কিছু নিয়ম সংজ্ঞায়িত করে। অন্যদিকে ক্যাচিং সর্বদা : ক্যাশেটি ভুল।
ওডাল্রিক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.