ویژگی های جدید API7 Enterprise 3.2.9: پیکربندی بررسی سلامت ارتقا یافته

مقدمه ای بر ویژگی های جدید بررسی سلامت

در نسخه 3.2.9 API7 Enterprise، تجربه تعامل پیکربندی برای بررسی سلامت به طور جامع بهینه شده است.

1. موارد پیکربندی که قبلاً پراکنده شده بودند، به طور منطقی تجمیع شده‌اند، مانند تنظیمات کاوشگر، و معیارهایی برای تعیین گره‌های سالم و ناسالم و ساختن آنها ساختارمندتر.

2. برخی از نام آیتم های پیکربندی انتزاعی به تبدیل شده اند شهودی تر و عبارات معنایی، به کاربران این امکان را می دهد که مستقیماً پارامترهای مربوطه را از طریق قالب پر کردن خالی وارد کنند، بنابراین درک واضح تری از اثرات عملی پیکربندی ها به دست می آورند.

3. در طول پیکربندی گره‌های بالادست و فرآیندهای بررسی سلامت، پیام‌های سریع‌تری اضافه شده‌اند تا به کاربران در درک بهتر ارتباط ذاتی بین گره‌های بالادست و بررسی‌های سلامت کمک کنند و در نتیجه تسهیل کنند. آسان تر تکمیل وظایف پیکربندی

مفاهیم اساسی چک های سلامت

در API7 Enterprise، تنظیمات اولویت گره‌های بالادست با مکانیسم‌های تعادل بار و بررسی سلامت مرتبط است. هنگامی که کاربران چندین گره بالادست را با اولویت های مختلف برای دروازه پیکربندی می کنند، دروازه گره های با بالاترین اولویت را در طول متعادل سازی بار اولویت بندی می کند. این بدان معنی است که تا زمانی که گره های با اولویت سالم باقی بمانند، دروازه به هدایت ترافیک به این گره ها ادامه خواهد داد.

تنها زمانی که تمام گره‌های با بالاترین اولویت به دلیل بررسی‌های سلامت ناموفق در دسترس تلقی شوند، دروازه به‌طور خودکار تخریب می‌شود و ترافیک را به گره‌های با بالاترین اولویت بعدی هدایت می‌کند. این طراحی استفاده موثر از ترافیک و در دسترس بودن بالای سیستم را تضمین می کند.

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

روش‌های پیکربندی برای بررسی سلامت

پیکربندی پروب

یک کاوشگر برای تشخیص زنده بودن و وضعیت سرویس گره های بالادست استفاده می شود. در APISIX، کاوشگر مانند یک “بازرس” است که مرتباً در را می زند تا بررسی کند که آیا سرویس بالادستی به درستی کار می کند یا خیر. اگر مشکلی پیدا کرد یا سرویس “در دسترس نیست”، به APISIX اطلاع می دهد: “این سرویس در حال حاضر در دسترس نیست، بنابراین از ارسال درخواست ها به اینجا خودداری کنید.” این فرآیند «کوبیدن در» از طریق پروب ها انجام می شود.

پروب عمدتاً شامل موارد پیکربندی زیر است:

• طرح کاوشگر: نوع پروتکلی که توسط پروب بررسی سلامت استفاده می شود و از TCP، HTTP و HTTPS پشتیبانی می کند.

• همزمانی: این آیتم پیکربندی به شما امکان می دهد تعداد درخواست های بررسی سلامت همزمان را تنظیم کنید. به عبارت دیگر، این تعداد دفعاتی است که می خواهید به طور همزمان “در را بکوبید” تا پاسخگویی سرویس های بالادستی را بررسی کنید. با تنظیم همزمانی، می‌توانید درخواست‌های همزمان احتمالی را در سناریوهای دنیای واقعی شبیه‌سازی کنید و در نتیجه عملکرد و پایداری خدمات بالادستی را بهتر ارزیابی کنید.

• میزبان: آدرس میزبان سرور بالادستی را که باید بررسی شود را مشخص می کند. این مانند تعیین این است که کدام خانه را «در بزنیم».

• بندر: شماره پورت سرویس بالادست. مثل این است که بدانید در حین کاوشگر باید به کدام در بکوبید.

• مسیر: اگر از پروب HTTP استفاده می کنید، این مورد پیکربندی مسیر URL را که می خواهید به آن دسترسی داشته باشید مشخص می کند. مثل این است که به کاوشگر بگوییم یک بار داخل اتاق دقیق را بررسی کند.

معیارهای تعیین گره های سالم

با توجه به تعیین گره‌های سالم، سیستم به طور مرتب گره‌هایی را که قبلاً به عنوان ناسالم علامت‌گذاری شده‌اند، در بازه زمانی تعیین‌شده توسط کاربر (در ثانیه) بررسی می‌کند تا از تشخیص به موقع و مدیریت صحیح هرگونه ناهنجاری گره گذرا اطمینان حاصل کند.

اگر پروب از پروتکل TCP استفاده کند، بعد از اینکه پروب به تعداد دفعات تعیین شده توسط کاربر با موفقیت به گره بالادست متصل شد، گره سالم در نظر گرفته می شود.

اگر کاوشگر از پروتکل HTTP/HTTPS استفاده کند، سیستم تنها زمانی گره را سالم در نظر می گیرد که به طور مداوم درخواست های پروب را با کدهای وضعیت مشخص (مانند 200 و 302) از گره. این بدان معنی است که گره تنها زمانی به درستی کار می کند که به طور مداوم این کدهای وضعیت خاص را برمی گرداند.

معیارهای تعیین گره های ناسالم

در مورد تعیین گره های ناسالم، روش پیکربندی مشابه تعیین گره های سالم است. این سیستم به طور مرتب گره هایی را که به عنوان سالم علامت گذاری شده اند در بازه زمانی تعیین شده توسط کاربر بررسی می کند. هنگامی که این گره ها شرایط ناسالم از پیش تعیین شده را برآورده می کنند، مجدداً به عنوان ناسالم طبقه بندی می شوند.

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

بهترین روش ها برای بررسی سلامت

انتخاب نوع پروب مناسب

• پروب TCP: مناسب برای سناریوهایی که فقط نیاز به تایید باز بودن و در دسترس بودن پورت سرویس دارند. به عنوان مثال، یک سرویس پایگاه داده ممکن است فقط به یک پروب TCP برای تأیید باز شدن پورت نیاز داشته باشد.

• پروب HTTP/HTTPS: برای سناریوهایی که نیاز به تأیید اینکه نه تنها اتصال شبکه عادی است بلکه سرویس می تواند به درستی درخواست ها را انجام دهد نیز مناسب تر است. به عنوان مثال، برای یک وب سرور یا سرویس API، باید اطمینان حاصل کنیم که نه تنها می تواند اتصالات را دریافت کند، بلکه صفحات یا داده های صحیح را نیز برمی گرداند.

پارامترهای پیکربندی معقول برای بررسی سلامت

هنگام پیکربندی چک های سلامت، به چند پارامتر کلیدی توجه کنید:

• فاصله را بررسی کنید: نباید خیلی کوتاه باشد تا از هزینه های اضافی غیر ضروری جلوگیری شود یا خیلی طولانی باشد تا در صورت بروز مشکلات از پاسخ آهسته جلوگیری شود. به عنوان مثال، برای یک وب سایت تجارت الکترونیک پربازدید، بررسی هر 30 ثانیه یک انتخاب نسبتا معقول است. این فاصله نه بیش از حد منابع سیستم را مصرف می کند و نه تشخیص و رسیدگی به مشکلات وب سایت را به تاخیر می اندازد.

البته این فاصله مطلق نیست و باید بر اساس وضعیت واقعی وب سایت تنظیمات انجام شود. به عنوان مثال، اگر وب‌سایت با نوسانات قابل توجهی در ترافیک یا افزایش ترافیک در دوره‌های خاص (مانند کمپین‌های تبلیغاتی) مواجه شود، ممکن است لازم باشد بازه بررسی را برای تطبیق با این تغییرات تنظیم کنید.

• تایم اوت: زمانی که کاوشگر منتظر پاسخ سرویس است. اگر سرویس در این مدت پاسخ ندهد، کاوشگر سرویس را ناسالم می داند. این مقدار باید با توجه به زمان پاسخگویی واقعی سرویس تنظیم شود.

• تعداد تلاش مجدد: تعداد دفعاتی که کاوشگر تلاش می کند قبل از تعیین سرویس وصل شود، ناسالم است. این مقدار باید متوسط ​​باشد تا از قضاوت نادرست جلوگیری شود.

تنظیم استراتژی ها بر اساس کسب و کار

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

فعال کردن تأیید درخواست مشتری به عنوان مناسب

راستی‌آزمایی درخواست مشتری می‌تواند به‌طور مؤثر وضعیت خدمات را بر اساس درخواست‌های واقعی کسب‌وکار، به‌ویژه برای شناسایی مسائلی که نزدیک به منطق کسب‌وکار مرتبط است، تعیین کند. با این حال، ممکن است برای هر سناریوی تجاری مناسب نباشد.

1. خدمات کم تردد: اگر ترافیک سرویس کم باشد، بررسی‌های سلامت غیرفعال براساس درخواست‌های مشتری ممکن است نقاط داده کافی برای ارزیابی دقیق وضعیت خدمات ارائه نکند. در چنین مواردی، تکیه بر بررسی های کاوشگر فعال ممکن است قابل اعتمادتر باشد.

2. ملاحظات عملکرد در محیط های با همزمانی بالا: بررسی های سلامت غیرفعال نیاز به نظارت و پردازش هر درخواست مشتری دارد، که ممکن است سربار عملکرد اضافی را در محیط های با همزمانی بالا افزایش دهد. اگر عملکرد یک نگرانی اولیه باشد و خدمات به اندازه کافی از طریق روش های دیگر نظارت شده باشد، ممکن است بررسی های سلامت غیرفعال برای بسته شدن در نظر گرفته شود.

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

نتیجه

بررسی سلامت یک جنبه حیاتی برای اطمینان از در دسترس بودن بالای دروازه های API است. در نسخه 3.2.9 API7 Enterprise، ما به طور جامع پیکربندی تعاملی بررسی های سلامت را بهینه سازی کرده ایم، عملیات را ساده کرده و تجربه کاربر را افزایش می دهیم.

با پیکربندی مناسب پروب‌ها، تعیین معیارها برای گره‌های سالم و ناسالم، و تنظیم استراتژی‌ها بر اساس نیازهای واقعی کسب‌وکار، کاربران می‌توانند به طور مؤثرتری وضعیت سرویس‌های بالادستی را نظارت کنند و اطمینان حاصل کنند که ترافیک همیشه به گره‌های سالم هدایت می‌شود. این نه تنها ثبات و در دسترس بودن سیستم را افزایش می دهد، بلکه تضمین می کند که درخواست های کاربر پاسخ های به موقع و دقیق را دریافت می کنند.