در پارت قبلی در مورد scalability صحبت کردیم و تا حدودی با مفهوم آن آشنا شدیم و همچنین روش های آن را بررسی کردیم. اما در این پارت و پارت های بعدی با مفاهیمی مثل docker , microservice و نیز کاربردهای آنها آشنا می شویم.
توجه داشته باشید که هدف از این مقاله آشنایی کامل با این مفاهیم نیست پس کاربرد های دیگری نیز برای docker وجود دارد که در اینجا هدف ما معرفی این کاربردها نیست.پس به خاطر داشته باشید که scalability و microservice تنها دلیل استفاده از docker نیستند!
و همچنین برعکس این مورد هم منظور ما نیست یعنی تنها راه پیاده سازی microserviceها استفاده از داکر نیست اما می توان گفت که راه خوبی است.
توصیه می شود قبل از مطالعه ی این مطلب پارت قبلی را با دقت بخوانید!
طرح مشکل: بررسی یک مثال
فرض کنید که شما یک اپلیکیشن نوشته اید و آن را روی یک سرور یا فضای ابری host کرده اید و چون هنوز تبلیغات انجام نداده اید فعلا در هر ثانیه ۵۰۰۰ کاربر می گیرید(خیلی فضایی به نظر میرسه) و بااین تعداد کاربر سرور شما به راحتی می تواند تمام کاربران را سروریس دهد.
حال فرض کنید که می خواهید فیچری جدید به اپ اضافه کنید و همزمان تبلیغات خود را شروع می کنید و حسابی اپلیکیشن شما معروف و محبوب می شود و پس از ارائه ی نسخه ی جدید تعداد درخواست ها در هر ثانیه به ۶۰ هزار درخواست افزایش می یابد و سرور شما دیگر قادر نخواهد بود که این تعداد را هندل کند و timeout رخ می دهد و این در کیفیت خدمات اپلیکیشن شما تاثیر زیادی خواهد داشت!
پس راه حل این مشکل چیست؟ جواب در پارت قبلی است استفاده از روش های scalability یعنی Vertical scaling و Horizontal scaling
در مورد این دو روش در پارت قبلی صحبت کردیم.
اما همین طور که اپلیکیشن شما بزرگ تر می شود و فیچر های آن بیشتر می شوند حجم کدها و داده ها هم زیاد می شوند و شما مجبور می شوید که آنها را در چندین سرور نگه دارید اما همین کار خود سبب به وجود آمدن پیچیدگی می شود.
در حقیقت هر بار که شما یک فیچر جدید اضافه می کنید سه کار را باید انجام دهید:
۱- کل اپلیکیشن را از روی سرور پایین بیاورید.
۲-فیچر جدید را به اپلیکیشن خود اضافه کنید.
۳-دوباره روی سرور ببرید.
همین توسعه ی مجدد گاهی سبب می شود تا downtime شما بیش از ۲۰ دقیقه باشد و این خیلی بد است و عملا شما مشتریان خود را از دست می دهید. البته تکنیک هایی برای کاهش این زمان هست اما خیلی کار ساز نیستند.
اما این مشکل را چگونه باید حل کرد؟ پاسخ microservice است.
اصلا تعریف microservice چیست ؟
میکروسرویس فقط یک الگوی معماری است که سرویس های بزرگ را به سرویس های خرد تبدیل می کند.
و یکسری ویژگی های خاص دارد مثلا:
-قابل تست و بسیار قابل نگه داری است.
-به طور مستقل قابل استفاده است.
-امکان تحویل سریع ، مکرر و قابل اعتماد برنامه های پیچیده و بزرگ را فراهم می کند.
-سیستم را قادر می سازد تا technology stack خود را توسعه دهد. و....
بنابراین شما به آرامی و به صورت اصولی شروع به شکستن برنامه ی عظیم خود می کنید و آنرا به سرویس های مستقل و کوچک تر تبدیل می کنید که می توانند با هم صحبت کنند و در نهایت به هدف مشترک خود برسند.
برای فهم بهتر این موضوع یک مثال آشنا را بررسی می کنیم:
فرض کنید که شما یک اپلیکیشن فروشگاهی نوشته اید؛ و داخل آن کاربر می خواهد کالایی را به سبد خرید اضافه کند.چه اتفاقی می افتد؟!
1- کاربری که درخواست را ارسال کرده در مرحله ی اول اعتبار سنجی می شود در صورت تایید اعتبار وارد مرحله بعدی می شود.
۲-پس از انجام اعتبار سنجی و دریافت تاییدیه ها رکوردی برای این کاربر ثبت می شود که فلان کالا را می خواهد.
۳- سپس سفارش کاربر برای شرکت یا فروشگاه مورد نظر ارسال می شود.
۴- پس از آن نتجه سفارش برای کاربر ارسال می شود.(موجود یا ناموجود بودن کالا. البته در فروشگاه های اینترنتی ایران این مورد وجود دارد)
۵- پس از انجام تمام این کار ها پیغامی برای کاربر با عنوان ثبت سفارش ارسال می گردد یا در صورت بروز مشکل پیغام بروز خطا ارسال می شود.
انجام این مراحل به صورت واحد یکسری مشکلات دارد و پس از آن یکسری مشکلات دیگر را به همراه دارد:
-اول اینکه طی شدن این مراحل نگهداری از پروژه های بزرگ را پیچیده و دست و پا گیر می کند و همچنین در انجام این مراحل ما تکرار کد هم داریم. زیرا اکثر عملکردهای شما که درخواست های کاربر را برآورده می کنند هر بار در حال تکرار شدن هستند.
-دوم اینکه؛ هر بارتأیید اعتبار کاربر می تواند منجر به افزایش اندازه کدهای شما شود.
پس راه حل مناسب برای حل این مشکلات شکستن یکپارچه ی این سرویس است به شرط مستقل بودن هر مرحله و کنترول عملکرد در هر مرحله.
پس مراحل را به صورت زیر اصلاح می کنیم:
۱- ابتدا یک سرویس تایید اعتبار برای Authentication کاربران ایجاد می کنیم.
۲-در مرحله بعد یک سرویس خرید کالا ایجاد می کنیم که بگوید که کدام کاربر کدام کالا یا کالا ها را می خواهد.
۳- در مرحله بعد یک سرویس اعلان ایجاد می کنیم که اعلان ها را ارسال کند.
اما راستی گواهینامه های SSL چه می شود؟!
خب ما برای آن سرویس خاصی ایجاد نمی کنیم. اما برای آن از API Gateway استفاده می کنیم. API Gateway را به عنوان یک پروکسی معکوس پیشرفته در نظر بگیرید.بنابراین API Gateway اکنون تأیید گواهینامه های SSL را انجام می دهد. علاوه بر آن، با استفاده از این API Gateway ، نیازی به پیاده سازی احراز هویت و سروریس های خرد نداریم. اگرچه به خاطر این مثال ، اجازه دهید آن را به عنوان یک سرویس کوچک در نظر بگیریم.
خب حالا چطور این microservices ها را پیاده سازی کنیم؟!
خب جواب معمول به این صورت است که ما این سرویس ها را روی پورت های جداگانه اجرا می کنیم مثلا سرویس Authentication روی پورت ۳۰۰۰ و سرویس اطلاع رسانی(notification) روی پورت ۴۰۰۰ وهمین ترتیب سرویس های دیگر را روی پورت های دیگر پیاده سازی می کنیم.
مگر این روند مشکلی دارد؟!
فرض کنید شما می خواهید یک فیچر جدید به اپلیکیشن خود اضافه کنید و این کار را با آخرین نسخه زبانی که آن را توسعه داده اید انجام می دهید و همچنین توسعه خود را نیز آپدیت کرده اید ): پس از آن متوجه می شود که سایر microservices هایی که با استفاده از نسخه ی قدیمی ساخته شده اند دیگر کار نمی کنند(لحظه ی خیلی سختی خواهد بود) خب اصلا چرا این اتفاق افتاد؟!!
ببینید وقتی شما از نسخه ی جدید استفاده می کنید این نسخه برخی از API های نسخه های قدیمی را ندارد چرا؟ چون آن API ها در این microservices ها حذف شده اند و یا مشکلات ناشی از استفاده از نسخه های مختلف روی نرم افزاری هایی مختلف در کنار هم. مثلا فرض کنید یک نرم افزار به پایتون نسخه ی ۲ نیاز دارد و یک نرم افزار به پایتون نسخه ۳ نیاز دارد و شما فقط می توانید روی سیستم خود تنها یک نسخه نصب کنید.
خب باید چه کاری انجام داد؟!
جواب کوتاه و ساده است!! استفاده از ماشین های مجازی
فکر کنم تا حدودی با ماشین مجازی (Virtual Machines) آشنایی دارید به هر حال بررسی VMs موضوع بحث ما نیست.
اینجا می تونید در موردش بخونید!
درواقع با VMs ما می توانیم یک محیط جدا شده در بالای سیستم عامل یا مستقیما روی سخت افزار ایجاد کنیم!
این مطلب ادامه دارد...
نوشته شده توسط: علی آخی
