মাইক্রোসার্ভিস: তারা কি, কেন তারা এবং কখন তাদের বাস্তবায়ন করতে হবে

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

কনওয়ের আইন এবং ব্যবসা, সংস্থা এবং তথ্য ব্যবস্থার মধ্যে সম্পর্ক

আবারও আমি নিজেকে উদ্ধৃত করার অনুমতি দেব:

"যে কোনও সংস্থা যে একটি সিস্টেম ডিজাইন করে (বিস্তৃত অর্থে) এমন একটি নকশা পাবে যার কাঠামো সেই সংস্থার দলগুলির কাঠামোর প্রতিলিপি করে।"
— মেলভিন কনওয়ে, 1967

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

তথ্য সিস্টেমের ব্যবসা অভিযোজন

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

সবকিছু প্রবাহিত হয়, সবকিছু পরিবর্তিত হয়, নাকি মাইক্রোসার্ভিসগুলি জটিলতা মোকাবেলার একটি উপায়?

আমরা চালিয়ে যাওয়ার আগে, আসুন মাইক্রোসার্ভিস আর্কিটেকচার সম্পর্কে কিছু ভুল ধারণা দেখি।

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

একটি ভিন্নধর্মী স্ট্যাক ব্যবহার করার সুবিধাটিও সন্দেহজনক। আমি তর্ক করব না যে এটিও সম্ভব, তবে বাস্তবে এটি খুব কমই ঘটে (সামনে দেখা - এটি হওয়া উচিত - তবে একটি সুবিধার চেয়ে পরিণতি হিসাবে)।

পণ্য জীবন চক্র এবং সেবা জীবন চক্র

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

আসুন তথ্য সিস্টেমের বিবর্তনের পরবর্তী পর্যায়ে চলে যাই - SOA-এর পরিষেবা-ভিত্তিক আর্কিটেকচারে। সুতরাং, কিছু নির্দিষ্ট সময়ে আমরা আমাদের পণ্য হাইলাইট দীর্ঘজীবী সেবা - দীর্ঘস্থায়ী এই অর্থে যে যখন একটি পণ্যের সংস্করণগুলির মধ্যে স্থানান্তরিত হয়, তখন একটি সুযোগ থাকে যে পরিষেবাটির জীবনচক্র পণ্যের পরবর্তী সংস্করণের জীবনচক্রের চেয়ে দীর্ঘ হবে৷ তাদের একেবারে পরিবর্তন না করাই যৌক্তিক হবে - আমরা যা গুরুত্বপূর্ণ তা হল পরবর্তী সংস্করণে স্থানান্তরের গতি. কিন্তু হায়, আমরা পরিষেবাগুলিতে ক্রমাগত পরিবর্তন করতে বাধ্য হচ্ছি - এবং এখানে সবকিছুই আমাদের জন্য কাজ করে, DevOps অনুশীলন, কন্টেইনারাইজেশন এবং আরও অনেক কিছু - যা মনে আসে। কিন্তু এগুলো এখনো মাইক্রোসার্ভিস নয়!

জটিলতা মোকাবেলায় মাইক্রোসার্ভিসেস... কনফিগারেশন ম্যানেজমেন্ট

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

তথ্যও

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

উত্স: www.habr.com