যখন কোনও মাইক্রোসারওয়াস আর্কিটেকচারে কোনও নিয়ম ইঞ্জিনকে ফিট করতে হয় যখন এর জন্য প্রচুর ইনপুট ডেটার প্রয়োজন হয়?


12

বর্তমান পরিস্থিতি

আমরা একটি মাইক্রোসারাইস আর্কিটেকচারে একটি অনলাইন শপিং ওয়েব অ্যাপ্লিকেশন বাস্তবায়ন করছি (এবং এখন বজায় রেখেছি)।

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

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

এই মুহুর্তের জন্য, আমাদের shopping-cartমাইক্রোসারওয়াইস অন্যান্য মাইক্রোসার্ভিসেস থেকে এই সমস্ত ডেটা সংগ্রহ করছে। যদিও এই ডেটার অংশটি ব্যবহার করে shopping-cart, বেশিরভাগ সময় এটি মূলত নিয়ম ইঞ্জিনকে খাওয়ানোর জন্য ব্যবহৃত হয়।

নতুন প্রয়োজনীয়তা

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

যেমনটি অব্যাহত রেখে আমরা বেশ কয়েকটি সমস্যার মুখোমুখি হব:

  • প্রত্যেককে (নিয়ম ইঞ্জিনকে কল করা) ডেটা আনতে পুনরায় প্রতিস্থাপন করতে হবে, এমনকি তাদের নিজের প্রয়োজন না হলেও;
  • বিধি ইঞ্জিনের অনুরোধগুলি জটিল;
  • এই দিক অব্যাহত রেখে, আমাদের অনেক অনুরোধের জন্য নেটওয়ার্কের চারপাশে এই ডেটা পরিবহনের করতে হবে (নিয়ম ইঞ্জিনকে কল করার μ 'এস কলিং'স বি'র কথা ভাবেন, তবে এ-এর বিধিগুলির ইঞ্জিনের প্রয়োজনীয় কিছু ডেটা ইতিমধ্যে রয়েছে);
  • shopping-cart সমস্ত ডেটা আনার কারণে বিশাল আকার ধারণ করেছে;
  • আমি সম্ভবত অনেক ভুলে গেছি ...

এই সমস্যাগুলি এড়াতে আমরা কী করতে পারি?

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

কিছু ধারণা

  1. নিয়ম ইঞ্জিনটিকে প্রয়োজনীয় ডেটা আনতে দিন। এটি এতে আরও জটিলতা যুক্ত করবে, একক দায়িত্বের নীতি লঙ্ঘন করে ( আরও বেশি… );
  2. ডেটা আনার জন্য নিয়ম ইঞ্জিনের আগে একটি প্রক্সি প্রয়োগ করুন;
  3. কোনও "ডেটা ফ্যাচার" প্রয়োগ করুন the যা নিয়ম ইঞ্জিনকে একবারে প্রয়োজনীয় সমস্ত ডেটা আনার জন্য কল করে (সম্মিলিত তদন্ত)।

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

3
এই ঝামেলাগুলি এড়াতে আপনার সেরা বেট হ'ল নিয়ম ইঞ্জিন থেকে মুক্তি পাওয়া।
হোসনেম

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

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

উত্তর:


8

আসুন এক-এক সেকেন্ডের জন্য পিছনে ফিরে আসুন এবং সম্ভবত-উপন্যাস-দৈর্ঘ্যের এই উত্তরটি লেখার আগে আমাদের শুরু স্থানটি মূল্যায়ন করুন। তোমার আছে:

  • একটি বড় একঘেয়ে (নিয়ম ইঞ্জিন)
  • বিপুল পরিমাণে অ-মডুলারাইজড ডেটা যা প্রচুর পরিমাণে পাঠানো হয়
  • নিয়ম ইঞ্জিন থেকে এবং এটি পাওয়া কঠিন
  • আপনি নিয়ম ইঞ্জিনটি সরাতে পারবেন না

ঠিক আছে, এটি মাইক্রোসার্চেসিসের জন্য এতটা দুর্দান্ত নয়। তাত্ক্ষণিকভাবে উদ্বেগজনক সমস্যা হ'ল আপনি ছেলেরা মাইক্রোসার্ভেসিসগুলি কী তা ভুল বোঝাবুঝি করছেন।

প্রত্যেককে (নিয়ম ইঞ্জিনকে কল করা) ডেটা আনতে পুনরায় প্রতিস্থাপন করতে হবে, এমনকি তাদের নিজের প্রয়োজন না হলেও;

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

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

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

আপনার বেশিরভাগ ইস্যু এটি থেকে শুরু করে।

বিধি ইঞ্জিনের অনুরোধগুলি জটিল;

এগুলি কম জটিল করুন।

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

আপনার ডেটা জন্য কিছু প্রোটোকল সংজ্ঞায়িত করুন। আমার অনুমান যে আপনার ছেলেরা কোনও সংজ্ঞায়িত API পরিকল্পনা নেই (উপরের হিসাবে) এবং যখনই প্রয়োজন হবে তখনই REST কল অ্যাডহ্যাক লেখা শুরু করেছেন। আপনি এখন প্রতিবার কিছু আপডেট হওয়ার সাথে সাথে প্রতিটি মাইক্রো সার্ভিস বজায় রাখতে হবে বলে এটি ক্রমশ জটিল হয়ে ওঠে।

আরও ভাল, আপনি কোনও অনলাইন শপিং সরঞ্জাম কার্যকর করার মতো হ'ল প্রথম সংস্থা নন । অন্যান্য সংস্থাগুলিতে গবেষণা করুন।

এখন কি...

এর পরে, আপনি কমপক্ষে কয়েকটি বড় সমস্যা ট্রাইজেড করেছেন।

পরবর্তী সমস্যাটি আপনার নিয়ম ইঞ্জিনের এই প্রশ্ন। আমি আশা করি এটি যথাযথভাবে রাষ্ট্রহীন, আপনি এটি স্কেল করতে পারেন। যদি এটি হয় তবে সাবমোটিমাল হওয়ার সময় আপনি কমপক্ষে গৌরবতে জ্বলে মারা যাবেন না বা পাগল হয়ে যাবেন না।

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

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

বিকল্পভাবে, আপনার নিয়ম ইঞ্জিনকে কি টুকরো টুকরো করা যেতে পারে? আপনার নিয়ম ইঞ্জিন নির্দিষ্ট পরিষেবাদির টুকরো তৈরি করে আপনি লাভ পেতে পারেন।

আমাদের এটিও নিশ্চিত করতে হবে যে এটি কোনও বাধা হয়ে দাঁড়ায় না - উদাহরণস্বরূপ কিছু ডেটা আনতে ধীর (10 বা আরও বেশি)

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

আপনি "ডেটা আনয়ন" শব্দটি বারবার ব্যবহার করেছেন। এই ডেটাবেস কি ডাটাবেসে আছে? যদি তা না হয় তবে এটি করার বিষয়ে বিবেচনা করুন - যদি আপনি "ম্যানুয়ালি" ডেটা আনার জন্য এত বেশি সময় ব্যয় করেন তবে মনে হয় আসল ডাটাবেসটি ব্যবহার করা ভাল ধারণা।

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

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

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


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

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

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

1

বিধি ইঞ্জিন এবং এর ইনপুট এবং আউটপুটগুলি সম্পর্কে যে পরিমাণ তথ্য উপস্থাপন করা হয়েছে, সেগুলি সহ আমি আপনার পরামর্শ নং no 2 সঠিক পথে আছে।

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

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

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

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

নিয়ম ইঞ্জিনটি কেবল বিধিগুলি প্রয়োগ করে, নির্দিষ্ট প্রসঙ্গের জন্য নিয়ম ইঞ্জিনটি সঠিক ডেটা কী প্রয়োজন তা ভোক্তাদের চিন্তা করার দরকার নেই এবং এই নতুন মধ্যস্থতাকারী পরিষেবাগুলি কেবল একটি কাজ করে: প্রসঙ্গটি একত্রিত করুন এবং বিধিগুলির ইঞ্জিনকে অনুরোধটি প্রেরণ করুন এবং প্রতিক্রিয়াটি অশোধিত করে দেয় returns


0

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

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


0

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

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