মাইক্রোসার্ভেসেস ডাটাবেসগুলি বপন করছে

10

প্রদত্ত সার্ভিস এ (সিএমএস) যা একটি মডেলকে নিয়ন্ত্রণ করে (পণ্য, আসুন এটির একমাত্র ক্ষেত্রগুলি আইডি, শিরোনাম, মূল্য) এবং পরিষেবা বি (শিপিং) এবং সি (ইমেল) যা দেখতে হবে তা প্রদত্ত মডেলটি প্রদর্শন করতে হবে ইভেন্ট সোর্সিং পদ্ধতির সেই পরিষেবাগুলিতে প্রদত্ত মডেল তথ্যগুলিকে সিঙ্ক্রোনাইজ করার জন্য? আসুন ধরে নেওয়া যাক পণ্য ক্যাটালগ খুব কমই পরিবর্তিত হয় (তবে পরিবর্তিত হয়) এবং এমন অ্যাডমিন রয়েছে যা শিপমেন্ট এবং ইমেলের ডেটা খুব ঘন ঘন অ্যাক্সেস করতে পারে (উদাহরণস্বরূপ কার্যকারিতা: বি: display titles of products the order containedএবং সি display content of email about shipping that is going to be sent:)। প্রতিটি পরিষেবার নিজস্ব ডিবি রয়েছে।

সমাধান ঘ

ইভেন্টের মধ্যে পণ্য সম্পর্কিত সমস্ত প্রয়োজনীয় তথ্য প্রেরণ করুন - এর অর্থ নিম্নলিখিত কাঠামোর জন্য order_placed:

{
    order_id: [guid],
    product: {
        id: [guid],
        title: 'Foo',
        price: 1000
    }
}

পরিষেবাতে বি এবং সি পণ্য সম্পর্কিত তথ্য টেবিলের productজেএসএন বৈশিষ্ট্যে সংরক্ষণ করা হয়orders

যেমন, প্রয়োজনীয় তথ্য প্রদর্শন করতে কেবল ইভেন্ট থেকে পুনরুদ্ধার করা ডেটা ব্যবহৃত হয়

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

সমাধান 2

ইভেন্টের মধ্যে কেবলমাত্র পণ্য নির্দেশিকা প্রেরণ করুন - এর অর্থ নিম্নলিখিত কাঠামোর জন্য order_placed:

{
    order_id: [guid],
    product_id: [guid]
}

পরিষেবাগুলিতে বি এবং সি পণ্য সম্পর্কিত তথ্য টেবিলের product_idঅ্যাট্রিবিউটে সংরক্ষণ করা হয়orders

প্রোডাক্ট তথ্য বি এবং সি পরিষেবাগুলি দ্বারা পুনরুদ্ধার করা হয় যখন A/product/[guid]এন্ডপয়েন্টে এপিআই কল করা প্রয়োজন হয়

সমস্যা : এটি বি এবং সি এ এর উপর নির্ভর করে (সর্বদা)। যদি এ-তে পণ্যের স্কিমা পরিবর্তন হয় তবে তাদের উপর নির্ভরশীল সমস্ত পরিষেবাতে পরিবর্তনগুলি করতে হবে (হঠাৎ)

সমাধান 3

ইভেন্টের মধ্যে কেবলমাত্র পণ্য নির্দেশিকা প্রেরণ করুন - এর অর্থ অর্ডার_প্লেডের জন্য নিম্নলিখিত কাঠামো:

{
    order_id: [guid],
    product_id: [guid]
}

পরিষেবাগুলিতে বি এবং সি পণ্যের তথ্য productsসারণীতে সংরক্ষণ করা হয় ; এখনও আছে product_idউপর ordersটেবিল, কিন্তু এর রেপ্লিকেশন এর productsএ, বি এবং C মধ্যে ডেটা; বি এবং সিতে এ সম্পর্কিত পণ্য সম্পর্কে বিভিন্ন তথ্য থাকতে পারে

পরিষেবাদি বি এবং সি তৈরি করা হয় এবং যখন A/productআপডেটগুলি এন্ডপয়েন্টে কল করে (যে সমস্ত পণ্যগুলির প্রয়োজনীয় তথ্য প্রদর্শন করে) বা এ-তে সরাসরি ডিবি অ্যাক্সেস করে এবং প্রয়োজনীয় পণ্য সম্পর্কিত তথ্যের অনুলিপি করে যখন পণ্যগুলির তথ্য পরিবর্তন করা হয় তখন পণ্যের তথ্য বীজযুক্ত হয় Product সেবা।

সমস্যা : এটি বি এবং সি এ এর উপর নির্ভরশীল করে (যখন বপন করার সময়)। যদি এ-তে পণ্যের স্কিমা পরিবর্তন হয় তবে তাদের উপর নির্ভরশীল সমস্ত পরিষেবাগুলিতে (বীজ বপন করার সময়) পরিবর্তনগুলি করতে হবে

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

microservices event-sourcing

— eithed
সূত্র

শুভেচ্ছা updating event history- ঘটনা গুন ঘটনা ইতিহাসে সত্যের আপনার উৎস এবং কখনও পরিবর্তন করা উচিত কিন্তু শুধুমাত্র এগিয়ে যেতে। ইভেন্টগুলি পরিবর্তিত হলে আপনি ইভেন্টের সংস্করণ বা অনুরূপ সমাধানগুলি ব্যবহার করতে পারেন তবে সময়গুলিতে একটি নির্দিষ্ট পয়েন্ট পর্যন্ত আপনার ইভেন্টগুলি পুনরায় চালনার সময় ডেটার অবস্থা যেমন হওয়া উচিত ততক্ষণে।

— নাঃ

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

— নাঃ

@ না হ'ল updating event historyআমার অর্থ হ'ল ধারাবাহিক ইভেন্টের স্কিমা বজায় রাখার জন্য সমস্ত ইভেন্টের মধ্য দিয়ে যান, একটি প্রবাহ (v1) থেকে অন্য স্ট্রিমের (অনি) থেকে অনুলিপি করুন।

— ই

একদিকে যেমন বাণিজ্য / ই-কমার্সের রাজ্যে আপনি দামটি প্রায়শই পরিবর্তিত হয় বলে উল্লেখ করতে পারেন। প্রকৃত অর্ডারটি ক্যাপচার করার সময় ব্যবহারকারীর কাছে প্রদর্শিত দাম আলাদা হতে পারে। সমস্যাটি সমাধানের বিভিন্ন উপায় রয়েছে তবে এটি বিবেচনা করা উচিত।

— সিপারসন

@ সিপারসন হ্যাঁ - দাম ইভেন্টের মধ্যেই যে বৈশিষ্ট্যগুলি পাশ করা হয় তার মধ্যে একটি হতে পারে। অন্যদিকে, চিত্রটির জন্য ইউআরএল ইভেন্টের মধ্যে উপস্থিত থাকতে পারে (এর উদ্দেশ্যকে উপস্থাপন করে display image at the point when purchase was made) বা করতে পারে না (উদ্দেশ্যটির প্রতিনিধিত্ব করে display current image as it within catalog)

— এথেড

3

সমাধান # 3 সত্যিই সঠিক ধারণার কাছাকাছি।

এটি সম্পর্কে চিন্তা করার একটি উপায়: বি এবং সি হ'ল প্রতিটি প্রয়োজনীয় তথ্যের "স্থানীয়" কপি। বিতে প্রক্রিয়া করা বার্তাগুলি (এবং একইভাবে সি তে) স্থানীয়ভাবে ক্যাশেড তথ্য ব্যবহার করে। একইভাবে, স্থানীয়ভাবে ক্যাশেড তথ্য ব্যবহার করে প্রতিবেদনগুলি তৈরি করা হয়।

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

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

এটি আপনাকে "স্বায়ত্তশাসন" দেয়, এই অর্থে যে A এবং সাময়িকভাবে অনুপলব্ধ থাকে তখন বি এবং সি ব্যবসায়ের মূল্য সরবরাহ করতে পারে।

প্রস্তাবিত পাঠ: বাইরের তথ্য , ইনসাইডে ডেটা , প্যাট হেলল্যান্ড 2005।

— VoiceOfUnreason
সূত্র

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

— eithed

1

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

— মাইক বি

2

কম্পিউটার সায়েন্সে দুটি কঠিন জিনিস রয়েছে এবং এর মধ্যে একটি হ'ল ক্যাশে অবৈধ।

সমাধান 2 একেবারে আমার ডিফল্ট অবস্থান এবং আপনি নিম্নলিখিত পরিস্থিতিগুলির মধ্যে একটিতে চলে আসলে আপনার সাধারণত কেবল ক্যাচিং বাস্তবায়ন বিবেচনা করা উচিত:

পরিষেবা A তে API কলটি পারফরম্যান্সের সমস্যা তৈরি করছে।
পরিষেবা A এর দাম কম হওয়া এবং ডেটা পুনরুদ্ধার করতে অক্ষম হওয়া ব্যবসায়ের পক্ষে তাৎপর্যপূর্ণ।

পারফরম্যান্স সমস্যাগুলি আসলেই প্রধান চালক। # 2 সমাধানের অনেকগুলি উপায় রয়েছে যা ক্যাশে জড়িত না, যেমন পরিষেবা A অত্যন্ত উপলব্ধ।

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

থেকে উদী দহন এই চমৎকার নিবন্ধ :

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

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

— ফিল স্যান্ডলার
সূত্র

1

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

— ফিল স্যান্ডলার

1

@SavvasKleanthous এছাড়াও বিবেচনা (যেমন আমি আমার উত্তর উল্লেখিত) যে অনেক ক্ষেত্রে বাসি তথ্য ফেরার হতে পারে অনেক সময় একটি ত্রুটি নিক্ষেপ চেয়ে খারাপ।

— ফিল স্যান্ডলার

1

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

— ফিল স্যান্ডলার

1

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

— সাভভাস ক্লিথনথাস

1

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

— ফিল স্যান্ডলার

2

এটি সহজভাবে বলা খুব সহজ যে একটি সমাধান অন্যটির চেয়ে ভাল। সমাধান # 2 এবং # 3 এর মধ্যে একটি নির্বাচন করা অন্যান্য কারণের উপর নির্ভর করে (ক্যাশের সময়কাল, ধারাবাহিকতা সহনশীলতা, ...)

আমার 2 সেন্ট:

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

সমাধান # 1 (NOK)

একাধিক সিস্টেমে ডেটা নকল করা হয়

সমাধান # 2 (ঠিক আছে)

দৃ strong় ধারাবাহিকতা প্রস্তাব
কেবল তখনই কাজ করে যখন পণ্য পরিষেবা অত্যন্ত উপলব্ধ এবং ভাল পারফরম্যান্স সরবরাহ করে
যদি ইমেল পরিষেবা একটি সংক্ষিপ্তসার (প্রচুর পণ্য সহ) প্রস্তুত করে, তবে সামগ্রিক প্রতিক্রিয়া সময়টি আরও দীর্ঘ হতে পারে

সমাধান # 3 (জটিল তবে পছন্দসই)

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

— সুধীর
সূত্র

1

সাধারণভাবে বলতে গেলে, আমি এই দুটি পরিষেবার মধ্যে অস্থায়ী সংযোগের কারণে বিকল্প 2 এর বিরুদ্ধে দৃ strongly়তার সাথে সুপারিশ করব (যদি না এই পরিষেবাগুলির মধ্যে যোগাযোগ অত্যন্ত স্থিতিশীল হয় এবং খুব ঘন ঘন না হয়)) অস্থায়ী সংযুক্তি যা আপনি বর্ণনা করেনthis makes B and C dependant upon A (at all times) এবং এর অর্থ হ'ল যদি A বা B বা C থেকে অ্যাক্সেসযোগ্য হয় তবে বি এবং সি তাদের কার্য সম্পাদন করতে পারে না।

আমি ব্যক্তিগতভাবে বিশ্বাস করি যে 1 এবং 3 উভয় বিকল্পের এমন পরিস্থিতি রয়েছে যেখানে তারা বৈধ বিকল্প রয়েছে।

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

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

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

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

2020-03-03 সম্পাদনা করুন

ইন্টিগ্রেশন পদ্ধতির নির্ধারণ করার সময় আমার কাছে অগ্রাধিকারগুলির একটি নির্দিষ্ট ক্রম রয়েছে:

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

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

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

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

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

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

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

— স্যাভাস ক্লিনথস
সূত্র

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

— 12

@ ততক্ষণে আমি আমার তৈরি কিছু অনুমানের প্রসারণের উত্তর আপডেট করেছি।

— স্যাভাস ক্লিনথাস