درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
پیکربندی TargetEndpoint روش اتصال Apigee Edge به سرویس یا میانای برنامه‌سازی کاربردی زیرینه را تعریف می‌کند. درخواست‌ها را به سرویس زیرینه ارسال می‌کند و پاسخ‌ها را از آن دریافت می‌کند. سرویس زیرینه می‌تواند سرور HTTP/HTTPS، NodeJS، یا «هدف میزبانی‌شده» باشد.
سرویس زیرینه در TargetEndpoint می‌تواند به یکی از روش‌های زیر فراخوانی شود:
- نشانی وب مستقیم به سرور HTTP یا HTTPS
- ScriptTarget به دستورگان Node.js میزبانی‌شده در Edge
- HostedTarget به NodeJS که در Hosted Target Environment مستقر شده است
- پیکربندی TargetServer
به‌همین ترتیب، از خط‌مشی «خدمات تماس» می‌توان برای برقراری تماس با هر سرویس خارجی از جریان «پراکسی API» استفاده کرد. این خط‌مشی از تعریف نشانی‌های وب مقصد HTTP/HTTPS هم به‌صورت مستقیم در خود خط‌مشی و هم بااستفاده از پیکربندی «سرور هدف» پشتیبانی می‌کند.
پیکربندی TargetServer
پیکربندی TargetServer نشانی‌های وب نقطه پایان واقعی را از پیکربندی‌های TargetEndpoint یا در خط‌مشی‌های «برون‌برد سرویس» جدا می‌کند. «سرور هدف» به‌جای نشانی وب در «نقطه پایانی هدف» با نام ارجاع داده می‌شود. پیکربندی TargetServer نام میزبان سرویس زیرینه، شماره درگاه، و جزئیات دیگر را خواهد داشت.
در اینجا پیکربندی نمونه TargetServer آورده شده است:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer به شما امکان می‌دهد برای هر محیط پیکربندی‌های مختلفی داشته باشید. خط‌مشی «نقطه پایانی هدف/پیامک سرویس» را می‌توان با یک یا چند «سرور هدف» نام‌گذاری‌شده بااستفاده از «توزیع‌کننده بار» پیکربندی کرد. پشتیبانی داخلی از تراز بار، دردسترس بودن میاناهای برنامه‌سازی کاربردی و عملکرد ازکارافتادگی را در میان نمونه‌های سرور زیرینه پیکربندی‌شده بهبود می‌بخشد.
در اینجا پیکربندی نمونه‌ای از TargetEndpoint بااستفاده از TargetServers آورده شده است:
<TargetEndpoint name="default">
<HTTPTargetConnection>>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>MaxFailures
پیکربندی MaxFailures حداکثر تعداد خطاهای درخواست را برای سرور هدف مشخص می‌کند که پس‌از آن سرور هدف به‌عنوان پایین علامت‌گذاری می‌شود و از چرخش برای همه درخواست‌های بعدی برداشته می‌شود.
پیکربندی نمونه با MaxFailures مشخص‌شده:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>در مثال بالا، اگر پنج درخواست متوالی برای «هدف۱» ناموفق باشد، «هدف۱» از چرخش برداشته می‌شود و همه درخواست‌های بعدی فقط به هدف۲ ارسال می‌شود.
الگوی بد
داشتن یک TargetServer در پیکربندی LoadBalancer از خط‌مشی
TargetEndpoint یا «پیام‌واره سرویس» با MaxFailures تنظیم‌شده روی مقدار غیرصفر توصیه نمی‌شود زیرا می‌تواند پیامدهای نامطلوبی داشته باشد.
پیکربندی نمونه زیر را درنظر بگیرید که یک TargetServer
به‌نام «target1» دارد و MaxFailures روی ۵ (مقدار غیرصفر) تنظیم شده است:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>اگر درخواست‌های TargetServer «target1» پنج بار ناموفق باشد (تعداد مشخص‌شده در MaxFailures)،
TargetServer از چرخش برداشته می‌شود. ازآنجایی‌که هیچ TargetServer دیگری برای انتقال وجود ندارد،
همه درخواست‌های بعدی به «پراکسی میانای برنامه‌سازی کاربردی» که این پیکربندی را دارد با خطای
503 Service Unavailable ناموفق خواهد بود.
حتی اگر TargetServer «target1» به حالت عادی خود بازگردد و بتواند پاسخ‌های موفقیت‌آمیز ارسال کند، درخواست‌های «پراکسی API» همچنان خطای ۵۰۳ برمی‌گردانند. دلیل این است که Edge حتی پس‌از اینکه هدف دوباره فعال و درحال اجرا می‌شود، به‌طور خودکار TargetServer را دوباره در چرخش قرار نمی‌دهد. برای پرداختن به این مشکل، «پراکسی میانای برنامه‌سازی کاربردی» باید مجدداً مستقر شود تا Edge بتواند TargetServer را دوباره در چرخه قرار دهد.
اگر از پیکربندی یکسانی در خط‌مشی «پیام‌واره سرویس» استفاده شود، پس‌از اینکه درخواست‌های «کارخواه» به «سرور هدف» «target1» ۵ بار ناموفق بود، درخواست‌های API خطای ۵۰۰ دریافت خواهد کرد.
تأثیر
استفاده از یک TargetServer در پیکربندی LoadBalancer از خط‌مشی TargetEndpoint یا Service Callout با MaxFailures که روی مقدار غیرصفر تنظیم شده است باعث موارد زیر می‌شود:
- درخواست‌های API به‌طور مداوم با خطاهای ۵۰۳/۵۰۰ ناموفق می‌شوند (پس‌از اینکه درخواست‌ها برای تعداد MaxFailures بار ناموفق شدند) تا زمانی که «پراکسی API» دوباره مستقر شود.
- وقفه طولانی‌تر زیرا تشخیص علت این مشکل دشوار است و ممکن است زمان بیشتری ببرد (بدون داشتن اطلاعات قبلی درباره این الگوی ضد).
روال مطلوب
- برای دردسترس بودن بیشتر، بیش‌از یک TargetServer در پیکربندی
LoadBalancerداشته باشید. وقتی
MaxFailuresروی مقدار غیرصفر تنظیم شده است، همیشه «پایشگر سلامتی» را تعریف کنید. وقتی تعداد خطاها به تعداد مشخص‌شده درMaxFailuresبرسد، سرور هدف از چرخش برداشته خواهد شد. داشتن HealthMonitor تضمین می‌کند که TargetServer به‌محض اینکه سرور هدف دوباره دردسترس قرار گرفت، به چرخش برگردانده شود، یعنینیازی به استقرار مجدد پراکسی نیست.برای اطمینان از اینکه بررسی وضعیت در همان شماره درگاهی انجام می‌شود که Edge برای اتصال به سرورهای هدف استفاده می‌کند، Apigee توصیه می‌کند عنصر فرزند
<Port>را در<TCPMonitor>حذف کنید، مگر اینکه با درگاه TargetServer متفاوت باشد. به‌طور پیش‌فرض<Port>همان درگاه TargetServer است.پیکربندی نمونه با HealthMonitor:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>اگر محدودیتی وجود دارد که فقط یک TargetServer و اگر HealthMonitor استفاده نمی‌شود، در پیکربندی
LoadBalancer،MaxFailuresرا مشخص نکنید.مقدار پیش‌فرض MaxFailures برابر با ۰ است. این یعنی Edge همیشه برای هر درخواست سعی می‌کند به هدف متصل شود و هرگز سرور هدف را از چرخش برنمی‌دارد.