آیا طراحی API یک هنر گمشده است؟

از APIها و سرویس‌های مبتنی بر ابری که طراحی، توسعه و استقرار ضعیفی دارند، تأخیر زیادی دریافت می‌کنیم. زمان آن رسیده است که آزمایش و نظارت را بررسی کنیم.

صبح جمعه است و شما هیجان زده اید. امروز سیستم هوش مصنوعی مولد جدید شما که بر روی یک ارائه دهنده ابر عمومی بزرگ اجرا می شود، قرار است با سیستم های تجارت الکترونیک موجود که ۸۰ درصد از درآمد شرکت را تامین می کنند، کار کند.

این شرکت انتظار دارد توانایی جدید برای ایجاد فروش بیشتر در حالی که درک بهتری از مشتریانی که از سایت استفاده می‌کنند ارائه کند. این سیستم همچنین می‌تواند معاملات بسته‌بندی سفارشی را در پرواز انجام دهد. بازاریابی تخمین می زند که این امر میانگین فروش واحد را تا ۳۰ درصد افزایش می دهد. تغییر دهنده بازی.

چنان فشاری برای پیاده‌سازی این امر صورت گرفته است که تیم‌های توسعه ابری و وب‌سایت اکثر تست‌های استرس را نادیده گرفتند و در عوض بر این قول تکیه کردند که این سیستم‌های مبتنی بر ابر «باید قادر به مقیاس‌پذیری» باشند.

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

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

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

اصول طراحی API

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

مبانی طراحی خوب API چیست؟ بیایید موارد بزرگ را مرور کنیم:

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

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

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

مدیریت کارآمد دادهبه معنی بهینه سازی اندازه بسته های داده ای است که به درخواست کننده ارسال می شوند. پاسخ های API باید داده های غیر ضروری را حذف کنند. این کار تأخیر و استفاده از پهنای باند را به حداقل می رساند.

نظارت و آزمایش

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

من معیارهای عملکرد زیر را توصیه می‌کنم:

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

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

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