در این مقاله میخواهیم پیرامون سیستم های reactive صحبت کنیم و باید این نکته را مد نظر داشت که reactive را  نمیتوان صرفا محدود به زبان خاصی دانست.

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

در گذشته برنامه های بزرگ ده ها response, Server های چند ثانیه ای, ساعت ها offline بودن و  داده هایی در مقیاس Gigabyte را شامل می‌شدند. اما امروزه برنامه ها بر روی دامنه گسترده ای از دستگاه ها قرار دارند و این دامنه از تلفن های همراه تا مجموعه های cloud-base که به صورت multi-core processing عمل میکنند را شامل می‌شود. کاربران response هایی در مقیاس میلی ثانیه و سیستم هایی با دسترسی پذیری ۱۰۰٪ را انتظار دارند. حجم اطلاعات افزایش پیدا کرده است و در مقیاس Petabyte محاسبه می‌گردد. بنابراین معماری های قدیمی قابلیت تعامل با خواسته های جدید را ندارند.

پس میتوان نتیجه گرفت که معماری سیستم های به یک رویکر منسجم نیاز دارد و همچنین تمام جنبه های آن مشخص شده اند :

• Responsive : یک سیستم در صورت امکان به موقع اقدام به پاسخ به درخواست می‌کند. پاسخگویی یک سیستم یکی از مهم ترین معیار ها در تعیین کارایی یک سیستم است اما نکته مهم تر این است که اگر مشکلات و نقص هایی بوجود آمد, با سرعت شناسایی شوند و نسبت به رفع آنها اقدام شود. سیستم های Responsive بر روی ارائه خدمات به صورت مستمر,  داشتن  response time های نا متغیر و همچنین داشتن قابلیت اعتماد بالا تمرکز می‌کنند و نتیجه آن داشتن یک QoS ثابت است. این رفتار ثابت باعث راحت تر شدن error handling, افزایش اعتماد کاربران می‌شود.
• Resilient : یک Server, شبکه, سیستم ذخیره سازی, Data center و … ممکن است بدلیل بروز اشکال در تجهیزات دچار نقص شود. بر اساس این خاصیت سیستم باید سریع ترمیم شود و به فعالیت خود ادامه دهد. در واقع یک سیستم به هنگام وقوع یک مشکل نیز responsive باقی بماند و مطمعنا سیستمی که Resilient نباشد بعد از وقوع نقص به حالت unresponsive در می آید. لازمه Resilient بودن یک سیستم را در میزان بهره وری سیستم از موارد زیر می‌توان تلقی کرد :
  • Replication : استفاده از یک component به صورت همزمان در یک محیط دیگر می باشد. محیط دیگر میتوان Thread ها یا Process های دیگر, Node های دیگر شبکه و یا Computing Center های دیگر باشند. نتیجه این است که یک حجم کار وارد شده به سیستم بین چندین  instance از یک component توضیع می‌شود و به صورت موازی فرآیند مربوط به آن صورت می‌گیرد و در نهایت نتایج در هم ادغام می‌گردند.
  • containment : به معنای نگهداری چندین instance از data type می‌باشد. مانند:  link list ها و آرایه ها و یا  در Object Oriented Programming وقتی یک object را از روی object دیگر می‌سازیم.
  • Isolation : به معنایی جدایی هم در زمان و هم در فضا می‌باشد. جدایی در زمان به این معناست که فرستنده و گیرنده می‌توانند در Life Cycle های غیر مرتبط باشند. در حقیقت نیاز نیست تا هر دو آنها در زمان ارتباط present باشند تا ارتباط برقرار گردد و برای دستیابی به آن, نیاز است تا بین component های غیر مرتبط به هم یک ارتباط asynchronous ایجاد گردد. جدایی در فضا که به عنوان Location Transparency شناخته می‌شود به این معنا می‌باشد که sender و receiver نیازی نیست حتما در یک process مشترک اجرا شوند. این قابلیت با استفاده از asynchronous message passing امکان پذیر گردیده است.
• Elastic : مشخص کننده قدرت یک سیستم در انطباق با حجم کار است که با تصمیم پیرامون اختصاص منابع صورت می‌گیرد و عمدتا در cloud computing مورد استفاده قرار می‌گیرد. مانند اینکه در زمان فعلی چه منابعی با درخواست متناسب هستند. در واقع این خاصیت باعث می‌شود تا سیستم در مقابل حجم کار با ابعاد متفاوت responsive باقی بماند. سیستم های reactive می‌توانند نسبت به تغییرات در نرخ ورودی با تغییر در اختصاص منابع واکنش نشان دهند.
• Message Driven: در مبحث پردازش client-server مورد بررسی قرار میگیرد. یک client در خواست یک سرویس را در قالب یک پیام با ساختار مشخص به برنامه ارسال می‌کند. در واقع درخواست های زیادی از client های زیادی برای ارسال به server های گوناگون به آن ارسال می‌گردد و در این بین Message Driven Processing در نقش یک جابجا کننده ظاهر می‌گردد. برای مدیریت این درخواست ها اقدام به ایجاد یک صف می‌کند. در اینجا client ها و server ها فقط کافی است تا interface message را بدانند تا بتوانند با یکدیگر ارتباط برقرار کنند. در واقع این سیستم ها با تکیه بر asynchronous message passing اقدام به ایجاد مرز بین component ها می‌کند. استفاده از message passing قابلیت هایی مانند‌: elasticity (مورد قبلی که اشاره شد), Load Management و Flow Control را از طریق تغییر شکل و monitor کردن صف پیغام ها در سیستم در اختیار ما می‌گذارد. استفاده از Location Transparent Messaging به منظور ارتباطات می‌تواند باعث مدیریت اشکالات در هر تعداد از node ها شود. ارتباطات به صورت non blocking,  بدلیل اینکه مصرف کننده تنها در زمان فعال بودن می‌تواند از منابع استفاده کند, باعث می‌شود تا overhead سیستم کمتر شود.

و چنین سیستم هایی را Reactive System گویند. سیستم هایی که بر مبنای Reactive ساخته می‌شوند بسیار منعطف تر و مقیاس پذیر تر هستند. این سیستم ها به صورت loosely coupled هستند. به این معنا که هریک از component های آن بدون داشتن اطلاعات و یا با حداقل اطلاعات نسبت به component های مجزای دیگر فعالیت می‌کنند.

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

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

در این مقاله سعی شد تا توضیحات مختصری پیرامون سیستم های Reactive و قوانینی که این سیستم ها باید داشته باشند تا خواص آنها را پوشش دهند صحبت کنیم.

موفق باشید.