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

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

مقدمه

در اواخر دهه ۸۰ و اوایل دهه ۹۰، برنامه‌نویسی شی‌گرا، توسعه نرم افزار را به کلی متحول کرد و باعث فراگیر شدن رویکرد ساخت برنامه ها به شکل مجموعه ای از مولفه های مستقل از هم شد. امروزه با گسترش محبوبیت و فراگیر شدن معماری ریزسرویسهایی که توسط محفظه‌هایی از قطعات نرم‌افزاری ساخته شده‌اند، شاهد انقلابی مشابه در توسعه سیستمهای توزیع‌شده هستیم.

محفظه ها را با توجه به مرز روشنی که با بقیه سیستم دارند، میتوان به عنوان “اشیا” ی پایه در سیستمهای توزیع شده در نظر گرفت. همزمان با اینکه این سبک معماری بالغتر میشود، ما شاهد ظهور الگوهای طراحی برای آن هستیم همان اتفاقی که در برنامه های شی گرا افتاد. به دلیلی مشابه که فکر کردن به اشیا (یا محفظه‌ها) با انتزاع از جزئیات سطح پایین کدها بود که در ادامه به پیدایش الگوهای سطح بالاتر انجامید که در کاربردها و الگوریتمهای مختلفی رایج هستند.

در این مقاله سه نوع از الگوهای طراحی که در محیط های توزیع شدهٔ محفظه-مبنا مشاهده کرده ایم را توصیف میکنیم:

• الگوهای تک محفظه‌ای برای مدیریت محفظه‌ها
• الگوهای تک-گره‌ای برای محفظه‌های همکار و شدیدا وابسته به هم
• الگوهای چند-گره‌ای برای الگوریتمهای توزیع شده.

این الگوها برای محاسبات توزیع شده، همانند نظایرشان در شی‌گرایی، شامل رویه های برتر هستند. روند توسعه را ساده میکنند و سیستمهایی که در آنها مورد استفاده قرار گیرند را قابل اتکاتر میکنند.

الگوهای طراحی سیستمهای توزیع‌شده

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

امروزه وضعیت مهندسی سیستمهای توزیع شده بسیار مشابه شرایط برنامه نویسی در اویل دهه ۸۰ است بیش از آنکه شبیه توسعه شی گرا باشد.

با توجه به موفقیت الگوی MapReduce در به ارمغان آوردن قدرت برنامه نویسی کلان داده برای مجموعه گسترده ای از زیرشاخه ها و برنامه نویسان، بسیار روشن است که استفاده به جا از مجموعه الگوها میتواند به شکل چشمگیری کیفیت، سرعت و سهولت استفاده از سیستمهای توزیع شده را بهبود دهد. اما حتی موفقیت MapReduce بسیار محدود به یک زبان برنامه نویسی است تا جاییکه اکوسیستم Apache Hadoop غالبا با جاوا و برای جاوا نوشته شده است.

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

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

در ادامه توضیح می‌دهیم که چرا به این موضوع معتقدیم و بعضی از الگوهایی که شاهد ظهورشان بوده‌ایم را برای شکل دادن و هدایت مهندسی سیستمهای توزیع‌شده در سالهای آینده توضیح می‌دهیم.

الگوهای مدیریت تک-محفظه‌ای

محفظه یک مرز مشخص برای تعریف یک واسط خیلی شبیه مرز یک شی ارائه می‌دهد. محفظه ها از طریق این واسط می‌توانند نه تنها کاربردهای خاص برنامه را ارائه دهند، بلکه می‌توانند قلابهایی را در اختیار سیستمهای مدیریتی قرار دهند. واسطهای سنتی برای مدیریت محفظه بسیار محدود هستند. یک محفظه فقط می‌تواند واسط استفاده از سه دستورالعمل runو pauseوstop را به بیرون دهد.

گرچه این واسط مفید است، یک واسط غنی تر می‌تواند منفعت بیشتری به توسعه‌دهندگان و اپراتورها بدهد. با پشتیبانی از وب سرورهای HTTP در تقریبا تمام زبانهای مدرن برنامه نویسی و پشتیبانی وسیع برای فرمت داده‌هایی شبیه json ، بسیار ساده خواهد بود که یک api مدیریتی بر مبنای http داشته باشیم. این واسط می‌تواند با داشتن محفظه ای که به اضافه کارکردهای اصلی خود، یک وب سرور درونی هم داشته باشد، پیاده سازی شود.

“در جهت رو به بیرون” محفظه می‌تواند یک مجموعه غنی از اطلاعات برنامه کاربردی شامل معیارهای مانیتورینگ مختص کاربرد (مثل QPS و معیارهای سلامت برنامه ) اطلاعات profiling مورد توجه برنامه نویسان (شامل اطلاعات ریسه‌ها، پشته، رقابت روی قفل)اطلاعات پیکربندی مولفه‌ها و لاگهای مولفه‌ها را یبرون بدهد. به عنوان یک مثال عینی Kubernetes و Aurora و Marathon و بقیه سیستمهای مدیریت محفظه، اجازه می‌دهند که کاربران تست های سلامتی خاصی را با urlهای خاصی تعریف کنند.(/health) پشتیبانی استاندارد از بقیه مواردی که نام بردیم بسیار نادرتر است.

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

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

قابل تصور است که از این روش برای پشتیبانی از متوالی سازی حالات و بازیابی آنها استفاده کرد. که مدیریت حالت ها را برای سیستمهای توزیع شدهٔ حالتمند بسیار ساده تر می‌کند. به عنوان یک مثال عینی از یک سازوکار پیچیده تر، مدل فعالیت در اندروید را در نظر بگیرید که یک سری نقاط فراخوانی (مثل oncreate ،onstart ،onstop ,…) را ارائه می‌دهد و به شکل صوری یک ماشین حالت را توصیف می‌کند که سیستم چگونه آنها را برمی‌انگیزد. بدون این سازوکار صوری ساخت برنامه های قابل اتکا و مقاوم بسیار سختتر می‌شد.

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

الگوهای چند محفظه روی تک-گره

فراتر از واسط یک محفظه، ما چند الگو طراحی را مشاهده می‌کنیم که با چندین محفظه سروکار دارند. ما قبلا در اینجا چند نمونه از این الگوها را نام برده‌ایم. این الگوهای تک گره‌ای شامل چند محفظه شدیدا به هم وابسته هستند که روی یک ماشین میزبان اجرا میشوند. پشتیبانی سیستمهای مدیریت محفظه از زمانبندی چندین محفظه به شکل یک واحد مجزا، مثل انتزاع Kubernetes که “PODS” و انتزاع Nomad که “گروههای کاری” نامیده می‌شود، یک ویژگی لازم است برای اینکه ما بتوانیم الگوهایی که در این بخش، معرفی کرده‌ایم را به کار بگیریم.

الگویSidecar

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

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

دلیل امکان وجود محفظه های Sidecar این است که محفظه های روی یک ماشین می‌توانند قسمتی از دیسک محلی را با هم به اشتراک بگذارند.با وجود اینکه همیشه ممکن است کارکرد محفظهSidecar را از ابتدا در محفظه اصلی داشته باشیم، از جدا کردن این دو محفظه فواید زیر حاصل می‌شود.

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

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

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

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

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

توجه شود که این پنج منفعت در تمام الگوهایی که در ادامه این مقاله می آید هم وجود دارد.

الگوی سفیر

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

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

آنها می توانند برنامه اشان را با یک نسخه memcached روی سرور محلی تست کنند بدون اینکه از محفظه سفیر استفاده کنند و آنها می‌توانند از سفیر twemproxy با برنامه های دیگر که به زبانهای دیگر نوشته شده اند استفاده کنند.

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

الگوی مبدل

آخرین الگوی تک-گره‌ای که ما مشاهده کردیم، الگوی مبدل است. برخلاف الگوی سفیر، که به برنامه یک دید ساده از دنیای خارج ارائه می‌دهد، مبدلها یک دید ساده شده و یکسان از برنامه‌ها به دنیا بیرون ارائه می‌دهند. آنها این کار را با یکسان سازی خروجی ها و واسطهای بین چند محفظه انجام می‌دهند. یک مثال عینی از الگوی مبدل، مبدلهایی هستند که مطمئن می‌شوند که تمام محفظه ها در یک سیستم، یک واسط مانیتورینگ یکسان دارند.برنامه ها امروزه از گستره وسیعی از روشها برای برون دهی معیارهایشان (مثلJMXوstatsd)استفاده می‌کنند.

اما برای یک ابزار مانیتورینگ، ساده تر است که معیارها را از یک مجموعه ناهمگون از برنامه ها جمع آوری، تجمیع و ارائه کند، وقتی که تمام این برنامه ها یک واسط یکسان برای این کار در اختیارش قرار دهند.

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

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

الگوهای کاربردهای چند گره‌ای

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

الگوی انتخاب رهبر

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

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

کتابخانه های زیادی برای اجرای الگوریتم انتخاب رهبر وجود دارد. فهم و استفاده درست از اغلب آنها سخت است. به اضافه اینکه آنها در زبانهای برنامه نویسی خاصی نوشته شده اند. یک راه جایگزین برای اتصال کتابخانه انتخاب رهبر به برنامه، استفاده از محفظه انتخاب رهبر است. مجموعه‌ای از محفظه های انتخاب رهبر هر کدام با یک نسخه از برنامه که نیاز به انتخاب رهبر دارد، متصل است و می‌توانند از بین خودشان رهبر انتخاب کنند. می‌توانند یک API ساده HTTP روی ماشین محلی برای هر محفظه برنامه کاربردی که نیاز به انتخاب رهبر دارد ارائه دهند (مثلا becomeLeader ,renewLeadership …).

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

الگوی صف کارها

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

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

تمام کارهای دیگر در توسعه یک صف کار کامل می‌تواند با این چارچوب عام منظوره صف کار انجام شود و هر وقت که این سیستم مورد نیاز بود، می‌تواند استفاده مجدد شود شیوه‌ای که کد کاربر در این صف کار اشتراکی، ادغام می‌شود در شکل زیر نمایش داده شده است.

الگوی پراکندگی/گردآوری

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

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

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

کارهای مرتبط

معماری های سرویس گرا(SOA) ویژگیهای مشترکی با سیستمهای توزیع شده محفظه-مبنا دارند. برای مثال هردو روی مولفه های قابل استفاده مجدد که واسطهای خوش تعریف دارند، که از طریق شبکه با هم در ارتباطند، تاکید می‌کنند. در سمت مخالف مولفه ها در سیستمهای soa گرایش دارند به این که درشت دانه تر باشند و به هم پیوستگی کمتری داشته باشندنسبت به الگوهای چند محفظه ای که ما توضیح دادیم. به اضافه مولفه ها در soa اغلب اَعمال مرتبط با کسب و کار را پیاده سازی می‌کنند در حالیکه مولفه هایی که که ما اینجا رویشان متمرکز شدیم بیشتر وابسته به کتابخانه های عام منظوره هستند که که ساخت سیستمهای توزیع شده را ساده تر می‌کنند.

واژه ریزسرویس برای توضیح دادن انواع مولفه هایی که ما در این مقاله راجع بهشان بحث کردیم اخیرا پدیدار شده است. مفهوم واسط مدیریت استاندارد شده برای مولفه های مرتبط با شبکه پیشینه‌ای طولانی دارد که حداقل به SNMP باز می‌گردد. SNMP تمرکز اصلیش روی مدیریت مولفه های سخت افزاری است. هیچ استانداردی برای مدیریت ریزسرویسها/سیستمهای محفظه-مبنا هنوز وجود ندارد.

با این وجود تعداد زیادی از سیستمهای مدیریت محفظه مثل Aurora, ECS, Docker Swarm, Kubernetes Marathon و Nomad توسعه یافته اند. تمام الگوریتمهای توزیع شده که ما در بخش آخر به آنها اشاره کردیم پیشینه ای طولانی دارند. پیاده سازی های انتخاب رهبر به سادگی از Github قابل دسترسی هستند. تعدادی از پیاده سازیهای صف کار وجود دارد مثلCelery و Amazon SQS. پراکنده‌ساز/گردآور به عنوان یک الگوی یکپارچه سازی معظم شناخته شده است.

نتیجه گیری

همانطور که برنامه نویسی شی گرا به پیدایش و دسته بندی “الگوهای طراحی”شی گرا انجامید، ما شاهد آن هستیم که معماریهای محفظه ای، ما را به سمت الگوهایی برای سیستمهای توزیع شده محفظه-مبنا هدایت می‌کنند. در این مقاله ما سه نوع از الگوهایی که مشاهده کرده‌ایم را نامگذاری و تعریف کردیم:

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

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