Antipattern: استفاده از Service Callout Policy برای فراخوانی یک سرویس Backend در یک پروکسی No Target API

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

یک پروکسی API یک نمای مدیریت‌شده برای سرویس‌های backend است. پیکربندی اولیه پروکسی API شامل یک ProxyEndpoint (تعریف URL پروکسی API) و یک TargetEndpoint (تعریف URL سرویس backend) است.

Apigee Edge انعطاف‌پذیری زیادی برای ساخت رفتارهای پیچیده بر اساس این الگو ارائه می‌دهد. به عنوان مثال، می‌توانید سیاست‌هایی را برای کنترل نحوه پردازش درخواست کلاینت توسط API قبل از ارسال آن به سرویس backend اضافه کنید، یا پاسخ دریافتی از سرویس backend را قبل از ارسال آن به کلاینت دستکاری کنید. می‌توانید سرویس‌های دیگر را با استفاده از سیاست‌های فراخوانی سرویس فراخوانی کنید، با افزودن کد جاوا اسکریپت رفتار سفارشی اضافه کنید و حتی یک پروکسی API ایجاد کنید که سرویس backend را فراخوانی نکند.

ضدالگو

استفاده از فراخوانی‌های سرویس برای فراخوانی یک سرویس backend در یک پروکسی API بدون هیچ مسیری به نقطه پایانی هدف، از نظر فنی امکان‌پذیر است، اما منجر به از دست رفتن داده‌های تحلیلی در مورد عملکرد سرویس خارجی می‌شود.

یک پروکسی API که حاوی مسیرهای هدف نیست، می‌تواند در مواردی مفید باشد که نیازی به ارسال پیام درخواست به TargetEndpoint ندارید. در عوض، ProxyEndpoint تمام پردازش‌های لازم را انجام می‌دهد. به عنوان مثال، ProxyEndpoint می‌تواند داده‌ها را از یک جستجو در مخزن کلید/مقدار سرویس API بازیابی کند و بدون فراخوانی یک سرویس backend، پاسخ را برگرداند.

می‌توانید یک مسیر تهی (null Route) را در یک پروکسی API تعریف کنید، همانطور که در اینجا نشان داده شده است:

<RouteRule name="noroute"/>

پروکسی که از مسیر تهی (null route) استفاده می‌کند، یک پروکسی "بدون هدف" (no target) است، زیرا سرویس backend هدف را فراخوانی نمی‌کند.

از نظر فنی می‌توان یک فراخوانی سرویس به یک پروکسی بدون هدف اضافه کرد تا یک سرویس خارجی را فراخوانی کند، همانطور که در مثال زیر نشان داده شده است:

<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>ServiceCallout-InvokeBackend</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/no-target-proxy</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

با این حال، پروکسی نمی‌تواند اطلاعات تحلیلی در مورد رفتار سرویس خارجی (مانند زمان پردازش یا نرخ خطا) ارائه دهد، که ارزیابی عملکرد سرویس خارجی را دشوار می‌کند.

تأثیر

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

بهترین روش

اگر یک پروکسی API فقط با یک سرویس خارجی تعامل داشته باشد، پروکسی باید از الگوی طراحی اولیه پیروی کند، که در آن سرویس backend به عنوان نقطه پایانی هدف پروکسی API تعریف می‌شود. یک پروکسی بدون قوانین مسیریابی به یک نقطه پایانی هدف، نباید با استفاده از سیاست ServiceCallout، یک سرویس backend را فراخوانی کند.

پیکربندی پروکسی زیر همان رفتار مثال بالا را پیاده‌سازی می‌کند، اما از بهترین شیوه‌ها پیروی می‌کند:

<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/simple-proxy-with-route-to-backend</BasePath>
        <Properties/>
        <VirtualHost>secure</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>

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

مطالعه بیشتر