🥇بدون سرور توسط رک

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

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

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

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

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

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

بیایید ببینیم روند توسعه برنامه اکنون چگونه خواهد بود.

از طرف توسعه دهنده

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

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

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

توابع بدون سرور باید در مدت زمان کوتاهی (تایم اوت) که توسط ارائه دهنده خدمات تعیین می شود، اجرا شوند. به عنوان مثال، برای AWS فاصله زمانی 15 دقیقه است. این بدان معنی است که عملکردهای طولانی مدت باید برای مطابقت با نیازها تغییر کنند - این همان چیزی است که Serverless را از سایر فناوری های رایج امروزی (کانتینرها و پلت فرم به عنوان سرویس) متمایز می کند.

به هر تابع یک رویداد اختصاص می دهیم. یک رویداد محرک یک عمل است:

رویداد
عملی که تابع انجام می دهد

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

آدرس فروشگاه فیزیکی در پایگاه داده به روز شده است
یک مکان جدید را در نقشه ها بارگیری کنید

مشتری هزینه کالا را پرداخت می کند
شروع پردازش پرداخت

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

معماری کار شد و برنامه تقریباً بدون سرور شد. در مرحله بعد به سراغ ارائه دهنده خدمات می رویم.

از طرف ارائه دهنده

به طور معمول، محاسبات بدون سرور توسط ارائه دهندگان خدمات ابری ارائه می شود. آنها متفاوت نامیده می شوند: توابع Azure، AWS Lambda، Google Cloud Functions، IBM Cloud Functions.

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

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

در اینجا رویدادهایی را تنظیم می کنیم که تابع را فراخوانی می کنند. مجموعه رویدادها ممکن است برای ارائه دهندگان مختلف متفاوت باشد.

ارائه دهنده سیستم Function as a Service (FaaS) را در زیرساخت خود ساخته و خودکار کرده است:

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

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

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

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

از سمت منبع باز

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

گوگل ابزار منبع باز خود را به توسعه دهندگان ارائه می دهد - چاقو. IBM، RedHat، Pivotal و SAP در توسعه آن شرکت داشتند.
آی بی ام روی پلتفرم بدون سرور کار می کرد OpenWhisk، که سپس به پروژه بنیاد آپاچی تبدیل شد.
مایکروسافت کد پلت فرم را تا حدی باز کرد توابع لاجوردی.

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

چارچوب ها فضایی را برای پیکربندی ابزار متناسب با نیازهای شما باقی می گذارند. بنابراین، در Kubeless، یک توسعه‌دهنده می‌تواند زمان اجرای تابع را پیکربندی کند (مقدار پیش‌فرض 180 ثانیه است). Fission، در تلاشی برای حل مشکل شروع سرد، پیشنهاد می‌کند که برخی از کانتینرها همیشه در حال کار باشند (اگرچه این مستلزم هزینه‌های خرابی منابع است). و OpenFaaS مجموعه ای از محرک ها را برای هر سلیقه و رنگی ارائه می دهد: HTTP، Kafka، Redis، MQTT، Cron، AWS SQS، NATs و دیگران.

دستورالعمل های شروع را می توان در اسناد رسمی چارچوب ها یافت. کار با آنها مستلزم داشتن مهارت های کمی بیشتر از زمان کار با یک ارائه دهنده است - این حداقل توانایی راه اندازی یک خوشه Kubernetes از طریق CLI است. حداکثر، سایر ابزارهای منبع باز (مثلاً مدیر صف کافکا) را نیز در نظر بگیرید.

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

از نظر مزایا و معایب

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

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

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

مانند هر فناوری دیگری، سرور بدون سرور دارای معایبی است.

به عنوان مثال، چنین نقطه ضعفی ممکن است زمان شروع سرد باشد (به طور متوسط تا 1 ثانیه برای زبان هایی مانند JavaScript، Python، Go، Java، Ruby).

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

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

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

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

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

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

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

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

در این راستا، من می خواهم به آرامی به موضوع استفاده از رویکرد بدون سرور بپردازم.

از سمت برنامه

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

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

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

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

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

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

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

بدون سرور و Selectel

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

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

مواد استفاده شده در مقاله:

منبع: www.habr.com

بدون سرور روی رک ها