الگوی طراحی سیستم های توسعه پذیر

همواره در طراحی یک سیستم، سعی میشود که از الگوهای طراحی آزموده شده استفاده شود. در این الگوها برای حل مشکلات خاصی، راه حل مشخصی را ارائه میدهد که میتوان آن را استفاده کرد. با ترکیب این الگوها میتوان به قالب کلی سیستم دست یافت. مشابه مبحث طراحی شی گرایی، که در اون design pattern وجود داره، یک مساله anti pattern هم وجود داره. مساله anti pattern مشخص کننده مسائلی هست که توی استفاده از الگو باید در نظر گرفته بشه. حالا بعدا شاید به مساله طراحی الگو پرداخته بشه.

توزیع کننده بار (load balancer)

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

تقسیم و تجمیع دوباره (scatter and Gather)

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

کش کردن نتایج (result cache)

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

این الگو در کاربردهای بزرگ مورد استفاده قرار میگیرد. یک مثال از سرورهای کش، memcached است (بررسی کامل این محصول بعدا نوشته میشه، چون میخوام استفاده کنم ازش).

فضای اشتراکی

به این الگو "تخته سیاه" هم گفته میشه. در این مدل، تمامی سرورهای کاری (workers)، داده های خودشون رو در فضابی اشتراکی مینویسن. پاسخ نهایی در این سیستم ها به صورت افزایشی تکمیل میشه.

این الگو در JavaSpace و در محصول تجاری GigaSpace استفاده میشه.

مسیر داده و خط داده (Pipe and filter)

این الگو با عنوان "data flow programmin" هم شناخته میشه. تمامی گارگذاران به خطوط لوله داده ای متصل هستند که از طریق اونها داده ها منتقل میشه. این الگو یک الگوی طراحی در نرم افزار هست و برای طراحی سیستم نیز استفاده میشه.

map Reduce

این الگو برای شرایطی که مسیر I/O دیسک به عنوان یک bootleneck مطرح میشه قابل استفاده هست. در این الگو از یک فضای ذخیره سازی توزیع شده استفاده میشه. این الگو در بسیاری از کاربردهای گوگل استفاده میشه. یک پیاده سازی متن باز از این الگو، hadoop هست

Bulk Synchronous Parallel

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

1- هر کارگذار داده را از خط روردی دریافت میکند.

2- هر کارگذار پردازش دستور رودی را بر روی داده های محلی انجام میدهن

3- هر کارگذار نتایج محلی رو از طریق خط ارتباطی مستقیم به سرور میفرستد.

این الگو در سیستم پردازش گرافی گوگل استفاده میشه و همچنین سیستم متن باز hama برای این سیستم موجود هست.

سیستم ها، اجزا، رابط ها و محیط

در مطلب قبلی یک تعریف کلی از سیستم ارائه کردیم که عبارت بود از:مجموعه ای پیچیده از اجزای جدا از همدیگر که در مسیر هدفی مشترک یا یک سرویس مشترک با یکدیگر ارتباط دارند. این تعریفی است که در وبستر برای سیستم مطرح شده است. در مهندسی یک تعریف نزدیک‌تر به دنیای واقعی نیاز دارند. بنابراین تعریف فوق به تعریف زیر تغییر میابد:

یک سیستم مجموعه ای است از مؤلفه های (components) متصل به همدیگر که یک رفتار مورد انتظار از طریق رابط‌ها با محیط (environment) دارند.

همیشه تعامل‌ها بین یک سیستم و محیط اطراف آن وجود دارد، که این تعاملات رابط بین سیستم و محیط است. برای مثال رابط در یک فضای بین سیاره‌ها، نیروی جاذبه القایی آن‌ها بین همدیگر و تاثیرات مغناطیسی آن‌ها به همدیگر است. رابط‌های پیش فرض در یک سیستم کامپیوتر شخصی، همان صفحه کلید، صفحه نمایش و امثالهم است. اینکه بتوان رفتار یک سیستم را پیش بینی کرد، وابسته است به شناخت اجزای تشکیل دهنده آن، روابط آن‌ها و رفتار هر کدام از تک اجزا. یافتن اجزا (اجزای تشکیل دهنده سیستم را تشخیص دهیم) نیازمند یک دیدگاه خاص است که به دو سؤال اصلی پاسخ دهد: هدف و ریز دانگی (granularity). نتیجه حاصل از هر کدام از این موارد در تعداد و نوع مؤلفه های تشکیل شده و در نتیجه در طراحی کل سیستم تأثیرگذار خواهد بود.

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

مثالی که ذکر شد، چه تأثیری در طراحی سیستم دارد؟ در همان سیستم هواپیما، یک مهندس طراحی خارجی از فضای درون به عنوان یک فضایی که ارتباط آن با طراحی تنها در حد میزان متر مکعب فضای مورد نیاز و حداکثر وزن است. برای یک مهندس طراح داخلی هواپیما، سیستم رانش، موتور، و بال‌ها و غیره، تنها ارتباطی در حد میزان صدای تولیدی و محل قرارگیری اجزای مختلف دارد (اینکه صندلی مسافران نزدیک بال‌ها چگونه قرار گیرد یا اینکه با موتورها چقدر فاصله داشته باشند).

ریز دانگی در طراحی اجزای یک سیستم، ممکن است باعث شود که یک مؤلفه، در یک طراحی دیگر به عنوان یک سیستم کامل در نظر گرفته شود. برای مثال در سیستم هواپیما، خود موتور که برای بسیاری از مهندسان طراح قسمت‌های دیگر هواپیما، یک مؤلفه کلی بیان می‌شود و تنها با مشخصات آن شناخته می‌شود، خود یک سیستم کامل و پیچیده است که شامل مؤلفه های (و زیر سیستم‌های) زیادی درون خود است.

به یک سیستم که در یک مورد خاص، به عنوان مؤلفه ای از سیستم دیگر استفاده می‌شود، زیر سیستم گفته می‌شود.

در مطلب بعدی به بحث پیچیدگی خواهیم پرداخت.

مسائل مشترک در طراحی سیستم

مسائل و مشکلاتی که در یک طراحی سیستم ممکن است بوجود آید را می‌توان در چهار فیلد اصلی تقسیم بندی کرد:

•     ویژگی‌های اورژانسی (emergent properties).
•     پخش شدن تأثیر‌ها (propagation of effects).
•     گسترش غیر متناسب (incommensurate scaling).
•     توازن (trade-offs).

در ادامه به برسی هر کدام در طراحی سیستم و مثال‌هایی از آن‌ها خواهیم پرداخت.
قبل از ادامه مطلب بهتر است تعریف خودمون رو از سیستم به یک تعریف واحد تبدیل کنیم: سیستم مجموعه ای است از اجرایی که یک رفتار مورد انتظار را از خود نشان داده و با محیط اطراف خود از طریق رابط‌ها ارتباط دارد.
در تعریف بالا مواردی همچون محیط، رابط و رفتار مورد انتظار نیاز به تعریف دقیق‌تر دارد که در مطالب‌های بعدی به آن‌ها خواهیم پرداخت.

• ویژگی های اورژانسی

این ویژگی‌ها شامل ویژگی‌هایی می‌باشند که در تحلیل اولیه اجزای سیستم به صورت تک به تک خودشان را نشان نداده‌اند و بعداً هنگامی که در صدد اتصال اجرا به همدیگر هستیم، خودشان را نشان می‌دهند. می‌توان این اجزا را به عنوان سورپرایز در نظر گرفت. این ویژگی‌ها معمولاً در سیستم‌ها در نظر گرفته نمی‌شوند، هرچند روش‌هایی در طراحی برای پیش‌بینی این موارد وجود دارد. «بعضی موارد تنها زمانی خود را نشان می‌دهند که یک سیستم ساخته شد».
یک مثال جالب: مهندسان پل هزاره که بر روی رودخانه توماس در انگلیس تنها چند روز بعد از افتتاح پل، آن را بستند تا تغییراتی بر روی آن انجام دهند. دلیلی آن یک موضوع جالب بود، مردمی که از روی پل عبور می‌کردند، قدم‌های خود را با نوسانات پل تنظیم می‌کردند، در نتیجه نوسانات بیشتر می‌شد و ممکن بود آسیب جدی به ساختار آن وارد کند.
یک مثال دیگر: وجود چندین تولید کننده برق و اتصال آنها به همدیگر، باعث پخش شدن بار بر روی تولید کنندگان مختلف است. مشکل زمانی به وجود میابد که یکی از تولید کنندگان از مدار خارج شود که ممکن است به دلیل اضافه بار بر روی تولید کنندگان دیگر، تمامی شبکه دچار مشکل شود.
به قول استاد خوبم، جبان آقای دکتر محمدی:"تجزیه شون خوبه، اما مرده شور ترکیب شون رو ببره"

• پخش شدن تاثیرات

در همان مثال مربوط به شبکه برق، یک سقوط درخت در یک منطقه و قطع شدن سیم‌های برق، ممکن است چندین کیلومتر دورتر باعث قطعی برق هزاران نفر شود. یک مسئله که در ابتدا کوچک به نظر می‌رسد و تأثیرات آن محلی تصور می‌شود، می‌تواند باعث تأثیر بر روی اجزای بسیار دورتر سیستم شود. یک نیازمندی اصلی در طراحی سیستم، محدود کردن تاثیرات خطا در سیستم است.
یک مثال دیگر که شاید برای درک تاثیر تغییرات خوب باشد، در طراحی خودرو است. فرض کنید یک مهندس طراح خودرو برای افزایش سرعت، قطر چرخ ها را از 13 به 15 افزایش دهد، در این افزایش، تاثیراتی که باید در سیستم فرمان گیری، ترمز و حتی ظاهر خودرو به وجود میاید را باید در نظر داشت.

• گسترش غیر متناسب

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

• توازن

بسیاری از محدودیت‌ها خود را به صورت یک توازن بین اجزا یا عوامل موثر نشان می‌دهند. یک مدل عام از این توازن عبارت است از اینکه یک عامل خوب در فضای مسئله است و چالش‌های مسئله عبارت است از حداکثر سازی این عوامل خوب و در مرحله دوم جلوگیری از هدر رفتن آن‌ها و در مرحله سوم، تخصیص این عوامل به محل‌هایی که بیشترین سود را داشته باشد. این مفهوم تا حدی در این تعریف مشکل است. این مفهوم را معمولاً با عنوان «اثر تخت خواب آبی (waterbed effect)» مطرح می‌شود. اگر یک مسئله را در محلی فشار دهیم، ممکن است در محل دیگر یک مسئله دیگر به وجود آید یا خود را نشان دهد.
مثال بارز این مسئله در طراحی مدارات سخت افزار و توازن برقرار کردن بین سرعت پردازش، انرژی مصرفی و حرارت تولیدی است.

سؤال مهم این است که با وجود این مسائل و مشکلات، چگونه یک سیستم کامپیوتری را طراحی کنیم. در بهترین حالت، می‌خواهیم یک روش کامل طراحی داشته باشیم که بتوان در آن به صورت کامل همه اجزا را تحلیل کرد و نتیجه نهایی را به بهترین شکل بر اساس تجربیات گذشته بدست آورد. اما متأسفانه در بحث تحلیل و طراحی سیستم کامپیوتری نسبت به علوم مهندسی دیگر بسیار جوان تر هستیم.