এসওএ পরিষেবা রচনাটি বাস্তবে অনুশীলন করে?

Question

এসওএর পরিষেবা নকশার মূল নীতিগুলির মধ্যে একটি হ'ল সার্ভিস কমপোসিবিলিটি নীতি ( https://en.wikedia.org/wiki/Service_composability_pr صول )।

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

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

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

আমি দুটি বিকল্প জানি:

1. ডাব্লুএস-পারমাণবিক লেনদেন বা এই জাতীয় মাধ্যমে বাস্তব লেনদেন প্রয়োগ করুন
2. ক্ষতিপূরণ-ভিত্তিক সমাধান কার্যকর করুন যা "ক্যান্সেলএ ()" বা "বি" তে কল ব্যর্থ হলে সামসুছের সাথে A এর কলকে ক্ষতিপূরণ দেয়

এগুলি উভয়ই আমার কাছে অত্যন্ত সমস্যাযুক্ত / অকেজো করার ঘনিষ্ঠ বলে মনে হচ্ছে:

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

আমার কাছে মনে হয় যে পরিষেবা রচনাটি এমন একটি মৌলিক এসওএ নীতি যা আপনি যদি (সুবিধে) পরিষেবা রচনা করতে না পারেন তবে আপনি সত্যই এসওএর সুবিধা পাবেন না । বাস্তবতা কি? 90% এসওএ ব্যবহারকারী প্রকৃত পরিষেবাগুলির কোনও ক্ষতি ছাড়াই "পঙ্গু এসওএ" ব্যবহার করেন? বা বেশিরভাগ ব্যবহারকারীরাই প্রকৃতপক্ষে পরিষেবা রচনাটি ব্যবহার করেন এবং আমি এর অসুবিধাটি অতিরঞ্জিত করছি?

Comments

+1 এটি এমন দুর্দান্ত প্রশ্ন এবং এরকম লজ্জার বিষয়টির তেমন মনোযোগ নেই।

— গাজ_এডজ

Answer 1

সংক্ষিপ্ত উত্তর হল হ্যাঁ!

আমি বেশ কয়েকটি বড় আর্থিক সংস্থায় এটি দেখেছি এবং এটি ভাল কাজ করেছে।

লেনদেনের সমস্যাগুলি জটিল তবে সাধারণত (ব্যয়বহুল) মিডলওয়্যার যেমন হ্যান্ডেলগুলি যেমন ওরাকলস ওয়েবলজিক ইএআই বা আইবিএম ওয়েবসাইটসফিয়ার ইএসবি দ্বারা পরিচালিত হয়।

Comments

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

— জান্নে মাতিলা

ফলো-আপ প্রশ্ন হিসাবে আমি আগ্রহী যে এসওএ বাস্তবায়নের কত শতাংশ এটি "সঠিকভাবে" করে এবং প্রকৃত পরিষেবা রচনা ব্যবহার করে? আমার কুণ্ডুলি খুব কম হবে, 10% এর মতো ... আমি কি ভুল করছি?

— জান্নে মাতিলা

Answer 2

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

আপনার আরও কিছু নির্দিষ্ট উদ্বেগের উত্তর দিতে ...

আপনি লেনদেন ব্যবহার করতে পারেন:

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

ক্ষতিপূরণ ভিত্তিক পদ্ধতির বিষয়টি বিবেচনা করে:

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

কিছু পরিস্থিতিতে কিছু যায় আসে না:

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

আপনি প্রেরিত ইমেলের একটি লগ রাখতেও পারেন এবং পতাকাটি সেট হয়ে যাওয়ার পরে ডি-ডুপ করতেও ব্যবহার করতে পারেন এবং কেবলমাত্র একবার ইমেলটি প্রেরণ করতে পারেন।

লেনদেনকে ছোট ছোট করে বিভক্ত করতে আপনি অ্যাসিক্রোনাস মেসেজিং ব্যবহার করতে পারেন:

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

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

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

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

Comments

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

— ম্যাপেল_শ্যাফ্ট

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

— ব্যবহারকারী 2800708

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

— গাজ_এডজ

Answer 3

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

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

পরিষেবা আর্কিটেকচারের কাছে যাওয়ার আরও আরও ভুল উপায় রয়েছে । তাই সাবধান হন।

Comments

@ ডাউনভোটার একমত নন? এটি নিয়ে আলোচনা করবেন না, কেন বিরক্ত করবেন, কেবল ডাউনভোট!

— Zapadlo