2000+ ক্লায়েন্ট মেশিনের জন্য অ্যাপ্লিকেশন সার্ভার হিসাবে REST পরিষেবা। এটা কি ভাল ধারণা?


11

আমরা জাভাএফএক্সে ইউআই সহ একটি সিস্টেম তৈরি করব যা 2000+ মেশিনে মোতায়েন করা হবে (সর্বনিম্ন 2000, তবে এটি আরও বেশি হবে - 5000 মেশিনে পৌঁছতে পারে)।

অন্যান্য কারণে / সীমাবদ্ধতার জন্য এটি অবশ্যই মেশিনে ইনস্টল করা উচিত, তাই আমরা এটি কোনও ওয়েব ব্রাউজার ইন্টারফেস দিয়ে করতে পারি না।

2000+ মেশিনগুলি বিভিন্ন ভৌগলিক অবস্থানের গ্রুপে থাকবে। সাধারণভাবে সংযোগটি ভাল তবে বেশি দূরবর্তী অবস্থানগুলিতে এটি এত ভাল নাও হতে পারে।

সরাসরি ডাটাবেস অ্যাক্সেস না করে আমি স্প্রিং + স্প্রিং বুট + স্প্রিং ডেটা (জাভা) দিয়ে একটি আরইএসটি পরিষেবা ক্লাস্টার তৈরি করার কথা ভাবছি।

আরআরইএসটি পরিষেবা জেসনকে গ্রহণ করবে এবং ফিরিয়ে দেবে।

আমি মনে করি এটি একটি ভাল ধারণা কারণ:

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

এটা কি আসলেই ভাল ধারণা?

আপনি কিছু ইতিবাচক বা নেতিবাচক অভিজ্ঞতা ভাগ করতে পারেন?

ধন্যবাদ.


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

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

উত্তর:


3

এটি একটি প্রচুর সম্ভাব্য প্রতিক্রিয়া সহ একটি মুক্ত সমাপ্ত প্রশ্ন যা আপনি যা করার চেষ্টা করছেন তার উপর নির্ভর করে। তবুও আমি উত্তর হিসাবে কয়েকটি জিনিস যুক্ত করব, যেহেতু কোনও মন্তব্য যথেষ্ট পরিমাণে বড় হবে না।

পরিষেবাটি একটি ডাটাবেস সংযোগ পুল হিসাবে কাজ করবে (আমার মনে হয় একটি ডাটাবেসে 2000+ সংযোগ সমস্যার কারণ হতে পারে);

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

ইতিমধ্যে সংগ্রহ করা ডেটা ফেরত দিতে ক্যাচিং সেখানে সহায়তা করতে পারে (যেমন আমি বলেছিলাম, আপনি যা করার চেষ্টা করছেন তার উপর নির্ভর করে - যদি প্রশ্নগুলি অনন্য হয় তবে আপনি বেশি ক্যাশে করতে পারবেন না)।

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

কিছু প্রশ্নের পরিবেশন করার জন্য অন্যান্য পঠনযোগ্য ডেটাবেজে লগ শিপিংয়ের সাথে একটি ডাটাবেস পাওয়া সম্ভব;

ডাটাবেস সহজেই আপনার অস্থির হয়ে উঠতে পারে। অনেক সংযোগ এবং / অথবা অনেকগুলি প্রশ্ন এবং আপনি এটিকে ভেঙে ফেলতে পারেন। এই মুহুর্তে এটি কোনও বিষয় নয় যে আপনি আপনার পরিষেবাগুলিকে কোনও সংখ্যায় অনুভূমিকভাবে স্কেল করতে পারবেন। সমস্ত অনুরোধগুলি শেষ পর্যন্ত একই ডাটাবেসে পৌঁছে যাবে।

এটি রক্ষার বিভিন্ন উপায় রয়েছে: ক্যাশিং আমি ইতিমধ্যে উল্লেখ করেছি (আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে), অন্যান্য সার্ভারে কিছু তথ্য নকল করুন যেমন আপনি উল্লেখ করেছেন এমন কিছু প্রশ্নের পরিবেশন করতে, সিকিউআরএস (আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে), রিলেশনাল বনাম অ-রিলেশনাল ব্যবহার করুন (আপনার ব্যবহারের ক্ষেত্রে আবার নির্ভর করে), ইত্যাদি

নোট করুন যদিও আপনি যখন এর মতো ডেটা বিতরণ করেন তখন সিএপি উপপাদ্য প্রয়োগ করা শুরু করে। ধারাবাহিকতা এবং প্রাপ্যতার মধ্যে আপনার আপস করার প্রয়োজন হতে পারে সে সম্পর্কে সচেতন হন।

আরআরএসটি পরিষেবা চালানোর জন্য আরও মেশিন যুক্ত করতে পারলে এটি আরও ভাল স্কেল হবে;

হ্যাঁ, আরআরইএসটি পরিষেবা স্কেল করবে তবে আমি উপরে উল্লিখিত হিসাবে, আপনি যদি ডাটাবেসটি সুরক্ষা না করেন, তবে এটি সহজেই একটি বাধা হয়ে উঠতে পারে।

সুরক্ষা এবং ব্যান্ডউইথ সংরক্ষণের কারণে সংকোচনের সাথে এইচটিটিপিএস ব্যবহার করা সম্ভব;

হ্যাঁ, পাশাপাশি অন্যান্য জিনিসগুলি ... সম্ভবত আপনি পরে প্রমাণীকরণ / অনুমোদন চান ইত্যাদি

2000+ মেশিন পুনরায় প্রবর্তন না করে ব্যবসায়ের সত্তায় কিছু কেন্দ্রীভূত পরিবর্তন করা সম্ভব;

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

এটি অন্যান্য সিস্টেমের সাথে আরও ভাল সংহত করে (কেবল এটি আরএসটি পরিষেবাতে দেখায়)।

হ্যাঁ, তবে এর অর্থ আপনার সেবার ক্লায়েন্ট যা সম্ভবত আপনি নিয়ন্ত্রণ করতে পারবেন না।

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

আমি যেমন বলেছি, এটি আপনি কী করার চেষ্টা করছেন তার উপর নির্ভর করে। সামগ্রিকভাবে, আপনার একটি ভাল ধারণা। তবে সচেতন থাকুন যে কোনও ডাটাবেসের সামনে আপনি একটি রেস্ট সার্ভিস আটকে রেখেছেন তাই কেবল স্টাফ ফ্রি আসবে না।

শুধু আমার 2 সেন্ট!


ভাল উত্তর। আমি কেবল থিয়াগোকেই হাইলাইট করতে চেয়েছিলাম যে যত তাড়াতাড়ি সম্ভব একটি RESTful এপিআইতে সংস্করণকরণ বিবেচনা করা উপযুক্ত। শুরুতে আপনার এটি করার প্রয়োজন হতে পারে না তবে আপনার এটি সম্পর্কে সচেতন হওয়া এবং প্রস্তুত হওয়া উচিত।
ড্যানিয়েল হোলিনরাকে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.