راهنمای معمار راه حل برای سرور بدون سرور

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

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

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

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

تنظیم مستقیم رکورد

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

آنها فقط برای برنامه های بدون سرور هستند

احتمالاً بزرگترین افسانه موجود این است که خدمات بدون سرور منحصراً برای برنامه های بدون سرور طراحی شده اند. این درست نیست! می‌توانید از سرویس‌های بدون سرور در هر نرم‌افزاری، خواه یک برنامه مبتنی بر Kubernetes، یک راه‌حل اولیه یا یک API بدون سرور استفاده کنید. این خدمات ارائه می کنند قابلیت های بدون سرور، مانند پرداخت برای آنچه شما استفاده می کنید، مقیاس بندی الاستیک (از جمله تا 0 در صورت عدم استفاده)، و عملیات ساده کنترل/طرح داده «این فقط کار می کند».

می‌توانید از سرویس‌هایی مانند Amazon DynamoDB یا MongoDB Atlas به‌عنوان ذخیره اولیه داده‌های خود در یک برنامه مبتنی بر کانتینر استفاده کنید. این خدمات پایگاه داده بدون سرور برای ساده سازی توسعه و نگهداری طولانی مدت با ارائه APIهای ساده برای انجام عملیات قدرتمند در نظر گرفته شده است. آنها نگهداری و مدیریت سخت افزار را از شما انتزاع می کنند تا تیم های مهندسی شما بتوانند روی چیز مهمتری تمرکز کنند – حل مشکل کسب و کار.

آنها بسیار گران هستند “در مقیاس”

من قبلاً این را از رهبران ارشد شرکت های بزرگ دریافت می کردم. اول از همه، افراد زیادی نمی توانند معنی واقعی “در مقیاس” را بیان کنند. آیا این به معنی تعداد مشتریان پرداخت کننده است؟ آیا این به میزان ترافیک وارد شده به برنامه شما اشاره دارد؟ آیا تعداد کاربران فعال روزانه است؟ حتی اگر همه ما در مورد آنچه «در مقیاس» به آن اشاره می‌شود توافق داشته باشیم، دیدگاه نیز نقش بزرگی در معادله بازی می‌کند. برای یک استارتاپ، «در مقیاس» ممکن است به ۱۰۰ تراکنش در ساعت اشاره داشته باشد. برای شرکت های بزرگ و چند مستاجر، ممکن است به معنای 10000 تراکنش در ثانیه باشد.

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

شروع سرد غیر شروع کننده است

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

بنا به دلایلی، بسیاری از مردم تصور می‌کنند که چندین ثانیه طول می‌کشد و اکثر تماس‌ها به یک API بدون سرور منجر به شروع سرد می‌شود. مگر اینکه به طور مداوم بارهای کاری spikey داشته باشید، اینطور نیست. ترافیک مداوم به ندرت منجر به شروع سرد می شود. در مورد مدت زمان، می توانید خودتان ببینید که بسته به زمان اجرا که استفاده می کنید، از ~ 18 تا ~ 500 میلی ثانیه متغیر است.

بسیاری از بارهای کاری ضربه تأخیر متناوب یک شروع سرد را تحمل می کنند. تأخیر اغلب حداقل است و معمولاً فقط در دوره‌های ترافیک ناسازگار دیده می‌شود.

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

سورپرایز دارم احتمالاً از یک سرویس بدون سرور استفاده کرده اید و متوجه آن نشده اید. آیا تا به حال از Amazon EC2 استفاده کرده اید؟ AMI های شما در S3 ذخیره می شوند که یک سرویس بدون سرور است. آیا با استفاده از API Twilio ارسال کرده اید؟ آنها بدون سرور هستند.

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

ملاحظات طراحی

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

خاصیت ارتجاعی مهم است

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

در مثال بالا، ما یک برنامه کاربردی موجود در EC2 داشتیم. بهبود ما یک API بدون سرور اضافه کرد که به عنوان نقطه ورود عمل می کند. قبل از انتشار وب هوک، اعتبارسنجی و غنی‌سازی را انجام می‌دهد تا فرآیند موجود در EC2 را راه‌اندازی کند.

API و خدمات پشتیبان بدون سرور جدید تا 10000 درخواست در ثانیه مقیاس خواهند داشت (محدودیت سرویس API Gateway). تابع Lambda از SNS برای انتشار در یک وب هوک که توسط نمونه EC2 در معرض دید قرار می گیرد، استفاده می کند. اندازه نمونه EC2 تنها می تواند تا 500 درخواست در ثانیه را مدیریت کند.

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

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

توجه به این نکته مهم است که اگر API بدون سرور شما به طور مداوم موارد را سریعتر از خواندن آنها توسط EC2 وارد صف SQS کند، شما یک انحراف دائمی از رویدادها ایجاد خواهید کرد. در این سناریو، نمونه EC2 شما باید به اندازه موارد کاری سریعتر از آنچه وارد می شود، بزرگ شود.

با ارکستراسیون شروع کنید

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

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

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

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

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

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

طراحی برای امتحان مجدد

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

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

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

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

خلاصه

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

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

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

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

کد نویسی مبارک!