سفر API طولانی است و راه پیش رو پر از موانع است. در اینجا پنج مورد از بدترین آنتی پترن هایی که باید هنگام شروع API خود اجتناب کنید، آورده شده است. این را تصور کنید: شما در شرکتی به نام آنوفل به عنوان رئیس مهندسی پلتفرم کار می کنید و هر ساله چندین API را به صورت آنلاین برای توسعه برنامه‌هایتان منتشر و پیاده سازی می کنید. شما باید خدمات حیاتی خود را از طریق APIهای ایمن در اختیار صدها مشتری قرار دهید. از آنجایی که هیچ‌کس روی زمین نمی‌خواهد خدمات شما باید از طریق APIهای ایمن در اختیار صدها فروشنده قرار گیرد تا هیچ مشکلی پیش نیاید.
محیط فعلی شما بیشتر از ماشین های مجازی تشکیل شده است، اما شما در حال مهاجرت تدریجی به یک پلتفرم بومی ابری هستید. بیشتر خدمات تولیدی که شما مدیریت می‌کنید، APIها را در معرض نمایش قرار می‌دهند، اما تیم شما کنترل و دید بسیار کمی روی آنها دارد. هر سرویس متعلق به یک تیم توسعه‌دهنده متفاوت است و هیچ سازگاری در زبان‌ها، مصنوعات مستقر شده، نظارت، قابلیت مشاهده، کنترل دسترسی، رمزگذاری و غیره وجود ندارد.
برخی از سرویس‌ها مبتنی بر جاوا، «امن» با گواهی‌های قدیمی TLS 1.1 و پشت کنترل دسترسی JWT هستند. سایر سرویس‌ها مبتنی بر پایتون هستند، از گواهی‌های TLS 1.3 استفاده می‌کنند و پشت کنترل دسترسی سفارشی هستند. این تنوع را می توان به بقیه خدمات در محیط تولید شما تعمیم داد.
شما (به طور منطقی) فکر می کنید که این وضعیت بسیار ایده آل نیست و قصد دارید API ها را در آنوفل با کمک یک راه حل مدیریت API منطقی کنید. الزامات شما عبارتند از:
API های شما باید به شدت با سیاست های امنیتی متمرکز و منسجم اداره شوند
شما به مدیریت ترافیک پیشرفته مانند محدود کردن نرخ یا انتشار canary نیاز دارید
شما به معیارهای قابل مشاهده و استفاده بی‌درنگ در تمام نقاط پایانی عمومی نیاز دارید
به عبارت ساده، شما عملیات قابل پیش بینی، آرامش و خواب بهتر می خواهید.
به نظر می رسد برنامه شما درست است، و شما در مسیر روزهای (یا شب های) بهتر هستید. با این حال، یک سفر API طولانی است و راه پیش رو پر از موانع است. در اینجا پنج مورد از بدترین آنتی پترن هایی که باید هنگام شروع API خود اجتناب کنید، آورده شده است.
آنتی پترن چیست؟
ویکی‌پدیا یک آنتی پترن نرم‌افزاری را این‌گونه تعریف می‌کند:
"در مهندسی نرم افزار، یک ضد الگو (آنتی پترن) الگویی است که ممکن است معمولا مورد استفاده قرار گیرد، اما در عمل بی اثر و یا معکوس است."
به بیان ساده، آنتی پترن چیزی است که در ابتدا ایده خوبی به نظر می رسد اما در نهایت باعث ایجاد مشکلاتی می شود. با درک این مشکلات، می‌توانید APIهایی ایجاد کنید که قوی، قابل نگهداری و توسعه‌دهنده باشند. اینها باگ نیستند، بلکه انتخاب های طراحی هستند که می توانند منجر به مشکلات طولانی مدت شوند. بیایید به برخی از موارد رایج بپردازیم!
آنتی پترن 1: Monolith-Microservices
شما در حال سرمایه گذاری زمان، پول و تلاش برای راه اندازی یک راه حل مدیریت API هستید. در این فرآیند، بسیاری از جنبه‌های سرویس‌های در معرض دید خود مانند مدیریت ترافیک، امنیت اتصال و قابلیت مشاهده را متمرکز خواهید کرد. فکر کردن آسان است: «هر چه همه چیز متمرکزتر باشد، کنترل بیشتری دارم و بهتر می‌خوابم». چرا از این راه حل مدیریت API برای رهگیری هر تماس API و تغییر بدنه HTTP برای پاکسازی آن از داده های حساس (مانند اطلاعات خصوصی) استفاده نمی کنید؟
این تضمین می کند که هر تماس API در کل سیستم تمیز است. این درست است، اما فقط در کوتاه مدت.
برای آشنایی با تفاوت های بین میکروسرویس و مونولیث این مقاله را بررسی کنید و برای آشنایی با 10 آنتی پترن در میکروسرویس ها نیز این مقاله را بررسی کنید.
بیایید سه سال جلوتر برویم. پلتفرم مدیریت API شما اکنون بالغ شده است و صدها API را در ده ها تیم مختلف مدیریت می کند. پیروزی سریع اولیه برای پاکسازی بدنه HTTP در گردش کار مدیریت API به تدریج به یک غول تبدیل شد:
اولین وصله سریع ناگزیر به نیازمندی های پیچیده تری تبدیل شد که باید با هر API سازگار شود. ده خط شیک کد شما به سرعت به یک اسکریپت 5000 خطی غیرقابل نگهداری تبدیل می شود.
اکنون که این اسکریپت سفارشی API های بسیاری از تیم ها را اجرا می کند، هیچ کس نمی خواهد مالکیت این اسکریپت سفارشی را در اختیار بگیرد
هر نسخه جدید یک API ممکن است نیاز به به روز رسانی و آزمایش این قطعه کد داشته باشد که در پلتفرم API قرار دارد و از مخازن کد سرویس ها جدا شده است.
آزمایش این اسکریپت سفارشی کار زیادی می خواهد. اگر مشکلی دارید، ابتدا از ترافیک زنده یاد خواهید گرفت و برای رفع اشکال آن مشکل خواهید داشت.
راه حل API شما به شدت نیازمند منابع است. باید از واگذاری کل بدنه HTTP به پروکسی معکوس خود اجتناب کنید. این بیشتر CPU اختصاص داده شده به پلتفرم شما را مصرف می کند، و در عین حال که آن را به یک رویکرد فوق العاده گران تبدیل می کند، حاشیه بسیار کمی برای امنیت به شما می دهد.
به طور خلاصه، بهتر است از تصمیم گیری های کوتاه مدت اجتناب کنید. چیزی که در آن زمان ایده خوبی به نظر می‌رسد ممکن است تا چندین سال ادامه پیدا نکند. مدیریت API برای کشف، ایمن سازی، سازماندهی و نظارت بر API های شما طراحی شده است. نباید به عنوان میانبر برای اجرای کد برنامه استفاده شود.
نکته : جداسازی نگرانی هنگام طراحی پلتفرم تولید بعدی شما حیاتی است.
برای آشنایی با 10 دیزاین پترن برای معماری بهتر در میکروسرویس این مقاله را بررسی کنید.
آنتی پترن 2: Cart Before the Horse
آنتی پترن جالب دیگر تمرکز لیزری بر روی نتیجه بلندمدت، احتمالا ایده آل، بدون تشخیص یا درک مراحل رسیدن به آن است. پروژه تبدیل API شما آنقدر گران است که می خواهید مطمئن شوید همه چیز به خوبی اجرا می شود. بنابراین، شما غنی ترین راه حل مدیریت API را انتخاب می کنید تا تمام نیازهای احتمالی آینده را پوشش دهد، علیرغم اینکه امروز قادر به استفاده از بیشتر قابلیت های آن نیستید.
مطمئناً گران‌تر است، اما اگر در عرض سه سال از مهاجرت احتمالی شما جلوگیری کند، یک شرط مطمئن است. این ممکن است بدون خطر به نظر برسد، اما شما فقط نوک کوه یخ پروژه API را می بینید.
سه سال به جلو با این راه حل درجه یک و گران قیمت:
انتقال از پلتفرم قدیمی بیشتر از حد انتظار طول کشید.
این راه حل جدید مستلزم جلسات آموزشی پولی از طرف فروشنده برای تیم شما و بسیاری از توسعه دهندگان در سراسر شرکت بود
شما هنوز از بسیاری از ویژگی های راه حل استفاده نکرده اید.
بسیاری از تیم‌های توسعه‌دهنده از پذیرش این پلتفرم جدید به دلیل پیچیدگی آن اجتناب کردند.
هدف اولیه شما برای کنترل همه تماس‌های API در داخل شرکت هنوز محقق نشده است.
هنوز خواب ناکافی دارید.
در این مرحله، شما تصدیق می‌کنید که کامل‌ترین (و پیچیده‌ترین) راه‌حل ممکن است بهترین گزینه نباشد، بنابراین گلوله را گاز می‌گیرید و تصمیم می‌گیرید به یک راه‌حل ساده‌تر بروید که متناسب با نیازهای فعلی شما باشد. در تلاش شما برای جلوگیری از انتقال مدیریت API سه سال پس از شروع پروژه، به هر حال، فقط زودتر از آنچه در ابتدا پیش بینی می شد، باعث آن شدید.
نکته در اینجا این است که در حالی که باید چشم انداز بلندمدت خود را هدف گذاری کنید (و راه حلی را انتخاب کنید که با آن همسو باشد)، نیازهای امروز خود را برطرف کنید و به طور استراتژیک به سمت آن چشم انداز بسازید. این شامل برنامه ریزی برای آموزش تدریجی و پذیرش توسط تیم ها می شود. اگر محصول نتواند منحنی یادگیری پیشرونده و سفر استقرار را برای شما فراهم کند، نمی‌توانید به برنامه خود پایبند باشید.
در اینجا یک نمونه از یک سفر پیشرونده با همان محصول آورده شده است:
از منابع اولیه ورودی در Kubernetes شروع کنید.
سپس یک API Gateway معرفی خواهد شد که مدیریت ترافیک و امنیت API را به ارمغان می آورد.
سپس، پس از اینکه درک بهتری از ویژگی‌هایی که برای کسب‌وکارتان مهم هستند به دست آوردید، به یک پلتفرم مدیریت API بروید.
به طور خلاصه، یک محصول را به دلیل همه زنگ ها و سوت ها انتخاب نکنید. هیچ مقدار از ویژگی های جالب چالش های شما را حل نمی کند اگر هرگز استفاده نشوند. آنها را بر اساس این که استفاده از آن برای برآوردن نیازهای امروزی شما چگونه است و اینکه آیا آنها یک انتقال تدریجی به موارد استفاده پیشرفته تر در آینده را فراهم می کنند یا خیر، ارزیابی کنید.
نکته : هنگام انتقال به پلتفرم مدیریت API خود جلوتر نباشید.
امنیت در داکر: 14 روش که باید بدانید
آنتی پترن 3: به اندازه کافی خوب به عنوان کد
به عنوان یک رئیس مدرن مهندسی پلتفرم، شما به شدت به Infrastructure as Code (IaC) اعتقاد دارید. مدیریت و تهیه منابع شما در فایل های پیکربندی اعلامی یک الگوی طراحی مدرن و عالی برای کاهش هزینه ها و خطرات است. به طور طبیعی، در حین طراحی زیرساخت خود، این را به یک پایه قوی تبدیل خواهید کرد.
در طول سفر API خود، وسوسه خواهید شد که برخی از میانبرها را انتخاب کنید زیرا در کوتاه مدت پیکربندی یک مؤلفه مستقیماً در رابط کاربری مدیریت API نسبت به راه‌اندازی یک فرآیند IaC تمیز می‌تواند سریع‌تر باشد. یا ممکن است در ابتدا تغییر پیکربندی زمان اجرای تولید به صورت دستی به جای استقرار یک پیکربندی به روز شده از یک گردش کاری Git commit قابل دسترسی تر باشد. البته، همیشه می‌توانید بعداً آن را اصلاح کنید، اما در اعماق درون، آن مشکلاتی برای همیشه آنجا می‌مانند.
یا بدتر از آن، محصول مدیریت API شما باید تجربه کاربری ثابت IaC را ارائه دهد. برخی از مؤلفه ها باید در UI پیکربندی شوند. برخی از قطعات از YAML استفاده می کنند، برخی دیگر از XML استفاده می کنند، و شما حتی فرمت های پیکربندی اختصاصی دارید. این رویکردهای متنوع، داشتن یک فرآیند منسجم را غیرممکن می کند.
شما می گویید، «زیرساخت به عنوان یک کد عالی است، اما استثناها خوب هستند. تقریباً زیرساخت به عنوان یک کد به اندازه کافی خوب است.
سه سال سریع به جلو:
60 درصد زیرساخت به طور کامل در فایل های پیکربندی اعلام شده است و در یک مخزن git قرار دارد.
این فایل های پیکربندی در پنج فرمت نوشته شده اند: YAML، INI، XML، JSON، و یک فرمت سفارشی.
40 درصد باقیمانده به عملیات دستی در برخی داشبوردها یا فایل ها نیاز دارد.
چنان تنوعی در فرمت‌ها یا فرآیندهای پیکربندی وجود دارد که تیم شما نمی‌تواند پلتفرم را تحت کنترل درآورد و دائماً باید توسط تیم‌های دیگری که از هر قالب یا فرآیند آگاهی دارند نجات یابد.
خطای انسانی آنقدر زیاد است که فرآیند انتشار شما طولانی و غیر قابل اعتماد است. هر تغییری در زیرساخت نیاز به چند روز برای استقرار در تولید دارد و این بهترین سناریو است.
در بدترین سناریو، تغییری در تولید ایجاد می‌شود که باعث قطعی بزرگ می‌شود. از آنجایی که تیم شما قادر به عیب یابی سریع مشکل نیست، زمان بازیابی بر حسب ساعت اندازه گیری می شود. رئیس شما با نگرانی به صفحه نمایش روی شانه شما نگاه می کند و منتظر است تا راه حل معجزه آسایی به کار گرفته شود. هزاران سفارش دونات در این فرآیند از دست رفته است.
شما حتی سعی نمی کنید امشب بخوابید.
نتیجه واضح است، راه اندازی مدیریت API تا حدی به عنوان کد هدف کاهش هزینه ها و خطرات را از بین می برد. تنها زمانی که راه حل مدیریت API شما 100% به عنوان کد باشد، می توانید از یک پلتفرم قابل اعتماد، زمان پرشور بازار و بازیابی سریع بهره مند شوید.
استثناهای این فرآیند همیشه کارایی و قابلیت اطمینان جهانی پلتفرم شما را پایین می آورد. هرگز به فرآیندهای نیمه کاره بسنده نکنید.
آنتی پترن 4: System Versioning Chaotic
آنتی پترن نسخه سیستم هرج و مرج،هنگامی که سفر API خود را شروع می کنید، برنامه ریزی و پیش بینی هر مورد استفاده دشوار است. تغییر اجتناب ناپذیر است، اما نحوه مدیریت آن نیست. همانطور که در این بخش خواهیم دید، اثرات مدیریت ضعیف تغییر می‌تواند در طول سال‌ها گلوله برفی کند.
بیایید به همان ابتدا برگردیم: شما در حال راه اندازی پلتفرم جدید API خود هستید و در حال حاضر صدها API را به تولید منتقل کرده اید. شما از نتایج بسیار خوشحال هستید. احساس می کنید تحت کنترل هستید و بهتر می خوابید.
پس از یک سال، هشدارهای نظارتی پیشرفته شما به اعلان‌های شما سرازیر می‌شود و به مجموعه‌ای از تماس‌های API از یکی از بزرگترین مشتریان شما با خطاهای 404 اشاره می‌کند. خطاهای 404 گسترده هستند، بنابراین شما توجه کمی به آنها می کنید و به سرعت مشکل را به تیم توسعه دهنده مسئول API ارسال می کنید.
در طول ماه‌های بعد، تعداد 404 خطا و 500 خطا به طور قابل توجهی افزایش می‌یابد که ده‌ها API مختلف را تحت تأثیر قرار می‌دهد. شما شروع به نگرانی در مورد این موضوع می کنید و تیم خود را برای عیب یابی و یافتن علت اصلی جمع می کنید.
تجزیه و تحلیل شما مشکل مهم تری را آشکار می کند: API های شما به یک سیستم نسخه سازی سازگار نیاز دارند. شما پلتفرم خود را طوری طراحی کردید که گویی قراردادهای API شما هرگز تغییر نخواهند کرد، گویی API های شما برای همیشه دوام خواهند داشت.
در نتیجه، برای مدیریت تغییرات و انتشار نسخه‌های جدید APIهای خود، هر تیم فرآیندهای زیر را دنبال کرد:
برخی از تیم‌ها به خود زحمت رسیدگی به بررسی‌های سازگاری را ندادند و به تغییرات پیشرونده ادامه دادند.
برخی از تیم ها سعی کردند API های خود را به هر قیمتی سازگار نگه دارند. این نه تنها باعث شد که پایگاه کد به یک کابوس برای نگهداری تبدیل شود، بلکه به تدریج آشکار شد که تیم ها را از نوآوری منصرف می کند، زیرا آنها می خواستند از شکستن تغییرات و حفظ سازگاری با همه نسخه ها جلوگیری کنند.
برخی از تیم‌ها فرآیند قوی‌تری را با استفاده از نسخه‌سازی URL دنبال کردند، مانند https://api.anophel.com/v1/users و https://api.anophel.com/v2/users. آنها می‌توانستند چندین نسخه را همزمان با کدهای مختلف برای هر نسخه حفظ کنند. مشکل این بود که تیم‌های دیگر از استراتژی‌های متفاوتی مانند نسخه‌سازی پارامتر کوئری (https://api.anophel.com/users?version=v1) یا حتی نسخه‌سازی هدر استفاده می‌کردند.
برخی از تیم‌ها به طور مداوم از یک استراتژی نسخه‌سازی خاص مانند نسخه‌سازی URL پیروی می‌کردند، اما اسناد نسخه‌سازی شده را ارائه نکردند.
این مطالعه به شما کمک می کند تا متوجه شوید که مغز انسان چقدر خلاق است - توسعه دهندگان گزینه های مختلفی را انتخاب کردند!
نتیجه این است که کلاینت ها عبارتند از:
استفاده از اسناد قدیمی
فراخوانی API های منسوخ یا مرده
فراخوانی API های مختلف با استراتژی های نسخه سازی متفاوت
فراخوانی APIهای غیرقابل اعتماد
نکات کلیدی آشکار هستند: هیچ کدی برای همیشه دوام نمی آورد و تغییر بخشی طبیعی از توسعه API است. با توجه به این حقیقت، شما باید یک پایه قوی، قابل اعتماد و قابل تکرار برای فرآیند انتشار و مدیریت چرخه عمر API خود داشته باشید.
انتخاب راه حل مدیریت API شما نیز می تواند کمک کند. راه حلی را انتخاب کنید که یک استراتژی نسخه‌سازی انعطاف‌پذیر متناسب با نیازهای شما ارائه دهد و بتواند در هر API آنوفل اعمال شود.
علاوه بر این، اطمینان حاصل کنید که تیم‌ها چندین نسخه از API خود را حفظ می‌کنند که به‌عنوان بخشی از بهترین روش مدیریت تغییر گسترده‌تر به راحتی قابل دسترسی باشد. این تنها راه برای حفظ یک تجربه کاربری ثابت و قابل اعتماد برای مشتریان شما است. یک استراتژی نسخه‌سازی یکنواخت را برای همه APIهای خود اعمال کنید.
آنتی پترن 5: مدیریت وابستگی های YOLO
اکنون که فهمیدید چرا مدیریت استراتژی نسخه‌سازی API شما حیاتی است، بیایید مدیریت وابستگی برای APIها را مورد بحث قرار دهیم، موضوعی که اغلب به دلایل خوبی دست کم گرفته می‌شود. بسیار پیشرفته است
پس از اپیزود رقت‌انگیز بدون نسخه‌سازی-استراتژی، مطمئن شدید که سیاست‌های نسخه‌سازی را در آنوفل روی هر قطعه کد اعمال می‌کنند. شما حتی داشتید بهتر بخوابید، اما اگر تا اینجا مطالعه کرده باشید، می دانید که این نمی تواند دوام داشته باشد.
پس از دو ماه دیگر، مانیتورینگ پیشرفته شما دوباره به شما در مورد چندین تماس API از یکی از بزرگترین مشتریانتان هشدار می دهد که منجر به خطای 404 می شود! تو باید با من شوخی کنی! شما بقیه داستان را می دانید: کارگروه، دیباگ، TooManyRequestErrors، تجزیه و تحلیل علت ریشه، و (درام رول)…
همه APIهای شما واقعاً از استراتژی نسخه‌سازی اجباری پیروی می‌کنند: https://api.anophel.com/v1/users. پس چه اتفاقی افتاد؟
این فقط در مسیرهای منتشر شده در پلتفرم مدیریت API اعمال شد. سرویس های بک اندAPI ها از استراتژی نسخه سازی متفاوتی پیروی می کردند. حتی برای آن تعداد معدودی، هیچ مدیریت وابستگی بین مسیرهای API و خدمات بک اند شما وجود نداشت.
به عبارت دیگر، https://api.anophel.com/v1/users و https://api.anophel.com/v2/users توانستند نسخه مشابهی از یک سرویس را فراخوانی کنند که منجر به وضعیتی شبیه به نسخه بدون نسخه شد. قسمت استراتژی، با تجربه مشتری وحشتناک. اگر برخی از سرویس ها خدمات دیگری را فراخوانی کنند، حتی پیچیده تر می شود.
شما شروع به درک نظر من کردید: شما نیاز به سیاست های وابستگی دارید که بر روی همه API ها و سرویس های شما اعمال شود. هر API باید نسخه شود و یک نسخه (یا محدوده) سرویس خاص را فراخوانی کند، و همین رویکرد باید برای هر سرویس اعمال شود. برای دستیابی به این هدف، راه حل مدیریت API شما باید راهی منعطف برای بیان وابستگی ها در تعاریف API ارائه دهد. علاوه بر این، باید وابستگی‌ها را در مرحله استقرار از طریق لینترهای هوشمند بررسی کند تا از انتشار یک زنجیره وابستگی API شکسته جلوگیری کند.
این قابلیت ها در محصولات مدیریت API غیر معمول هستند، بنابراین باید عاقلانه انتخاب کنید. نکته اصلی این است : اجرای بررسی وابستگی در هنگام استقرار.
نتیجه
شما بیشتر کار خود را به ساخت زیرساخت آنوفل اختصاص دادید و چالش های بی شماری را در طول این ماجراجویی حل کردید. نتیجه بسیار مفید بوده است: آنوفل اکنون به درستی مدیریت می شود. برای آشنایی با طراحی صحیح API این مقاله را بررسی کنید.
هنگام برنامه ریزی سفر API خود، باید این پنج اصل را در نظر بگیرید تا بازده خود را به حداکثر برسانید و تلاش خود را به حداقل برسانید:
پلتفرم API خود را با جدایی قوی از نگرانی ها طراحی کنید. از واگذاری منطق تجاری به پلتفرم خودداری کنید.
نوار را خیلی بالا یا خیلی سریع قرار ندهید. قدم به قدم پیش بروید. با مفاهیم ساده‌تر مانند ورودی‌ها شروع کنید و زمانی که آنها را بهتر درک کردید، به تدریج به سمت موارد استفاده پیشرفته‌تر از API بروید.
در حالی که فرآیندهای خود را صنعتی می کنید، تحمل استثناها هدف را از بین می برد و تمام مزایای مورد انتظار یک پلتفرم کاملاً خودکار را به دست نخواهید آورد.
نسخه سازی در درازمدت به یک چالش حیاتی تبدیل می شود. شروع سفر API خود با یک استراتژی نسخه‌سازی قوی و منسجم در تمام APIهای شما، پلتفرم شما را مقیاس‌پذیرتر، قابل اعتمادتر و قابل پیش‌بینی‌تر می‌کند.
در زیرساخت‌های پیچیده با بسیاری از قطعات متحرک، کنترل و تأیید وابستگی‌های زمان اجرا برای همه مؤلفه‌ها برای دستیابی به سطح بالایی از اعتماد و ثبات برای پلتفرم شما بسیار مهم است.
البته این فهرست جامع نیست، اما رایج ترین شیوه ها را پوشش می دهد. تمام آنچه گفته شد، این توصیه‌ها نباید مانع از دور شدن شما و امتحان فرآیندهای مختلف شود. نوآوری بر اساس بازخورد دیگران ساخته می شود، اما همچنان به خلاقیت نیاز دارد.