মাইক্রোসার্ভেসিস এবং সঞ্চিত পদ্ধতি

Question

একটি মাইক্রোসার্চ আর্কিটেকচারে সঞ্চিত পদ্ধতিগুলি খারাপ অভ্যাস হিসাবে বিবেচিত হয়?

আমার মতামত এখানে:

• মাইক্রোসার্ভিসেসের বেশিরভাগ বই মাইক্রোসার্ভিস প্রতি একটি ডাটাবেসের প্রস্তাব দেয়। সঞ্চিত পদ্ধতিগুলি সাধারণত একঘেয়ে ডাটাবেসে কাজ করে।

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

• বেশিরভাগ মাইক্রোসারওয়াইস আর্কিটেকচার বইগুলি (যা আমি পড়েছি) এটি সুপারিশ করে যে মাইক্রোসার্ফেসগুলি ব্যবসায়িক ভিত্তিক হওয়া উচিত ( ডোমেন-চালিত ডিজাইন (ডিডিডি) ব্যবহার করে ডিজাইন করা )। ডাটাবেসে সঞ্চিত পদ্ধতিতে ব্যবসায়িক যুক্তি সরিয়ে দিয়ে এটি আর হয় না।

এই সম্পর্কে কোন চিন্তা?

Comments

@ এলোমেলো ইউএস 1 দুঃখিত, এটি আমার কাছে বোধগম্য নয়। ডিবি কাঠামোটি কেন অপেক্ষাকৃত হতে হবে? অবশ্যই, এটিতে বাহ্যিক উল্লেখ থাকতে পারে তবে এর অভ্যন্তরীণ কাঠামোটি 100% সম্পর্কিত হতে পারে

— IMil

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

— ফিলিপ মিলোভানোভিć

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

— আরবেরি ইয়ং

"সঞ্চিত পদ্ধতি সাধারণত একঘেয়ে ডাটাবেসে কাজ করে।" আপনার সাথে সেই "সত্য" ভাগ করে নেওয়া যে কোনও উত্স থেকে প্রাপ্ত কোনও তথ্য বা পরামর্শকে ত্যাগ করার বিষয়ে আপনার দৃ strongly়তার সাথে বিবেচনা করা উচিত।

— স্টিঞ্জি জ্যাক

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

— ভু

Answer 1

এমন কোনও কিছুই নেই যা মাইক্রোসার্ভেসিস সহ সঞ্চিত পদ্ধতি ব্যবহারের বিরুদ্ধে স্পষ্টভাবে নিষিদ্ধ বা তর্ক করে।

দাবি অস্বীকার: আমি কোনও বিকাশকারীর পিওভির কাছ থেকে সঞ্চিত প্রক্রিয়া পছন্দ করি না তবে এটি কোনওভাবেই মাইক্রোসার্ভেসিসের সাথে সম্পর্কিত নয়।

সঞ্চিত পদ্ধতিগুলি সাধারণত একঘেয়ে ডাটাবেসে কাজ করে।

আমি মনে করি আপনি একটি লজিকাল ভ্রান্তিতে ডুবে যাচ্ছেন।

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

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

মাইক্রোসার্ভিসেসের বেশিরভাগ বই মাইক্রোসার্ভিস প্রতি একটি ডাটাবেসের প্রস্তাব দেয়।

এই ছোট ডাটাবেসগুলিতে স্টোরেজ পদ্ধতি থাকতে পারে না এমন কোনও প্রযুক্তিগত কারণ নেই।

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

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

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

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

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

এটি স্প্রোকস সম্পর্কে সর্বদা আমার প্রধান আকস্মিক বিষয়: ডাটাবেসে ব্যবসায়িক লজিক। এমনকি যখন উদ্দেশ্য নয়, এটি কোনওভাবে সর্বদা সেভাবেই শেষ হয়।

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

Comments

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

— টি। সার - মনিকা পুনরায় ইনস্টল করুন

@ টি.এসআর মডার্ন এর চেয়ে ভাল নয়। রিফ্যাক্টরিং (মাইক্রোসার্ভেসিস বা যাই হোক না কেন) এর অর্থ পরিবর্তন। পরিবর্তন আপনাকে আপনার বর্তমান ধারণাগুলি ব্যবহার করতে বাধ্য করে। আমরা আশা করি তারা ভাল ধারণা।

— candied_orange

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

— ফ্লাটার

"ক্যান্ডিড_আরঙ্গ" "আধুনিক এর চেয়ে ভালো আর নয়" - আমি মনে করি আমি আন্তরিকভাবে তাতে একমত হই। খুব ভাল পয়েন্ট।

— টি। সার -

আধুনিক এমনকি "পর্যাপ্ত" সমার্থক নয় ony

— লাইভ

Answer 2

সফ্টওয়্যারটি লেখার জন্য আপনাকে কোনও প্রযুক্তির সাথে দৃly়ভাবে জুড়ি দেওয়া দরকার।

প্রোগ্রামিং ভাষার দ্বারা সরবরাহ করা রানটাইম পরিবেশের মধ্যে খুব কমপক্ষে within

আরও সাধারণভাবে আপনি দেখতে পাবেন যে আপনার মাইক্রো পরিষেবাটি বেশ কয়েকটি প্রযুক্তির সাথে দৃ tight়ভাবে মিলিত হয়েছে:

• উচ্চ স্তরের HTTP / SSL / SOAP প্রোটোকল বাস্তবায়ন সরবরাহ করার জন্য নেটওয়ার্ক পরিষেবা ফ্রেমওয়ার্ক
• অধ্যবসায় সরবরাহের জন্য সংগ্রহস্থল / ওআরএম / ডিএও ফ্রেমওয়ার্ক।
• ডেটা সহ কাজের জন্য সরঞ্জাম সরবরাহ করতে ডেটা ম্যানিপুলেশন ফ্রেমওয়ার্ক।
• মাল্টি-টাস্কিং, ফাইল সিস্টেম, মেমরি, জিপিইউ কম্পিউট, এক্সপেনশন কার্ড ইত্যাদির মতো ওএস সংস্থানগুলিতে অ্যাক্সেস সরবরাহ করার জন্য প্রক্রিয়া / থ্রেডিং / ওএস ফ্রেমওয়ার্ক ...

এবং এটি একটি খালি-হাড়ের মাইক্রো-পরিষেবা করা।

সঞ্চিত পদ্ধতি

সঞ্চিত পদ্ধতি হ'ল অন্য প্রযুক্তি যা আপনি ব্যবহার বা না ব্যবহার করতে বেছে নিতে পারেন। এটি ম্যাজিকভাবে আপনার কোড একচেটিয়া বা মাইক্রো তৈরি করে না।

যদিও এটি হ'ল:

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

এর প্রত্যেকটিই আসল ব্যয়। কিছু ক্ষেত্রে ব্যয়টি ন্যায়সঙ্গত, অন্যথায় এটি হয় না।

আপনি কোনও স্ক্রিপ্টিং ইঞ্জিনটি হোস্ট করে প্রায় একই সেট ব্যয় প্রদান করবেন। একমাত্র হ্রাস হ'ল আপনি হোস্ট ভাষা হিসাবে একই প্রোগ্রামিং দৃষ্টান্ত চয়ন করতে পারেন।

ব্যবসায় যুক্তি

ব্যবসায়ের নিয়মগুলিকে ডাটাবেসে স্থানান্তরিত করা খারাপ অভ্যাস। সঞ্চিত পদ্ধতিগুলির কারণে নয়।

এটি একটি খারাপ অনুশীলন, কারণ ডেটাবেস এবং ব্যবসার যুক্তি বিভিন্ন শিয়ারিং স্তরে কাজ করে।

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

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

ব্যবসায়ের যুক্তি যদি শিয়ারিং স্তরগুলি জুড়ে বিতরণ করা হয়, বিশেষত একটি ধীর এবং দীর্ঘস্থায়ী স্তরগুলিতে, এটি পরিবর্তনের প্রতিরোধ তৈরি করবে। এই অগত্যা একটি খারাপ জিনিস নয়। সর্বোপরি, এটিতে শূন্য ব্যবসায়িক যুক্তিযুক্ত একমাত্র ডাটাবেস হ'ল একটি ট্রিপল স্টোর।

একটি টেবিল স্কিমা নির্দিষ্ট করার নিছক কাজটি ব্যবসায়িক লজিককে ডাটাবেসে সরিয়ে নিয়েছে।

স্থাপত্য

সমাধান তৈরি এবং বজায় রাখতে খুব বেশি সরঞ্জামের প্রয়োজন না হওয়া বা সমাধান করা খুব কঠিন করে না রেখে আপনি উপযুক্ত সমস্যার জন্য উপযুক্ত সরঞ্জামটি ব্যবহার করে বিতর্ক করছেন।

এটি সহজ নয়।

তবে আসুন ভাবা যায় না, আপনি কীভাবে বেশ কয়েকটি ভাষায় বিতরণ করা ব্যবসায়িক যুক্তি বজায় রাখবেন?

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

তবে এটির একটি ব্যয়ও রয়েছে।

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

Answer 3

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

সুতরাং সংক্ষিপ্ত উত্তরটি হ'ল, না, সঞ্চিত পদ্ধতিগুলি কোনও মাইক্রোসারওয়াস আর্কিটেকচারে অন্তর্নিহিত খারাপ নয়। তবে আপনার বুঝতে হবে:

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

এগুলি সঞ্চিত পদ্ধতির কয়েকটি ব্যবহার যা আমার মনে হয় প্রায়শই সার্থক:

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

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

যেহেতু আপনাকে ইতিমধ্যে কিছু স্বয়ংক্রিয় সরঞ্জামের মাধ্যমে আপনার ডাটাবেস সংস্থানগুলি (স্কিমা, অনুমতি ইত্যাদি) পরিচালনা করা উচিত, তাই না, সঞ্চিত প্রক্রিয়াগুলি মাইক্রোসার্চেসিসের জন্য সহজাত খারাপ নয় bad

Comments

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

— ফ্যালকো

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

— ngreen

Answer 4

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

মাইক্রোসার্ভিসেসের বেশিরভাগ বই মাইক্রোসার্ভিস প্রতি একটি ডাটাবেসের প্রস্তাব দেয়।

ঠিক আছে, সুতরাং আমরা এই ডাটাবেসগুলিতে সঞ্চিত পদ্ধতি কোড করতে পারি।

আবার বেশিরভাগ মাইক্রোসার্ভাইস আর্কিটেকচার বইতে বলা হয়েছে যে সেগুলি স্বায়ত্তশাসিত এবং আলগাভাবে মিলিত হওয়া উচিত

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

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

লিখিত সঞ্চিত পদ্ধতি ব্যবহার করে বিশেষত ওরাকলে বলুন, সেই প্রযুক্তিতে মাইক্রোসার্চিসকে শক্তভাবে দম্পত্তি করুন।

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

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

বেশিরভাগ এমএসএ বই (যা আমি পড়েছি) এটি সুপারিশ করে যে মাইক্রোসার্ভেসিসগুলি ব্যবসায়িক ভিত্তিক হওয়া উচিত (ডিডিডি ব্যবহার করে ডিজাইন করা)।

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

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

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

Answer 5

মাইক্রোসার্চেসিসের সাথে এর আসলে কোনও সম্পর্ক নেই।

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

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

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

মাইক্রোসার্ভেসিসের সাথে সম্পর্কটি কেবল মাইক্রোসার্ফেসিস নতুন এবং আরোহী - আমরা আর মনোলিথ করি না - এবং এই নতুন স্থাপত্য শৈলীগুলিও আরোহী - আমরা আর ফ্ল্যাট স্তরগুলি করি না।