এনডিসি লন্ডন সম্মেলন। মাইক্রোসার্ভিস বিপর্যয় প্রতিরোধ করা। অংশ 1

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

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

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

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

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

প্রাথমিক নকশাটি বেশ সুন্দর লাগছিল এবং এতে একটি শীর্ষ-স্তরের সাইট bell.com এবং স্বতন্ত্র অ্যাপ্লিকেশনের জন্য বেশ কয়েকটি সাবডোমেন রয়েছে: catalog.bell.com, accounts.bell.com, orders.bell.com, পণ্য অনুসন্ধান search.bell। com. প্রতিটি সাবডোমেন ASP.Net 1.0 ফ্রেমওয়ার্ক এবং এর নিজস্ব ডাটাবেস ব্যবহার করে এবং তারা সবাই সিস্টেম ব্যাকএন্ডের সাথে কথা বলে। যাইহোক, সমস্ত আদেশ একটি একক বিশাল মেইনফ্রেমের মধ্যে প্রক্রিয়া করা এবং কার্যকর করা অব্যাহত ছিল, যেখানে সমস্ত আবর্জনা রয়ে গেছে, তবে সামনের প্রান্তটি ছিল পৃথক অ্যাপ্লিকেশন এবং পৃথক ডেটাবেস সহ পৃথক ওয়েবসাইট।

সুতরাং সিস্টেমের নকশাটি সুশৃঙ্খল এবং যৌক্তিক লাগছিল, কিন্তু প্রকৃত সিস্টেমটি পরবর্তী স্লাইডে দেখানো হয়েছে।

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

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

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

বিদ্যমান অ্যাপ্লিকেশনটি 15 বছর ধরে উৎপাদনে ছিল, যা ASP.Net-ভিত্তিক অ্যাপ্লিকেশনগুলির জন্য একটি রেকর্ড। পরিষেবাটি সারা বিশ্ব থেকে অর্ডার গ্রহণ করেছে এবং এই একক অ্যাপ্লিকেশন থেকে বার্ষিক আয় এক বিলিয়ন ডলারে পৌঁছেছে। লাভের একটি উল্লেখযোগ্য অংশ bell.com ওয়েবসাইট দ্বারা উত্পন্ন হয়েছিল। ব্ল্যাক ফ্রাইডে, সাইটের মাধ্যমে দেওয়া অর্ডারের সংখ্যা কয়েক মিলিয়নে পৌঁছেছে। যাইহোক, বিদ্যমান স্থাপত্যটি কোন উন্নয়নের অনুমতি দেয়নি, যেহেতু সিস্টেম উপাদানগুলির কঠোর আন্তঃসংযোগ কার্যত পরিষেবাতে কোনও পরিবর্তন করার অনুমতি দেয়নি।

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

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

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

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

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

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

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

এই চিত্রের সবুজ রঙটি একটি অর্ধবৃত্ত দেখায় যেখানে পরিষেবাগুলি একে অপরকে কল করে - পরিষেবা A কল পরিষেবা B, পরিষেবা B পরিষেবা C কল করে এবং এটি আবার পরিষেবা Aকে কল করে৷ ফলস্বরূপ, আমরা একটি "ডিস্ট্রিবিউটেড ডেডলক" পাই৷ একটি একক অনুরোধ এক হাজার নেটওয়ার্ক API কল তৈরি করেছে, এবং যেহেতু সিস্টেমে বিল্ট-ইন ফল্ট টলারেন্স এবং লুপ সুরক্ষা নেই, তাই এই API কলগুলির একটিও ব্যর্থ হলে অনুরোধটি ব্যর্থ হবে।

আমরা কিছু গণিত করেছি। প্রতিটি API কলের SLA ছিল 150 ms এর বেশি এবং 99,9% আপটাইম। একটি অনুরোধের ফলে 200টি ভিন্ন কল হয়েছে এবং সবচেয়ে ভালো ক্ষেত্রে, পৃষ্ঠাটি 200 x 150 ms = 30 সেকেন্ডে দেখানো হতে পারে। স্বাভাবিকভাবেই, এটি ভাল ছিল না। 99,9% আপটাইমকে 200 দ্বারা গুণ করে, আমরা 0% উপলব্ধতা পেয়েছি। দেখা যাচ্ছে যে এই স্থাপত্যটি প্রথম থেকেই ব্যর্থতার জন্য ধ্বংস হয়ে গিয়েছিল।

আমরা ডেভেলপারদের জিজ্ঞাসা করেছি কিভাবে তারা 18 মাস কাজ করার পরে এই সমস্যাটি চিনতে ব্যর্থ হয়েছে? দেখা গেল যে তারা যে কোডটি চালায় তার জন্য তারা শুধুমাত্র SLA গণনা করেছে, কিন্তু যদি তাদের পরিষেবা অন্য পরিষেবায় কল করে, তারা তাদের SLA-তে সেই সময় গণনা করে না। একটি প্রক্রিয়ার মধ্যে যে সমস্ত কিছু চালু করা হয়েছিল তা 150 ms এর মান মেনে চলে, কিন্তু অন্যান্য পরিষেবা প্রক্রিয়াগুলিতে অ্যাক্সেস মোট বিলম্বকে বহুগুণ বাড়িয়ে দিয়েছে। শিখে নেওয়া প্রথম পাঠটি ছিল: "আপনি কি আপনার SLA নিয়ন্ত্রণে আছেন, নাকি SLA আপনার নিয়ন্ত্রণে আছে?" আমাদের ক্ষেত্রে, এটি পরবর্তী ছিল।

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

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

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

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

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

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

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

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

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

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

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

চলুন দেখি সেবা বলতে কি বুঝায়। একটি পরিষেবা সংজ্ঞার 6টি বৈশিষ্ট্যযুক্ত বৈশিষ্ট্য রয়েছে - এটি এমন সফ্টওয়্যার যা:

• একটি নির্দিষ্ট সংস্থা দ্বারা তৈরি এবং ব্যবহৃত;
• সিস্টেমের মধ্যে একটি নির্দিষ্ট ধরনের তথ্যের বিষয়বস্তু, প্রক্রিয়াকরণ এবং/অথবা বিধানের জন্য দায়ী;
• নির্দিষ্ট অপারেশনাল প্রয়োজন মেটাতে স্বাধীনভাবে নির্মিত, স্থাপন করা এবং চালানো যেতে পারে;
• ভোক্তা এবং অন্যান্য পরিষেবার সাথে যোগাযোগ করে, চুক্তি বা চুক্তিভিত্তিক গ্যারান্টির উপর ভিত্তি করে তথ্য প্রদান করে;
• অননুমোদিত অ্যাক্সেস থেকে নিজেকে রক্ষা করে, এবং ক্ষতি থেকে তার তথ্য;
• ব্যর্থতাগুলিকে এমনভাবে পরিচালনা করে যাতে তারা তথ্যের ক্ষতি না করে।

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

এখন মাইক্রোসার্ভিসের সংজ্ঞা দেখি:

• একটি মাইক্রোসার্ভিস আকারে ছোট এবং একটি নির্দিষ্ট সমস্যা সমাধানের জন্য ডিজাইন করা হয়;
• মাইক্রোসার্ভিস স্বায়ত্তশাসিত;
• একটি মাইক্রোসার্ভিস আর্কিটেকচার তৈরি করার সময়, শহর পরিকল্পনা রূপক ব্যবহার করা হয়। এটি স্যাম নিউম্যানের বই, বিল্ডিং মাইক্রোসার্ভিসেস থেকে সংজ্ঞা।

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

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

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

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

তাই আমরা বেল কম্পিউটারের ছেলেদের বলেছিলাম, “আপনারা যে বিশৃঙ্খলা তৈরি করেছেন তার কোনোটিই আমরা ঠিক করতে পারব না কারণ এটি করার জন্য আপনার কাছে টাকা নেই, কিন্তু আমরা শুধুমাত্র একটি পরিষেবা ঠিক করব যাতে এটি সব করা যায়। অনুভূতি." এই মুহুর্তে, আমি আপনাকে বলার মাধ্যমে শুরু করব কিভাবে আমরা আমাদের একমাত্র পরিষেবাটি ঠিক করেছি যাতে এটি 9 এবং দেড় মিনিটের চেয়ে দ্রুত অনুরোধে সাড়া দেয়।

22:30 মিনিট

খুব শীঘ্রই চালিয়ে যেতে হবে...

কিছু বিজ্ঞাপন

আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com