با استفاده از این روش‌های برتر مایکروسرویس، با تلاش کمتر بهره وری بیشتری داشته باشید و در بازاری که دائماً در حال تغییر است، فرز و چابک عمل کنید!
چکیده: معماری مایکروسرویس انعطاف‌پذیری و سهولت بیشتری را در توسعه از طریق خدمات جداسازی (ناجفت‌سازی) به ارمغان می‌آورد. با این حال، معماری مایکروسرویس شامل چالش‌هایی مانند کارایی، ثبات، امنیت و غیره است. در این مطلب برخی از بهترین روش‌های مایکروسرویس، همراه با حساب‌های کاربری واقعی از شرکت‌های پیشرو نام برده شده‌اند.
6 ویژگی تعیین‌کننده در معماری مایکروسرویس
این روزها، مایکروسرویسها همه جا هستند و به طور کلی مزایای زیادی برای توسعه‌دهندگان و تیم‌های توسعه ایجاد می‌کنند. همیشه این احتمال وجود دارد که چیزی بدون این که هیچ فایده‌ای داشته باشد، هایپ شود. اما این موضوع در مورد معماری مایکروسرویس صدق نمی‌کند. موارد زیر، دلایلی هستند برای اینکه معماری خود را بر اساس مایکروسرویس پایه‌ریزی کنید.
چندین مؤلفه قابل استقرار جداگانه
معماری مایکروسرویس شما را تشویق می‌کند تا برنمه خود را به اجزای کوچکتر تقسیم کنید. این کار اعمال تغییرات را آسان می‌کند. استقرار چنین مؤلفه‌هایی بر بخش بزرگی از پایگاه کد بی‌تأثیر خواهد بود.
این به نوبه خود، معرفی ویژگی‌های جدید در برنامه را آسان‌تر می‌کند. زیرا واحدهای استقرار کوچک و قابل مدیریت هستند.
توزیع خدمات بر اساس قابلیت تجاری
مرزهای تکنیکال، معماری کلی اپلیکیشن‌های Monolithic را تعیین می‌کند. شما تیمی دارید که بر روی رابط کاربری کار می‌کند، تیم دیگری به طور همزمان بر روی دیتابیس کار می‌کند و تیم سومی هم هست که بر روی لایه integration کار می‌کند.
معماری مایکروسرویس چنین مدلی را نمی‌پذیرد. عملکردهای تجاری چشم‌انداز کلی مایکروسرویس‌های شما را تعیین می‌کنند.
در مایکروسرویسها، تیم‌ه برا اساس تخصص خود در یک عملکرد تجاری خاص چیده می‌شوند. در این مدل هر تیم در تلاش است تا از نظر tech stack خودکفا باشد.
به عنوان مثال، در یک برنامه کاربردی مبتنی بر مایکروسرویس معمولی، می‌توانید ثبت نام کاربر را به عنوان یک مایکروسرویس و مدیریت فروش را به عنوان یک مایکروسرویس دیگر در نظر بگیرید. تیم‌های مختلفی این خدمات متفاوت را مدیریت می‌کنند.
غیرمتمرکز بودن
معماری مایکروسرویس همواره به سیستم‌های توزیع‌شده منتهی می‌شود و مفهوم مدیریت غیرمتمرکز داده را در بر می‌گیرد. در این مدل، دیتابیس یکپارچه‌ای (Monolithic) وجود نخواهد داشت که حاوی تمام داده‌های مربوط به اپلیکیشن باشد. ولی در عوض، هر سرویس مالکیت داده‌های مربوط به عملکرد تجاری پشتیبانی شده، توسط آن سرویس خاص را در اختیار دارد.
این موضوع تأثیر تغییرات Schema را جدا می‌کند. تیم‌های توسعه می‌توانند هنگام برنامه‌ریزی انتشار، کنترل بیشتری بر این تأثیر داشته باشند.
بسازید، اجرا کنید
مایکروسرویسها نیز دربرگیرنده مفهوم DevOps هستند.
ایده این است: تیمی که مسئول ساخت یک سرویس است، مسئول عملیات و پشتیبانی کد آن در تولید نیز هست.
این یک تغییر ذهنیت بزرگ از ذهنیت اپلیکیشن‌های کاربردی یکپارچه (Monolithic) است. در اپلیکیشن‌های یکپارچه، توسعه‌دهندگان اغلب فقط نگران نوشتن کد ویژگی (feature code) خود هستند. در پایان، آنها به سادگی تغییرات را در یک Repository مرکزی انجام می‌دهند. مسئولیت اعمال تغییرات برعهده تیم دیگری است.
این یک لایه افزوده از فرآیند را معرفی می‌کند و باعث کندتر شدن تغییرات می‌شود. اگر مشکلی رخ دهد، همان سربار فرآیند ممکن است باعث تأخیر بیشتری شود.
DevOps با تحمیل مسئولیت استقرار و اجرای یک سرویس به تیم توسعه‌دهنده آن، این مشکل را از بین می‌برد. بنابراین، اگر مشکلی وجود داشته باشد، این تیم‌ها می‌توانند بسیار سریعتر واکنش نشان دهند. این تیم‌ها همچنین می‌توانند release ها و hot-fix های خود را برنامه‌ریزی کنند. این باعث افزایش رضایت مشتری می‌شود.
چند زبانه بودن
یکی دیگر از جنبه‌های مهم معماری مایکروسرویس، استقلال فناوری آن است.
هر مایکروسرویس، دنیای خودش را دارد، از طریق کانال‌های استاندارد با سرویس‌های دیگر ارتباط برقرار می‌کند و به الزامات مرتبط با فناوری متکی نیست.
این ویژگی، امکانات فوق‌العاده‌ای را به توسعه‌دهندگان این مدل می‌دهد. تیم‌هایی که یک سرویس را نگهداری می‌کنند، اکنون در انتخاب tech stack برای سرویس خود آزاد هستند.
تیم می‌تواند بر اساس مشکلی که در حال حل شدن است، انتخاب‌های آگاهانه‌ای داشته باشد. به عنوان مثال، مشکلات خاص برای حل شدن، به طور غیرمستقیم به استفاده از یک الگوی خاص یا انتخاب پایگاه داده، کمک می‌کنند. اما چگونه؟ تیم‌ها آزادند که بهترین گزینه را برای مورد استفاده خود انتخاب کنند. این به طور مستقیم به استقلال و مالکیت تیم‌ها مربوط است.
جعبه سیاه بودن
هر مایکروسرویس به عنوان یک جعبه سیاه تعریف می‌شود. این بدان معنی است که جزئیات پیچیدگی آنها از سایر اجزا پنهان است.
سرویس‌ها با استفاده از مجموعه‌ای از API های تعریف‌شده یا کانال‌های پیام‌رسانی، با یکدیگر ارتباط برقرار می‌کنند. این امر از تکثیر وابستگی بین مایکروسرویسها جلوگیری می‌کند.
10 روش برتر مایکروسرویس: اصل 80/20
Capital One، به عنوان یک موسسه مالی مشهور در ایالات متحده، معماری مایکروسرویس ابری-محلی را پذیرفته است. آنها از کانتینرهای داکر باسرویس کانتینر ارتجاعی آمازون (ECS) برای گسترش مایکروسرویس پیشرفته استفاده کردند. بهترین روش‌های مایکروسرویس کانتینری به آنها کمک کرد تا برنامه‌ها را جدا کنند. اما آنها با چالش‌های زیر مواجه شدند:
- مسیریابی (روتینگ) چندپورته برای همان سرور
- مسیریابی زمینه‌محور خدمات
چنین مشکلاتی را می‌توان با ابزارهایی مانند Nginx و Consul برطرف کرد. اما به پیچیدگی‌ها و هزینه‌های عملیاتی می‌افزاید. در نتیجه، آنها load balancing ارتجاعی AWS را انتخاب کردند که در موارد زیر به آنها کمک کرد:
- نقشه‌نگاری داینامیک پورت
- ثبت خودکار یا لغو ثبت کانتینرهای داکر
- مسیریابی مبتنی بر مسیر تخصیص خدمات زمینه‌ای
یکی از مهم‌ترین درس‌هایی که باید از Capital One گرفت این است که چگونه می‌توان با کار بسیار کم، به نتایج عالی دست پیدا کرد. همچنین اصل پارِتو که به‌عنوان اصل 80/20 شناخته می‌شود، از این امر پشتیبانی می‌کند.
در این مقاله 10 روش برتر مایکروسرویس را بررسی می‌کنیم که به شما کمک می‌کند با ورودی نسبتاً کمتر، نتایج عالی کسب کنید.
10 روش برتر مایکروسرویس برای پروژه‌های شما
تمام چیزی که قانون 80/20 می‌گوید تمرکز بر روی چیزهای مهم و نادیده گرفتن تمام چیزهای دیگر است. همین امر ممکن است در مورد گسترش مایکروسرویسها نیز اعمال شود. که در ادامه به آن خواهیم پرداخت.
روش اول: بهبود بهره وری با استفاده از طراحی دامنه محور (DDD)
در حالت ایده آل، مایکروسرویسها باید با استفاده از DDD و حول قابلیت‌های تجاری طراحی شوند. انسجام عملکرد را در سطحی بالا فعال کنند و به جفت‌های سست خدمات ارائه دهند.
هر مدل DDD دو مرحله دارد: استراتژیک و تاکتیکی. مرحله استراتژیک تضمین می‌کند که معماری طراحی قابلیت‌های تجاری را دربر گیرد. مرحله تاکتیکی از سوی دیگر، امکان ایجاد یک مدل دامنه را با استفاده از الگوهای طراحی مختلف فراهم می‌کند.
موجودیت‌ها، مجموعه‌ها و خدمات دامنه برخی از الگوهای طراحی هستند که ممکن است به شما در طراحی مایکروسرویس‌های با جفت آزاد کمک کنند.
SoundCloud چگونه زمان چرخه انتشار را با DDD کاهش داد
معماری سرویس SoundCloud از الگوی Backend for frontend (BFF) پیروی می کند. با این حال، با وجود کدهای تکراری پیچیدگی‌ها و نگرانی‌هایی وجود داشت. علاوه بر این، آنها برای کسب و کار از الگوی BFF و در الگوی BFF از منطق مجوزدهی استفاده کردند که خطرناک بود. در نتیجه، آنها تصمیم گرفتند از یک الگوی طراحی دامنه محور استفاده کنند و یک رویکرد جدید به نام "خدمات ارزش افزوده (VAS)" را توسعه دهند. در VAS سه سطح خدمات وجود دارد. اولین لایه Edge است که به عنوان یک دروازه API عمل می‌کند. دومین لایه، لایه ارزش افزوده است که داده‌های سرویس‌های مختلف را پردازش می کند تا یک تجربه کاربری غنی ارائه دهد. در نهایت به عنوان لایه سوم، "Foundation" وجود دارد که بلوک های ساختمان دامنه را فراهم می‌کند. در الگوی DDD، SoundCloud از VAS به عنوان یک مجموعه استفاده می‌کند. VAS همچنین جداسازی نگرانی‌ها را امکان پذیر کرده و یک ارکستراسیون متمرکز فراهم می‌کند. همچنین می‌تواند مجوز را اجرا کند و تماس‌های سرویس‌های مرتبط را برای ترکیب ابرداده هماهنگ کند. با استفاده از رویکرد VAS، SoundCloud موفق شد چرخه های انتشار را کاهش داده و در عین حال استقلال تیم را بهبود بخشد.
روش دوم: با اصل مسئولیت واحد (SRP)، واکنش‌های سریع‌تری داشته باشید.
SRP یک اصل طراحی مایکروسرویس است که در آن هر ماژول یا کلاس موظف است کاری را انجام دهد که برای عملکرد بهبود یافته اختصاص داده شده است. هر سرویس یا عملکرد مجموعه ای از منطق‌های تجاری خاص خود را دارد که مختص کار مورد نظر است.
یکی از مزایای اصلی SRP کاهش وابستگی است. هیچ هزینه اضافی برای هیچ سرویسی وجود ندارد زیرا هر عملکرد برای انجام وظایف خاصی طراحی شده است. همچنین با از بین بردن نیاز به انتظار، برای اجرای خدمات پشتیبانی قبل از پاسخ به درخواست کاربر، زمان پاسخگویی را کاهش می دهد.
Gojek چگونه با استفاده از SRP به اطمینان‌پذیری بالاتر و زمان پاسخ کوتاه‌تری دست یافت؟
Gojekis بازاری بر حسب تقاضا است که رانندگان و مسافران موتورسیکلت را به هم متصل می کند. یکی از ویژگی های متمایز، قابلیت چت است که به کاربران امکان می دهد از طریق برنامه "Icebreaker" با رانندگان وارد صحبت شوند. اتکای شدید Icebreaker به خدمات برای ایجاد یک کانال ارتباطی بین کاربران و رانندگان، مانعی برای Gojek بود.
برای ایجاد یک کانال، Icebreaker نیاز به انجام کارهایی مانند موارد زیر را داشت:
- احراز مجوز تماس های API
- فچ کردن (واکشی) پروفایل مشتری
- فچ کردن جزئیات راننده
- بررسی اینکه آیا پروفایل مشتری/راننده با جزئیات سفارش فعال مطابقت دارد یا خیر
- ساختن یک کانال ارتباطی
مشکل وابستگی به چندین تابع یا سرویس این است که اگر یکی از آنها از کار بیفتد، عملکرد فرایند چت به کل از کار می افتد.
تیم Gojek از اصل مسئولیت واحد برای اضافه کردن خدمات برای هر عملکرد، اختصاص وظایف به هر یک و کاهش فشار بر روی یک سرویس استفاده کردند.
- تابع فراخوانی API: آنها برای احراز هویت، دروازه API Kong را اضافه کردند.
- بازیابی نمایه: Icebreaker به توکن‌های چت از داده‌های راننده و کاربر ذخیره‌شده در پایگاه‌های داده جداگانه نیاز داشت، که سپس در محل دیتااستور‌های Icebreaker سیو می‌شدند. در نتیجه برای ایجاد کانال نیازی به بازیابی بیشتر نبود.
- رزرو فعال: Icebreaker باید در هنگامی که کاربر بر یک API ایجاد کانال کلیک می‌کند، بررسی کند که رزرو فعال از پیش انجام شده است یا خیر. تیم Gojek از رویکرد کارگر-سرور برای کاهش این وابستگی استفاده کرد.
بنابراین، هر بار که سفارشی ارسال می‌شود، یک کارگر یک کانال ارتباطی ایجاد می‌کند و آن را در حافظه پنهان Redis ذخیره می‌کند. که سرور بر حسب نیاز، هر بار که کاربر بر API کانال کلیک می‌کند، آن را راه‌اندازی می‌کند.
در نتیجه، Gojek زمان پاسخگویی خود را با رویکرد اصل مسئولیت واحد ، تا 95 درصد کاهش داد.
روش سوم: استقلال سرویس را با مایکروسرویس های مستقل فعال کنید
مایکروسرویس مستقل روشی است که در آن جداسازی سرویس را یک قدم فراتر می‌بریم. از طریق روش‌های مایکروسرویس مستقل، سه نوع از استقلال را می‌توان به دست آورد.
- سرویس مستقل تکامل: فرآیندی است برای جداسازی توسعه ویژگی بر اساس نیاز به تکامل.
- آزمایش مستقل: فرآیندی است از انجام تست هایی که اولویت بندی شده و بر تکامل سرویس‌ها تمرکز دارد. این فرآیند باعث کاهش تعداد خطاهای تست، ناشی از وابستگی به سرویس می شود.
- گسترش مستقل: احتمال خرابی بر اثر آپگرید سرویس‌ها را کاهش می دهد. این کار مفید است، به خصوص اگر در حین گسترش برنامه، وابستگی چرخه‌ای داشته باشید.
عملکردهای تک منظوره آمازون و مسائل مربوط به مدیریت مایکروسرویس های مستقل
در سال 2001، حفظ گسترش یک خط لوله با معماری یکپارچه برای توسعه دهندگان آمازون سخت بود. بنابراین، آنها تصمیم گرفتند به سمت معماری مایکروسرویس بروند، اما چالش واقعی آنها پس از این تصمیم اتفاق افتاد. تیم های آمازون چینش واحدهای تک منظوره را انجام دادند و آنها را با یک رابط وب به هم وصل کردند. بدون شک این یک راه حل کارآمد بود، اما مشکل این بود که مدیریت چندین عملکرد تک منظوره بسیار سخت است. ادغام سرویس آنها برای گسترش، هفته‌ها به طول انجامید و با افزایش سرویس‌ها، تبدیل به یک چالش بزرگ شد. از این رو، تیم های توسعه‌دهنده در آمازون «Apollo» را ساختند، یک سیستم گسترش خودکار مبتنی بر سرویس‌های جدا شده. علاوه بر این، آنها قانونی را ایجاد کردند که توابع همه منظوره باید از طریق یک API رابط وب با یکدیگر ارتباط برقرار کنند. آنها مجموعه ای از قوانین جداسازی را تعریف کردند که هر تابعی باید از آنها پیروی کند. در نهایت، آنها مجبور به پاسکاری‌های دستی شدند که منجر به فرا رسیدن "وقت‌های اضافه" شد. در نهایت، توالی لوله گسترش برای کاهش انتقال دستی، به‌منظور بهبود کارایی کل سیستم کشف شد.
روش چهارم: از موازی بودنِ ارتباطات ناهمزمان استقبال کنید.
بدون ارتباط مناسب بین سرویس ها، عملکرد مایکروسرویس های شما می تواند به شدت آسیب ببیند. دو پروتکل ارتباطی وجود دارد که معمولاً برای مایکروسرویس ها استفاده می شود:
- ارتباط همزمان: یک پروتکل ارتباطی از نوع مسدودکننده است که در آن مایکروسرویس ها، زنجیره ای از درخواست‌ها را تشکیل می دهند. گرچه این پروتکل دارای یک تک نقطه شکست است و به دلیل وابستگی در عملکرد، یک پله عقب‌تر از پروتکل دیگر است.
- ارتباطات ناهمزمان: یک پروتکل غیر مسدود کننده است که از معماری رویداد محور پیروی می کند. این پروتکل امکان اجرای موازی درخواست ها را فراهم کرده و انعطاف پذیری بهتری را فراهم می‌سازد.
پروتکل ارتباطی ناهمزمان گزینه بهتری برای ارتباطات پیشرفته بین مایکروسرویسها است و جفت شدن بین سرویس ها را در طول اجرای درخواست‌های کاربر کاهش می دهد.
Flywheel Sports چگونه از ارتباطات مایکروسرویس پیشرفته برای پخش بلادرنگ استفاده کرد؟
Flywheel Sports، پلتفرم Flywheel anywhere را راه‌اندازی کرد. یک پلتفرم برای جامعه تناسب اندام که تجربه دوچرخه‌سواری از طریق پخش بلادرنگ موقعیت را فراهم کرد. مهندسان Flywheel این پلتفرم را با استفاده از رویکرد ماژولار و معماری مایکروسرویس ایجاد کردند. با این حال، برخی چالش‌های ارتباطی وجود داشت که منجر به خرابی شبکه و مشکلات دسترسی سیستم شد.
برای حل این مشکلات، آنها چک لیستی از این ویژگی‌ها را آماده کردند:
- کشف سرویس
- پیام رسانی
- صف سازی
- ورود به سیستم
- Load balancing
آنها “Hydra” را ساختند، یک کتابخانه داخلی که از ویژگی‌های فوق و خوشه‌های Redis پشتیبانی می کند. آنها هر مایکروسرویس را به یک خوشه Redis مشترک گره زدند و از pub/sub (ارتباطات ناهمزمان) برای حفظ ارتباطات بین فرآیندی استفاده کردند.
و این همه ماجرا نبود. Hydra همچنین ویژگی‌های زیر را هم فعال کرد:
- ارتباط بین سرویس
- کشف سرویس
- Load Balancing و مسیریابی
- خود ثبت‌نام بودن سرویس با پیکربندی صفر
- صف های شغلی
به طور کلی، می‌توان نتیجه گرفت که ارتباطات ناهمزمان از طریق Hydra، در ایجاد یک پایه محکم برای ارائه پخش بلادرنگ به مشتریان، به Flywheel کمک کرد.
روش پنجم: دیتابیس مایکروسرویس جداگانه برای کاهش تاخیر
اگرچه مایکروسرویسها به طور ضعیفی جفت می شوند، اما همه آنها نیاز به بازیابی داده ها از یک دیتااستور با یک دیتابیس مشترک دارند. در چنین مواردی، دیتابیس باید با سوالات و مشکلات تأخیر زیادی سروکار داشته باشد. ممکن است راه حل یک دیتابیس قابل توزیع برای مایکروسرویس ها باشد، که در آن هر سرویس برای پاسخگویی، یک دیتااستور مخصوص به خود داشته باشد.
دیتابیس مایکروسرویس جداگانه به سرویس ها اجازه می‌دهد تا داده ها را به صورت محلی در یک کش ذخیره کنند. در نتیجه تأخیر کاهش می یابد. از آنجایی که هیچ نقطه شکستی با یک دیتااستور متمایز وجود ندارد، امنیت و انعطاف پذیری نیز بهبود می‌یابد.
توانایی توییتر برای پردازش میلیون‌ها QPS، از طریق یک دیتااستور مایکروسرویس اختصاصی بهبود یافته است.
توییتر در سال 2012 رویه خود را از معماری نرم افزاری یکپارچه، به معماری مایکروسرویس تغییر داد و از چندین سرویس مختلف از جمله Redis و Cassandra برای رسیدگی به حدود 600 درخواست در ثانیه استفاده کرد. با این حال که این پلتفرم گسترده‌تر شد، به یک راه‌حل برای دیتابیس نیاز داشت که قابل گسترش، انعطاف‌پذیر و دارای توانایی رسیدگی به کوئری‌های بیشتر در ثانیه باشد.
لورم ایپسوم متن ساختگی با تولید سادگی نامفهوم از صنعت چاپ و با استفاده از طراحان گرافیک است چاپگرها و متون بلکه روزنامه و مجله در ستون و سطرآنچنان که لازم است.
روش ششم: مایکروسرویس ها را کانتینری کنید تا کارایی فرآیند بهبود یابد
کانتینری کردن مایکروسرویس ها یکی از کارآمدترین روش هاست. کانتینرها به شما این امکان را می دهند که حداقل تنظیمات برنامه، کتابخانه ها و باینری ها را بسته بندی کنید. در نتیجه وزن آنها کاهش یافته و قابل حمل در سراسر محیط خواهند شد.
جدای از این، کانتینرها هسته و سیستم عامل را به اشتراک می گذارند، که نیاز به منابع مورد نیاز برای سیستم عامل فردی را کاهش می دهد. از جمله مزایای فراوانی که کانتینرسازی می‌تواند ارائه دهد می‌توان به موارد زیر اشاره کرد:
- جداسازی فرآیند با حداقل منابع
- فوت‌پرینت حافظه کوچکتر
- سازگاری داده های بالاتر به دلیل سیستم عامل مشترک.
- عدم تاثیر تغییرات ناگهانی محیط بیرون بر روی کانتینرها
- هزینه های بهینه و تکرار سریع تر
- عرضه و برگشت سریع
Spotify چگونه برای پردازش 10 میلیون درخواست در ثانیه، 150 سرویس را به Kubernetes QPS منتقل کرد؟
Spotify از سال 2014 کانتینری مایکروسرویس ها را انجام داده است. با این حال، از سال 2017، آنها متوجه شدند که سیستم ارکستراسیون خانگی آنها، یعنی Helios، به منظور تکرار سریع برای 200 تیم تولید مستقل کافی نیست. Kubernetes برای Spotify، راه حلی بر ناکارآمدی Helios بود. مهندسان Spotify برای اینکه تمام تخم مرغ‌های خود در یک سبد نگذاشته باشند، برخی از خدمات را به Kubernetes منتقل کردند که در کنار Helios اجرا شوند. آنها پس از بررسی کامل چالش‌های فنی اصلی، از APIهای Kubernetes و ویژگی‌های توسعه‌پذیری برای ادغام استفاده کردند. علاوه بر این، Spotify در سال 2019 با تمرکز بر خدمات بدون تابعیت، انتقال به Kubernetes را تسریع کرد. آنها بیش از 150 سرویس را به منظور رسیدگی به 10 میلیون درخواست در ثانیه منتقل کردند.
روش هفتم: قابلیت های بومی UI را با مایکروفرانت‌اند افزایش دهید.
معماری مایکروفرانت‌اند روشی برای تجزیه یک فرانت‌اند یکپارچه به عناصر کوچکتر است. این روش از معماری مایکروسرویس پیروی می کند و ارتقاء عناصر منفرد UI را امکان پذیر می کند. با این رویکرد، می توانید تغییراتی در اجزای جداگانه ایجاد و آنها را آزمایش و اجرا کنید.
علاوه بر این، معماری مایکروفرانت‌اند به ایجاد تجربیات بومی نیز کمک می کند. به عنوان مثال، استفاده از رویدادهای ساده مرورگر را برای برقراری ارتباط فعال می‌کند که از نگهداری APIشان آسان تر است. مایکروفرانت‌اند خطوط لوله CI/CD را با فعال کردن حلقه های بازخورد سریعتر بهبود می بخشد. بنابراین، می‌توانید فرانت‌اندی بسازید که هم مقیاس‌پذیر و هم چابک باشد.
چگونه فیس بوک تاخیرهای صفحه وب را با BigPipe بهبود بخشید؟
در سال 2009، فیسبوک با فرانت‌اند وب‌سایت خود مشکل داشت و نیاز به راه‌حلی برای کاهش زمان بارگذاری صفحاتش داشت. معماری سنتی فرانت‌اند نیاز به رندر همپوشانی مرورگر و بهینه سازی تولید صفحات داشت. این دست بهینه سازی‌ها تنها راه حلی بود که در کاهش تاخیر و افزایش زمان پاسخ‌دهی به آنها کمک می‌کرد. به همین دلیل فیسبوک یک راه‌حل مایکروفرانت‌اند به نام BigPipe ساخت. این راه حل فیس بوک اجازه داد تا صفحه وب را به اجزای کوچکتری به نام «pagelets» تقسیم کند. فیسبوک با استفاده از BigPipe، تاخیر در صفحات وب مرورگرها را کاهش داد. با گذشت زمان، معماری‌های مدرن صفحات وب با استفاده از مایکروفرانت‌اند، برای پشتیبانی از موارد استفاده مانند برنامه‌های وب و برنامه‌های کاربردی تلفن همراه نیز تکامل یافتند.
روش هشتم: مایکروسرویس ها را برای حفاظت از داده ها ایمن کنید.
مایکروسرویس ها از طریق API با سرویس ها یا پلتفرم های خارجی ارتباط برقرار می‌کنند و ایمن سازی چنین ارتباطی ضروری است. داده‌ها می‌توانند به خطر بیفتند و هکرها می‌توانند کنترل خدمات اصلی را در دست بگیرند و در صورت عدم استفاده از اقدامات ایمنی مؤثر، عملکرد برنامه شما را مختل کنند. برای اینکه این مسئله را بهتر توضیح بدهیم، لازم به ذکر است که بگوییم نقض داده‌ها در هر دقیقه بیش از 2.9 میلیون دلار خسارت به کسب و کارها وارد می‌کند.
بنابراین، امنیت مایکروسرویس ها برای کسب و کار شما حیاتی است. راه های زیادی برای ایمن سازی مایکروسرویس ها وجود دارند. برای مثال:
- رمزگذاری SSL/TLS
- احراز هویت چند عاملی
- محدودیت دسترسی به داده‌ها
- فایروال برنامه های وب
- اسکن آسیب پذیری
- تست نفوذ
OFX مایکروسرویسها را با یک ابزار امنیتی سطح متوسط ایمن کرد
OFX یک موسسه انتقال مالی بین المللی در استرالیا است که سالانه بیش از 22 میلیارد دلار تراکنش را پردازش می‌کند. پس از مهاجرت به محیط ابری، OFX نیاز به یک راه حل ایمن برای افزایش قابلیت دید و محافظت در برابر تهدیدات سایبری که توسط پروژه امنیتی اپلیکیشن اپن‌وب (OWASP) تعریف شده بود، نیاز داشت. شرکای OFX و سرویس های خارجی از طریق API و در یک شبکه داخلی با مایکروسرویس ها ارتباط برقرار می کنند. بنابراین، آنها نیاز به بهبود امنیت و قابلیت دید برای تأیید درست درخواست های دسترسی از سیستم عامل های خارجی داشتند.
برای مقابله با این موضوع، OFXبا یک ایجنت یک ابزار امنیتی را در محیط سطح متوسط سرورهای وب خود مستقر کرد تا دید بهتری به جنبه‌های مختلف زیر داشته باشد:
- تشخیص الگوهای مشکوک
- نظارت بر تلاش برای ورود به سیستم
- مسدود کردن ترافیک مخرب
- تست نفوذ گسترده
با افزودن یک ابزار امنیتی در سطح متوسط، تیم‌های امنیتی و معماران ابری می‌توانند هر تعاملی در APIها را ردیابی کنند. این به آنها کمک کرد تا خطرات را شناسایی و سرومایکروسرویس‌ها را ایمن کنند.
روش نهم: برنامه نویسی موازی را با API های تغییرناپذیر ساده کنید.
مایکروسرویسها و تغییرناپذیری، هر دو ایده‌ی موازی‌گرایی را به اشتراک می گذارند، که در به کارگیری اصل پارِتو نیز کمک می‌کند. علاوه بر این، موازی سازی به شما این امکان را می‌دهد که در مدت زمان کمتر، کارهای بیشتری انجام دهید.
تغییرناپذیری مفهومی است که در آن داده ها یا آبجکت‌ها، پس از ایجاد شدن، تغییر نمی‌کنند. بنابراین، برنامه نویسی موازی به خصوص در هنگام استفاده از معماری مایکروسرویس، بسیار آسان تر است.
بیاموزید که چگونه کانتینرهای تغییرناپذیر، امنیت، تأخیر و موارد دیگر را بهبود می‌بخشند
بیایید یکی از موارد استفاده، مانند یک وب اپ تجارت الکترونیک را در نظر بگیریم که نیاز به ادغام درگاه های پرداخت خارجی و خدمات شخص ثالث دارد.
یکپارچه سازی سرویس های خارجی برای ارتباطات مایکروسرویس و تبادل داده به API نیاز دارد. به طور سنتی APIها قابل تغییر هستند و قدرت ایجاد چندین جهش را بر حسب نیاز فراهم می‌کنند.
با این حال، مشکل APIهای قابل تغییر، حساسیت به حملات سایبری است. هکرها از دسترسی به داده های shell (پوسته) برای تزریق کدهای مخرب استفاده می کنند.
از سوی دیگر، تغییرناپذیری با مایکروسرویس‌های کانتینری، امنیت و یکپارچگی داده‌ها را بهبود می بخشد. می توانید به سادگی به جای اینکه کانتینرهای معیوب را تعمیر کرده یا اینکه ارتقائشان بدهید، آنها را به وسیله کانتینرهای غیرقابل تغییر حذف کنید. به عبارت دیگر، API های تغییرناپذیر می‌توانند به پلتفرم تجارت الکترونیک شما کمک کنند تا داده‌های کاربران ایمن‌سازی شود.
یکی دیگر از مزایای کلیدی API تغییرناپذیر، برنامه نویسی موازی است. یک نکته مهم در مورد برنامه های همزمان این است که چگونه تغییرات در یک رشته، بر موضوعات دیگر تأثیر می گذارد. این منجر به پیچیدگی مسئله برای برنامه نویسانی می شود که باید زمینه اجرای رشته (Thread) خود را کشف کنند.
APIهای غیرقابل تغییر این مشکل را با محدود کردن اثرات جانبی یک رشته بر روی دیگر رشته‌ها حل می‌کنند. با صرف نظر از اینکه این رشته به کدام نسخه از یک آبجکت دسترسی دارد، تغییر حالت محدود می‌شود. اگر یک رشته به یک نسخه تغییر یافته از یک آبجکت نیاز داشته باشد، یک رشته جدید به صورت موازی ایجاد می شود. بنابراین، می توانید چندین رشته را به صورت موازی اجرا کنید و کارایی برنامه نویسی خود را بهبود ببخشید.
روش دهم: سرعت دلیوری را با کالچرِ DevOps افزایش دهید.
DevOps مجموعه‌ای از روش‌هاست که قابلیت‌های عملیاتی و توسعه‌ای را برای افزایش قابلیت همکاری در هم می‌شکند. DevOps می تواند با یک استراتژی منسجم و همکاری کارآمد، و همچنین بسیاری از مزایای دیگر، به سازمان شما کمک کند.
DocuSign خطاها را کاهش داد و کارایی CI/CD را با DevOps بهبود بخشید.
DocuSign فناوری امضای الکترونیکی برای توسعه نرم افزار را با استفاده از رویکرد Agile معرفی کرد. با این حال، آنها به زودی متوجه شدند که عدم همکاری بین تیم های منفرد منجر به شکست می‌شود.
مدل کسب و کار DocuSign، که شامل قراردادها و امضاها بود، نیاز به یکپارچگی مداوم داشت. به علاوه، مبادله امضاها و تاییدیه‌ها باید بدون خطا می‌بود، زیرا تنها یک اشتباه می‌توانست منجر به بروز مشکلات جدی شود.
بنابراین، DocuSign کالچر DevOps را برای بهبود همکاری بین اعضای تیم عملیات و توسعه اتخاذ کرد. با وجود تغییر کالچر سازمان به دلیل پذیرش DevOPs، مشکل CI/CD همچنان ادامه داشت. آنها به‌منظور پشتیبانی از یکپارچه سازی مداوم از اپلیکیشن جعلی برای APIهای داخلی استفاده کردند.
ابزار اپلیکیشن جعلی (mock) یک اندپوینت و پاسخ ساختگی ارائه می‌دهد. DocuSign آن را با مدیریت تصادفی ترکیب می کند و پیش از انتشار، برنامه را از طریق شبیه‌سازی آزمایش می‌کند. این به آنها کمک کرد تا برنامه‌ها را به سرعت و از طریق یک استراتژی منسجم، ساخته، آزمایش و منتشر کنند.
شبیه‌سازی به آنها اجازه می‌داد تا رفتار برنامه را در سناریوهای واقعی آزمایش کنند، جداسازی خطا را بهبود بخشند و تغییرات سریع ایجاد کنند. بنابراین، آنها می توانستند به طور مداوم آزمایش کرده، تغییرات را ادغام کنند و به طور منسجمی تحویل مستمر داشته باشند.
اصل 80/20!
تمام چیزی که اصل 80/20 می‌گوید، در مورد کاهش تلاش‌ها و به حداکثر رساندن سود است. روش‌های برتر مایکروسرویس می‌توانند به شما در دستیابی به حداکثر بهره‌وری کمک کنند. با این حال، هر کدام از این روش‌ها را که انتخاب کنید، مورد استفاده خاص باقی می‌ماند. مثالی از CrayPay را در نظر بگیرید، که برای پرداخت های خرده فروشی به یک راه حل پرداخت m-pay نیاز داشت.
Leave feedback about this