عکس پیش‌فرض نوشته

در معماری متمرکز تنها یک سرویس دهنده اغلب قطعات نرم افزاری را پیاده سازی میکند، درحالی که سرویس گیرندگان راه دور میتوانند با ابزارهای ارتباطی به آن سرویس دهنده دست یابند.

در این مطلب مسائل و مشکلاتی که در معماری متمرکز سیستم های توزیعی در پیش روی ماست بررسی میشوند.

معماری متمرکز سیستم های توزیعی

 

علی رغم توافق درباره موضوعات سیستم های توزیع شده، موضوعی وجود دارد که پژوهشگران و دانشمندان درباره آن توافق دارند؛ تفکر بر اساس سرویس گیرندگانی که سرویس ها را از سرویس دهنده ها درخواست میکنند، به ما کمک میکند تا پیچیدگی سیستم های توزیع شده را درک و مدیریت کنیم.

 

در مدل اصلی سرویس گیرنده – سرویس دهنده، فرآیندها در سیستم توزیع شده به دو گره (احتمالاً همپوشانی کننده) تقسیم میشوند.

سرویس دهنده، فرآیندی است که سرویس خاصی را پیادده سازی میکند، مثل سرویس سیستم فایل یا سرویس بانک اطلاعاتی.

سرویس گیرنده فرآیندی است که سرویس را از سرویس دهنده درخواست میکند. برای این کار پیامی به آن میفرستد و منتظر پاسخ از سرویس دهنده می ماند.

این تعامل سرویس گیرنده – سرویس دهنده را رفتار درخواست-پاسخ نیز می نامند.

 

وقتی شبکه کامپیوتری ایمن باشد، مثل بسیاری از شبکه های محلی، ارتباط بین سرویس گیرنده و سرویس دهنده میتواند به وسیله پروتکل بی اتصال ساده پیاده سازی شود.

در این موارد، وقتی سرویس گیرنده، سرویسی را درخواست میکند، پیام را برای سرویس دهنده بسته بندی میکند، سرویس مورد نظر را شناسایی کرده و به همراه سایر داده های ضروری به آن میفرستد.

سرویس دهنده منتظر پاسخ ورودی می ماند، سپس آنرا پردازش کرده و نتیجه را در پیام پاسخ بسته بندی میکند و به سرویس گیرنده میفرستد.

 

استفاده از پروتکل بی اتصال، کارآمد است. تا زمانی که پیام ها مفقود یا خراب نشوند، پروتکل درخواست-پاسخ به خوبی عمل خواهد کرد.

متاسفانه مقاوم کردن پروتکل در برابر خرابی، ساده نیست.

تنها کاری که میتوانیم انجام دهیم این است که اگر پاسخ دریافت نشد، سرویس گیرنده را وادار کنیم که درخواست را دوباره ارسال کند.

اما مشکل این است که سرویس گیرنده نمیتواند تشخیص دهد که آیا پیام درخواست اصلی مفقود شده است یا انتقال پاسخ با شکست مواجه شده است.

اگر پاسخ مفقود شده باشد، ممکن است ارسال مجدد درخواست، عملی را دوباره اجرا کند. اگر این عملیات یک عملیات انتقال پول از حساب بانکی باشد، بهتر است خطا صادر شود و  اگر عملیات صرفا بررسی موجودی یک حساب باشد، ارسال مجدد درخواست قابل قبول خواهد بود.

وقتی پیامی بتواند بدون ضرر چند بار تکرار شود، آنرا همانی (Idempotent) می نامند. چون بعضی از درخواست ها همانی هستند و بعضی دیگر نیستند، روشن است که تنها یک راه حل برای اداره کردن پیام های مفقود وجود ندارد.

 

در روش دیگر، بسیاری از سیستم های سرویس گیرنده – سرویس دهنده، از پروتکل اتصال گرا استفاده میکنند.

گرچه این راه حل به دلیل کارایی نسبتاً پایین به طور کامل در شبکه محلی مناسب نیست، ولی در سیستم های شبکه گسترده که در آنها ارتباطات غیر قابل اعتماد هستند، به خوبی کار میکنند.

به عنوان مثال، تمام پروتکل های کاربرد اینترنتی مبتنی بر اتصال های قابل اعتماد TCP/IP هستند.

در این مورد، هر زمان سرویس گیرنده سرویسی را درخواست میکند، قبل از ارسال درخواست، اتصالی را برقرار میکند.

سرویس دهنده با استفاده از همان اتصال، پیام پاسخ را میفرستد و پس از آن اتصال قطع میشود.

مشکل اینجاست که ایجاد و قطع اتصال برای ما هزینه بر خواهد بود، مخصوصاً وقتی که پیام های درخواست و پاسخ کوچک باشند.

 

لایه بندی کاربرد در معماری متمرکز

مدل سرویس گیرنده – سرویس دهنده، طی چندین سال دچار بحث و گفت و گو بوده است. یکی از موضوعات اصلی، تمایز بین سرویس گیرنده و سرویس دهنده بود.

تمایز روشنی بین آنها وجود ندارد. به عنوان مثال ممکن است سرویس دهنده مربوط به بانک اطلاعاتی توزیع شده دائماً به عنوان سرویس گیرنده عمل کند، زیرا درخواست ها را به سرویس دهنده های فایل مختلف میفرستد که مسئول پیاده سازی جدول های بانک اطلاعاتی اند.

در چنین موردی، خود سرویس دهنده بانک اطلاعاتی، چیزی بیشتر از پردازش درخواست ها را انجام نمیدهد.

 

پیشنهاد میکنم مقاله مربوط به سبک های معماری سیستم های توزیعی را مطالعه کنید!

اما با توجه به این که کاربردهای سرویس گیرنده – سرویس دهنده سعی میکنند از دستیابی کاربران به بانک اطلاعاتی پشتیبانی نمایند، بسیار از مردم میخواهند بین سه سطح زیر تمایز قائل شوند و از سبک معماری لایه ای که در مطالب گذشته مطرح شد پشتیبانی شود:

1- سطح واسط کاربر : شامل تمام امکانات لازم برای ارتباط با کاربر، مثل مدیریت نمایش است.

2- سطح پردازش : معمولا شامل کاربردهاست.

3- سطح داده : داده واقعی را که بر روی آن عمل میشود مدیریت میکند.

 

سرویس گیرندگان معمولاً سطح واسط کاربر را پیاده سازی میکنند. این سطح شامل برنامه هایی است که به کاربران اجازه میدهد با کاربردها تعامل داشته باشند.

 

بسیاری از کاربردهای سرویس گیرنده – سرویس دهنده را میتوان با سه قطعه مختلف ساخت:

– بخشی که تعامل با کاربر را اداره میکند.

– بخشی که بر روی سیستم فایل یا بانک اطلاعات عمل میکند.

– بخش میانی که معمولاً شامل عملکرد اصلی کاربرد است.

این بخش میانی به طور منطقی در سطح پردازش قرار دارد. برعکس واسط های کاربر و بانک های اطلاعاتی، جنبه های مشترکی با سطح پردازش وجود ندارد.

 

سطح داده شامل برنامه هایی است که داده های واقعی را نگه میدارد که کاربردها بر روی آن عمل میکنند.

خاصیت مهم سطح داده این است که داده ها معمولاً پایدار هستند، یعنی حتی اگر هیچ کاربردی در حال اجرا نباشد، داده ها برای استفاده بعدی ذخیره میشوند.

در این شکل ساده،سطح داده شامل سیستم فایل است اما متداول است که از بانک اطلاعاتی کامل (full-fledget) استفاده شود.

در مدل سرویس گیرنده – سرویس دهنده، سطح داده معمولاً در سرویس دهنده پیاده سازی میشود.

 

در کنار ذخیره داده ها، سطح داده معمولاً مسئول نگهداری داده ها در بین کاربردهای مختلف نیز خواهد بود.

وقتی از بانک های اطلاعاتی استفاده میشود، سازگاری به معنای این است که متاداده ای مثل توصیف جدول یا متاداده خاص کاربرد نیز در این سطح ذخیره شوند.

 

در اغلب محیط های تجاری، سطح داده به صورت بانک اطلاعاتی رابطه ای سازمان دهی میشود. در این جاست که استقلال داده ها مهم خواهد بود.

داده ها مستقل از کاربردها سازمان دهی میشوند، به طوری که تغییرات در آن سازمان تاثیری در کاربردها ندارد و اجرای کاربردها تاثیری در سازمان دهی داده ها ندارد.

استفاده از بانک اطلاعاتی رابطه ای در مدل سرویس گیرنده – سرویس دهنده به تفکیک سطح پردازش از سطح داده کمک میکند، به طوری که پردازش و داده ها جدا از هم در نظر گرفته میشوند.

این آموزش بیش از ۳ سال قبل ارسال شده و اکنون در لیست به‌روزرسانی‌های سایت قرار دارد. اگر پیشنهاد یا انتقادی برای بهبود آموزش دارید، خوشحال می‌شیم به ما اطلاع بدهید.