মাইক্রোসার্ভেসিসকে কি একে অপরের সাথে কথা বলা উচিত?

Question

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

আমি বিশ্বাস করি যে দুটি বিকল্প রয়েছে:

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

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

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

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

আমি জানতে চাই যে এই সমস্যার স্ট্যান্ডার্ড অ্যাপ্রোচ কি এবং যদি অন্য কোনও তৃতীয় বিকল্পটি আমি মিস করছি?

Comments

আপনি কিছু প্রসঙ্গ সরবরাহ করতে পারেন? আপনার অ্যাপ্লিকেশনটি কী এবং এটি করার চেষ্টা করছে

— ইওয়ান

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

— বার্ট ভ্যান ইনজেন শেহেনো

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

— অবৈধ হয়ে উঠছি

Answer 1

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

আমি রাষ্ট্র পরিবর্তনকারী ক্রিয়াকলাপ এবং পাঠ্য অপারেশনগুলির (সিকিউএস কমান্ড কোয়েরি পৃথককরণ ) এর মধ্যে একটি স্পষ্ট পার্থক্য করব । রাষ্ট্র পরিবর্তনের ক্রিয়াকলাপগুলির জন্য আমি এক ধরণের ম্যাসেজিং অবকাঠামো ব্যবহার করব এবং আগুনে যাব এবং ভুলে যাব। প্রশ্নের জন্য আপনি সিঙ্ক্রোনাস অনুরোধ প্রতিক্রিয়া যোগাযোগ ব্যবহার করবেন এবং একটি HTTP API ব্যবহার করতে পারেন বা কেবল আপনার ডেটা স্টোরে সরাসরি যেতে পারেন।

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

আরেকটি বিষয় বিবেচনা করার বিষয় হ'ল (লেনদেনের) ডেটা ভাগ করে নেওয়া (কেবলমাত্র দর্শনগুলি পড়ার বিপরীতে) যদি আপনি আপনার অভ্যন্তরীণ অবস্থাটি প্রকাশ করেন তবে পাঠক আপনার ডেটার ভুল অবস্থা, বা ভুল সংস্করণ পেতে পারে এবং সম্ভাব্যভাবে আপনার ডেটা লক করে দেবে?

সর্বশেষে তবে সর্বনিম্ন নয়, আপনার পরিষেবাদিগুলিকে স্বায়ত্তশাসিত রাখতে সর্বনিম্ন চেষ্টা করার চেষ্টা করুন (কমপক্ষে যৌক্তিক স্তরে)।

আশা করি এটি উপলব্ধিযোগ্য।

Answer 2

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

তবে কিছু যুক্তির জন্য যদি আপনার এটির প্রয়োজন হয় তবে আপনার পরিষেবার সীমানা ভুল হওয়ার সম্ভাবনা রয়েছে।

বেশ কয়েকটি বৈশিষ্ট্য রয়েছে যা সাধারণ জ্ঞান আমাদের বলে যে আমাদের পরিষেবাগুলির উচিত । তারা হ'ল:

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

এটি অর্জন করার জন্য, আপনার পরিষেবার সীমানাটিকে ব্যবসায়ের সক্ষমতা হিসাবে বিবেচনা করুন । পরিষেবার সীমানা চিহ্নিত করার একটি আনুষ্ঠানিক প্রক্রিয়া নিম্নলিখিতগুলির মতো দেখায়:

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

একটি উদাহরণ এই পদ্ধতির প্রয়োগের কিছু সুদ হতে পারে।

Answer 3

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

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

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

Answer 4

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

আপনি যে সমস্যাটি সমাধান করার চেষ্টা করছেন সে সম্পর্কে আপনি আরও ব্যাখ্যা করতে সক্ষম হন? সহজ ইংরেজিতে?