মাইক্রোসার্ভেসিস: মনোলিথ ফার্স্ট?


9

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

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

বিশেষত একটি বিষয় হ'ল:

আমি যখন মাইক্রোসার্ফেস আর্কিটেকচার ব্যবহার করে এমন টিমগুলির গল্প শুনি, তখন আমি একটি সাধারণ প্যাটার্ন লক্ষ্য করেছি।

  • প্রায় সমস্ত সফল মাইক্রোসার্চিস স্টোরি এমন এক মনোলিথ দিয়ে শুরু হয়েছিল যা খুব বড় হয়ে গেছে এবং ভেঙে গিয়েছিল
  • প্রায় সব ক্ষেত্রেই যেখানে আমি এমন একটি সিস্টেম শুনেছি যা প্রথম থেকেই মাইক্রোসার্চিস সিস্টেম হিসাবে নির্মিত হয়েছিল, এটি মারাত্মক সমস্যায় শেষ হয়েছে in

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

(রেফ: https://martinfowler.com/bliki/ MonolithFrst.html - তাদের জোর জোর দেওয়া)

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

বা, উপরের বিবৃতিগুলির বিপরীতে, কোনও দানাদার মাইক্রোসার্ভাইস আর্কিটেকচার দিয়ে স্ক্র্যাচ থেকে কোনও প্রকল্প শুরু করার কোনও আদর্শ আছে কি?

একটি বুদ্ধিমান সাধারণ পদ্ধতির মতো মনে হয় তবে সম্প্রদায়ের চিন্তাগুলি সম্পর্কে আগ্রহী।

উত্তর:


2

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

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

মাইক্রোসার্ভেসিসের সুবিধা হ'ল আপনি চাহিদা অনুসারে কাজটি স্কেল করার জন্য দৃষ্টান্ত যুক্ত করতে পারেন। যদি আপনার কিছু কাজ ফেটে আসে, তবে এটি নিজের মাইক্রোসার্চিসের মধ্যেই এটি আলাদা করে নেওয়া বুদ্ধিমান হতে পারে।

সাধারণভাবে:

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

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

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


13

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


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

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

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

2
এটি একটি ভাল পদ্ধতির। মাইক্রোসার্ভিস করার স্বার্থে একটি মাইক্রোসার্ভিস তৈরি করবেন না। সমস্যাগুলি সমাধানের জন্য মাইক্রোসার্চেস আর্কিটেকচারটি ব্যবহার করা উচিত, তবে সেগুলি তার নিজস্ব সমস্যার একটি সেটও নিয়ে আসে, তাই আপনি যদি এই ট্রেড অফগুলি সম্পর্কে প্রস্তুত / সচেতন না হন তবে আপনার গ্রাউন্ড আপ থেকে মাইক্রোসার্চিস বিকাশ সম্পর্কে সত্যই সতর্ক হওয়া উচিত।
মিথ্যা রায়ান

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

2

আমার মতে, প্রথমে মনোলিথ বিকাশ করা (বা আরও ভাল: আপনার অ্যাপ্লিকেশনটির অংশটি একরঙা হিসাবে বিকাশ করা) উপকারী হতে পারে।

এমন কিছু ক্ষেত্রে রয়েছে যখন আপনি ডোমেন এবং আপনার সমস্যার সীমানা সম্পর্কে নিশ্চিত নন (উদাঃ আমি একটি শিপ ম্যানেজমেন্ট সাইট তৈরি করি, আমার কি একটি জাহাজ পরিষেবা এবং একটি বহর পরিষেবা প্রয়োজন, বা একটি জাহাজের পরিষেবা যথেষ্ট?) এবং এই জাতীয় ক্ষেত্রে একটি একরঙা বিকাশ করা সহজ হতে পারে।

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


1
"এবং এই জাতীয় ক্ষেত্রে মাইক্রোসার্চিস বিকাশ করা সহজতর হতে পারে" - আপনি কি সেখানে মনোলিথগুলি সম্পর্কে কথা বলতে চান ?
আমন

@ এ্যামন আপনাকে ধন্যবাদ, আমি এই বাক্যটি সংশোধন করেছি - আমার পুত্র 34235 বার আমাকে বাধা দিয়েছেন যাতে আমি বিভ্রান্ত হয়েছিলাম;)
খ্রিস্টান সৌর

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

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

1

আমি খুব নিশ্চিত যে এমএফ-র এই নিবন্ধটি সম্পর্কে বেশ কয়েকটি প্রশ্ন রয়েছে।

আমার গ্রহণযোগ্যতা এটি:

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

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

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

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

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


ধন্যবাদ। যদি এমএফ সামান্য পক্ষপাতদুষ্ট হয়ে থাকে, তবে এমন কেউ কি আছেন যার কাজকে আমি বিপরীত দিকে অধ্যয়ন করতে পারি দৃষ্টিকোণের গভীরতা বাড়ানোর জন্য?
jlach

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

0

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

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


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

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

@ রায়ান, কেউ যদি মনে করেন যে মাইক্রোসার্চেস এবং মডিউলাইজেশন সমার্থক হয় তবে তারা বিষয়টি পুরোপুরি মিস করেছেন।
সফটওয়্যার ইঞ্জিনিয়ার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.