شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
پیکربندی TargetEndpoint نحوه اتصال Apigee Edge به یک سرویس backend یا API را تعریف میکند. این سرویس درخواستها را به/از سرویس backend ارسال و پاسخها را دریافت میکند. سرویس backend میتواند یک سرور HTTP/HTTPS، NodeJS یا Hosted Target باشد.
سرویس backend در TargetEndpoint میتواند به یکی از روشهای زیر فراخوانی شود:
- آدرس اینترنتی (URL) مستقیم به سرور HTTP یا HTTPS
- ScriptTarget به یک اسکریپت Node.js میزبانی شده توسط Edge
- HostedTarget برای NodeJS مستقر در محیط Hosted Target
- پیکربندی سرور هدف
به همین ترتیب، میتوان از سیاست فراخوانی سرویس (Service Callout) برای فراخوانی هر سرویس خارجی از جریان پروکسی API استفاده کرد. این سیاست از تعریف URLهای هدف HTTP/HTTPS یا مستقیماً در خود سیاست یا با استفاده از پیکربندی TargetServer پشتیبانی میکند.
پیکربندی سرور هدف
پیکربندی TargetServer، URLهای نقطه پایانی مشخص را از پیکربندیهای TargetEndpoint یا در سیاستهای فراخوانی سرویس جدا میکند. یک TargetServer به جای URL در TargetEndpoint، با یک نام ارجاع داده میشود. پیکربندی TargetServer شامل نام میزبان سرویس backend، شماره پورت و سایر جزئیات خواهد بود.
در اینجا یک نمونه پیکربندی TargetServer آورده شده است:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer شما را قادر میسازد تا برای هر محیط پیکربندیهای متفاوتی داشته باشید. یک سیاست فراخوانی TargetEndpoint/Service را میتوان با یک یا چند TargetServer با نام و با استفاده از LoadBalancer پیکربندی کرد. پشتیبانی داخلی برای متعادلسازی بار، دسترسی به APIها و failover را در بین نمونههای سرور backend پیکربندی شده افزایش میدهد.
در اینجا یک نمونه پیکربندی TargetEndpoint با استفاده از TargetServers آورده شده است:
<TargetEndpoint name="default">
<HTTPTargetConnection>>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>مکسفایلرز
پیکربندی MaxFailures حداکثر تعداد شکستهای درخواست به سرور هدف را مشخص میکند که پس از آن سرور هدف به عنوان از کار افتاده علامتگذاری شده و برای همه درخواستهای بعدی از چرخش حذف میشود.
یک نمونه پیکربندی با MaxFailures مشخص شده:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>در مثال بالا، اگر پنج درخواست متوالی برای "target1" با شکست مواجه شود، "target1" از چرخش حذف شده و تمام درخواستهای بعدی فقط به target2 ارسال میشوند.
ضدالگو
داشتن یک TargetServer در پیکربندی LoadBalancer مربوط به TargetEndpoint یا Service Callout policy با MaxFailures که روی مقداری غیر از صفر تنظیم شده باشد، توصیه نمیشود زیرا میتواند پیامدهای نامطلوبی داشته باشد.
پیکربندی نمونه زیر را در نظر بگیرید که دارای یک TargetServer با نام "target1" و MaxFailures با مقدار 5 (مقدار غیر صفر) است:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection> اگر درخواستها به TargetServer "target1" پنج بار (تعداد مشخص شده در MaxFailures ) با شکست مواجه شوند، TargetServer از چرخه حذف میشود. از آنجایی که هیچ TargetServer دیگری برای failover وجود ندارد، تمام درخواستهای بعدی به API Proxy که این پیکربندی را دارند با خطای 503 Service Unavailable با شکست مواجه میشوند.
حتی اگر TargetServer "target1" به حالت عادی خود برگردد و قادر به ارسال پاسخهای موفقیتآمیز باشد، درخواستها به API Proxy همچنان خطاهای 503 را برمیگردانند. دلیل این امر این است که Edge حتی پس از راهاندازی مجدد TargetServer، به طور خودکار TargetServer را به حالت چرخش برنمیگرداند. برای رفع این مشکل، API Proxy باید مجدداً مستقر شود تا Edge بتواند TargetServer را به حالت چرخش برگرداند.
اگر از همین پیکربندی در سیاست فراخوانی سرویس استفاده شود، درخواستهای API پس از ۵ بار شکست درخواستها به سرور هدف "target1" با خطای ۵۰۰ مواجه میشوند.
تأثیر
استفاده از یک 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 استفاده نمیشود، در پیکربندی
LoadBalancerMaxFailuresمشخص نکنید.مقدار پیشفرض MaxFailures برابر با ۰ است. این یعنی Edge همیشه سعی میکند برای هر درخواست به سرور هدف متصل شود و هرگز سرور هدف را از چرخش حذف نمیکند.