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