شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
در طول ماه‌های آگوست و سپتامبر ۲۰۱۵، ما در حال انتقال روترهای ابری و متعادل‌کننده‌های بار Apigee Edge خود به NGINX (که "Engine X" تلفظ می‌شود) هستیم. NGINX، یک وب سرور متن‌باز، عملکرد حتی بهتر و همزمانی بالاتری نسبت به متعادل‌کننده‌های بار و روترهای فعلی ما ارائه می‌دهد.
این برای مشتریان ابری ما چه معنایی دارد؟
نکته اصلی این است که این تغییر باید برای شما شفاف باشد و به هیچ اقدامی از جانب شما نیاز نداشته باشد، جز تأیید اینکه سیستم‌های شما طبق انتظار کار می‌کنند. در ادامه توضیحاتی در مورد مراحلی که انجام خواهیم داد، به همراه پاسخ به برخی از سوالات متداول آمده است.
مرحله ۱ - به‌روزرسانی نرم‌افزار
ما با استفاده از مدل استقرار مرحله‌ای خود، تمام روترها را به روتر جدید مبتنی بر NGINX ارتقا خواهیم داد تا اطمینان حاصل شود که سرویس‌ها در نتیجه این فعالیت تحت تأثیر قرار نمی‌گیرند.
مرحله ۲ - حذف لایه متعادل‌کننده بار در محیط‌های غیرتولیدی
با مدیریت قابلیت متعادل‌سازی بار توسط روتر جدید NGINX، ابتدا فرآیند حذف لایه متعادل‌کننده بار موجود در محیط(های) غیرتولیدی شما آغاز خواهد شد. متعادل‌کننده‌های بار تولیدی در این مرحله دست‌نخورده و بدون تغییر باقی خواهند ماند. قبل از حذف متعادل‌کننده‌های بار موجود، رویکردی جامع برای اطمینان از عملکرد ترافیک مطابق انتظار اتخاذ خواهیم کرد. برای تکمیل این مرحله نیازی به انجام هیچ اقدامی از سوی شما نیست. با این حال، شما باید هرگونه مشکلی را به Apigee گزارش دهید و ما قبل از ادامه مرحله 3 با شما همکاری خواهیم کرد تا مشکلات را حل کنیم.
مرحله ۳ - حذف لایه متعادل‌کننده بار در محیط‌های عملیاتی
پس از اتمام موفقیت‌آمیز مرحله ۲، مجموعه‌ای از پنجره‌های نگهداری را برای حذف لایه متعادل‌کننده بار در محیط(های) عملیاتی با استفاده از همان رویکرد ذکر شده در مرحله ۲ تعیین خواهیم کرد تا اطمینان حاصل شود که ترافیک API در زمان اجرا طبق انتظار به کار خود ادامه می‌دهد.
تغییرات در عملکرد محصول
در اینجا برخی از تغییرات در عملکرد محصول با تغییر به NGINX آورده شده است.
منسوخ شده
ویژگی‌های زیر دیگر در ProxyEndpoints پشتیبانی نمی‌شوند:
- اجازه دهید.http10
- اجازه دهید.http11
- اجازه دهید.http.method.*
- اجازه ارسال بدون محتوا با طول مشخص
- اجازه قرار دادن بدون محتوا با طول دلخواه
برای حل این مشکل، به مقاله انجمن زیر مراجعه کنید: عدم کارکرد ویژگی‌های متد در Proxy Endpoint HTTP allow .
سوالات متداول
در ادامه به برخی از سوالات متداول در مورد مهاجرت به NGINX پاسخ داده شده است.
در طول مرحله ۱، پاسخ «خیر» است زیرا ما به متعادل‌کننده‌های بار موجود دست نمی‌زنیم، که مستقیماً هیچ یک از IPهای سرویس‌دهنده ترافیک را تغییر نمی‌دهند. با این حال، با توجه به ماهیت سرویس متعادل‌کننده بار Amazon Web Services (AWS)، قوانین مقیاس‌بندی عادی اعمال می‌شود، به این معنی که IPها ممکن است به عنوان بخشی از منطق مقیاس‌بندی آن (عملکرد موجود) تغییر کنند. به همین دلیل است که ما پیاده‌سازی پیکربندی‌های لیست مجاز Northbound را با مجموعه محصولات Apigee Edge توصیه نمی‌کنیم. در طول مراحل ۲ و ۳، با حذف متعادل‌کننده بار و آدرس‌های IP مرتبط با آن، پیامدهای لیست مجاز وجود دارد. در نتیجه، ما در طول این مراحل با شما هماهنگی نزدیکی خواهیم داشت تا با ارائه مجموعه‌ای جدید از آدرس‌های IP که اجازه دسترسی به آنها داده می‌شود، انتقال روان را تضمین کنیم.
با فرض اینکه سرورهای مبدا، سرورهای نقطه پایانی هدف (سرورهایی که از بسته پروکسی فراخوانی می‌شوند) باشند، نیازی به تغییر نیست. این تغییر در سمت شمال Apigee یا نقطه ورود به Apigee است.
خیر. ورودی‌های CNAME موجود طبق انتظار به کار خود ادامه خواهند داد.
اگر از SSL استفاده می‌کنید، مرحله اولیه تاثیری بر پیکربندی SSL موجود نخواهد داشت. با این حال، قبل از ادامه مراحل ۲ و ۳، باید با شما هماهنگی‌های لازم را انجام دهیم تا مطمئن شویم SSL به درستی روی روتر جدید تنظیم شده است.
مراحل ۲ و ۳ تا زمان تأیید پشتیبانی SNI به تعویق خواهند افتاد.
ما انتظار هیچگونه خرابی را نداریم. تغییرات با استفاده از مدل استقرار استاندارد ما در طول بازه‌های انتشار فعلی ما اجرا خواهند شد.