معماری بومی ابر

صنایع پایداری که سالها تحت سلطه رهبران خود جا افتاده بوده اند، درحال مختل شدن توسط صنعت نرم افزار هستند. شرکت هایی مانند Square ، Uber ، Netflix ، Airbnb و Tesla همچنان دارای ارزش بازار خصوصی هستند که به سرعت در حال رشد است. اشتراک این شرکت های نوآور در چیست؟

سرعت نوآوری

سرویس های دسترس پذیر

مقیاس وب

تجارب کاربر مبتنی بر موبایل

حرکت به سمت ابر، تحولی طبیعی در تمرکز برروی نرم افزار بوده و معماری برنامه های کاربردی بومی، در مرکز رسیدن به ویژگی های حیاتی این شرکت هاست. منظور از ابر، هر محیط محاسباتی است که در آن می توان منابع محاسباتی ، شبکه ای و ذخیره سازی را بصورت سلف سرویس بر اساس تقاضا تهیه و آزاد نمود. این تعریف شامل زیرساخت‌های ابری عمومی همچون سرویس‌های وب آمازون ، Google Cloud یا Microsoft Azure و زیرساخت‌های ابری خصوصی مانند VMware vSphere یا OpenStack است.

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

چرا معماری برنامه بومی ابر؟

ابتدا انگیزه های رایج در انتقال به معماری کاربردی بومی ابر را بررسی می نماییم.

سرعت

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

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

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

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

امنیت

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

چگونه سریع و ایمن پیش برویم؟

قابلیت دیده شدن یا پدیداری

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

ایزوله‌سازی اشتباه

برای محدود کردن خطر همراه با خرابی، باید دامنه اجزا (components) یا ویژگی هایی را که می توانند تحت تأثیر خرابی قرار گیرند، محدود کنیم. اگر هربار که موتور توصیه‌ها از کار می‌افتد، کسی نتواند از سایت Amazon.com محصولی را خریداری کند، این فاجعه بار خواهد بود. معماری‌های برنامه یکپارچه، اغلب دارای این نوع حالت خرابی هستند. معماری برنامه بومی ابر معمولا از میکرو سرویس‌ها استفاده می‌کنند.

تحمل خطا

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

بازیابی خودکار

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

مقیاس

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

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

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

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

برنامه های تلفن همراه و تنوع مشتری

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

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

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

برنامه‌های تلفن همراه اغلب مجبورند با چندین سیستم قدیمی و همچنین چندین میکروسرویس در یک معماری برنامه ابری تعامل داشته باشند. این سرویس ها را نمی‌توان برای تأمین نیازهای منحصر به فرد هر یک از سیستم عامل‌های مختلف تلفن همراهِ مورد استفاده مشتریان طراحی کرد. مجبور کردن بار ادغام این سرویس های متنوع برروی توسعه دهنده تلفن همراه، تأخیر و ترافیک شبکه را افزایش می‌دهد که این امر منجر به کندی زمان پاسخ‌دهی و مصرف زیاد باتری شده و در نهایت کاربران منجر به حذف برنامه شما می‌شوند! معماری‌های برنامه‌های بومی ابری از مفهوم توسعه همراه اول از طریق الگوهای طراحی مانند API Gateway پشتیبانی می‌کنند که بار تجمیع خدمات را به سمت سرور منتقل می‌کند.

تعریف معماری بومی ابری

اکنون چند ویژگی اصلی معماری برنامه های بومی ابر را بررسی خواهیم کرد. همچنین خواهیم دید که چگونه این ویژگی‌ها مواردی را که قبلاً بحث کردیم، برطرف می‌سازد.

Twelve-Factor Applications یا برنامه های دوازده عاملی

برنامه دوازده عاملی مجموعه‌ای از الگوهای معماری کاربردهای بومی ابر است که در ابتدا توسط مهندسین Heroku توسعه یافته است. این الگوها، توصیف می‌کنند که "چرا" معماری برنامه های بومی ابر آنها را بهینه می‌کند. آنها بر سرعت، ایمنی و مقیاس‌پذیری با تکیه بر پیکربندی اعلانی و فرایندهای بدون‌حالت که به صورت افقی مقیاس می‌شوند و یک اتصال کلی shell به محیط استقرار، تمرکز دارند. سیستم عامل‌های برنامه‌های ابری همچونCloud Foundry ، Heroku و Amazon Elastic Beanstalk برای استقرار برنامه های دوازده عاملی بهینه شده‌اند.

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

• CodeBase: هر برنامه قابل اجرا به عنوان یک پایگاه کد در فرایند بازبینی ردیابی می‌شود. ممکن است موارد زیادی در چندین محیط مستقر شده باشد.
• Dependencies: یک برنامه صراحتا وابستگی‌ها را از طریق ابزار مناسبی همچونMaven ، Bundler ، NPM اعلام و جدا می‌کند تا اینکه وابستگی‌های ضمنی آن را در محیط استقرار خود انجام دهد.
• Config: پیکربندی یا هر چیزی که احتمالاً بین محیط‌های استقرار متفاوت باشد (به عنوان مثال محیطهای توسعه، تست، عملیات) از طریق متغیرهای محیطی در سطح سیستم عامل تنظیم می‌شود.
• Backing services: خدمات پشتیبان‌گیری، مانند پایگاه داده یا کارگزار پیام، به عنوان منابع پیوست شده تلقی شده و در تمام محیط‌ها به طور یکسان مصرف می‌شوند.
• Build, release, run: مراحل ساخت آرتیفکتِ برنامه‌ی قابل اجرا، ترکیب آن آرتیفکت با پیکربندی و شروع یک یا چند فرآیند از آنها کاملاً تفکیک شده اند.
• Processes: برنامه بصورت یک یا چند فرآیند stateless اجرا می‌شود.
• Port binding: برنامه خودمختار است و همه خدمات را از طریق اتصال به پورت ارائه می‌دهد.
• Concurrency: همزمانی معمولاً با مقیاس‌گذاری افقی فرآیندهای برنامه انجام می شود.
• Disposability: استحکام از طریق فرآیندهایی که به سرعت شروع شده و با ظرافت پایان می‌یابند ، به حداکثر میزان خود می‌رسد.
• Dev/Prod parity: تحویل و استقرار دائمی با حفظ محیط‌های توسعه، تست و عملیات بسیار شبیه هم می‌شود.
• Logs: به جای مدیریت ثبت وقایع سیستم، گزارشات را به عنوان جریان‌های رویداد در نظر گرفته و به محیط اجرا اجازه می‌دهید تا از طریق سرویس‌های متمرکز، رویدادها را گردآوری، تجمیع، نمایه‌سازی و تحلیل کند.
• Admin processes: وظایف مدیریتی همچون انتقال پایگاه داده، به عنوان فرایندهای یکبار مصرف در محیطی مشابه با برنامه‌های طولانی مدت اجرا می‌شود.

میکروسرویس ها

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

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

زیرساخت چابک self-service

تیم‌هایی که در حال توسعه معماری برنامه‌های بومی ابری هستند، معمولاً مسئول استقرار و فعالیت‌های مستمر آنها هستند. پذیرندگان موفق برنامه‌های بومی ابری، تیم‌ها را با پلتفرم‌های سِلف سرویس توانمند کرده‌اند.

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

بهترین این سیستم عامل‌ها لایه انتزاعی اولیه را برای مصرف کنندگان خود افزایش می‌دهند. با استفاده از زیرساخت به عنوان سرویس (IAAS) از API خواستیم تا موارد سرور مجازی، شبکه‌ها و فضای ذخیره سازی ایجاد نماید تا اَشکال مختلف مدیریت پیکربندی و اتوماسیون را برای فعال کردن برنامه ها و سرویس های پشتیبانی خود اعمال کنیم. اکنون سیستم عامل‌هایی در حال ظهور هستند که به ما امکان می‌دهند درباره برنامه‌ها و خدمات پشتیبانی فکر کنیم.

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

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

همکاری مبتنی بر API

تنها حالت تعامل بین سرویس‌ها در معماری برنامه بومی ابر از طریق API های منتشر شده و نسخه‌سازی شده است. این API ها معمولاً به سبک HTTP REST با سریال سازی JSON هستند اما می‌توانند از پروتکل‌های دیگر و قالب‌های سریال‌سازی نیز استفاده کنند.

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