دوازده عاملی که در پست قبل با آنها آشنا شدیم در سال 2011 توسط آقای Adam Wiggins مطرح شدند و به بهبود ساختار و مقیاس پذیری نرم افزارها کمک زیادی کردند. اما طی سالهای گذشته شرایط تغییر کرد مثلا API محبوبیت پیدا کرد و تکنولوژی ها جدید به وجود آمدند. این تغییرات باعث شدند که این عامل ها نیز بروز شوند.
فهرست مقالات
1. طراحی نرم افزار ابرزی: شروع داستان …
2. طراحی نرم افزار ابرزی: برنامه 12 عاملی
3. طراحی نرم افزار ابرزی: 12 عامل و فراتر از آن
علاوه بر 12 عامل مطرح شده، سه عامل دیگر نیز برای نرم افزارهای ابرزی در نظر گرفته شدند.
عامل 13. شروع با API
همه چیز را به سرویس تبدیل کنید. با این ذهنیت برنامه تان را طراحی کنید که امکان استفاده از برنامه شما توسط هر برنامه دیگری وجود داشته باشد.
در برنامه فرضی هم رابط کاربری و هم بخش سرویس در یک کد قرار داشتند. با توجه به این عامل باید این دو را از هم مجزا کنیم و هر یک را در یک مخزن کد قرار دهیم. برای بخش سرویس باید API در نظر بگیریم تا بخش رابط کاربری و برنامه های دیگر بتوانند از آن استفاده کنند.
البته همه بخش ها نباید اینطور باشند. مثلا بخش رابط کاربری را نمی توان از طریق API در اختیار دیگران قرار داد و منحصر به این برنامه است. تنها بخش های اصلی برنامه شما باید این ویژگی را داشته باشد.
عامل 14. سنجش (Telemetry)
این عامل به نظر من یکی از مهم ترین عوامل است چون به یک تفاوت اساسی بین اجرای نرم افزار ها در فضای ابری و غیر ابری اشاره دارد.
اینکه در حین طراحی یک نرم افزار ابرزی به بحث مانیتورینگ و نظارت بر سلامت و عملکرد برنامه دقت داشته باشید و راهکاری برای سنجش آن در نظر بگیرید.
در برنامه فرضی کل برنامه روی یک سرور مجازی قرار داشت و به راحتی و خیلی با جزییات می شد رفتار برنامه و نحوه عملکرد آنرا زیر نظر داشت. اما در فضای ابری این دسترسی وجود ندارد. بنابراین باید برنامه را طوری طراحی کرد که بتوان از صحت عملکرد و رفتار آن مطمئن شد.
یکی از مواردی که می توان انجام داد طراحی یک نقطه دسترسی برای سنجش سلامت و وضعیت برنامه است. به این معنی که در برنامه فرضی که الان api دارد یک آدرس با این شرایط ایجاد می کنیم https://serveraddress/blog/api/healtz. می توانیم در خروجی این مسیر گزارشی از وضعیت سلامت و عملکرد برنامه را قرار دهیم. با این کار در فضای ابری با فراخوانی این آدرس، از اجرای برنامه مطمئن می شویم و در عین حال می توانیم گزارشی از وضعیت برنامه داشته باشیم.
عامل 15. احراز هویت/ دسترسی
از همان ابتدا بحث احراز هویت و مدیریت دسترسی ها را در نظر بگیرید و برای آن برنامه داشته باشید.
این مورد هم اهمیت زیادی دارد چرا که به ماهیت فضای ابری بستگی دارد. این عامل بیان کننده این موضوع است که هر درخواستی که به برنامه شما ارسال می شود باید هویت و منبع آن مشخص باشد. علاوه بر این به منابع تنها باید بر اساس نقش ها و سیاست های امنیتی که وجود دارند اجازه دسترسی داده شود.
در برنامه فرضی و بخش سرویس وبلاگ برای احزار هویت و مدیریت دسترسی ها می توان از OAuth2 استفاده کرد.
هنوز ادامه دارد …
این ها مواردی بودند که در این متدولوژی تعریف شده بودند اما موارد دیگری نیز وجود دارند که به خود برنامه شما مرتبط نیستند و بیشتر به محیط اجرای برنامه شما و ماهیت ابر مرتبط می شوند. به نظر من حتی این موارد از خود برنامه هم مهم تر هستند زیرا گاهی ممکن است ساختار برنامه شما را تغییر بدهند.
ارتباطات
بخش رابط کاربری برنامه شما با بخش بک شما چطور ارتباط برقرار می کند؟ ارتباط بین سرویس های مختلف در برنامه شما چگونه است؟ مستقیما دسترسی دارند و یا از یک API gateway استفاده می کنند؟ از REST استفاده می کنند یا gRPC؟ یا اینکه قرار است از یک Message Bus استفاده کنند؟
در هنگام طراحی برنامه به این سوالات و سوالات مشابه آنها فکر کنید و درباره آنها تصمیم گیری کنید.
تاب آوری (Resiliency)
همان طور که دیدید برنامه فرضی ما که خیلی هم ساده بود وقتی قرار شد که ابرزی شود به دو بخش متفاوت تقسیم شد و در واقع الان با یک سیستم توزیع شده روبرو هستیم. در این شرایط اگر بخش رابط کاربری برنامه من نتواند با بخش سرویس بلاگ ارتباط بگیرد چه اتفاقی باید رخ دهد؟ رفتار برنامه من وقتی سرویس بلاگ نتواند با پایگاه داده ارتباط برقرار کند چطور باید باشد؟
ناپایداری و قابل اعتماد نبودن شبکه و سیستم های توزیع شده به تنهایی کافی هستند که مساله تاب آوری امری مهم در طراحی نرم افزار های ابرزی باشد.
استفاده از الگوهایی مانند Circuit Breaker و Bulkhead می توانند شروع خوبی برای بهبود تاب آوری برنامه فرضی باشند.
داده های توزیع شده
همان طور که می بینید با جدا کردن کش از برنامه اصلی و پنهان کردن آن در پشت یک API با بحث داده های توزیع شده روبرو هستیم. هماهنگ کردن این داده ها، کوئری زدن روی داده های توزیع شده، اجرای درخواست هایی که داده در بخش های مختلف را تحت تاثیر قرار می دهند و … از جمله چالش هایی هستند که داده های توزیع شده با خود به همراه دارند.
استفاده از الگوهایی مانند Materialized View، publish/subscribe و saga از جمله الگوهایی هستند که می توان برای روبرو شدن با چالش های داده توزیع شده در نرم افزارهای ابرزی استفاده کرد.
جمع بندی
همان طور که می بینید ابر و فضای ابری اکوسیستم جدیدی را خلق کرده است که نیازمندی ها و شرایط خودش را دارد و نرم افزارهایی که برای این اکوسیستم طراحی و ساخته می شوند باید خودشان را با این شرایط سازگار کنند. پیروی از اصول و قواعد مطرح شده به شما کمک کند که نرم افزارتان را برای زیست در چنین فضایی آماده کنید. اما چیزی که به نظرم خیلی بهتر می تواند به ما کمک کند تغییر ذهنیت است. اینکه باید برای فضای جدید و متفاوتی نرم افزار طراحی کنیم و بسازیم.
منابع:
1. کتاب Cloud Native DevOps with Kubernetes-O’Reilly Media نوشته John Arundel و Justin Domingus
2. Beyond the Twelve-Factor App نوشته Kevin Hoffman
3. https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition.
4. https://www.bmc.com/blogs/twelve-factor-app/#
5. https://tanzu.vmware.com/content/blog/beyond-the-twelve-factor-app
2 دیدگاه روشن طراحی نرم افزار ابرزی (Cloud Native): 12 عامل و فراتر از آن
سلام
ممنون از زحمات شما
خواهش می کنم.