মাইক্রোসার্ভেসিসে অনেকগুলি সংখ্যক সমিতি

Question

আমার কাছে বর্তমানে দুটি মাইক্রোসার্ভিস রয়েছে। আমরা তাদের কল করব Aএবং B।

মাইক্রোসার্চিসের অধীনে থাকা ডাটাবেসে Aনিম্নলিখিত সারণি রয়েছে:

A
|-- users

মাইক্রোসার্চিসের অধীনে থাকা ডাটাবেসে Bনিম্নলিখিত সারণি রয়েছে:

B
|-- trackers

প্রয়োজনীয়তা উল্লেখ করে যে usersএবং trackersএকটি বহু-বহু-সম্পর্ক রয়েছে।

কোনও মাইক্রোসার্চেস আর্কিটেকচারের মধ্যে কীভাবে এটি সঠিকভাবে পরিচালনা করতে হবে তা সম্পর্কে আমি নিশ্চিত নই।

আমি এই তিনটি পদ্ধতির মধ্যে একটির কাজ দেখতে পেলাম:

1. একটি user_trackersসারণী মাইক্রোসার্ভাইসে যুক্ত করা হয় A। এটি "বিদেশী কী" usersএবং এর সাথে যোগদানের টেবিলের অনুরূপ কাজ করে trackers।
2. একটি ownersসারণী মাইক্রোসার্ভাইসে যুক্ত করা হয় B। এই টেবিলটি বহুকোষী যোগদানের টেবিলের অনুরূপ কাজ করে। এটি কোনও পরিষেবাকে ট্র্যাকারের সাথে সমিতি তৈরি করার অনুমতি দেবে। এটি কিছুটা এর মতো দেখতে পারে: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. প্রতিটি মাইক্রোসার্ভির জন্য usersএবং এর trackersমধ্যে রেকর্ড রাখুন । এগুলিকে কিছুটা পাবস সিস্টেমের সাথে সিঙ্কে রাখুন।

আমি মূলত অপশন 2 সহ যাচ্ছিলাম কারণ আমার পছন্দ হয়েছে যে এটি লেনদেনের সীমানা সংরক্ষণ করে। আমি একটি ট্র্যাকার তৈরি করতে পারি এবং এটি পরমাণুর সাথে কোনও কিছুর সাথে যুক্ত করতে পারি। তবে এটি মাইক্রোসার্চিসের সুযোগের বাইরে রয়েছে বলে মনে হয় B। মাইক্রোসার্চিস কেন একটি সমিতি তৈরি করতে চায় Bযে যত্ন করা উচিত A?

আমি মনে করি এখানে সম্ভবত একটি ভাল প্যাটার্ন আছে যা সম্পর্কে আমি অবগত নই। আমি যে বিকল্পগুলি রেখেছি তা কি কোনও অর্থবোধ করে? আরও কিছুর বিকল্প থাকতে পারে?

Answer 1

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

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

দ্বিতীয় জিনিসটি হ'ল আপনি সম্ভবত আপনার ডোমেনের মাধ্যমে যথেষ্ট ভাল কাজ করেন নি। usersটেবিলের সাহায্যে কোন ধারণাটি উপস্থাপন করা হয় ? এটি registered userনিবন্ধকরণের জন্য প্রয়োজনীয় সমস্ত তথ্য এবং আচরণ সহ একটি ? আপনি কি নিশ্চিত যে এটি trackers(এটি যাই হোক না কেন) সাথে যোগাযোগের জন্য সঠিক ধারণা সুতরাং যদি আমি এটি সঠিকভাবে পেয়েছি তবে আপনার বিকল্প 2 হ'ল এটির সম্পর্কে: ownerআপনার ডোমেনের অনেক কাছাকাছি ধারণাটি প্রবর্তন করা । যদি এটি সত্যিই হয় তবে আমি বিকল্প 2 এর জন্যও আছি।

যাইহোক, এটি মাইক্রোসার্চিস বিয়ের সুযোগের বাইরে নয় বলে মাইক্রোসার্চিস বি কে কেন যত্ন নেওয়া উচিত যে মাইক্রোসার্চিস এ কোনও সমিতি তৈরি করতে চায়?

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

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

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

Comments

আমি "বিতরণ করা মনোলিথ" শব্দটি পছন্দ করি তবে আপনি যে লিঙ্কটি দিয়েছেন তাতে এটি যেভাবে সংজ্ঞায়িত হয়েছে তা এখানে সরাসরি প্রশ্নের সাথে সম্পর্কিত নয় বলে মনে হয়। আপনি যেভাবে এটি ব্যবহার করছেন বলে মনে করি সেগুলি এবং নিবন্ধের মধ্যে সংযোগের সাথে সম্পর্কিত বাইনারি নির্ভরতার উপর জোর দেয়। আমি মনে করি আপনি যেভাবে ব্যবহার করছেন সেটি উচ্চতর তবে আমি একটি রেফারেন্স খুঁজতে লড়াই করছি যা এটি পরিষ্কারভাবে परिभाषित করে।

— জিমি জেমস

আমি সর্বদা চ্যাটি পরিষেবাগুলিকে "বিতরণ করা মনোলিথ" বিভাগে অন্তর্ভুক্ত করেছি, যা সাধারণভাবে ছড়িয়ে যায় না common

— ভাদিম সমোখিন

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

প্রশ্ন: আপনার ডেটা ডাটাবেস বরাবর পৃথক করা হয় কেন?

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

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

Comments

এটি মাইক্রোসার্ভেসিসের ধর্মের অংশ, যে প্রতিটি সেবার সম্পূর্ণ স্বায়ত্তশাসন প্রয়োজন। টমাস এরেল এটিকে পরিষেবা সম্পর্কিত নকশার অন্যতম হিসাবে "পরিষেবা ডিজাইনের প্রিন্সপ্লেস" গ। 2008.

— জিমি জেমস 15

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

— খ্রিস্টান Sauer

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

— জিমি জেমস

@ জিমি জেমস আমি মনে করি এটি প্রযুক্তি সম্পর্কেও হতে পারে - বিশেষত যখন সার্টিয়ান প্রযুক্তিগুলি কিছু ডোমেনের জন্য উপযুক্ত তবে অন্যদের জন্য নয়। আমরা আমাদের এমএসগুলির জন্য সি # এবং পাইথন ব্যবহার করি। এর কয়েকটি সাংগঠনিক সমস্যার কারণে ("আমি 20 বছরের জন্য সি # প্রোগ্রাম করেছি, নতুন ফ্যাংড টাইপড ভাষা শেখার দরকার নেই!")। - তবে আমাদের সিস্টেমের প্রকৃতির কারণেও। ডেটা বিজ্ঞানের অংশগুলি অজগরে সেরা তৈরি করা হয়, যখন কিছু পরিকাঠামো এবং ওয়েব টাস্কগুলি সি # তে সেরা হয়।

— খ্রিস্টান সৌর

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

— জিমি জেমস 16