ডোডো আইএস আর্কিটেকচারের ইতিহাস: একটি প্রাথমিক মনোলিথ

অথবা একটি মনোলিথ সহ প্রতিটি অসুখী কোম্পানি তার নিজস্ব উপায়ে অসুখী।

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

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

প্রবন্ধের সিরিজ "ডোডো আইএস কি?" সম্পর্কে বলে:

1. ডোডো আইএস (2011-2015) এর প্রারম্ভিক মনোলিথ। (তুমি এখানে)

2. পিছনের অফিসের পথ: পৃথক ঘাঁটি এবং বাস.

3. ক্লায়েন্ট সাইড পাথ: বেসের উপর সম্মুখভাগ (2016-2017)। (চলমান...)

4. সত্যিকারের মাইক্রোসার্ভিসের ইতিহাস। (2018-2019)। (চলমান...)

5. মনোলিথের করাত এবং স্থাপত্যের স্থায়িত্ব সমাপ্ত। (চলমান…)

প্রাথমিক স্থাপত্য

2011 সালে, ডোডো আইএস আর্কিটেকচারটি এইরকম ছিল:

আর্কিটেকচারের প্রথম মডিউল হল অর্ডার গ্রহণযোগ্যতা। ব্যবসা প্রক্রিয়া ছিল:

• ক্লায়েন্ট পিজারিয়া কল;

• ম্যানেজার ফোন তুলে নেয়;

• ফোনের মাধ্যমে একটি অর্ডার গ্রহণ করে;

• অর্ডার গ্রহণযোগ্যতা ইন্টারফেসে সমান্তরালভাবে এটি পূরণ করে: এটি ক্লায়েন্ট সম্পর্কে তথ্য, অর্ডারের বিশদ তথ্য, বিতরণ ঠিকানা বিবেচনা করে। 

ইনফরমেশন সিস্টেমের ইন্টারফেসটি দেখতে এরকম কিছু ছিল ...

অক্টোবর 2011 থেকে প্রথম সংস্করণ:

জানুয়ারী 2012 এ কিছুটা উন্নতি হয়েছে

ডোডো পিজ্জা ইনফরমেশন সিস্টেম ডেলিভারি পিজা রেস্টুরেন্ট

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

তাদের প্রথম সিদ্ধান্ত প্রযুক্তি স্ট্যাকের ভাগ্য নির্ধারণ করে:

• ASP.NET MVC, C# ভাষার ব্যাকএন্ড। বিকাশকারীরা ডটনেটচিকি ছিল, এই স্ট্যাকটি তাদের কাছে পরিচিত এবং আনন্দদায়ক ছিল।

• বুটস্ট্র্যাপ এবং JQuery-এ ফ্রন্টএন্ড: স্ব-লিখিত শৈলী এবং স্ক্রিপ্টগুলিতে ব্যবহারকারী ইন্টারফেস। 

• মাইএসকিউএল ডাটাবেস: লাইসেন্স খরচ নেই, ব্যবহার করা সহজ।

• উইন্ডোজ সার্ভারে সার্ভার, কারণ .NET তখন শুধুমাত্র উইন্ডোজের অধীনে থাকতে পারে (আমরা মনো নিয়ে আলোচনা করব না)।

শারীরিকভাবে, এই সমস্ত "হোস্টারে উত্সর্গীকৃত" তে প্রকাশ করা হয়েছিল। 

অর্ডার ইনটেক অ্যাপ্লিকেশন আর্কিটেকচার

তারপরে সবাই ইতিমধ্যে মাইক্রোসার্ভিসেস সম্পর্কে কথা বলছিল, এবং SOA 5 বছর ধরে বড় প্রকল্পগুলিতে ব্যবহৃত হয়েছিল, উদাহরণস্বরূপ, WCF 2006 সালে প্রকাশিত হয়েছিল। কিন্তু তারপর তারা একটি নির্ভরযোগ্য এবং প্রমাণিত সমাধান বেছে নিয়েছে।

এটা এখানে.

Asp.Net MVC হল রেজার, যা একটি ফর্ম বা ক্লায়েন্টের অনুরোধে সার্ভার রেন্ডারিং সহ একটি HTML পৃষ্ঠা রেন্ডার করে। ক্লায়েন্টে, CSS এবং JS স্ক্রিপ্টগুলি ইতিমধ্যেই তথ্য প্রদর্শন করে এবং প্রয়োজনে JQuery এর মাধ্যমে AJAX অনুরোধগুলি সম্পাদন করে।

সার্ভারে অনুরোধগুলি *কন্ট্রোলার ক্লাসে শেষ হয়, যেখানে চূড়ান্ত HTML পৃষ্ঠার প্রক্রিয়াকরণ এবং প্রজন্ম পদ্ধতিতে সঞ্চালিত হয়। কন্ট্রোলাররা *পরিষেবা নামক যুক্তির একটি স্তরে অনুরোধ করে। প্রতিটি পরিষেবা ব্যবসার কিছু দিক থেকে সঙ্গতিপূর্ণ:

• উদাহরণস্বরূপ, ডিপার্টমেন্ট স্ট্রাকচার সার্ভিস পিজারিয়াস, বিভাগগুলির উপর তথ্য দিয়েছে। একটি বিভাগ হল একটি একক ফ্র্যাঞ্চাইজি দ্বারা পরিচালিত পিজারিয়ার একটি গ্রুপ।

• ReceivingOrdersService গৃহীত হয়েছে এবং অর্ডারের গঠন গণনা করেছে।

• এবং SmsService এসএমএস পাঠানোর জন্য API পরিষেবাগুলিতে কল করে এসএমএস পাঠিয়েছে।

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

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

এই সমস্ত একটি মডেল দ্বারা প্রতিনিধিত্ব করা যেতে পারে:

অর্ডার ওয়ে

এই ধরনের একটি অর্ডার তৈরি করার জন্য একটি সরলীকৃত প্রাথমিক উপায় বিবেচনা করুন।

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

• ক্লায়েন্ট দাম সহ একটি স্ট্যাটিক সাইট পরিদর্শন করে, পণ্য নির্বাচন করে এবং সাইটে তালিকাভুক্ত নম্বরে কল করে।

• গ্রাহক যে পণ্যগুলি অর্ডারে যুক্ত করতে চান তার নাম দেন।

• তার ঠিকানা ও নাম দেন।

• অপারেটর অর্ডার গ্রহণ করে।

• অর্ডারটি গৃহীত অর্ডার ইন্টারফেসে প্রদর্শিত হয়।

এটি সব মেনু প্রদর্শন সঙ্গে শুরু হয়. একটি লগ-ইন ব্যবহারকারী-অপারেটর একবারে শুধুমাত্র একটি অর্ডার গ্রহণ করে। অতএব, ড্রাফ্ট কার্টটি তার সেশনে সংরক্ষণ করা যেতে পারে (ব্যবহারকারীর সেশন মেমরিতে সংরক্ষণ করা হয়)। পণ্য এবং গ্রাহকের তথ্য ধারণকারী একটি কার্ট বস্তু আছে.

গ্রাহক পণ্যটির নাম দেয়, অপারেটর ক্লিক করে + পণ্যের পাশে, এবং সার্ভারে একটি অনুরোধ পাঠানো হয়। পণ্য সম্পর্কিত তথ্য ডাটাবেস থেকে বের করা হয় এবং পণ্য সম্পর্কে তথ্য কার্টে যোগ করা হয়।

মন্তব্য. হ্যাঁ, এখানে আপনি ডাটাবেস থেকে পণ্য টানতে পারবেন না, তবে ফ্রন্টএন্ড থেকে স্থানান্তর করতে পারবেন। কিন্তু স্পষ্টতার জন্য, আমি ডাটাবেস থেকে ঠিক পথ দেখিয়েছি। 

এরপরে, ক্লায়েন্টের ঠিকানা এবং নাম লিখুন। 

আপনি যখন "অর্ডার তৈরি করুন" ক্লিক করুন:

• অনুরোধটি OrderController.SaveOrder() এ পাঠানো হয়েছে।

• আমরা সেশন থেকে কার্ট পাই, আমাদের প্রয়োজনীয় পরিমাণে পণ্য রয়েছে।

• আমরা ক্লায়েন্ট সম্পর্কে তথ্য সহ কার্টটি পরিপূরক করি এবং এটিকে রিসিভিংঅর্ডার সার্ভিস ক্লাসের AddOrder পদ্ধতিতে প্রেরণ করি, যেখানে এটি ডাটাবেসে সংরক্ষিত হয়। 

• ডাটাবেসে অর্ডার, অর্ডারের কম্পোজিশন, ক্লায়েন্ট সহ টেবিল রয়েছে এবং সেগুলি সবই সংযুক্ত।

• অর্ডার ডিসপ্লে ইন্টারফেস যায় এবং সর্বশেষ অর্ডারগুলি বের করে এবং সেগুলি প্রদর্শন করে।

নতুন মডিউল

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

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

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

প্রযুক্তিগতভাবে, মডিউলগুলিকে এলাকা হিসাবে ডিজাইন করা হয়েছিল (এরকম একটি ধারণা রয়ে গেছে asp.net কোর) ফ্রন্টএন্ড, মডেলের পাশাপাশি তাদের নিজস্ব কন্ট্রোলার ক্লাসের জন্য আলাদা ফাইল ছিল। ফলস্বরূপ, সিস্টেমটি এখান থেকে রূপান্তরিত হয়েছিল ...

...এর মধ্যে:

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

• সাইট - প্রথম সংস্করণ সাইট dodopizza.ru.

• রপ্তানি: 1C এর জন্য Dodo IS থেকে রিপোর্ট আপলোড করা হচ্ছে। 

• ব্যক্তিগত - কর্মচারীর ব্যক্তিগত অ্যাকাউন্ট। এটি আলাদাভাবে তৈরি করা হয়েছে এবং এর নিজস্ব এন্ট্রি পয়েন্ট এবং আলাদা ডিজাইন রয়েছে।

• fs - হোস্টিং স্ট্যাটিক্সের জন্য একটি প্রকল্প। পরে আমরা এটি থেকে দূরে সরে গেছি, সমস্ত স্ট্যাটিক্সকে আকমাই সিডিএন-এ সরিয়ে নিয়েছি। 

বাকি ব্লকগুলি ব্যাকঅফিস অ্যাপ্লিকেশনে ছিল। 

নামের ব্যাখ্যা:

• ক্যাশিয়ার - রেস্টুরেন্ট ক্যাশিয়ার।

• ShiftManager - "Shift Manager" ভূমিকার জন্য ইন্টারফেস: pizzeria বিক্রয়ের অপারেশনাল পরিসংখ্যান, পণ্যগুলিকে স্টপ লিস্টে রাখার ক্ষমতা, অর্ডার পরিবর্তন করুন।

• অফিস ম্যানেজার - "পিজারিয়া ম্যানেজার" এবং "ফ্রাঞ্চাইজি" ভূমিকার জন্য ইন্টারফেস। এখানে একটি পিজারিয়া সেট আপ করার জন্য সংগৃহীত ফাংশন, এর বোনাস প্রচার, কর্মীদের সাথে প্রাপ্তি এবং কাজ করা, রিপোর্ট।

• পাবলিক স্ক্রিন - পিজারিয়াতে ঝুলন্ত টিভি এবং ট্যাবলেটগুলির জন্য ইন্টারফেস৷ টিভিগুলি মেনু, বিজ্ঞাপনের তথ্য, বিতরণের সময় অর্ডারের স্থিতি প্রদর্শন করে। 

তারা একটি সাধারণ পরিষেবা স্তর, একটি সাধারণ Dodo.Core ডোমেইন ক্লাস ব্লক এবং একটি সাধারণ বেস ব্যবহার করেছে৷ কখনও কখনও তারা এখনও একে অপরের রূপান্তর বরাবর নেতৃত্ব দিতে পারে। পৃথক সাইটগুলি সহ, যেমন dodopizza.ru বা personal.dodopizza.ru, সাধারণ পরিষেবাগুলিতে গিয়েছিল৷

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

সিস্টেমে তৈরি মডিউলগুলির স্কেল সম্পর্কে আরও ভালভাবে বোঝার জন্য, এখানে উন্নয়ন পরিকল্পনা সহ 2012 এর একটি চিত্র রয়েছে:

2015 সাল নাগাদ, সবকিছুই মানচিত্রে ছিল এবং আরও বেশি কিছু উৎপাদনে ছিল।

• অর্ডার গ্রহণযোগ্যতা যোগাযোগ কেন্দ্রের একটি পৃথক ব্লকে পরিণত হয়েছে, যেখানে অপারেটর অর্ডারটি গ্রহণ করে।

• মেনু এবং তথ্য সহ পাবলিক স্ক্রীন ছিল pizzerias ঝুলন্ত.

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

• ডেলিভারি ইউনিটটি একটি পৃথক ডেলিভারি চেকআউটে পরিণত হয়েছে, যেখানে কুরিয়ারকে আদেশ জারি করা হয়েছিল যারা আগে শিফট নিয়েছিল। বেতন গণনার জন্য তার কাজের সময় বিবেচনা করা হয়েছিল। 

সমান্তরালভাবে, 2012 থেকে 2015 পর্যন্ত, 10 টিরও বেশি বিকাশকারী উপস্থিত হয়েছিল, 35টি পিজারিয়া খোলা হয়েছিল, সিস্টেমটি রোমানিয়াতে স্থাপন করেছিল এবং মার্কিন যুক্তরাষ্ট্রে আউটলেট খোলার জন্য প্রস্তুত হয়েছিল। বিকাশকারীরা আর সমস্ত কাজ নিয়ে কাজ করেনি, তবে দলে বিভক্ত ছিল। প্রতিটি সিস্টেমের নিজস্ব অংশে বিশেষ। 

সমস্যার

স্থাপত্যের কারণে সহ (তবে কেবল নয়)।

গোড়ায় বিশৃঙ্খলা

এক বেস সুবিধাজনক. সামঞ্জস্যতা অর্জন করা যেতে পারে এটিতে, এবং রিলেশনাল ডাটাবেসে তৈরি সরঞ্জামের খরচে। এটির সাথে কাজ করা পরিচিত এবং সুবিধাজনক, বিশেষত যদি কয়েকটি টেবিল এবং সামান্য ডেটা থাকে।

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

অনেক টেবিলের উপযুক্ত সূচক ছিল না, কোথাও, বিপরীতভাবে, অনেকগুলি সূচক ছিল, যা সন্নিবেশ করা কঠিন করে তুলেছিল। এটি প্রায় 20টি টেবিল পরিবর্তন করার প্রয়োজন ছিল - একটি অর্ডার তৈরি করতে লেনদেন প্রায় 3-5 সেকেন্ড সময় নিতে পারে। 

টেবিলের ডেটা সবসময় সবচেয়ে উপযুক্ত আকারে ছিল না. কোথাও ডিনরমালাইজেশন করা দরকার ছিল। নিয়মিত প্রাপ্ত ডেটার একটি অংশ XML কাঠামোর আকারে একটি কলামে ছিল, এটি কার্যকর করার সময় বাড়িয়েছে, প্রশ্নগুলিকে দীর্ঘায়িত করেছে এবং বিকাশকে জটিল করেছে।

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

তথ্য একত্রিত করা হয়নি এবং অনেক গণনা বেস ব্যবহার করে উড়ে সঞ্চালিত হয়েছে. এটি অপ্রয়োজনীয় গণনা এবং অতিরিক্ত লোড তৈরি করেছে। 

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

কোডে সমন্বয় এবং অস্পষ্টতা

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

পরিষেবাগুলি (একটি একচেটিয়া বড় প্রকল্পের মধ্যে ক্লাস) তাদের ডেটা সমৃদ্ধ করতে একে অপরকে কল করতে পারে।

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

যুক্তিটি হয় নিয়ন্ত্রকদের মধ্যে বা পরিষেবা ক্লাসে ছিল। 

এগুলিকে ছোটখাটো সমস্যা বলে মনে হয়, কিন্তু এগুলি বিকাশকে ধীর করে দেয় এবং গুণমান হ্রাস করে, যার ফলে অস্থিরতা এবং বাগগুলি দেখা দেয়৷ 

একটি বড় উন্নয়ন জটিলতা

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

সিস্টেমের কিছু অংশে, এর জন্য আরও উপযুক্ত ডাটাবেস ব্যবহার করা যেতে পারে।. উদাহরণস্বরূপ, পরবর্তীতে আমাদের কাছে একটি অর্ডার বাস্কেট সংরক্ষণ করতে Redis থেকে CosmosDB-তে যাওয়ার ব্যবহার ছিল। 

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

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

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

কিভাবে মনের শক্তি ব্লগ রেস্টুরেন্টে নগদ রেজিস্টার রাখা

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

ব্লগে "মনের শক্তি” একটি উইজেট ছিল যা পুরো নেটওয়ার্কের বছরের জন্য আয়ের ডেটা দেখায়৷ উইজেটটি Dodo পাবলিক API অ্যাক্সেস করেছে, যা এই ডেটা প্রদান করে। এই পরিসংখ্যান বর্তমানে পাওয়া যায় http://dodopizzastory.com/. উইজেটটি প্রতিটি পৃষ্ঠায় দেখানো হয়েছিল এবং প্রতি 20 সেকেন্ডে একটি টাইমারে অনুরোধ করা হয়েছিল। অনুরোধটি api.dodopizza.ru এ গিয়ে অনুরোধ করেছে:

• নেটওয়ার্কে pizzerias সংখ্যা;

• বছরের শুরু থেকে মোট নেটওয়ার্ক রাজস্ব;

• আজকের জন্য রাজস্ব।

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

রেস্তোঁরাগুলিতে নগদ ডেস্কগুলি অর্ডারের একই টেবিলে গিয়েছিল, আজকের জন্য প্রাপ্ত অর্ডারগুলির একটি তালিকা আনলোড করেছে এবং এতে নতুন অর্ডার যুক্ত করা হয়েছে। ক্যাশ রেজিস্টার প্রতি 5 সেকেন্ডে বা পৃষ্ঠা রিফ্রেশ করে তাদের অনুরোধ করে।

চিত্রটি দেখতে এইরকম ছিল:

এক পড়ে, Fyodor Ovchinnikov তার ব্লগে একটি দীর্ঘ এবং জনপ্রিয় নিবন্ধ লিখেছেন। অনেক লোক ব্লগে এসে মনোযোগ দিয়ে সবকিছু পড়তে শুরু করল। যারা এসেছেন তাদের প্রত্যেকে নিবন্ধটি পড়ার সময়, রাজস্ব উইজেটটি সঠিকভাবে কাজ করেছে এবং প্রতি 20 সেকেন্ডে API-এর অনুরোধ করেছে।

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

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

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

দ্রুত ব্যবসা বৃদ্ধি

কেন তা এখনই করা গেল না? শুধু নিম্নলিখিত চার্ট তাকান.

এছাড়াও 2014-2015 সালে রোমানিয়াতে একটি উদ্বোধন ছিল এবং মার্কিন যুক্তরাষ্ট্রে একটি উদ্বোধন প্রস্তুত করা হচ্ছে।

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

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

সাহায্য করেছে যে দ্রুত সমাধান

সমস্যার সমাধান প্রয়োজন। প্রচলিতভাবে, সমাধান 2 গ্রুপে বিভক্ত করা যেতে পারে:

• দ্রুত যারা আগুন নিভিয়ে দেয় এবং নিরাপত্তার একটি ছোট মার্জিন দেয় এবং আমাদের পরিবর্তন করার জন্য সময় দেয়।

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

দ্রুত পরিবর্তনের শুষ্ক তালিকা নিম্নরূপ:

স্কেল আপ বেস মাস্টার

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

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

পড়ার জন্য বেস প্রতিলিপি

বেসের জন্য দুটি প্রতিলিপি তৈরি করা হয়েছিল:

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

প্রতিবেদনের অনুরোধের জন্য প্রতিলিপি পড়ুন. এই ডাটাবেসের প্রাপ্যতা কম ছিল, কিন্তু সমস্ত রিপোর্ট এটিতে গিয়েছিল। তাদের বিশাল ডেটা পুনঃগণনার জন্য ভারী অনুরোধ থাকতে দিন, কিন্তু তারা প্রধান ডাটাবেস এবং অপারেশনাল ইন্টারফেসগুলিকে প্রভাবিত করে না। 

কোড ক্যাশে

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

একাধিক ব্যাকএন্ড সার্ভার

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

ফলস্বরূপ, স্থাপত্য আরও জটিল হয়ে উঠেছে ...

…কিন্তু কিছুটা উত্তেজনা দূর হল।

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

উত্স: www.habr.com