شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
در Apigee Edge، یک روتر تمام ترافیک ورودی API را مدیریت می کند. این بدان معناست که تمام درخواست‌های HTTP و HTTPS به پروکسی Edge API ابتدا توسط یک روتر Edge رسیدگی می‌شود. بنابراین، درخواست پروکسی API باید به آدرس IP و پورت باز روی روتر هدایت شود.
میزبان مجازی به شما امکان می دهد چندین نام دامنه را روی یک سرور یا گروهی از سرورها میزبانی کنید. برای Edge، سرورها با Edge Routers مطابقت دارند. با تعریف هاست مجازی در روتر، می توانید درخواست های چندین دامنه را مدیریت کنید.
یک میزبان مجازی در Edge یک پروتکل (HTTP یا HTTPS) را به همراه یک پورت روتر و یک نام مستعار میزبان تعریف می کند. نام مستعار میزبان معمولاً یک نام دامنه DNS است که به آدرس IP روتر نگاشت می شود.
به عنوان مثال، تصویر زیر یک روتر با دو تعریف میزبان مجازی را نشان می دهد:
در این مثال دو تعریف میزبان مجازی وجود دارد. یکی درخواست های HTTPS در دامنه domainName1 را مدیریت می کند، دیگری درخواست های HTTP را در domainName2 انجام می دهد.
در یک درخواست به یک پروکسی API، روتر هدر میزبان و شماره پورت درخواست ورودی را با لیست نام مستعار میزبان تعریف شده توسط همه میزبان های مجازی مقایسه می کند تا مشخص کند کدام میزبان مجازی درخواست را مدیریت می کند.
نمونه پیکربندی هاست های مجازی در زیر نشان داده شده است:
ضد الگو
تعریف چندین میزبان مجازی با نام مستعار میزبان و شماره پورت یکسان در محیط‌های مشابه/متفاوت یک سازمان یا در بین سازمان‌ها منجر به سردرگمی در زمان مسیریابی درخواست‌های API می‌شود و ممکن است باعث خطاها/رفتارهای غیرمنتظره شود.
بیایید از یک مثال برای توضیح مفاهیم داشتن میزبان های مجازی متعدد با نام مستعار میزبان استفاده کنیم.
در نظر بگیرید که دو میزبان مجازی sandbox and secure وجود دارد sandbox and secure با همان نام مستعار میزبان یعنی api.company.abc.com در یک محیط تعریف شده است:
با تنظیمات فوق، دو حالت ممکن است وجود داشته باشد که در بخش های زیر توضیح داده شده است.
سناریو 1: یک API Proxy برای پذیرش درخواست‌ها برای تنها یکی از جعبه‌های ایمنی میزبان مجازی پیکربندی شده است.
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>
در این سناریو، هنگامی که برنامه های سرویس گیرنده با استفاده از نام مستعار میزبان api.company.abc.com با یک پروکسی API خاص تماس می گیرند، به طور متناوب با این پیام خطای 404 دریافت می کنند:
Unable to identify proxy for host: secure
این به این دلیل است که روتر درخواست ها را هم به sandbox و هم به هاست مجازی secure ارسال می کند. هنگامی که درخواست ها به میزبان مجازی sandbox هدایت می شوند، برنامه های مشتری پاسخ موفقیت آمیزی دریافت می کنند. با این حال، زمانی که درخواست‌ها به سمت میزبان مجازی secure هدایت می‌شوند، برنامه‌های سرویس گیرنده خطای 404 دریافت می‌کنند زیرا پروکسی API برای پذیرش درخواست‌ها در میزبان مجازی secure پیکربندی نشده است.
سناریو 2: یک پروکسی API پیکربندی شده است تا درخواست‌ها را به جعبه ایمنی میزبان مجازی و ایمن بپذیرد.
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>
در این سناریو، هنگامی که برنامه های سرویس گیرنده با استفاده از نام مستعار میزبان api.company.abc.com با پروکسی API خاص تماس می گیرند، بر اساس منطق پروکسی پاسخ معتبری دریافت می کنند.
با این حال، این باعث می‌شود که داده‌های نادرست در Analytics ذخیره شوند زیرا درخواست‌های API به هر دو میزبان مجازی هدایت می‌شوند، در حالی که درخواست‌های واقعی فقط به یک میزبان مجازی ارسال می‌شوند.
این همچنین می تواند بر اطلاعات ورود به سیستم و هر داده دیگری که بر اساس میزبان مجازی است تأثیر بگذارد.
تاثیر
- 404 خطاهایی که درخواست‌های API ممکن است به یک میزبان مجازی هدایت شوند که ممکن است پروکسی API برای پذیرش درخواست‌ها پیکربندی نشده باشد.
- داده‌های Analytics نادرست است زیرا درخواست‌های API به همه میزبان‌های مجازی با نام مستعار میزبان یکسان هدایت می‌شوند در حالی که درخواست‌ها فقط برای یک میزبان مجازی خاص انجام شده‌اند.
بهترین تمرین
- چندین هاست مجازی با نام مستعار میزبان و شماره پورت یکسان در یک محیط یا محیط های مختلف یک سازمان تعریف نکنید.
اگر نیاز به تعریف چندین میزبان مجازی وجود دارد، از نام مستعار میزبان مختلف در هر یک از میزبان های مجازی مانند شکل زیر استفاده کنید:
