মাইক্রোসার্ফেসগুলি জুড়ে ডেটা সিঙ্ক্রোনাইজ করার উপযুক্ত উপায় কী?


19

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

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

তবে, যদি Bনিচে / ব্যর্থ হয় এবং কিছুক্ষণ পরে, আবার ফিরে আসে what যে ডাউন সময়, Aআরও দুটি বার্তা প্রকাশিত হয়েছে। এর তথ্যের Bস্থানীয় কপিটি কীভাবে আপডেট করবেন তা কীভাবে জানবেন A?

মঞ্জুর, যদি Bকেবলমাত্র Aসারির একমাত্র গ্রাহক হয় তবে এটি অনলাইনে ফিরে আসার পরে এটি পড়তে শুরু করতে পারে তবে যদি সেই সারিটির অন্যান্য গ্রাহক থাকে এবং সেই বার্তাগুলি গ্রাস হয় তবে কী হবে?

আরও দৃ concrete় উদাহরণ হিসাবে, Usersকোনও Billingমাইক্রোসারওয়াইস ডাউন থাকাকালীন যদি কোনও পরিষেবার ইমেলের ঠিকানা আপডেট হয়, যদি Billingমাইক্রোসারওয়াইস আবার ফিরে আসে তবে কীভাবে এটি ইমেলটি আপডেট হয়েছে তা কীভাবে জানবে?

যখন মাইক্রোসার্ভেসেসস ফিরে আসে, তখন কি এটি সম্প্রচার করে "আরে আমি ফিরে এসেছি, আমাকে আপনার সমস্ত বর্তমান তথ্য দিন?"

সাধারণভাবে ডেটা সিঙ্ক্রোনাইজেশনের জন্য সেরা শিল্প অনুশীলনগুলি কী হবে?


1
এটি যখনই সম্ভব এড়াতে।
টেলাস্টিন

1
কেন Ordersকিছু জানতে হবে Users?
কেডগ্রিগরি

এটি কেবল একটি উদাহরণ। আপনি যে অর্থ চান তা দিয়ে দুটিকে প্রতিস্থাপন করুন।
নোবেলারে

একটি ফ্যান আউট রাউটিং আপনার 'বার্তাটি অন্য কারও দ্বারা গ্রাস হচ্ছে' সমস্যার সমাধান করবে। তবে আপনি কী অর্জন করতে চাইছেন তা সত্যিই অস্পষ্ট।
ইভান

@ ইয়ান আমি কী জিজ্ঞাসা করতে চাইছি তা আরও ভাল করে ব্যাখ্যা করার জন্য আমি আমার মূল পোস্টটি আপডেট করেছি
নোবেলরে

উত্তর:


5

আমি "সমস্ত অন্যান্য মাইক্রোসার্ভেসগুলিতে ডেটা চাপানো" আপনার সম্পূর্ণ ধারণাটিকে চ্যালেঞ্জ জানাব would

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


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

2
আপনার উত্তরের জন্য ধন্যবাদ. তাহলে কেন সেখানে একটি পাব / সাব মডেল এবং বার্তার সারি দরকার? আমরা যদি "পুশ" ডেটার পরিবর্তে "টানতে" চেষ্টা করি তবে আমরা পরিষেবা বিলম্বিতা নিয়ে চিন্তিত।
নোবেলরে

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

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

@dukethrash এর পরে এগুলিকে অত্যন্ত সহজলভ্য করুন।
জে ফ্যাবিয়ান মেয়ার

5

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

ইভেন্ট-গুন

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

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

ইভেন্ট ব্রোকার হিসাবে অ্যাপাচি কাফকা

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

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

প্রকৃতপক্ষে, যখন গ্রাহকরা কাফকার কাছে নিজেকে সনাক্ত করেন, কাফকা রেকর্ড করবে যে কোন বার্তাটি কোন ভোক্তার কাছে পৌঁছেছিল যাতে এটি আর ব্যবহার না করে।

কাহিনীগুলি

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

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


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

^ তবে এটি সিস্টেমের প্রাপ্যতা হ্রাস করবে। উচ্চ স্থিতিস্থাপকতার প্রয়োজন হলে জটিল কাঠামোটি পুনরায় সাজানো হতে পারে।
অ্যাভোহন

1

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

এখন মাইক্রোসার্ভাইস জানে যে কোনও বার্তা শেষ পর্যন্ত সরবরাহ করা হয় তবে এটি পর্যাপ্ত নয়: কোন একক বার্তা সরবরাহের প্রত্যাশাটি কোনভাবে? এটি কি একই ইভেন্টের বিজ্ঞপ্তির একাধিক অনুলিপি সরবরাহ করতে পারে? এটি বিতরণার্থের বিষয় (কমপক্ষে একবার, ঠিক একবার)

সর্বশেষ ভাবনা):

  1. আপনি যখন আপনার আর্কিটেকচারে এমন কোনও মাইক্রোসার্ভিস যুক্ত করেন যা অন্যের কাছ থেকে ইভেন্টগুলি গ্রহন করা প্রয়োজন, আপনাকে প্রথম সিঙ্ক করতে হবে

  2. এমনকি ব্রোকারও ব্যর্থ হতে পারে, এক্ষেত্রে বার্তা হারিয়ে যায় lost

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


0

আপনি কোনও প্রকাশক / গ্রাহক মডেল দিয়ে কোনও সাধারণ ইভেন্টের সারিটি প্রতিস্থাপন করতে পারেন, যেখানে Aপরিষেবা টি বিষয়ের একটি নতুন বার্তা প্রকাশ করে এবং Bমাইক্রোসার্ফেসিসের ধরণ একই বিষয়ে সাবস্ক্রাইব করে।

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


0

যদি এ দ্বারা কোনও বার্তা পোস্ট করা হয় যা এই বলেছে যে কিছু পরিবর্তন হয়েছে, বি সেই বার্তাটি গ্রাহ্য করতে এবং এ এর ​​তথ্যের স্থানীয় কপিটি প্রতিলিপি করতে পারে এবং বি-কে যা করতে হবে তা করতে এটি ব্যবহার করতে পারে।

আপনি যদি B এর A এর অভ্যন্তরীণ ডেটা অ্যাক্সেস করতে সক্ষম হতে চান তবে এটি এ এর ​​অভ্যন্তরীণ ডাটাবেসে অ্যাক্সেস দেওয়া ভাল।

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

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

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