JSON-RPC? কৌশলী বিশ্রাম নিন

আমি নিশ্চিত যে শিরোনামটি একটি স্বাস্থ্যকর প্রতিক্রিয়া সৃষ্টি করেছে - "ভাল, এটি আবার শুরু হয়েছে..." তবে আমাকে 5-10 মিনিটের জন্য আপনার দৃষ্টি আকর্ষণ করতে দিন, এবং আমি আপনার প্রত্যাশাগুলিকে হতাশ না করার চেষ্টা করব।

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

আরপিসি কী তা স্পষ্ট হওয়ার জন্য, আমি মান বিবেচনা করার প্রস্তাব দিই JSON-RPC 2.0. REST এর সাথে কোন স্পষ্টতা নেই। এবং এটা উচিত নয়. REST সম্পর্কে আপনার যা কিছু জানা দরকার - এটি থেকে আলাদা করা যায় না HTTP- র.

RPC অনুরোধগুলি দ্রুত এবং আরও কার্যকর কারণ তারা আপনাকে ব্যাচ অনুরোধ করতে দেয়।

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

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

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

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

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

স্ক্রিপ্টে সমৃদ্ধকরণের জন্য দুটি অনুরোধ নয়, তবে বলুন, পাঁচ বা দশটি ... এবং "এখন কে জিতবে?" প্রশ্নের উত্তর দেওয়া যথেষ্ট। অস্পষ্ট হয়ে যায়।

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

দেখুন কিভাবে RPC পরিকাঠামো উচ্চ লোডের চাহিদা মেটাতে উল্লেখযোগ্যভাবে উন্নতি করেছে। জিনিসটি হল যে REST HTTP প্রোটোকলের সম্পূর্ণ শক্তি ব্যবহার করে, RPC এর বিপরীতে। উপরের চিত্রে, এই শক্তি অনুরোধ পদ্ধতির মাধ্যমে উপলব্ধি করা হয়েছে - GET।

HTTP পদ্ধতি, অন্যান্য জিনিসের মধ্যে, ক্যাশিং কৌশল আছে। আপনি তাদের ডকুমেন্টেশন এ খুঁজে পেতে পারেন HTTP- র. RPC-এর জন্য, POST অনুরোধগুলি ব্যবহার করা হয়, যেগুলিকে অদম্য বলে মনে করা হয় না, অর্থাৎ, একই POST অনুরোধের বারবার পুনরাবৃত্তি ভিন্ন ফলাফল দিতে পারে (উদাহরণস্বরূপ, প্রতিটি মন্তব্য পাঠানোর পরে, এই মন্তব্যের আরেকটি অনুলিপি প্রদর্শিত হবে) (উৎস).

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

আসুন এখন গণনা করা যাক কতগুলি অনুরোধ REST এবং RPC বিবেচনাধীন অবকাঠামোতে "জন্ম দিয়েছে"?

অনুরোধ
ইনবক্স
ব্যাকএন্ড
ডিবিএমএসের কাছে
নরম ক্যাশে (Redis)
মোট

বিশ্রাম
1 / 32 *
1
1
0
3 / 35

আরপিসি
32
32
1
31
96

[*] সর্বোত্তম ক্ষেত্রে (স্থানীয় ক্যাশে ব্যবহার করা হলে) 1 অনুরোধ (এক!), সবচেয়ে খারাপ ক্ষেত্রে 32টি আগত অনুরোধ।

প্রথম স্কিমের তুলনায়, পার্থক্যটি আকর্ষণীয়। এখন REST এর সুবিধা পরিষ্কার হয়ে যায়। তবে আমি সেখানে না থামার পরামর্শ দিই। উন্নত অবকাঠামো একটি CDN অন্তর্ভুক্ত. প্রায়শই এটি DDoS এবং DoS আক্রমণগুলি মোকাবেলার সমস্যার সমাধান করে। আমরা পেতে:

আরপিসির জন্য জিনিসগুলি সত্যিই খারাপ হয়ে যায়। RPC শুধুমাত্র একটি CDN-এ কাজের চাপ অর্পণ করতে সক্ষম নয়৷ আমরা আক্রমণ প্রতিহত করার জন্য শুধুমাত্র সিস্টেমের উপর নির্ভর করতে পারি।

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

তাহলে কেন পৌরাণিক কাহিনী যে ব্যাচ অনুরোধগুলি (RPC) দ্রুত এতটা স্থায়ী? ব্যক্তিগতভাবে, আমার কাছে মনে হয় যে বেশিরভাগ প্রকল্পগুলি কেবল উন্নয়নের এমন স্তরে পৌঁছায় না যেখানে REST তার শক্তি দেখাতে সক্ষম হয়। তাছাড়া, ছোট প্রকল্পে, তিনি তার দুর্বলতা দেখাতে বেশি ইচ্ছুক।

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

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

RPC অনুরোধগুলি আরও নির্ভরযোগ্য কারণ তারা একটি একক লেনদেনের মধ্যে ব্যাচ অনুরোধগুলি সম্পাদন করতে পারে

RPC এর এই সম্পত্তি একটি নির্দিষ্ট সুবিধা, কারণ ডাটাবেস সামঞ্জস্য রাখা সহজ। কিন্তু REST এর সাথে এটি আরও জটিল হয়ে ওঠে। অনুরোধগুলি বিভিন্ন ব্যাকএন্ড নোডে অসামঞ্জস্যপূর্ণভাবে আসতে পারে।

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

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

আসুন চিত্রটি দেখি। এটি উচ্চ প্রাপ্যতা উপাদান সহ একটি অবকাঠামো উপস্থাপন করে। এসএমএস গেটওয়ে সহ দুটি স্বাধীন যোগাযোগ চ্যানেল রয়েছে। কিন্তু... আমরা কি দেখতে পাচ্ছি? একটি এসএমএস পাঠানোর সময়, একটি ত্রুটি 503 ঘটে - পরিষেবাটি অস্থায়ীভাবে অনুপলব্ধ৷ কারণ এসএমএস পাঠানো একটি ব্যাচ অনুরোধে প্যাকেজ করা হয়, তারপর সমগ্র অনুরোধ রোল ব্যাক করা আবশ্যক। DBMS-এ অ্যাকশন বাতিল করা হয়েছে। ক্লায়েন্ট একটি ত্রুটি পায়.

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

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

সম্মত, ক্লায়েন্টের দিক থেকে, পরিষেবাটি আমাদের পছন্দ মতো নির্ভরযোগ্য বলে মনে হচ্ছে না... REST সম্পর্কে কী?

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

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

আমরা দেখতে পাচ্ছি, JSON-RPC এর নির্ভরযোগ্যতা ওভাররেট করা হয়েছে। প্রকৃতপক্ষে, ডাটাবেসে ধারাবাহিকতা সংগঠিত করা সহজ। কিন্তু ত্যাগ, এই ক্ষেত্রে, সামগ্রিকভাবে সিস্টেমের নির্ভরযোগ্যতা হবে.

উপসংহারটি অনেকাংশে আগেরটির মতোই। যখন পরিকাঠামো সহজ হয়, JSON-RPC-এর স্পষ্টতা অবশ্যই একটি প্লাস। যদি প্রকল্পটি একটি উচ্চ লোড সহ উচ্চ প্রাপ্যতা জড়িত, REST একটি আরো সঠিক মত দেখায়, যদিও আরো জটিল, সমাধান।

REST এ প্রবেশের থ্রেশহোল্ড কম

আমি মনে করি যে উপরের বিশ্লেষণ, RPC সম্পর্কে প্রতিষ্ঠিত স্টেরিওটাইপগুলিকে ডিবাঙ্ক করে, স্পষ্টভাবে দেখিয়েছে যে REST-এ প্রবেশের থ্রেশহোল্ড নিঃসন্দেহে RPC-এর চেয়ে বেশি। এটি HTTP কীভাবে কাজ করে সে সম্পর্কে গভীর বোঝার প্রয়োজন, সেইসাথে বিদ্যমান অবকাঠামো উপাদান সম্পর্কে যথেষ্ট জ্ঞান থাকা প্রয়োজন যা WEB প্রকল্পগুলিতে ব্যবহার করা যেতে পারে এবং করা উচিত।

তাহলে কেন অনেকেই মনে করেন যে REST সহজ হবে? আমার ব্যক্তিগত মতামত হল যে এই আপাত সরলতা REST থেকে আসে। সেগুলো. REST একটি প্রোটোকল নয় কিন্তু একটি ধারণা... REST এর কোনো মান নেই, কিছু নির্দেশিকা আছে... REST HTTP এর চেয়ে জটিল নয়। আপাত স্বাধীনতা এবং নৈরাজ্য "মুক্ত শিল্পীদের" আকর্ষণ করে।

অবশ্যই, REST HTTP এর চেয়ে বেশি জটিল নয়। কিন্তু HTTP নিজেই একটি ভাল ডিজাইন করা প্রোটোকল যা কয়েক দশক ধরে এর মূল্য প্রমাণ করেছে। যদি HTTP নিজেই কোন গভীর বোঝার না থাকে, তাহলে REST বিচার করা যাবে না।

কিন্তু RPC সম্পর্কে - আপনি পারেন. এর স্পেসিফিকেশন নেওয়াই যথেষ্ট। তাই আপনার কি দরকার বোকা JSON-RPC? বা এটা এখনও চতুর বিশ্রাম? তুমি ঠিক কর.

আমি আন্তরিকভাবে আশা করি যে আমি আপনার সময় নষ্ট করিনি।

উত্স: www.habr.com