دنیا نمی ایستد. پیشرفت چالش های تکنولوژیکی جدیدی ایجاد می کند. مطابق با الزامات در حال تغییر، معماری سیستم های اطلاعاتی باید تکامل یابد. امروز ما در مورد معماری رویداد محور، همزمانی، همزمانی، ناهمزمانی و اینکه چگونه می توانید با همه اینها در ارلنگ با آرامش زندگی کنید صحبت خواهیم کرد.
معرفی
بسته به اندازه سیستم طراحی شده و الزامات آن، ما توسعه دهندگان، روش تبادل اطلاعات در سیستم را انتخاب می کنیم. در بیشتر موارد، برای سازماندهی تعامل خدمات، یک گزینه کاری ممکن است طرحی با یک کارگزار باشد، به عنوان مثال، بر اساس RabbitMQ یا کافکا. اما گاهی اوقات جریان رویدادها، SLA و سطح کنترل سیستم به گونه ای است که پیام های آماده برای ما مناسب نیست. البته، می توانید با به عهده گرفتن مسئولیت لایه انتقال و تشکیل خوشه، برای مثال استفاده از ZeroMQ یا nanomsg، سیستم را کمی پیچیده کنید. اما اگر سیستم دارای توان عملیاتی و توانمندی های یک خوشه استاندارد ارلنگ باشد، موضوع معرفی موجودیت اضافی مستلزم مطالعه دقیق و توجیه اقتصادی است.
موضوع برنامه های کاربردی توزیع شده واکنشی بسیار گسترده است. برای حفظ قالب مقاله، موضوع بحث امروز فقط محیط های همگن ساخته شده بر روی Erlang/Elixir خواهد بود. اکوسیستم Erlang/OTP به شما اجازه می دهد تا با کمترین تلاش، یک معماری واکنشی را پیاده سازی کنید. اما در هر صورت به یک لایه پیام رسانی نیاز خواهیم داشت.
مبانی نظری
طراحی با تعریف اهداف و محدودیت ها آغاز می شود. هدف اصلی در حوزه توسعه به خاطر توسعه نیست. ما باید ابزاری امن و مقیاس‌پذیر به‌دست آوریم که بر اساس آن بتوانیم برنامه‌های کاربردی مدرن در سطوح مختلف ایجاد کنیم و از همه مهمتر توسعه دهیم: از برنامه‌های تک سروری که به مخاطبان کوچکی خدمت می‌کنند، که بعداً می‌توانند به خوشه‌هایی تا 50 نفر تبدیل شوند. -60 گره که به فدراسیون های خوشه ای ختم می شود. بنابراین، هدف اصلی به حداکثر رساندن سود با کاهش هزینه توسعه و مالکیت سیستم نهایی است.
اجازه دهید 4 الزام اصلی برای سیستم نهایی را برجسته کنیم:
- Сرویداد محور
سیستم همیشه آماده عبور از جریان رویدادها و انجام اقدامات لازم است. - Мمقیاس پذیری
بلوک های مجزا را می توان هم به صورت عمودی و هم به صورت افقی مقیاس بندی کرد. کل سیستم باید قابلیت رشد افقی بی نهایت را داشته باشد. - Оتحمل خطا.
همه سطوح و همه سرویس ها باید بتوانند به طور خودکار از خرابی ها بازیابی شوند. - Гزمان پاسخگویی تضمین شده
زمان ارزشمند است و کاربران نباید زیاد منتظر بمانند.
افسانه قدیمی "موتور کوچکی که می توانست" را به خاطر دارید؟ برای اینکه سیستم طراحی شده با موفقیت از مرحله نمونه اولیه خارج شود و پیشرو باشد، پایه آن باید حداقل الزامات را داشته باشد. SMOG.
یک نکته دیگر به پیام‌رسانی به‌عنوان ابزار زیرساختی و پایه‌ای برای همه خدمات اضافه می‌شود: سهولت استفاده برای برنامه‌نویسان.
رویداد محور
برای اینکه یک برنامه کاربردی از یک سرور واحد به یک خوشه تبدیل شود، معماری آن باید از اتصال آزاد پشتیبانی کند. مدل ناهمزمان این نیاز را برآورده می کند. در آن، فرستنده و گیرنده به بار اطلاعاتی پیام اهمیت می دهند و نگران انتقال و مسیریابی درون سیستم نیستند.
مقیاس پذیری
مقیاس پذیری و کارایی سیستم در کنار یکدیگر هستند. اجزای برنامه باید بتوانند از تمام منابع موجود استفاده کنند. هرچه بتوانیم از ظرفیت بهینه‌تر استفاده کنیم و روش‌های پردازش بهینه‌تر باشد، هزینه کمتری برای تجهیزات صرف می‌کنیم.
ارلنگ در یک ماشین یک محیط کاملا رقابتی ایجاد می کند. تعادل بین همزمانی و موازی بودن را می توان با انتخاب تعداد رشته های سیستم عامل موجود برای Erlang VM و تعداد زمانبندی هایی که از این رشته ها استفاده می کنند تنظیم کرد.
فرآیندهای Erlang حالت مشترک ندارند و در حالت غیر مسدود عمل می کنند. این تأخیر نسبتاً کم و توان عملیاتی بالاتری را نسبت به برنامه‌های مبتنی بر مسدود کردن سنتی ارائه می‌کند. زمانبندی Erlang تخصیص عادلانه CPU و IO را تضمین می‌کند و عدم مسدود کردن به برنامه اجازه می‌دهد حتی در زمان اوج بار یا خرابی پاسخ دهد.
در سطح خوشه، مشکل دفع نیز وجود دارد. مهم است که همه ماشین‌های موجود در کلاستر به طور یکنواخت بارگذاری شوند و شبکه بیش از حد بارگذاری نشود. بیایید وضعیتی را تصور کنیم: ترافیک کاربر بر روی متعادل کننده های ورودی (haproxy، nginx و غیره) قرار می گیرد، آنها درخواست های پردازش را تا حد امکان به طور مساوی بین مجموعه پشتیبان های موجود توزیع می کنند. در زیرساخت برنامه، سرویسی که رابط مورد نیاز را پیاده‌سازی می‌کند، تنها آخرین مایل است و برای پاسخ به درخواست اولیه، نیاز به درخواست تعدادی سرویس دیگر دارد. درخواست های داخلی نیز نیازمند مسیریابی و تعادل هستند.
برای مدیریت موثر جریان داده، پیام رسانی باید یک رابط برای مدیریت مسیریابی و تعادل بار در اختیار توسعه دهندگان قرار دهد. به لطف این، توسعه‌دهندگان قادر خواهند بود با استفاده از الگوهای میکروسرویس (جمع‌کننده، پروکسی، زنجیره، شاخه، و غیره) مشکلات استاندارد و مشکلاتی را که به ندرت پیش می‌آیند را حل کنند.
از دیدگاه تجاری، مقیاس پذیری یکی از ابزارهای مدیریت ریسک است. نکته اصلی این است که با استفاده بهینه از تجهیزات، خواسته های مشتری را برآورده کنید:
- هنگامی که قدرت تجهیزات در نتیجه پیشرفت افزایش می یابد. به دلیل نرم افزار ناقص بیکار نخواهد بود. Erlang به صورت عمودی به خوبی مقیاس می شود و همیشه می تواند از تمام هسته های CPU و حافظه موجود استفاده کند.
- در محیط های ابری، می توانیم مقدار تجهیزات را بسته به بار فعلی یا پیش بینی شده مدیریت کنیم و SLA را تضمین کنیم.
تحمل خطا
بیایید دو اصل را در نظر بگیریم: "شکست ها غیر قابل قبول هستند" و "شکست ها همیشه وجود خواهند داشت." برای یک تجارت، شکست نرم افزار به معنای از دست دادن پول و بدتر از آن، از دست دادن شهرت است. با ایجاد تعادل بین ضررهای احتمالی و هزینه توسعه نرم افزارهای مقاوم در برابر خطا، اغلب می توان مصالحه ای پیدا کرد.
در کوتاه‌مدت، معماری که تحمل خطا را در بر می‌گیرد باعث صرفه‌جویی در هزینه خرید راه‌حل‌های خوشه‌بندی خارج از قفسه می‌شود. آنها گران هستند و همچنین دارای اشکال هستند.
در درازمدت، یک معماری مقاوم در برابر خطا در تمام مراحل توسعه هزینه خود را چندین برابر می کند.
پیام‌رسانی در پایگاه کد به شما امکان می‌دهد تا تعامل اجزای درون سیستم را در مرحله توسعه با جزئیات بررسی کنید. این کار پاسخگویی و مدیریت خرابی‌ها را ساده‌تر می‌کند، زیرا تمام اجزای حیاتی خرابی‌ها را مدیریت می‌کنند، و سیستم حاصل می‌داند که چگونه به‌طور خودکار پس از شکست توسط طراحی به حالت عادی بازگردد.
پاسخگویی
صرف نظر از خرابی ها، برنامه باید به درخواست ها پاسخ دهد و SLA را برآورده کند. واقعیت این است که مردم نمی‌خواهند منتظر بمانند، بنابراین کسب‌وکارها باید مطابق با آن سازگار شوند. انتظار می رود برنامه های بیشتر و بیشتری به شدت پاسخگو باشند.
برنامه های پاسخگو تقریباً در زمان واقعی کار می کنند. Erlang VM در حالت زمان واقعی نرم کار می کند. برای برخی از حوزه‌ها، مانند معاملات سهام، پزشکی و کنترل تجهیزات صنعتی، حالت بلادرنگ سخت مهم است.
سیستم های پاسخگو UX را بهبود می بخشند و برای کسب و کار مفید هستند.
خلاصه مقدماتی
هنگام برنامه ریزی این مقاله، می خواستم تجربه خود را از ایجاد یک کارگزار پیام رسانی و ساخت سیستم های پیچیده بر اساس آن به اشتراک بگذارم. اما بخش نظری و انگیزشی کاملاً گسترده بود.
در قسمت دوم مقاله، در مورد تفاوت های ظریف پیاده سازی نقاط تبادل، الگوهای پیام رسانی و کاربرد آنها صحبت خواهم کرد.
در قسمت سوم به مسائل کلی سازماندهی خدمات، مسیریابی و تعادل می پردازیم. بیایید در مورد جنبه عملی مقیاس پذیری و تحمل خطا سیستم ها صحبت کنیم.
پایان قسمت اول.
عکس .
منبع: www.habr.com