معماری Backend به نحوه ساختار برنامه وب شما اشاره دارد. معماری Backend تعیین می کند که چگونه بخش هایی از برنامه با یکدیگر ارتباط برقرار می کنند تا درخواست های دریافتی را پردازش کنند و پاسخ ها را ایجاد کنند. هنگام ساختن یک برنامه وب، معماری بک‌اند را بر اساس نیازها و عوامل خاص خود، از جمله هزینه (هم در حال انجام و هم در مقیاس)، پیچیدگی برنامه، اهداف مقیاس‌بندی، و تخصص تیم خود انتخاب کنید.
مخصوصاً برای برنامه‌های کاربردی وب مبتنی بر محتوا، مانند تجارت الکترونیک، روزنامه‌ها یا وبلاگ‌ها، الزامات حیاتی شامل ثبات داده‌ها و عملکرد شما می‌شود، به‌ویژه زمانی که برنامه شما در مقیاس جهانی رشد می‌کند و ممکن است توزیع‌تر شود. برای برنامه‌های وب مبتنی بر محتوا، ذخیره‌سازی داده‌ای که برنامه شما استفاده می‌کند نیز حیاتی است و در راهنمای ذخیره‌سازی داده با جزئیات بیشتر مورد بحث قرار گرفته است. حرکت فراتر از معماری برنامه های معمولی، میزبانی محتوای خود و در دسترس قرار دادن آن برای بهینه سازی عملکرد برنامه بسیار مهم است. درباره انتخاب استراتژی میزبانی مناسب و بهینه سازی برنامه خود در راهنمای میزبانی بیشتر بیاموزید.
اگر یک Backend موجود برای یک برنامه وب دارید، محدودیت های معماری فعلی خود را در نظر بگیرید. به عنوان مثال، با افزایش مقیاس برنامه شما و افزایش تقاضا برای عملکرد و قابلیت اطمینان آن، در نظر بگیرید که آیا قسمت هایی از برنامه شما باید بازسازی شوند یا به معماری متفاوتی منتقل شوند که متناسب با مقیاس افزایش یافته شما باشد. به عنوان مثال، معماری های ترکیبی (یا چند ابری) به شما این امکان را می دهد که قبل از انجام یک انتقال کامل، برخی از بارهای کاری را به ابر منتقل کنید. در نظر گرفتن هزینه، زمان و ریسک موجود در چنین مهاجرتی نیز ضروری است.
معماری های یکپارچه
یک معماری یکپارچه دارای یک ساختار یکپارچه است، با تمام اجزای برنامه کاملاً در یک پایگاه کد واحد یکپارچه شده است. کل برنامه به عنوان یک واحد مستقل ساخته شده است. معماری یکپارچه چند لایه است، که در آن لایه های مختلف برنامه وظایف خاصی را انجام می دهند.
لایه های ساختاری
- رابط کاربری (UI)، که شامل اجزایی برای ارائه ویژگی های برنامه است، معمولاً یک برنامه مبتنی بر وب یا دسکتاپ است که با کاربران تعامل دارد.
- منطق برنامه جایی است که عملکرد اصلی در آن قرار دارد. این قسمت از پایگاه کد حاوی قوانین، محاسبات و عملیاتی است که نحوه عملکرد برنامه را تعریف می کند.
- لایه دسترسی به داده شامل توابعی برای خواندن و نوشتن داده ها و ترجمه بین ساختارهای داده برنامه و طرح پایگاه داده است. این لایه وظیفه تعامل با پایگاه داده یا ذخیره سازی داده های برنامه را بر عهده دارد.
- پایگاه داده جایی است که برنامه داده های خود را ذخیره می کند. معمولاً یک پایگاه داده واحد وجود دارد که تمام داده های برنامه از جمله داده های کاربر، پیکربندی ها و سایر اطلاعات را ذخیره می کند.
- اجزای میان‌افزار وظایفی مانند احراز هویت، مسیریابی درخواست و اعتبارسنجی داده‌ها را انجام می‌دهند. این مؤلفه ها به مدیریت جریان داده ها و درخواست ها کمک می کنند.
- برخی از برنامه های کاربردی یکپارچه دارای نقاط ادغام با سرویس های خارجی یا API ها هستند. این نقاط به برنامه اجازه می دهد تا با خدمات شخص ثالث، منابع داده یا سایر سیستم ها تعامل داشته باشد.
لایه‌های ساختاری معمولاً بخشی از یک پایگاه کد واحد هستند. این پایگاه کد شامل کل برنامه است و معمولاً در فهرست ها، ماژول ها و کلاس ها سازماندهی می شود. توسعه دهندگان برای ساخت و نگهداری برنامه روی قسمت های مختلف پایگاه کد کار می کنند. با این حال، کل برنامه معمولاً به صورت یک واحد مستقر می شود. هنگامی که به روز رسانی یا تغییرات ایجاد می شود، کل برنامه دوباره مستقر می شود.
چالش های بالقوه
- همانطور که برنامه های کاربردی یکپارچه رشد می کنند، پایگاه کد پیچیده می شود و نگهداری آن دشوار است. این می تواند منجر به چرخه های توسعه طولانی و دشواری در درک کل پایگاه کد شود.
- اعمال تغییرات در یک برنامه یکپارچه می تواند مخاطره آمیز باشد زیرا تغییرات ایجاد شده در یک قسمت از کد ممکن است به طور ناخواسته بر سایر قسمت های برنامه تأثیر بگذارد. این می تواند یک فرآیند استقرار طولانی و مستعد خطا ایجاد کند.
- مقیاس‌بندی برنامه‌های یکپارچه می‌تواند دشوار باشد زیرا آنها به عنوان یک واحد به کار گرفته می‌شوند. شما باید کل برنامه را مقیاس کنید حتی اگر تنها یک جزء با افزایش تقاضا مواجه شود.
- برنامه های یکپارچه اغلب به یک پشته فناوری یا زبان برنامه نویسی تکیه می کنند، ممکن است توانایی شما برای استفاده از بهترین ابزار برای یک کار خاص در داخل برنامه محدود باشد.
- حتی در دوره‌های تقاضای کم، برنامه‌های یکپارچه به منابع قابل توجهی برای کار کردن نیاز دارند. هزینه های تعمیر و نگهداری نیز با افزایش سن برنامه افزایش می یابد زیرا به روز رسانی و وصله برنامه بدون ایجاد رگرسیون چالش برانگیزتر می شود.
- تیم‌های توسعه که روی برنامه‌های یکپارچه کار می‌کنند، اغلب حول کل برنامه سازماندهی می‌شوند، این منجر به تیم‌های بزرگتر و هماهنگی پیچیده‌تر بین اعضای تیم می‌شود.
استفاده پیشنهادی
معماری‌های یکپارچه زمانی مناسب هستند که یک برنامه دارای الزامات متوسطی باشد و تیم توسعه کوچک باشد. همانطور که یک برنامه کاربردی در پیچیدگی و مقیاس رشد می کند، یا زمانی که بخش های مختلف برنامه نیاز به فناوری یا استراتژی های مختلف استقرار دارند، معماری های یکپارچه می توانند انعطاف پذیری کمتری داشته باشند و نگهداری آنها چالش برانگیزتر شود.
شما می توانید ماشین های مجازی ایجاد و مدیریت کنید که می توانند برنامه های یکپارچه را در Compute Engine اجرا کنند. شما کنترل کاملی بر سیستم عامل، نرم افزار و مدیریت این ماشین های مجازی برای اجرای برنامه یکپارچه خود دارید.
با یک سرویس پلت فرم به عنوان سرویس، مانند App Engine ، می توانید برنامه خود را بسازید و آن را بر روی زیرساخت کاملاً مدیریت شده اجرا کنید که به طور خودکار با درخواست ها مقیاس می شود.
اگر برنامه یکپارچه شما کانتینری است، می‌توانید آن را با استفاده از Google Kubernetes Engine (GKE) یا Cloud Run اجرا کنید. خدماتی مانند Cloud SQL یا Cloud Spanner را می توان برای ذخیره داده ها برای برنامه های یکپارچه استفاده کرد. ترکیبی از خدمات و سیستم ها را بر اساس نیازهای خاص برنامه خود در نظر بگیرید.
معماری های بدون سرور
با استفاده از معماری بدون سرور، می توانید برنامه هایی را بدون مدیریت سرورهای فیزیکی یا مجازی بسازید و اجرا کنید. ارائه‌دهنده ابر به‌طور خودکار زیرساخت، مقیاس‌بندی و تخصیص منابع را مدیریت می‌کند تا توسعه‌دهندگان بتوانند روی نوشتن کد برنامه‌های خود تمرکز کنند. معماری های بدون سرور می توانند توسعه را ساده کنند، سربار عملیاتی را کاهش دهند و هزینه ها را با حذف نیاز به نگهداری سرورها بهینه کنند. آنها برای میکروسرویس ها، پردازش بلادرنگ داده ها، برنامه های کاربردی وب با بار کاری متغیر و پردازش رویداد مناسب هستند.
معماری های بدون سرور مبتنی بر رویداد
معماری‌های بدون سرور مبتنی بر رویداد، نوع خاصی از معماری محاسباتی بدون سرور هستند که برای شروع اجرای توابع یا میکروسرویس‌ها به رویدادها یا محرک‌ها متکی هستند. اجزای سیستم از طریق رویدادها ارتباط برقرار می کنند و توابع در پاسخ به رویدادها فراخوانی می شوند. آنها اغلب به ارتباطات ناهمزمان متکی هستند زیرا توابع توسط رویدادها تحریک می شوند، سپس آنها را به طور مستقل پردازش می کنند و ممکن است رویدادهایی ایجاد کنند که سپس اقدامات بعدی را آغاز می کنند. این نوع معماری بدون سرور گزینه خوبی برای ساختن سیستم‌های مقیاس‌پذیر، پاسخ‌گو و با اتصال ضعیف است.
Google Cloud Functions و Cloud Functions for Firebase شما را قادر می سازد تا توابع رویداد محور را در یک محیط کاملاً مدیریت شده و بدون سرور ایجاد و استقرار دهید. این به شما امکان می‌دهد در پاسخ به رویدادها و محرک‌های مختلف، از جمله درخواست‌های HTTP، پیام‌های Cloud Pub/Sub، تغییرات Google Cloud Storage، به‌روزرسانی‌های پایگاه داده بیدرنگ Firebase، کد را بدون نیاز به مدیریت زیرساخت اجرا کنید. ویژگی‌های کلیدی شامل پشتیبانی از زبان‌های متعدد، مقیاس‌پذیری، صورت‌حساب ریز، ادغام‌های شخص ثالث، گزارش‌گیری و نظارت قوی، و ادغام با سایر سرویس‌های Google و Firebase است.
معماری‌های بدون سرور می‌توانند برای بسیاری از موارد استفاده مقرون‌به‌صرفه باشند، به‌ویژه برای برنامه‌هایی با حجم کاری متفاوت، نیازهای توسعه سریع و ترافیک غیرقابل پیش‌بینی. قابلیت اطمینان به ارائه‌دهنده ابر، با توافق‌نامه‌های سطح خدمات (SLA) برای اطمینان از عملکرد خاص و اهداف قابلیت اطمینان بستگی دارد. شما باید مورد استفاده و الزامات خاص خود را ارزیابی کنید تا تعیین کنید که آیا معماری بدون سرور بهترین گزینه شما است یا خیر.
کانتینرسازی
Containerization اجازه می دهد تا برنامه ها و وابستگی های آنها در ظروف سبک وزن و قابل حمل بسته بندی شوند. آنها یک محیط کاربردی سازگار را ارائه می دهند که از توسعه و استقرار در سیستم ها و پلتفرم های مختلف پشتیبانی می کند. برخی از پلتفرم های بدون سرور امکان اجرای بارهای کاری کانتینری را ارائه می دهند. اجرای کانتینرها در یک محیط بدون سرور زمانی می تواند مفید باشد که حجم کاری پیچیده یا حالت دار دارید که نمی تواند به عنوان توابع اصلی بیان شود. از نظر پشتیبانی زبان و محیط های زمان اجرا انعطاف پذیری را فراهم می کند.
Cloud Run یک پلت فرم محاسباتی بدون سرور است که به توسعه دهندگان اجازه می دهد تا برنامه های کاربردی کانتینری را در یک محیط کاملاً مدیریت شده استقرار و اجرا کنند. این یک راه ساده برای ساخت، استقرار و مقیاس‌بندی برنامه‌ها بدون مدیریت زیرساخت‌های زیربنایی ارائه می‌کند. برای طیف وسیعی از برنامه‌های وب و میکروسرویس‌ها، به‌ویژه برنامه‌هایی با بار کاری متغیر، و در مواردی که کانتینری‌سازی مزایایی از نظر بسته‌بندی و سازگاری برنامه‌ها ارائه می‌کند، مناسب است.
معماری میکروسرویس
برنامه‌ها به بخش‌های کوچکی تقسیم می‌شوند که به‌طور سست کوپل شده‌اند و ویژگی‌ها یا قابلیت‌های متمایز را اجرا می‌کنند. این سرویس‌ها ممکن است از طریق پیام‌های ناهمزمان، کانال‌های مبتنی بر رویداد یا مستقیماً با افشای یک رابط ارتباط برقرار کنند. هر سرویس به طور مستقل در ظرف خود توسعه یافته، آزمایش و مقیاس بندی می شود، که اغلب از طریق یک سرویس هماهنگ، مانند Kubernetes مدیریت می شود، یا با استفاده از یک پلت فرم مدیریت شده، مانند Cloud Run ، مستقر می شود.
استقرارهای میکروسرویس معمولاً با عدم اتکا به سرور متمرکز از الگوی برنامه کاربردی بدون سرور نیز بهره می برند.
تفکیک یک برنامه کاربردی به سرویس های مستقل می تواند یک سیستم پیچیده را ساده کند. مرزها و اهداف به خوبی تعریف شده می تواند سرعت توسعه و بهبود تعمیر و نگهداری را افزایش دهد. هر میکروسرویس را می توان به طور مستقل با استفاده از مؤثرترین چارچوب ها یا ابزارها توسعه داد. ارتباط بین سرویس‌ها اغلب با استفاده از رویدادها، ارتباطات انتشار-اشتراک، خطوط لوله پیام یا تماس‌های رویه از راه دور مانند gRPC انجام می‌شود.
برای هماهنگی وظایف در معماری میکروسرویس، استفاده از چارچوبی را در نظر بگیرید که از پلتفرم های مورد نظر شما پشتیبانی می کند، عمق کافی برای وظایف و انواع جریان های کاری که هماهنگ می کنید، و همچنین مدیریت خطا و تله متری برای رفع اشکال. انتخاب‌های محبوب شامل Conductor یا پیشنهادات ارائه‌دهنده ابری مانند Google Workflows است.
توسعه و نگهداری برنامه های کاربردی مبتنی بر میکروسرویس به دلیل ماهیت توزیع شده و نیاز به ارتباطات درون سرویس می تواند پیچیده باشد. بنابراین، مدیریت استقرار، نظارت و ثبت‌نام پیچیده‌تر از سایر گزینه‌های معماری است. از آنجایی که قابلیت اطمینان به معماری هر یک از خدمات بستگی دارد، ماهیت توزیع شده ممکن است انعطاف پذیری بیشتری ارائه دهد، به خصوص اگر نظارت و تله متری مستقر شده و در صورت لزوم فعال شود.
مقایسه معماری‌های مختلف برای برنامه‌های کاربردی وب محتوا محور
جدول زیر معماری ها را با الزامات کلیدی برای backend یک برنامه وب مبتنی بر محتوا مقایسه می کند.
| معماری های یکپارچه | معماری‌های مبتنی بر رویداد بدون سرور | معماری های میکروسرویس بدون سرور | |
|---|---|---|---|
| پیچیدگی و نگهداری |
|
|
|
| مقیاس پذیری و عملکرد |
|
|
|
| تاب آوری و استراتژی های بازگشتی |
|
|
|
| تجربه توسعه |
|
|
|
| هزینه |
|
|
|
درباره معماری های پشتیبان برای برنامه های کاربردی وب محتوا محور بیشتر بیاموزید
در اینجا چند منبع برای کسب اطلاعات بیشتر در مورد معماری برنامه های کاربردی وب محتوا محور، از جمله نحوه انتقال برنامه خود به معماری متفاوت وجود دارد: