اقدامات ذکر شده در زیر برای اجرا نسبتاً ساده هستند اما تأثیر زیادی دارند. اگر قبلا آنها را امتحان نکرده اید، از پیشرفت های قابل توجه شگفت زده خواهید شد.
زیرساخت به عنوان کد
بخش اول توصیه، پیاده سازی زیرساخت به صورت کد است. این بدان معنی است که شما باید یک روش برنامهریزی برای استقرار کل زیرساخت داشته باشید. پیچیده به نظر می رسد، اما ما در واقع در مورد کد زیر صحبت می کنیم:
استقرار 100 ماشین مجازی
با اوبونتو
هر کدام 2 گیگابایت رم
کد زیر را خواهند داشت
با این پارامترها
می توانید تغییرات زیرساخت خود را ردیابی کنید و با استفاده از کنترل نسخه به سرعت به آنها برگردید.
مدرنیست در من می گوید شما می توانید از Kubernetes/Docker برای انجام همه موارد بالا استفاده کنید و او درست می گوید.
علاوه بر این، می توانید اتوماسیون را با استفاده از Chef، Puppet یا Terraform ارائه دهید.
ادغام و تحویل مستمر
برای ایجاد یک سرویس مقیاس پذیر، داشتن یک خط لوله ساخت و آزمایش برای هر درخواست کشش مهم است. حتی اگر تست بسیار ساده باشد، حداقل از کامپایل شدن کدی که شما مستقر می کنید اطمینان حاصل می کند.
هر بار در این مرحله به این سوال پاسخ می دهید: آیا اسمبلی من تست ها را کامپایل و قبول می کند، آیا معتبر است؟ این ممکن است یک نوار پایین به نظر برسد، اما بسیاری از مشکلات را حل می کند.
هیچ چیز زیباتر از دیدن این کنه ها نیست
برای این فناوری می توانید Github، CircleCI یا Jenkins را ارزیابی کنید.
متعادل کننده های بار
بنابراین، ما می خواهیم یک متعادل کننده بار را اجرا کنیم تا ترافیک را تغییر مسیر دهیم و از بار مساوی در همه گره ها اطمینان حاصل کنیم یا در صورت خرابی سرویس ادامه یابد:
یک متعادل کننده بار معمولاً کار خوبی در توزیع ترافیک انجام می دهد. بهترین تمرین این است که بیش از حد تعادل ایجاد کنید تا حتی یک نقطه شکست نداشته باشید.
به طور معمول، بار متعادل کننده ها در ابری که استفاده می کنید پیکربندی می شوند.
RayID، شناسه همبستگی یا UUID برای درخواستها
آیا تا به حال با یک خطای برنامه با پیامی مانند زیر مواجه شده اید: "مشکلی پیش آمد. این شناسه را ذخیره کنید و برای تیم پشتیبانی ما ارسال کنید"?
یک شناسه منحصر به فرد، شناسه همبستگی، RayID یا هر یک از تغییرات، یک شناسه منحصر به فرد است که به شما امکان می دهد یک درخواست را در طول چرخه عمر آن ردیابی کنید. این به شما امکان می دهد کل مسیر درخواست را در گزارش ها ردیابی کنید.
کاربر درخواستی را به سیستم A ارسال می کند، سپس A مخاطب B، که با C تماس می گیرد، آن را در X ذخیره می کند و سپس درخواست به A برگردانده می شود.
اگر از راه دور به ماشینهای مجازی متصل میشوید و سعی میکنید مسیر درخواست را ردیابی کنید (و به صورت دستی تماسهایی را که برقرار میشوند مرتبط کنید)، دیوانه خواهید شد. داشتن یک شناسه منحصر به فرد زندگی را بسیار آسان تر می کند. این یکی از ساده ترین کارهایی است که می توانید برای صرفه جویی در زمان با افزایش خدمات خود انجام دهید.
سطح متوسط
مشاوره در اینجا پیچیدهتر از موارد قبلی است، اما ابزارهای مناسب کار را آسانتر میکنند و بازگشت سرمایه را حتی برای شرکتهای کوچک و متوسط فراهم میکنند.
جنگلداری متمرکز
تبریک می گویم! شما 100 ماشین مجازی مستقر کرده اید. فردای آن روز مدیرعامل می آید و از خطایی که هنگام تست سرویس دریافت کرده شکایت می کند. این شناسه مربوطه را گزارش می کند که در بالا در مورد آن صحبت کردیم، اما باید لاگ 100 دستگاه را جستجو کنید تا دستگاهی که باعث خرابی شده است را پیدا کنید. و باید قبل از ارائه فردا پیدا شود.
در حالی که این یک ماجراجویی سرگرم کننده به نظر می رسد، بهتر است مطمئن شوید که توانایی جستجوی همه مجلات را در یک مکان دارید. من مشکل متمرکز کردن گزارش ها را با استفاده از عملکرد داخلی پشته ELK حل کردم: از مجموعه گزارش های قابل جستجو پشتیبانی می کند. این واقعاً به حل مشکل یافتن یک مجله خاص کمک می کند. به عنوان یک امتیاز، می توانید نمودارها و چیزهای سرگرم کننده دیگری مانند آن ایجاد کنید.
عملکرد پشته ELK
عوامل نظارتی
اکنون که سرویس شما راه اندازی شده است، باید مطمئن شوید که به خوبی اجرا می شود. بهترین راه برای انجام این کار اجرای چندین است عوامل، که به صورت موازی کار می کنند و بررسی می کنند که کار می کند و عملیات اساسی انجام می شود.
در این مرحله شما آن را بررسی می کنید ساخت در حال اجرا احساس خوبی دارد و خوب کار می کند.
برای پروژه های کوچک تا متوسط، من Postman را برای نظارت و مستندسازی API ها توصیه می کنم. اما به طور کلی، شما فقط می خواهید مطمئن شوید که راهی برای اطلاع از زمان وقوع قطعی وجود دارد و به موقع به شما اطلاع داده می شود.
مقیاس خودکار بسته به بار
خیلی ساده است. اگر درخواست سرویس VM دارید و مصرف آن به 80٪ از حافظه نزدیک می شود، می توانید منابع آن را افزایش دهید یا ماشین های مجازی بیشتری را به خوشه اضافه کنید. اجرای خودکار این عملیات برای تغییرات الاستیک توان تحت بار بسیار عالی است. اما همیشه باید مراقب میزان پولی که خرج می کنید باشید و محدودیت های معقولی را تعیین کنید.
با اکثر سرویسهای ابری، میتوانید با استفاده از سرورهای بیشتر یا سرورهای قدرتمندتر، آن را برای مقیاس خودکار پیکربندی کنید.
سیستم آزمایشی
یک راه خوب برای ارائه ایمن بهروزرسانیها این است که بتوانید چیزی را برای 1% از کاربران به مدت یک ساعت آزمایش کنید. شما البته چنین مکانیسم هایی را در عمل دیده اید. به عنوان مثال، فیس بوک به قسمت هایی از مخاطبان رنگ متفاوتی نشان می دهد یا اندازه فونت را تغییر می دهد تا ببیند کاربران چگونه تغییرات را درک می کنند. به این تست A/B می گویند.
حتی انتشار یک ویژگی جدید را می توان به عنوان یک آزمایش شروع کرد و سپس نحوه انتشار آن را تعیین کرد. همچنین میتوانید «به خاطر بسپارید» یا پیکربندی را بر اساس عملکردی که باعث تخریب سرویس شما میشود، تغییر دهید.
سطح پیشرفته
در اینجا نکاتی وجود دارد که اجرای آنها بسیار دشوار است. احتمالاً به منابع بیشتری نیاز خواهید داشت، بنابراین یک شرکت کوچک یا متوسط برای مدیریت این موضوع مشکل خواهد داشت.
استقرارهای سبز-آبی
این همان چیزی است که من آن را روش "ارلنگ" می نامم. ارلنگ با ظهور شرکت های تلفن به طور گسترده مورد استفاده قرار گرفت. سوئیچ های نرم افزاری برای مسیریابی تماس های تلفنی مورد استفاده قرار گرفتند. هدف اصلی نرم افزار روی این سوئیچ ها عدم قطع تماس در حین ارتقاء سیستم بود. Erlang روش خوبی برای بارگذاری یک ماژول جدید بدون خراب شدن ماژول قبلی دارد.
این مرحله به وجود یک متعادل کننده بار بستگی دارد. بیایید تصور کنیم نسخه N نرم افزار خود را دارید و سپس می خواهید نسخه N+1 را اجرا کنید.
شما می توانست فقط سرویس را متوقف کنید و نسخه بعدی را در زمانی که برای کاربران شما کار می کند عرضه کنید و مدتی از کار افتادگی دریافت کنید. اما فرض کنید که دارید واقعا شرایط سختگیرانه SLA بنابراین، SLA 99,99٪ به این معنی است که می توانید آفلاین شوید تنها 52 دقیقه در سال
اگر واقعاً می خواهید به چنین شاخص هایی دست پیدا کنید، به دو استقرار همزمان نیاز دارید:
چیزی که در حال حاضر است (N)؛
نسخه بعدی (N+1).
شما به متعادل کننده بار می گویید که درصدی از ترافیک را به نسخه جدید (N+1) هدایت کند در حالی که شما فعالانه برای رگرسیون ها نظارت می کنید.
در اینجا ما یک استقرار N سبز داریم که به خوبی کار می کند. ما در حال تلاش برای انتقال به نسخه بعدی این استقرار هستیم
ابتدا یک آزمایش بسیار کوچک ارسال می کنیم تا ببینیم آیا استقرار N+1 ما با ترافیک کمی کار می کند یا خیر:
در نهایت، ما مجموعهای از بررسیهای خودکار را داریم که در نهایت تا زمانی که استقرار ما کامل شود اجرا میکنیم. اگر شما خیلی خیلی مراقب باشید، همچنین می توانید استقرار N خود را برای همیشه برای بازگشت سریع در صورت رگرسیون بد ذخیره کنید:
اگر می خواهید به سطح پیشرفته تری بروید، اجازه دهید همه چیز در استقرار سبز-آبی به طور خودکار اجرا شود.
تشخیص ناهنجاری و کاهش خودکار
با توجه به اینکه شما ثبت نام متمرکز و جمع آوری گزارش های خوبی دارید، می توانید اهداف بالاتری را تعیین کنید. به عنوان مثال، به طور فعالانه شکست ها را پیش بینی کنید. عملکردها بر روی مانیتورها و گزارشها ردیابی میشوند و نمودارهای مختلفی ساخته میشوند - و میتوانید از قبل پیشبینی کنید که چه چیزی اشتباه میشود:
پس از شناسایی ناهنجاری ها، شروع به بررسی برخی از سرنخ هایی می کنید که سرویس ارائه می دهد. به عنوان مثال، افزایش بار CPU ممکن است نشان دهنده خرابی هارد دیسک باشد، در حالی که افزایش درخواست ها ممکن است نشان دهنده این باشد که شما باید مقیاس را افزایش دهید. این نوع داده های آماری به شما امکان می دهد خدمات را فعال کنید.
با استفاده از این بینش ها، می توانید در هر بعد مقیاس بندی کنید و به طور فعال و واکنشی ویژگی های ماشین ها، پایگاه های داده، اتصالات و سایر منابع را تغییر دهید.
همین!
اگر در حال ارتقاء یک سرویس ابری هستید، این لیست از اولویت ها شما را از مشکلات زیادی نجات می دهد.
نویسنده مقاله اصلی از خوانندگان دعوت می کند تا نظرات خود را بنویسند و تغییراتی ایجاد کنند. مقاله به عنوان منبع باز توزیع شده است، درخواست های کشش توسط نویسنده در Github می پذیرد.