মাইক্রো পরিষেবা এবং তথ্য প্রতিলিপি


14

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

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

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

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

উপরে উল্লিখিত বিকল্পগুলির কোনও সম্পর্কে কোনও চিন্তা / সেরা-অনুশীলন / মতামত?


আপনি কি অণু পরিষেবা হিসাবে অ্যাকাউন্ট এবং পণ্য তৈরি করতে পারেন না? একটি "মাস্টার ডেটা সত্তা" থেকে তাদের পুরোপুরি ডিকুয়াল করুন। বিক্রয়গুলি কেবল কোনও ধরণের সত্তার বিক্রয় সম্পর্কে জানত, তবে সত্তাটি কোনও পণ্য, পরিষেবা বা আপনি যে পরে যুক্ত করতে চান এমন কোনও অন্য সত্তা কিনা তা জানতে হবে না।
bleakgadfly

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

উত্তর:


12

আমি এমন একটি দলের অংশ ছিলাম যে একটি সার্ভিস বাস ব্যবহার করে সফলভাবে একটি মাইক্রোসার্ভেসেস আর্কিটেকচার তৈরি করেছি।

প্রাথমিকভাবে, আমরা বিশ্বাস করি যে মাইক্রোসার্চেসিস এবং একটি ইভেন্ট চালিত আর্কিটেকচার আমাদের অন্তর্নিহিত শেয়ারড ডেটা বল-অফ-কাদার ডেটাবেস ঠিক করতে সক্ষম করবে ।

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

আমি বিশ্বাস করি যে ভাগ করা ডেটা মাইক্রোসার্ভেসিসের সাথে ভাল করা অবিশ্বাস্যরকম কঠিন - আমার কাছে এটি নিষিদ্ধভাবে কঠোর। আমি পরিষেবাগুলিকে একে অপরের ডেটা দেখতে না দেওয়ার পরামর্শ দিই । আপনি যদি এটি জিজ্ঞাসা করতে না পারেন তবে আপনি দুর্ঘটনাক্রমে কোনও নির্ভরতার পরিচয় দিতে পারবেন না।

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

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

মালিক যদি কোনও ভিন্ন আকারে ডেটা ধরে রাখতে চান তবে কী হবে? তারপরে প্রতিটি পাঠক পরিষেবা আপডেট করা দরকার। এটি একটি রক্ষণাবেক্ষণ দুঃস্বপ্ন।

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

বার্তাগুলি প্রায়শই তাদের প্রক্রিয়া করার জন্য পর্যাপ্ত সহ তথ্য সহ প্রকাশিত হত।

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

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

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

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


আপনি কি নিজের বিল্ট সলিউশন বা অন্য কিছু ব্যবহার করেন?
ফ্রিএইচএমএএন

2
আমরা এনএসওয়ারবুস ব্যবহার করছিলাম - যা প্রতিটি পরিষেবায় ঘটে যাওয়া কর্মপ্রবাহের সাথে লড়াই করার জন্য ধারণা / কাঠামোগুলির পরিচয় দেয়। দৃ Pers়তা রাভেনডিবি এর মাধ্যমে ঘটতে পারে। আপনি দেখতে পাচ্ছেন যে আপনি খুব তাড়াতাড়ি কোনও প্রযুক্তি বাছাই করতে চান না - আপনার পরিস্থিতি ভিন্ন হতে পারে এবং আমাদের সমস্যা সমাধান করার বিষয়টি ছিল। মার্টিন ফাউলারের মাইক্রোসার্ভিসেস শুরু করা লোকদের জন্য কিছু দুর্দান্ত পরামর্শ রয়েছে: মার্টিনফাউলার / পার্টিকেলস / মাইক্রোসার্ভিসেস এইচটিএমএল - "... আপনার কোনও মাইক্রোসার্চেস আর্কিটেকচার দিয়ে শুরু করা উচিত নয় Instead পরিবর্তে একটি একরঙা দিয়ে শুরু করুন, এটি মডুলার রেখে দিন এবং বিভাজন করুন split মনোলিথ একবার সমস্যা হয়ে গেলে এটি মাইক্রোসার্ভেসিসে পরিণত হয় "
পারফেকশনিস্ট

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

2

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

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


0

একই মাস্টার ডেটা উদাহরণগুলিতে অ্যাকাউন্টগুলি, পণ্যগুলিতে অ্যাক্সেস থাকা দরকার

একই নয়. প্রতিটি মাইক্রো পরিষেবা অ্যাকাউন্ট, পণ্য ইত্যাদির জন্য নিজস্ব ম্যাপিং করা উচিত We আমরা ধরে নিচ্ছি যে প্রতিটি মাইক্রো পরিষেবাদি সত্তাগুলির সাথে কাজ করার জন্য আলাদা উপায় থাকবে।

ডোমেন ড্রাইভড ডিজাইনে এটি সাধারণ, যেখানে প্রতিটি সীমাবদ্ধ প্রসঙ্গ (একই অ্যাপে!) একই সত্তাকে ভিন্ন উপায়ে মানচিত্র করতে পারে।

আপনার যদি আরও তথ্যের প্রয়োজন হয় তবে আমি বিল্ডিং মাইক্রোসার্ভেসিস বইয়ের সুপারিশ করছি : সুনির্দিষ্ট সিস্টেমগুলির ডিজাইনিং


0

আপনি একটি মাস্টার সেট উপর ভিত্তি করে কঙ্কাল রেকর্ড ধারণা বিবেচনা?

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.