سامرویل، ایان. مهندسی نرم افزار - فایل n1.doc. مفاهیم معماری توزیع شده را که هنگام ساختن یک سیستم پرداخت بزرگ یاد گرفتم

AggreGate یکی از معدود پلتفرم های اینترنت اشیا در جهان است که واقعاً از معماری توزیع شده پشتیبانی می کند. این مقیاس پذیری نامحدودی را برای ایجاد تعادل و جداسازی کلیه عملیات سرور AggreGate در سطوح مختلف فراهم می کند. چنین معماری می تواند مبنایی برای حل مشکلات فعلی و رفع نیازهای آینده باشد.

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

معماری توزیع شده AggreGate بسیار انعطاف پذیر است. از نظر فنی، بر اساس شکل‌گیری روابط همتا به همتا بین سرورها و پیوست کردن بخش‌هایی از یک مدل داده واحد از برخی سرورها ("تامین کنندگان") به دیگران ("مصرف کنندگان") است.

اهداف عملیات توزیع شده

اهداف اصلی یک معماری توزیع شده عبارتند از:

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

توزیع نقش های سرور

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

پلت فرم اینترنت اشیاء ابری در مقیاس بزرگ

ارائه دهندگان خدمات مخابراتی و ابری خدمات اینترنت اشیا را در مدل های IaaS/PaaS/SaaS ارائه می دهند. در این موارد، ما در مورد میلیون ها دستگاه متعلق به هزاران کاربر صحبت می کنیم. حفظ چنین زیرساخت عظیمی به صدها سرور AggreGate نیاز دارد که اکثر آنها را می توان به دو گروه دسته بندی کرد:

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

سرورهای مدیریت کاربر و دستگاه همچنین مسئول تعامل با سیستم مدیریت ابری هستند که سرورهای ذخیره سازی و تجزیه و تحلیل جدید را مستقر و نظارت می کند.

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

زیرساخت لایه ای اینترنت اشیا

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

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

مدیریت شهر هوشمند

این نمونه‌ای از معماری لایه‌ای مبتنی بر AggreGate برای اتوماسیون سرتاسر گروه بزرگی از ساختمان‌ها است:

• سطح 1: سخت افزار فیزیکی ( روترهای شبکه، کنترل کننده ها، تجهیزات صنعتی و غیره)
• سطح 2: سرورهای مدیریت (سرورهای مانیتورینگ شبکه، سرورهای کنترل دسترسی، سرورهای اتوماسیون ساختمان و غیره)
• سطح 3: ساخت مراکز کنترل سرور (یک سرور در هر ساختمان که اطلاعات را از تمام سرورهای سطح دوم جمع آوری می کند)
• سطح 4: سرورهای منطقه شهر (مقصد نهایی برای تشدید هشدار سطح پایین تر، نظارت در زمان واقعی، ادغام با سیستم های Service Desk)
• سطح 5: سرورهای دفتر مرکزی (کنترل سرورهای منطقه، جمع آوری و تدوین گزارش، هشدارها)

هر یک از سرورهای فوق می تواند یک خوشه شکست چند گره باشد.

مدیریت شبکه چند بخش

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

بنابراین، یک سیستم نظارت توزیع شده معمولاً از اجزای زیر تشکیل شده است:

• اولیهیا مرکزیسروری که اطلاعات را از تمام بخش های شبکه جمع آوری می کند
• ثانویسرورها یا سرورهای پروبکه دستگاه های نظرسنجی در بخش های جدا شده است
• تخصصیسرورهایی مانند سرورهای تجزیه و تحلیل ترافیک که میلیاردها رویداد NetFlow را در روز پردازش می کنند

سرورهای ثانویه و تخصصی ارائه دهندگان اطلاعات سرور اصلی هستند و بخشی از مدل داده خود را در اختیار مرکز کنترل قرار می دهند. میتوانست باشد:

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

مدیریت رویداد با عملکرد بالا

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

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

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

شرکت دیجیتال

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

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

اصول ایجاد یک سیستم پردازش اطلاعات در سطح سازمانی

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

برنج. 1. طرح محاسبات توزیع شده

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

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

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

در این دوره بود که مشخص شد مزایای اصلی برنامه های کاربردی توزیع شده عبارتند از:

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

· توانایی مدیریت بار - سطوح میانی یک برنامه کاربردی توزیع شده امکان مدیریت جریان درخواست های کاربر و هدایت آنها به سرورهای کمتر بارگذاری شده را برای پردازش فراهم می کند.

· جهانی بودن - یک ساختار توزیع شده به شما امکان می دهد تا توزیع فضایی فرآیندهای تجاری را دنبال کنید و مشاغل مشتری را در راحت ترین نقاط ایجاد کنید.

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

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

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

پارادایم محاسبات توزیع شده

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

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

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

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

جداسازی فضایی بخش‌های سازمان در فضا از هم جدا هستند و اغلب نرم‌افزار یکپارچه ضعیفی دارند.

انطباق ساختاری نرم افزار باید به اندازه کافی ساختار اطلاعات شرکت را منعکس کند - با جریان های اصلی داده مطابقت داشته باشد.

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

سیستم های توزیع شده تمام الزامات ذکر شده برای نرم افزار در مقیاس سازمانی را برآورده می کنند - طرح توزیع محاسباتی در شکل نشان داده شده است. 1.

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

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

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

کنترل پذیری - به توانایی سیستم برای کنترل موثر اجزای تشکیل دهنده آن اشاره دارد. این امر از طریق استفاده از نرم افزار کنترل به دست می آید.

· بهره وری - به دلیل امکان توزیع مجدد بار روی سرورهای سیستم با کمک نرم افزار کنترل ارائه می شود.

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

· توسعه پذیری - برنامه های کاربردی توزیع شده را می توان به اجزای جدید (نرم افزار سرور) با ویژگی های جدید اضافه کرد.

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

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

ویژگی های ذکر شده سیستم های توزیع شده دلیل کافی برای تحمل پیچیدگی توسعه آنها و هزینه بالای نگهداری است.

معماری کاربردی توزیع شده

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

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

نمایش داده ها (سطح کاربر). در اینجا، کاربران برنامه می توانند داده های لازم را مشاهده کنند، درخواست اجرا ارسال کنند، داده های جدید را وارد سیستم کنند یا آن را ویرایش کنند.

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

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

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

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

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

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

بنابراین، چهار سطح اصلی معماری توزیع شده را می توان متمایز کرد (شکل 2 را ببینید):

ارائه داده ها (سطح کاربر)؛

قوانین منطق کسب و کار (لایه پردازش داده)؛

مدیریت داده (سطح مدیریت داده)؛

ذخیره سازی داده ها (لایه ذخیره سازی داده ها).

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

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

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

ساختار فیزیکی برنامه های کاربردی توزیع شده

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

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

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

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

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

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

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

و تمرین این نتیجه را تأیید می کند. از این گذشته ، همیشه چند قانون وجود دارد که باید دقیقاً در رویه های ذخیره شده سرور پایگاه داده پیاده سازی شوند ، و اغلب به راحتی می توان برخی از عملیات داده های اولیه را به سمت مشتری منتقل کرد - حداقل برای جلوگیری از پردازش از درخواست های نادرست

لایه نمایشی

لایه ارائه تنها لایه موجود است کاربر نهایی. این لایه ایستگاه های کاری مشتری برنامه های کاربردی توزیع شده و نرم افزارهای مرتبط را مدل می کند. قابلیت های ایستگاه کاری مشتری در درجه اول توسط قابلیت های سیستم عامل تعیین می شود. بسته به نوع رابط کاربری، نرم افزار کلاینت به دو گروه تقسیم می شود: کلاینت هایی که از قابلیت های رابط کاربری گرافیکی استفاده می کنند (مثلاً ویندوز) و کلاینت های وب. اما در هر صورت، برنامه مشتری باید توابع زیر را ارائه دهد:

در حال دریافت اطلاعات؛

ارائه داده ها برای مشاهده توسط کاربر؛

ویرایش داده ها؛

بررسی صحت داده های وارد شده؛

ذخیره تغییرات ایجاد شده؛

· رسیدگی به استثناها و نمایش اطلاعات خطا به کاربر.

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

لایه پردازش داده

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

پردازش جریان های داده مطابق با قوانین تجاری؛

تعامل با لایه ارائه داده برای دریافت درخواست ها و بازگشت پاسخ ها.

تعامل با لایه ذخیره سازی داده برای ارسال درخواست و دریافت پاسخ.

اغلب، لایه پردازش داده با میان افزار یک برنامه کاربردی توزیع شده شناسایی می شود. این وضعیت برای سیستم "ایده آل" کاملاً صادق است و فقط تا حدی - برای برنامه های کاربردی واقعی(شکل 3 را ببینید). در مورد دومی، میان افزار برای آنها سهم زیادی از قوانین پردازش داده را شامل می شود، اما برخی از آنها در سرورهای SQL به شکل رویه های ذخیره شده یا تریگرها پیاده سازی می شوند و برخی در نرم افزار مشتری گنجانده می شوند.

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

لایه مدیریت داده

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

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

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

علاوه بر سرویس زمان واحد، لایه مدیریت داده ممکن است شامل خدماتی برای ذخیره اطلاعات عمومی (اطلاعات در مورد برنامه به عنوان یک کل)، تولید گزارش های کلی و غیره باشد.

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

مدیریت بخش های یک برنامه کاربردی توزیع شده؛

مدیریت ارتباطات و کانال های ارتباطی بین بخش های برنامه؛

مدیریت جریان داده بین مشتریان و سرورها و بین سرورها؛

مدیریت بار؛

پیاده سازی خدمات سیستم کاربردی

لازم به ذکر است که سطح مدیریت داده ها اغلب بر اساس راه حل های آماده ارائه شده به بازار نرم افزار توسط سازندگان مختلف ایجاد می شود. اگر توسعه دهندگان معماری CORBA را برای برنامه خود انتخاب کرده باشند، آنگاه شامل یک کارگزار درخواست شی (Object Request Broker، ORB) می شود، اگر پلتفرم ویندوز باشد، آنها ابزارهای مختلفی را در خدمت خود دارند: فناوری COM + (توسعه تراکنش مایکروسافت). سرور، فناوری MTS)، فناوری پردازش صف‌های پیام MSMQ، فناوری Microsoft BizTalk و غیره.

لایه ذخیره سازی

لایه ذخیره سازی داده ها سرورهای SQL و پایگاه های داده مورد استفاده توسط برنامه را ترکیب می کند. وظایف زیر را فراهم می کند:

ذخیره سازی داده ها در پایگاه داده و نگهداری آنها در شرایط کاری؛

پردازش درخواست‌های لایه پردازش داده و بازگرداندن نتایج؛

اجرای بخشی از منطق تجاری یک برنامه کاربردی توزیع شده؛

· مدیریت پایگاه های داده توزیع شده با کمک ابزارهای مدیریتی سرورهای پایگاه داده.

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

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

اتصال به پایگاه های داده سرورهای SQLعمدتا با کمک نرم افزار مشتری سرور انجام می شود. علاوه بر این، می‌توان از فناوری‌های مختلف دسترسی به داده‌ها مانند ADO (ActiveX Data Objects) یا ADO.NET استفاده کرد. اما هنگام طراحی یک سیستم، باید در نظر گرفت که فناوری‌های دسترسی متوسط ​​به داده‌ها به لایه ذخیره‌سازی داده‌ها تعلق ندارند.

پسوندهای سطح پایه

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

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

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

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

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

لایه دسترسی به داده ها بین لایه ذخیره سازی داده و لایه پردازش داده قرار دارد. این به شما امکان می دهد ساختار برنامه را مستقل از یک فناوری ذخیره سازی داده خاص کنید. در چنین مواردی، نهادهای نرم‌افزار لایه پردازش داده‌ها درخواست‌ها را ارسال می‌کنند و پاسخ‌ها را با استفاده از ابزارهای فناوری دسترسی به داده انتخابی دریافت می‌کنند.

هنگام پیاده‌سازی برنامه‌ها بر روی پلتفرم ویندوز، فناوری دسترسی به داده‌های ADO بیشتر مورد استفاده قرار می‌گیرد، زیرا راهی جهانی برای دسترسی به منابع داده‌ای متنوع - از سرورهای SQL گرفته تا صفحات گسترده، فراهم می‌کند. برای برنامه های کاربردی در پلت فرم دات نت، از فناوری ADO.NET استفاده می شود.

n1.doc

11. معماری سیستم های توزیع شده

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

• 
  مزایا و معایب اصلی سیستم های توزیع شده را بشناسید.
• 
  درک درستی از رویکردهای مختلف مورد استفاده در توسعه معماری مشتری/سرور داشته باشند.
• 
  درک تفاوت بین معماری مشتری/سرور و معماری اشیاء توزیع شده؛
• 
  مفهوم کارگزار درخواست شی و اصول پیاده سازی شده در استانداردهای CORBA را بشناسید.

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

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

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

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

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

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

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

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

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

5. تحمل خطا.وجود رایانه های متعدد و امکان تکرار اطلاعات به این معنی است که سیستم های توزیع شده در برابر سخت افزارهای خاص مقاوم هستند و اشکالات نرم افزاری(به فصل 18 مراجعه کنید). اکثر سیستم های توزیع شده معمولاً می توانند حداقل عملکرد جزئی را در صورت بروز خطا حفظ کنند. خرابی کامل سیستم تنها در صورت بروز خطاهای شبکه رخ می دهد.

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

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

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

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

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

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

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

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

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

11.1. معماری چند پردازنده

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

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

برنج. 11.1. سیستم کنترل ترافیک چند پردازنده ای
سیستم های نرم افزاری که چندین فرآیند را همزمان اجرا می کنند لزوماً توزیع نمی شوند. اگر بیش از یک پردازنده در سیستم وجود داشته باشد، اجرای توزیع فرآیند دشوار نیست. با این حال، هنگام ایجاد سیستم های نرم افزاری چند پردازنده، لازم نیست فقط از سیستم های توزیع شده شروع شود. طراحی این نوع سیستم ها اساساً از همان رویکرد طراحی سیستم های بلادرنگ که در فصل 13 بحث شد پیروی می کند.

11.2. معماری کلاینت/سرور

فصل 10 قبلاً به مفهوم مشتری/سرور پرداخته است. در معماری کلاینت/سرور، یک برنامه نرم افزاری به عنوان مجموعه ای از خدمات ارائه شده توسط سرورها و مجموعه ای از مشتریان با استفاده از آن خدمات مدل سازی می شود. مشتریان باید از سرورهای موجود (موجود) آگاه باشند، اگرچه ممکن است از وجود مشتریان دیگر آگاه نباشند. همانطور که در شکل دیده میشود. در شکل 11.2 که نموداری از معماری مشتری/سرور توزیع شده است، کلاینت ها و سرورها فرآیندهای متفاوتی را نشان می دهند.


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

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

ساده ترین معماری سرویس گیرنده/سرور یک معماری دو لایه است که در آن یک برنامه کاربردی از یک سرور (یا بسیاری از سرورهای یکسان) و گروهی از مشتریان تشکیل شده است. دو نوع از چنین معماری وجود دارد (شکل 11.5).
1. مدل تین کلاینتدر این مدل تمامی کارهای اپلیکیشن و مدیریت داده ها بر روی سرور انجام می شود. در دستگاه مشتری، فقط نرم افزار لایه ارائه اجرا می شود.

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


برنج. 11.3. کامپیوترهای روی یک شبکه کلاینت/سرور

برنج. 11.4. لایه های کاربردی نرم افزار
تین کلاینت معماری دو لایه ساده ترین راه برای انتقال سیستم های متمرکز موجود (به فصل 26 مراجعه کنید) به معماری کلاینت/سرور است. رابط کاربری در این سیستم ها به یک رایانه شخصی "حرکت" می کند و برنامه نرم افزاری خود عملکردهای یک سرور را انجام می دهد. تمام فرآیندهای برنامه را اجرا می کند و داده ها را مدیریت می کند. مدل تین کلاینت را می‌توان در جایی که کلاینت‌ها دستگاه‌های شبکه معمولی هستند به جای رایانه‌های شخصی یا ایستگاه‌های کاری، پیاده‌سازی کرد. دستگاه های شبکه یک مرورگر اینترنت و یک رابط کاربری پیاده سازی شده در سیستم را اجرا می کنند.


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

در مقابل، مدل fat client از قدرت محاسباتی ماشین‌های محلی استفاده می‌کند: هم لایه اجرای برنامه و هم لایه ارائه بر روی کامپیوتر مشتری قرار می‌گیرند. سرور در اینجا اساساً یک سرور تراکنش است که تمام تراکنش های پایگاه داده را مدیریت می کند. نمونه ای از این نوع معماری سیستم های ATM است که در آن ATM مشتری و سرور کامپیوتر مرکزی است که پایگاه داده حساب های مشتری را نگهداری می کند.

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


برنج. 11.6. سیستم مشتری/سرور برای شبکه ATM
از آنجایی که اجرای یک برنامه نرم افزاری در یک مدل کلاینت ضخیم تر از مدل تین کلاینت سازماندهی شده است، مدیریت چنین سیستمی دشوارتر است. در اینجا، عملکردهای برنامه در بسیاری از ماشین های مختلف توزیع می شود. نیاز به جایگزینی برنامه منجر به نصب مجدد آن بر روی تمام رایانه های مشتری می شود که در صورت وجود صدها مشتری در سیستم گران است.

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

در یک مدل مشتری/سرور دو لایه، یک مشکل مهم قرار دادن سه لایه منطقی بر روی دو سیستم کامپیوتری - ارائه، اجرای برنامه و مدیریت داده ها است. بنابراین، اگر مدل تین کلاینت انتخاب شود، این مدل اغلب یا دارای مشکلات مقیاس پذیری و عملکرد است، یا در صورت استفاده از مدل کلاینت ضخیم، مشکلات مدیریت سیستم را دارد. برای جلوگیری از این مشکلات، یک رویکرد جایگزین باید اتخاذ شود - مدل سه لایه معماری مشتری/سرور (شکل 11.7). در این معماری، فرآیندهای جداگانه با لایه های ارائه، اجرای برنامه و مدیریت داده مطابقت دارند.


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

یک سیستم بانکی با استفاده از خدمات اینترنتی می تواند با استفاده از معماری مشتری/سرور سه لایه پیاده سازی شود. پایگاه داده صورتحساب (معمولاً در رایانه میزبان قرار دارد) خدمات مدیریت داده را ارائه می دهد، وب سرور از خدمات کاربردی مانند تسهیلات انتقال پول، تولید گزارش، پرداخت قبض و غیره پشتیبانی می کند و رایانه کاربر با مرورگر اینترنت مشتری است. همانطور که در شکل نشان داده شده است. 11.8، این سیستم مقیاس پذیر است زیرا اضافه کردن وب سرورهای جدید با افزایش تعداد مشتریان نسبتا آسان است.

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

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


برنج. 11.8. معماری توزیع شده سیستم بانکیاستفاده كردناینترنت-خدمات
طراحان معماری های مشتری/سرور هنگام انتخاب مناسب ترین آنها باید فاکتورهای مختلفی را در نظر بگیرند. روی میز. 11.2 کاربردهای مختلف معماری کلاینت/سرور را فهرست می کند.
جدول 11.2. کاربرد انواع متفاوتمعماری مشتری/سرور

11.3. معماری اشیاء توزیع شده

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

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


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

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

معماری سیستم کاملاً باز است که به شما امکان می دهد در صورت لزوم منابع جدیدی را به سیستم اضافه کنید. بخش بعدی اشاره می کند که استانداردهای گذرگاه نرم افزار به طور مداوم در حال تغییر هستند تا به اشیاء نوشته شده در زبان های برنامه نویسی مختلف اجازه تعامل و ارائه خدمات به یکدیگر را بدهد.

انعطاف پذیری و مقیاس پذیری سیستم. برای مقابله با بارهای سیستم، می توانید نمونه هایی از سیستم را با همان خدمات ایجاد کنید که توسط اشیاء مختلف یا نمونه های مختلف (کپی) از اشیاء ارائه می شود. هنگامی که بار افزایش می یابد، می توان اشیاء جدیدی را بدون وقفه در کار سایر اشیاء در سیستم به سیستم اضافه کرد.

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

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

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


برنج. 11.10. معماری سیستم پردازش داده های توزیع شده
برای این نوع برنامه، یک معماری شی توزیع شده به سه دلیل مناسب تر از معماری مشتری/سرور است.
1. در این سیستم ها (برخلاف، برای مثال، سیستم ATM) هیچ ارائه دهنده خدماتی وجود ندارد که تمام خدمات مدیریت داده بر روی آن متمرکز شود.

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

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

11.4. CORBA

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

در حال حاضر دو استاندارد میان افزار اصلی برای پشتیبانی از محاسبات شی توزیع شده وجود دارد.
1. CORBA (معماری کارگزار درخواست شی مشترک - معماری کارگزاران درخواست برای اشیاء مشترک). این مجموعه ای از استانداردهای میان افزاری است که توسط OMG (گروه مدیریت اشیا) توسعه یافته است. OMG کنسرسیومی متشکل از تولیدکنندگان نرم افزار و سخت افزار، از جمله شرکت هایی مانند Sun، Hewlett-Packard و IBM است. استانداردهای CORBA یک رویکرد مشترک مستقل از ماشین را برای محاسبه اشیاء توزیع شده تعریف می کنند. توسط تولید کنندگان مختلفبسیاری از پیاده سازی های این استاندارد توسعه یافته است. استانداردهای CORBA توسط سیستم عامل یونیکس و سیستم های عاملاز مایکروسافت

2. DCOM (مدل شیء جزء توزیع شده - مدل شیاجزای توزیع شده). DCOM استانداردی است که توسط مایکروسافت توسعه و پیاده سازی شده و در سیستم عامل های آن ادغام شده است. این مدل از محاسبات توزیع شده نسبت به CORBA تطبیق پذیری کمتری دارد و امکانات محدودتری برای تعاملات شبکه ارائه می دهد. DCOM در حال حاضر محدود به سیستم عامل های مایکروسافت است.
در اینجا تصمیم گرفتم به فناوری CORBA توجه کنم، زیرا همه کاره تر است. علاوه بر این، من معتقدم که احتمالاً CORBA، DCOM و سایر فناوری‌ها، مانند RMI (Remote Method Invocation - call) روش از راه دور، فناوری ساخت برنامه های کاربردی توزیع شده در زبان جاوا) به تدریج با یکدیگر همگرا می شوند و این همگرایی بر اساس استانداردهای CORBA خواهد بود. بنابراین نیازی به استاندارد دیگری نیست. استانداردهای مختلف تنها مانعی در توسعه بیشتر خواهند بود.

استانداردهای CORBA توسط گروه OMG تعریف شده است که بیش از 500 شرکت را گرد هم می آورد که از توسعه شی گرا پشتیبانی می کنند. نقش OMG ایجاد استانداردهایی برای توسعه شی گرا است، نه ارائه پیاده سازی خاصی از آن استانداردها. این استانداردها به صورت رایگان در وب سایت OMG در دسترس هستند. این گروه نه تنها به استانداردهای CORBA توجه دارد، بلکه طیف گسترده ای از استانداردهای دیگر، از جمله زبان مدل سازی UML را نیز تعریف می کند.

نمایش برنامه های کاربردی توزیع شده در CORBA در شکل نشان داده شده است. 11.11. این یک نمودار ساده از معماری مدیریت شی است که از مقاله گرفته شده است. انتظار می رود یک برنامه کاربردی توزیع شده از اجزای زیر تشکیل شود.
1. اشیاء کاربردی که برای این محصول نرم افزاری ایجاد و توسعه یافته اند.

2. اشیاء استاندارد که توسط OMG برای وظایف خاص تعریف شده است. در زمان نگارش این کتاب، افراد زیادی در توسعه استانداردهای شی برای امور مالی، بیمه، تجارت الکترونیک، مراقبت های بهداشتی و غیره مشارکت داشته اند.

3. خدمات اساسی CORBA که پشتیبانی می کنند خدمات اساسیمحاسبات توزیع شده، مانند دایرکتوری ها، مدیریت امنیت و غیره.

4. ابزارهای افقی CORBA، مانند رابط های کاربری، ابزارهای مدیریت سیستم و غیره. با ابزارهای افقی که در بسیاری از کاربردها مشترک است.


برنج. 11.11. ساختار یک برنامه کاربردی مبتنی بر استانداردهای توزیع شدهCORBA
استانداردهای CORBA چهار عنصر اصلی را توصیف می کنند.
1. یک مدل شی که در آن یک شی CORBA حالت ها را از طریق یک توصیف واضح در زبان IDL (زبان تعریف رابط) کپسوله می کند.

2. یک کارگزار درخواست شی (ORB) که درخواست ها را برای خدمات شیء مدیریت می کند. ORB اشیایی را که خدمات ارائه می دهند، تخصیص می دهد، آنها را برای دریافت درخواست ها آماده می کند، درخواست را به سرویس ارسال می کند و نتایج را به شی ای که درخواست را ارائه می دهد، برمی گرداند.

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

4. تجمیع اجزای مشترکبر پایه خدمات اصلی ساخته شده است. آنها می توانند هم عمودی باشند و هم ویژگی های یک منطقه خاص را منعکس کنند و هم اجزای جهانی افقی که در بسیاری از آنها استفاده می شود نرم افزارهای کاربردی. این مؤلفه ها در فصل 14 مورد بحث قرار می گیرند.
در مدل CORBA، یک شیء مانند یک شیء معمولی، ویژگی ها و خدمات را در بر می گیرد. با این حال، اشیاء CORBA همچنین باید شامل تعریف واسط های مختلف باشد که ویژگی ها و عملیات کلی شی را توصیف می کند. رابط های شی CORBA در استاندارد تعریف شده است زبان جهانیتوضیحات رابط های IDL اگر یک شی خدمات ارائه شده توسط اشیاء دیگر را درخواست کند، از طریق رابط IDL به آن خدمات دسترسی پیدا می کند. اشیاء CORBA دارای یک شناسه منحصر به فرد به نام مرجع شیء تعاملی (IOR) هستند. هنگامی که یک نهاد درخواست هایی را به سرویس ارائه شده توسط نهاد دیگری ارسال می کند، از شناسه IOR استفاده می شود.

کارگزار درخواست شی اشیایی که درخواست خدمات می کنند و رابط های آنها را می شناسد. تعامل بین اشیاء را سازماندهی می کند. اشیاء همکاری نیازی به دانستن هیچ چیز در مورد قرار دادن اشیاء دیگر و همچنین اجرای آنها ندارند. از آنجا که رابط IDL اشیاء را از کارگزار جدا می کند، پیاده سازی اشیاء را می توان بدون تأثیرگذاری بر سایر اجزای سیستم تغییر داد.

روی انجیر شکل 11-12 نشان می دهد که چگونه اشیاء ol و o2 از طریق واسطه درخواست شی با هم ارتباط برقرار می کنند. تماس گیرنده (ol) با یک IDL خرد مرتبط است که رابط شیئی را که سرویس را ارائه می دهد، تعریف می کند. سازنده شی ol، هنگام درخواست سرویس، فراخوانی ها را به قسمتی از اجرای شیء خود تزریق می کند. IDL یک برنامه افزودنی از C++ است، بنابراین اگر به زبان های C++، C یا جاوا برنامه نویسی می کنید، دسترسی به خرد آسان است. ترجمه توضیحات رابط یک شی به IDL برای زبان های دیگر مانند Ada یا COBOL نیز امکان پذیر است. اما در این موارد به پشتیبانی ابزاری مناسب نیاز است.

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

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

این وضعیت در شکل نشان داده شده است. 11.13. در این مثال، اگر شی ol یا o2 درخواست هایی را به خدمات ارائه شده توسط اشیاء o3 یا o4 ارسال می کند، در این صورت تعامل کارگزاران مرتبط با این اشیاء ضروری است. استانداردهای CORBA از ارتباط کارگزار به کارگزار پشتیبانی می کند، که به کارگزاران اجازه می دهد به توضیحات رابط IDL دسترسی داشته باشند و استاندارد پروتکل بین ORB عمومی (GIOP) OMG را برای ارتباطات کارگزار ارائه می دهد. این پروتکل پیام‌های استانداردی را تعریف می‌کند که کارگزاران می‌توانند هنگام برقراری تماس با شی از راه دور و ارسال اطلاعات تبادل کنند. این پروتکل همراه با پروتکل اینترنت سطح پایین TCP/IP، به کارگزاران اجازه می دهد تا از طریق اینترنت با یکدیگر ارتباط برقرار کنند.

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


برنج. 11.13. تعامل بین کارگزاران درخواست شی
خدمات CORBA ابزارهایی هستند که در بسیاری از سیستم های توزیع شده مورد نیاز هستند. این استانداردها تقریباً 15 سرویس (خدمات) مشترک را تعریف می کنند. در اینجا به برخی از آنها اشاره می کنیم.
1. یک سرویس نامگذاری که به اشیا اجازه می دهد اشیاء دیگر را در شبکه پیدا کنند و به آنها ارجاع دهند. سرویس نام یک سرویس دایرکتوری است که نام هایی را به اشیا اختصاص می دهد. اشیاء می توانند از این سرویس برای جستجوی IOR اشیاء دیگر در صورت نیاز استفاده کنند.

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

3. یک سرویس تراکنش که از تراکنش های اولیه و بازگشت در صورت بروز خطا یا شکست پشتیبانی می کند. این سرویس یک امکان تحمل خطا است (به فصل 18 مراجعه کنید) که در صورت بروز خطا در حین عملیات به روز رسانی، بازیابی را فراهم می کند. اگر اقدامات به‌روزرسانی یک شی منجر به خطا یا خرابی سیستم شود، همیشه می‌توان شی را به حالت قبل از شروع به‌روزرسانی برگرداند.
اعتقاد بر این است که استانداردهای CORBA باید شامل تعاریف واسط برای طیف وسیعی از مؤلفه‌ها باشد که می‌توانند در ساخت برنامه‌های توزیع شده مورد استفاده قرار گیرند. این اجزا می توانند عمودی یا افقی باشند. اجزای عمودی به طور خاص برای کاربردهای خاص طراحی شده اند. همانطور که قبلاً اشاره شد، توسعه تعاریف برای این مؤلفه ها شامل متخصصان بسیاری از زمینه های مختلف فعالیت می شود. اجزای افقی عمومی هستند، مانند اجزای UI.

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

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

سیستم های مشتری/سرور توزیع شده اند. چنین سیستم هایی به عنوان مجموعه ای از خدمات ارائه شده توسط سرور به فرآیندهای مشتری مدل سازی می شوند.

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

در معماری اشیاء توزیع شده، هیچ تمایزی بین کلاینت و سرور وجود ندارد. اشیا خدمات اولیه ای را ارائه می دهند که سایر اشیاء می توانند آنها را فراخوانی کنند. همین رویکرد را می توان در پیاده سازی سیستم های مشتری/سرور استفاده کرد.

سیستم های اشیاء توزیع شده باید دارای میان افزار طراحی شده باشند تا تعاملات بین اشیاء را مدیریت کند و اشیا را از سیستم اضافه یا حذف کند. از نظر مفهومی، میان افزار را می توان به عنوان یک گذرگاه نرم افزاری در نظر گرفت که اشیا به آن متصل می شوند.

استانداردهای CORBA مجموعه ای از استانداردها برای میان افزار است که از معماری شی توزیع شده پشتیبانی می کند. اینها شامل مدل شی، کارگزار درخواست شی و تعاریف سرویس مشترک است. در حال حاضر چندین پیاده سازی از استانداردهای CORBA وجود دارد.
تمرینات
11.1. توضیح دهید که چرا سیستم های توزیع شده همیشه مقیاس پذیرتر از سیستم های متمرکز هستند. محدودیت احتمالی مقیاس پذیری سیستم نرم افزار چقدر است؟

11.2. تفاوت اصلی بین مدل های ضخیم و نازک کلاینت در توسعه کلاینت/سرور چیست؟ توضیح دهید چرا استفاده از جاوا به عنوان زبان پیاده سازی، تفاوت های بین این مدل ها را هموار می کند؟

11.3. بر اساس مدل کاربردی نشان داده شده در شکل. در شکل 11.4، مشکلات بالقوه ای را که ممکن است هنگام تبدیل یک سیستم مراقبت بهداشتی مرکزی دهه 1980 به یک سیستم مشتری/سرور ایجاد شود، در نظر بگیرید.

11.4. سیستم های توزیع شده بر اساس مدل مشتری/سرور از دهه 1980 توسعه یافته اند، اما اخیراً چنین سیستم هایی مبتنی بر اشیاء توزیع شده پیاده سازی شده اند. سه دلیل برای این اتفاق بیاورید.

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

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

11.7. یک کارگزار درخواست شی چه امکانات اساسی باید ارائه دهد؟

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

• ترجمه

من دو سال پیش به‌عنوان یک توسعه‌دهنده تلفن همراه با تجربه‌ای در زمینه توسعه Back-end به Uber پیوستم. در اینجا من در حال توسعه عملکرد پرداخت در برنامه بودم - و در طول مسیر خود برنامه را بازنویسی کردم. بعد از آن به مدیریت توسعه رفتم و خود تیم را هدایت کردم. از آنجایی که تیم من مسئول بسیاری از سیستم های پشتیبان ما است که امکان پرداخت را فراهم می کند، من توانستم با بک اند بسیار نزدیکتر آشنا شوم.

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

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

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

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

SLA

• دسترسی: درصدی از زمانی که سرویس بالا می رود. در حالی که وسوسه دستیابی به 100٪ در دسترس بودن وجود دارد، دستیابی به این نتیجه می تواند واقعا دشوار و بسیار پرهزینه باشد. حتی سیستم‌های بزرگ و حیاتی مانند شبکه کارت VISA، جی‌میل یا ISP‌ها 100% در دسترس نیستند - در طول سال‌ها، ثانیه‌ها، دقیقه‌ها یا ساعت‌هایی را که در زمان خرابی صرف می‌کنند جمع می‌کنند. برای بسیاری از سیستم ها، در دسترس بودن چهار نه (99.99٪ یا حدود 50 دقیقه توقف در سال) در دسترس بودن بالا در نظر گرفته می شود. برای رسیدن به این سطح باید زیاد عرق کنید.
• دقت: آیا از دست دادن اطلاعات یا عدم دقت قابل قبول است؟ اگر بله چند درصد قابل قبول است؟ برای سیستم پرداختی که من روی آن کار می کردم، این رقم باید 100٪ باشد، زیرا هیچ راهی برای از دست دادن داده وجود نداشت.
• پهنای باند/قدرت (ظرفیت): سیستم چه باری را باید تحمل کند؟ این معیار معمولاً به صورت درخواست در ثانیه بیان می شود.
• تاخیر: سیستم تا چه زمانی باید پاسخ دهد؟ 95% و 99% درخواست ها چه مدت باید انجام شود؟ در چنین سیستم هایی معمولاً بسیاری از درخواست ها "نویز" هستند، بنابراین تاخیر p95 و p99 بیشتر است. استفاده عملیدر دنیای واقعی.

مقیاس بندی افقی و عمودی

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

مقیاس بندی عمودی اساساً "خرید یک ماشین بزرگتر/قوی تر" است - یک ماشین (مجازی) با هسته های بیشتر، بهتر قدرت پردازشو حافظه بیشتر در مورد سیستم های توزیع شده، افزایش مقیاس معمولاً محبوبیت کمتری دارد زیرا می تواند گران تر از مقیاس افقی باشد. با این حال، برخی از سایت‌های بزرگ معروف، مانند Stack Overflow، با موفقیت مقیاس عمودی را برای مطابقت با بار انجام داده‌اند.

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

ثبات

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

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

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

خروجی لیست تراکنش های اخیر به خوبی این را نشان می دهد: آنها را می توان با استفاده از سازگاری در پایان پیاده سازی کرد ( ثبات نهایی) - یعنی آخرین تراکنش ممکن است فقط مدتی بعد در برخی از قسمت های سیستم ظاهر شود، اما به لطف این، query لیست نتیجه را با تاخیر کمتری برمی گرداند یا به منابع کمتری برای اجرا نیاز دارد.

دوام داده ها

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

چرا دوام داده هنگام ساخت یک سیستم پرداخت اهمیت دارد؟ اگر داده‌ها حیاتی هستند (مانند پرداخت‌ها)، پس نمی‌توانیم آن‌ها را در بسیاری از بخش‌های سیستم خود از دست دهیم. دیتا استورهای توزیع شده ای که ما ساختیم باید از دوام داده در سطح خوشه پشتیبانی می کردند - به طوری که حتی در صورت خراب شدن نمونه ها، تراکنش های تکمیل شده باقی می ماند. این روزها، اکثر سرویس‌های ذخیره‌سازی توزیع‌شده - مانند Cassandra، MongoDB، HDFS یا Dynamodb - همگی از دوام در سطوح مختلف پشتیبانی می‌کنند و همه می‌توانند برای ارائه دوام در سطح خوشه‌ای پیکربندی شوند.

ماندگاری و دوام پیام

در مورد سیستم های توزیع شده، پیام رسانی ( پیام رسانی) معمولاً با استفاده از برخی از سرویس های پیام رسانی توزیع شده - RabbitMQ، Kafka یا دیگران انجام می شود. این کارگزاران پیام ممکن است پشتیبانی کنند (یا برای پشتیبانی پیکربندی شده باشند) سطوح مختلفقابلیت اطمینان تحویل پیام

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


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

ناتوانی

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

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

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

شاردینگ و حد نصاب

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

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

مدل بازیگر

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

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

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

به عنوان مبنایی برای توصیف تعامل دو نهاد، مدل کلی تعامل مشتری و سرور را در نظر بگیرید، که در آن یکی از طرفین (مشتری) با ارسال یک درخواست به طرف دیگر (سرور) مبادله داده را آغاز می کند. سرور درخواست را پردازش می کند و در صورت لزوم، پاسخی را برای مشتری ارسال می کند (شکل 1.1).

برنج. 1.1.

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

برخی را در نظر بگیرید نرم افزار معمولی، که مطابق با ایده های مدرن می توان به سطوح منطقی زیر تقسیم کرد (شکل 1.2): رابط کاربری(IP)، منطق برنامه (LP) و دسترسی به داده (DD) کار با پایگاه داده (DB). کاربر سیستم از طریق رابط کاربری با آن تعامل دارد، پایگاه داده داده هایی را که حوزه موضوع برنامه را توصیف می کند ذخیره می کند و لایه منطق برنامه تمام الگوریتم های مربوط به موضوع.

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

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

توسعه معماری مشتری-سرور یک معماری سه لایه است که در آن رابط کاربری، منطق برنامه و دسترسی به داده ها به اجزای مستقل سیستم که می توانند بر روی رایانه های مستقل اجرا شوند، جدا می شوند (شکل 1.4).

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