ডোডো আইএস আর্কিটেকচারের ইতিহাস: ব্যাক অফিস পাথ

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

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

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

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

1. ডোডো আইএস (2011-2015) এর প্রারম্ভিক মনোলিথ। (চলমান...)
2. পিছনের অফিসের পথ: পৃথক ঘাঁটি এবং বাস। (তুমি এখানে)
3. ক্লায়েন্ট সাইড পাথ: বেসের উপর সম্মুখভাগ (2016-2017)। (চলমান...)
4. সত্যিকারের মাইক্রোসার্ভিসের ইতিহাস। (2018-2019)। (চলমান...)
5. মনোলিথের করাত এবং স্থাপত্যের স্থায়িত্ব সমাপ্ত। (চলমান…)

আপনি যদি অন্য কিছু জানতে আগ্রহী হন - মন্তব্যে লিখুন।

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

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

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

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

2020 সাল নাগাদ, এটি আরও কিছুটা জটিল হয়ে উঠেছে এবং এর মতো হয়েছে:

কিভাবে এই বিবর্তন ঘটেছে? কেন সিস্টেমের বিভিন্ন অংশ প্রয়োজন? কি স্থাপত্য সিদ্ধান্ত নেওয়া হয়েছিল এবং কেন? আসুন এই নিবন্ধের সিরিজে খুঁজে বের করা যাক।

2016 এর প্রথম সমস্যা: কেন পরিষেবাগুলি মনোলিথ ছেড়ে যাবে

চক্রের প্রথম নিবন্ধগুলি সেই পরিষেবাগুলি সম্পর্কে হবে যা মনোলিথ থেকে আলাদা করা প্রথম ছিল৷ আপনাকে প্রসঙ্গে বলতে, আমি আপনাকে বলব যে 2016 এর শুরুতে সিস্টেমে আমাদের কী কী সমস্যা ছিল, যেগুলি আমাদের পরিষেবাগুলির পৃথকীকরণের সাথে মোকাবিলা করতে হয়েছিল।

একটি একক MySql ডাটাবেস, যেখানে ডোডো আইএস-এর সেই সময়ে বিদ্যমান সমস্ত অ্যাপ্লিকেশনগুলি তাদের রেকর্ড লিখেছিল। ফলাফল ছিল:

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

সমস্যাটি ছিল মনোলিথের উপস্থিতি. ফলাফল ছিল:

• একক এবং বিরল রিলিজ.
• বিপুল সংখ্যক মানুষের যৌথ উন্নয়নে অসুবিধা।
• নতুন প্রযুক্তি, নতুন কাঠামো এবং লাইব্রেরি আনতে অক্ষমতা।

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

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

অধ্যায় নেভিগেশন

1. মনোলিথ স্কিম 2016
2. মনোলিথ আনলোড করা শুরু করা: প্রমাণ এবং ট্র্যাকার বিচ্ছেদ
   
3. Auth কি করে?
4. কোথা থেকে লোড হয়?
5. Auth আনলোড করা হচ্ছে
6. ট্র্যাকার কি করে?
7. কোথা থেকে লোড হয়?
8. ট্র্যাকার আনলোড করা হচ্ছে

মনোলিথ স্কিম 2016

এখানে ডোডো আইএস 2016 মনোলিথের প্রধান ব্লকগুলি রয়েছে এবং নীচে তাদের প্রধান কাজগুলির একটি প্রতিলিপি রয়েছে৷

ক্যাশিয়ার ডেলিভারি। কুরিয়ারগুলির জন্য অ্যাকাউন্টিং, কুরিয়ারগুলিতে আদেশ জারি করা।
যোগাযোগ কেন্দ্র. অপারেটরের মাধ্যমে আদেশ গ্রহণ।
সাইট. আমাদের ওয়েবসাইট (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ইত্যাদি)।
প্রমাণীকরণ. ব্যাক অফিসের জন্য অনুমোদন এবং প্রমাণীকরণ পরিষেবা।
যে ব্যক্তি অনুসরণ করে. রান্নাঘরে ট্র্যাকার অর্ডার করুন। একটি অর্ডার প্রস্তুত করার সময় প্রস্তুতির অবস্থা চিহ্নিত করার জন্য পরিষেবা।
রেস্টুরেন্টের ক্যাশ ডেস্ক. একটি রেস্টুরেন্টে অর্ডার নেওয়া, ক্যাশিয়ার ইন্টারফেস।
রপ্তানি. অ্যাকাউন্টিংয়ের জন্য 1C-তে রিপোর্ট আপলোড করা হচ্ছে।
বিজ্ঞপ্তি এবং চালান. রান্নাঘরে ভয়েস কমান্ড (উদাহরণস্বরূপ, "নতুন পিৎজা এসেছে") + কুরিয়ারের জন্য চালান প্রিন্টিং।
স্থানান্তর ম্যানেজার. শিফট ম্যানেজারের কাজের জন্য ইন্টারফেস: আদেশের তালিকা, কর্মক্ষমতা গ্রাফ, শিফটে কর্মচারীদের স্থানান্তর।
অফিস ব্যবস্থাপক. ফ্র্যাঞ্চাইজি এবং ম্যানেজারের কাজের জন্য ইন্টারফেস: কর্মচারীদের অভ্যর্থনা, পিজারিয়ার কাজের প্রতিবেদন।
রেস্টুরেন্ট স্কোরবোর্ড. পিজারিয়ার টিভিতে মেনু প্রদর্শন।
অ্যাডমিন. একটি নির্দিষ্ট পিজারিয়ার সেটিংস: মেনু, দাম, অ্যাকাউন্টিং, প্রচার কোড, প্রচার, ওয়েবসাইট ব্যানার ইত্যাদি।
কর্মচারীর ব্যক্তিগত অ্যাকাউন্ট. কর্মীদের কাজের সময়সূচী, কর্মীদের সম্পর্কে তথ্য।
রান্নাঘর মোটিভেশন বোর্ড. একটি পৃথক পর্দা যা রান্নাঘরে ঝুলে থাকে এবং পিৎজা প্রস্তুতকারকদের গতি প্রদর্শন করে।
যোগাযোগ. এসএমএস এবং ইমেল পাঠানো হচ্ছে।
ফাইল স্টোরেজ. স্ট্যাটিক ফাইল গ্রহণ এবং ইস্যু করার জন্য নিজস্ব পরিষেবা।

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

মনোলিথ আনলোড করা শুরু করা: প্রমাণ এবং ট্র্যাকার বিচ্ছেদ

প্রধান পরিষেবাগুলি যা তখন অন্যদের চেয়ে বেশি ডেটাবেস থেকে রেকর্ড করে এবং পড়ে:

1. প্রমাণ ব্যাক অফিসের জন্য অনুমোদন এবং প্রমাণীকরণ পরিষেবা।
2. ট্র্যাকার। রান্নাঘরে ট্র্যাকার অর্ডার করুন। একটি অর্ডার প্রস্তুত করার সময় প্রস্তুতির অবস্থা চিহ্নিত করার জন্য পরিষেবা।

Auth কি করে?

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

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

কোথা থেকে লোড হয়?

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

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

Auth আনলোড করা হচ্ছে

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

ডব্লিউএএস কাজের মূল পরিকল্পনাটি নিম্নরূপ ছিল:

আমি এটি কিভাবে কাজ করে তা একটু ব্যাখ্যা করতে চাই:

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

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

হয়ে তাই তারা করেছে:

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

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

কেন বিচ্ছেদ এত সময় লাগল?
পথে অনেক সমস্যা ছিল যা আমাদের ধীর করেছিল:

1. আমরা দেশ-নির্দিষ্ট ডাটাবেস থেকে ব্যবহারকারী, ডিভাইস এবং প্রমাণীকরণ ডেটা একটিতে সরাতে চেয়েছিলাম। এটি করার জন্য, আমাদের int শনাক্তকারী থেকে গ্লোবাল UUId শনাক্তকারীতে সমস্ত টেবিল এবং ব্যবহার অনুবাদ করতে হয়েছিল (সম্প্রতি এই কোডটি পুনরায় কাজ করা হয়েছে রোমান বুকিন "উইড - একটি ছোট কাঠামোর একটি বড় গল্প" এবং ওপেন সোর্স প্রকল্প আদিম) ব্যবহারকারীর ডেটা সংরক্ষণ করার (যেহেতু এটি ব্যক্তিগত তথ্য) এর সীমাবদ্ধতা রয়েছে এবং কিছু দেশের জন্য আলাদাভাবে সংরক্ষণ করা প্রয়োজন। কিন্তু ব্যবহারকারীর গ্লোবাল আইডি হতে হবে।
2. ডাটাবেসের অনেক টেবিলে অপারেশনটি সম্পাদনকারী ব্যবহারকারী সম্পর্কে নিরীক্ষার তথ্য রয়েছে। এই ধারাবাহিকতার জন্য একটি অতিরিক্ত প্রক্রিয়া প্রয়োজন.
3. এপিআই-পরিষেবা তৈরির পরে, অন্য সিস্টেমে রূপান্তরের একটি দীর্ঘ এবং ধীরে ধীরে সময় ছিল। স্যুইচিং ব্যবহারকারীদের জন্য নির্বিঘ্ন হতে হবে এবং প্রয়োজনীয় ম্যানুয়াল কাজ করতে হবে।

একটি পিজারিয়াতে ডিভাইস রেজিস্ট্রেশন স্কিম:

প্রমাণ এবং ডিভাইস পরিষেবা নিষ্কাশনের পরে সাধারণ স্থাপত্য:

মন্তব্য. 2020-এর জন্য, আমরা Auth-এর একটি নতুন সংস্করণ নিয়ে কাজ করছি, যা OAuth 2.0 অনুমোদনের মানদণ্ডের উপর ভিত্তি করে তৈরি। এই মানটি বেশ জটিল, তবে এটি একটি পাস-থ্রু প্রমাণীকরণ পরিষেবা বিকাশের জন্য দরকারী। প্রবন্ধে "অনুমোদনের সূক্ষ্মতা: OAuth 2.0 প্রযুক্তির একটি ওভারভিউ» আমরা আলেক্সি চেরনিয়াভ স্ট্যান্ডার্ড সম্পর্কে যতটা সম্ভব সহজ এবং স্পষ্টভাবে বলার চেষ্টা করেছি যাতে আপনি এটি অধ্যয়নের সময় বাঁচাতে পারেন।

ট্র্যাকার কি করে?

এখন লোড সেবা দ্বিতীয় সম্পর্কে. ট্র্যাকার একটি দ্বৈত ভূমিকা পালন করে:

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

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

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

ট্র্যাকার "রাসকাটকা" এর স্টেশনে ট্যাবলেটের স্ক্রিনটি এভাবেই দেখায়

কোথা থেকে লোড হয়?

প্রতিটি পিজারিয়াতে একটি ট্র্যাকার সহ প্রায় পাঁচটি ট্যাবলেট রয়েছে। 2016 সালে, আমাদের 100 টিরও বেশি পিজারিয়া ছিল (এবং এখন 600 টিরও বেশি)। প্রতিটি ট্যাবলেট প্রতি 10 সেকেন্ডে একবার ব্যাকএন্ডে একটি অনুরোধ করে এবং অর্ডার টেবিল থেকে ডেটা স্ক্র্যাপ করে (ক্লায়েন্ট এবং ঠিকানার সাথে সংযোগ), অর্ডার কম্পোজিশন (পণ্যের সাথে সংযোগ এবং পরিমাণের ইঙ্গিত), প্রেরণা অ্যাকাউন্টিং টেবিল ( চাপার সময় এটিতে ট্র্যাক করা হয়)। যখন একজন পিৎজা প্রস্তুতকারক ট্র্যাকারে একটি পণ্যে ক্লিক করেন, তখন এই সমস্ত টেবিলের এন্ট্রি আপডেট হয়। অর্ডার টেবিলটি সাধারণ, এটিতে একটি অর্ডার গ্রহণ করার সময় সন্নিবেশ, সিস্টেমের অন্যান্য অংশ থেকে আপডেট এবং অসংখ্য রিডিং রয়েছে, উদাহরণস্বরূপ, একটি টিভিতে যা একটি পিজারিয়াতে ঝুলে থাকে এবং গ্রাহকদের সমাপ্ত অর্ডার দেখায়।

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

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

ডব্লিউএএস মূল স্থাপত্য ছিল:

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

ট্র্যাকার আনলোড করা হচ্ছে

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

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

অর্ডার স্ট্যাটাস পরিবর্তন করার স্কিমটি এইরকম দেখাচ্ছে:

বিভিন্ন সিস্টেমের মধ্যে স্থিতি পরিবর্তন হয়। এবং এখানে ট্র্যাকার একটি চূড়ান্ত সিস্টেম নয় যেখানে ডেটা বন্ধ রয়েছে। আমরা এই ধরনের ক্ষেত্রে পার্টিশন করার জন্য বেশ কয়েকটি সম্ভাব্য পন্থা দেখেছি:

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

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

ততক্ষণে, আমাদের ইতিমধ্যেই স্ট্যাকের মধ্যে RabbitMQ ছিল, তাই এটি একটি বার্তা ব্রোকার হিসাবে ব্যবহার করার চূড়ান্ত সিদ্ধান্ত। চিত্রটি ট্র্যাকারের মাধ্যমে রেস্তোরাঁর ক্যাশিয়ার থেকে একটি অর্ডারের স্থানান্তর দেখায়, যেখানে এটি তার স্থিতি এবং ম্যানেজারের অর্ডার ইন্টারফেসে তার প্রদর্শন পরিবর্তন করে। হয়ে:

ধাপে ধাপে অর্ডার পাথ
অর্ডার পাথ অর্ডার উৎস পরিষেবাগুলির একটিতে শুরু হয়। এখানে রেস্তোরাঁর ক্যাশিয়ার:

1. চেকআউটে, অর্ডারটি সম্পূর্ণরূপে প্রস্তুত, এবং এটি ট্র্যাকারে পাঠানোর সময়। যে ইভেন্টে ট্র্যাকার সদস্যতা নেওয়া হয়েছে তা নিক্ষেপ করা হয়।
2. ট্র্যাকার, নিজের জন্য একটি অর্ডার গ্রহণ করে, এটিকে তার নিজস্ব ডাটাবেসে সংরক্ষণ করে, ইভেন্টটিকে "ট্র্যাকার দ্বারা গৃহীত আদেশ" তৈরি করে এবং এটি RMQ-এ পাঠায়।
3. অর্ডার প্রতি ইভেন্ট বাসে ইতিমধ্যেই বেশ কিছু হ্যান্ডলার সদস্যতা নিয়েছে৷ আমাদের জন্য, যেটি একচেটিয়া ভিত্তির সাথে সিঙ্ক্রোনাইজেশন করে তা গুরুত্বপূর্ণ।
4. হ্যান্ডলার একটি ইভেন্ট গ্রহণ করে, এটি থেকে ডেটা নির্বাচন করে যা এটির জন্য তাৎপর্যপূর্ণ: আমাদের ক্ষেত্রে, এটি "ট্র্যাকার দ্বারা গৃহীত" অর্ডারটির স্থিতি এবং মূল ডাটাবেসে এর অর্ডার সত্তা আপডেট করে।

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

অন্যান্য সমস্ত পরিষেবাগুলি তাদের নিজেদের জন্য ব্যবহার করার জন্য ট্র্যাকার থেকে ইভেন্টগুলি অর্ডার করতে সদস্যতা নিতে পারে।

যদি কিছুক্ষণ পরে অর্ডারটি কার্যকর করা হয়, তবে প্রথমে এটির স্থিতি তার ডাটাবেসে (ট্র্যাকার ডেটাবেস) পরিবর্তন হয় এবং তারপরে "অর্ডারইন প্রগ্রেস" ইভেন্টটি অবিলম্বে তৈরি হয়। এটি RMQ-তেও প্রবেশ করে, যেখান থেকে এটি একটি মনোলিথিক ডাটাবেসে সিঙ্ক্রোনাইজ করা হয় এবং অন্যান্য পরিষেবাগুলিতে বিতরণ করা হয়। পথে বিভিন্ন সমস্যা থাকতে পারে, সেগুলি সম্পর্কে আরও বিশদ বিবরণ জেনিয়া পেশকভের প্রতিবেদনে পাওয়া যাবে ট্র্যাকারে ঘটনাগত সামঞ্জস্যের বাস্তবায়নের বিশদ সম্পর্কে.

প্রমাণ এবং ট্র্যাকারে পরিবর্তনের পরে চূড়ান্ত স্থাপত্য

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

এই ধরনের উপাদানের সুবিধাগুলি (বা এর অভাব) প্রতিফলিত করে, আমি এই সিদ্ধান্তে পৌঁছেছি যে ঘটনাগুলির সম্পূর্ণ বিবরণ, বিশদ পূর্ববর্তী দৃষ্টিভঙ্গি এবং আমার অতীতের সিদ্ধান্তগুলির বিশ্লেষণ ছাড়া অবিচ্ছিন্ন বিকাশ অসম্ভব।

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

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

ডোডো আইএস-এর কোন অংশ সম্পর্কে আপনি পরবর্তী নিবন্ধে জানতে চান?

• 24,1%ডোডো আইএসের প্রারম্ভিক মনোলিথ (2011-2015)14

• 24,1%প্রথম সমস্যা এবং তাদের সমাধান (2015-2016)14

• 20,7%ক্লায়েন্ট-সাইড পাথ: বেসের উপর সম্মুখভাগ (2016-2017)12

• 36,2%সত্যিকারের মাইক্রোসার্ভিসের ইতিহাস (2018-2019)21

• 44,8%মনোলিথের সম্পূর্ণ করাত এবং স্থাপত্যের স্থিতিশীলতা 26

• 29,3%সিস্টেমের উন্নয়নের জন্য আরও পরিকল্পনা সম্পর্কে17

• 19,0%আমি Dodo IS11 সম্পর্কে কিছু জানতে চাই না

58 জন ব্যবহারকারী ভোট দিয়েছেন। 6 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com