ارزیابی Apache APISIX در مقابل Spring Cloud Gateway

ek3nk4r 2023-06-22

0 60 خواندن این مطلب 8 دقیقه زمان میبرد

ارزیابی Apache APISIX در مقابل Spring Cloud Gateway

پیشنهاد ویژه

خرید فالوور واقعی خرید لایک اینستاگرام خرید ویو اینستاگرام خرید فالوور اینستاگرام

با توجه به تعداد دروازه‌های API موجود در بازار، مرتباً از من سؤال می‌شود که کدام بهتر است. بهتر یک اصطلاح بسیار ذهنی است. با این حال، نمی توان انکار کرد که اگر از محصولی حمایت می کنید، باید محصول خود و رقبای آن را بشناسید. در این پست، می‌خواهم درک خود را از Spring Cloud Gateway و نحوه مقایسه آن با Apache APISIX به اشتراک بگذارم.

من هنگام مقایسه محصولات محتاط هستم زیرا اکثر مقایسه هایی که می خوانم به شدت مغرضانه هستند. این یک خطر است، به خصوص زمانی که روی یکی از محصولاتی که فرد در حال مقایسه است، کار می کند. من همچنین از “معیار مارکتینگ” اجتناب می کنم – زمانی که محصولات را در زمینه ای که به نفع خودتان است معیار قرار دهید. من روی به اصطلاح تجربه توسعه دهنده تمرکز خواهم کرد.

فیل افسانه ای و مردان کور

به عنوان حفاظت، از دوستم ایوان لوپز، کاربر Spring Cloud Gateway، خواسته ام که پست را تصحیح کند. ایوان پست را به عنوان دوست من بررسی کرد، نه به عنوان یک توسعه دهنده VMWare. علیرغم تمام تلاش‌هایم، ممکن است آنطور که می‌خواهم عینی به نظر نرسم. من آن را قبول دارم، و این خوب است.

فهرست مطالب

اولین قدم ها با Spring Cloud Gateway

تمام دروازه‌های API که من در مورد آنها می‌شناسم یک تصویر Docker ارائه می‌دهند. به عنوان مثال، Apache APISIX سه طعم ارائه می دهد: Debian، CentOS، و اخیرا، Red Hat. در این مرحله، می توانید شروع به استقرار تصاویر در معماری کانتینری خود کنید.

رویکرد Spring Cloud Gateway کاملاً متفاوت است. این فقط یک وابستگی منظم به یک پروژه معمولی بهار است:

<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-gateway</artifactId>
      <version>4.0.6</version>
</dependency>

می‌توانید از همه راه‌های استاندارد برای ایجاد پروژه، از جمله start.spring.io محبوب، مانند هر پروژه معمولی Spring استفاده کنید. این رویکرد توسعه‌گرا در همه چیز مربوط به Spring Cloud Gateway فراگیر است.

مفاهیم و انتزاعات

Apache APISIX دارای یک مدل غنی است:

خلاصه مدل آپاچی APISIX

به طور خاص، شما می توانید ایجاد کنید Upstream انتزاع و به اشتراک گذاری آن در مسیرهای مختلف. به همین ترتیب، Plugin Config به شما این امکان را می دهد که ترکیبی از پلاگین های قابل استفاده مجدد ایجاد کنید.

در اینجا مدل Spring Cloud Gateway آمده است:

مدل Spring Cloud Gateway

مدل APISIX غنی تر است، با انتزاعات و امکان استفاده مجدد.

پیکربندی

Apache APISIX دو حالت استقرار دارد (در واقع سه حالت، اما اجازه دهید وارد جزئیات نشویم): سنتی و مستقل.

در حالت سنتی، APISIX پیکربندی خود را در etcd ذخیره می کند. APISIX یک API غنی برای دسترسی و به روز رسانی پیکربندی ارائه می دهد، Admin API. در حالت مستقل، پیکربندی فقط YAML ساده است. این رویکرد برای پزشکان GitOps است: شما پیکربندی خود را در یک مخزن Git ذخیره می‌کنید، آن را از طریق ابزار مورد علاقه خود تماشا می‌کنید (به عنوان مثال، Argo CD یا Tekton)، و دومی تغییرات را به گره های APISIX پس از تغییرات منتشر می کند. APISIX پیکربندی خود را هر ثانیه بارگیری مجدد می کند.

در اینجا یک نمونه است:

upstreams:
  - id: 1
    nodes:
      "catalog:8080": 1
  - id: 2
    nodes:
      "pricing:8080": 1

routes:
  - uri: /v1/products*
    upstream_id: 1
    plugins:
      proxy-rewrite:
        regex_uri: ["/v1(.*)", "$1"]
  - uri: /prices*
    upstream_id: 2
    plugins:
      referer-restriction:
        whitelist:
          - catalog.me

global_rules:
  plugins:
    prometheus:
      prefer_name: true

Spring Cloud Gateway از تمامی گزینه های پیکربندی پروژه های بهار معمولی پشتیبانی می کند و تعداد آنها بسیار زیاد است. با این حال، تنظیمات “مسطح”، مانند .properties فایل(ها) و متغیرهای محیطی، مستعد خطا هستند:

spring.cloud.gateway.routes[0].id=products
spring.cloud.gateway.routes[0].uri=http://catalog:8080
spring.cloud.gateway.routes[0].predicates[0]=Path=/v1/products*
spring.cloud.gateway.routes[1].id=pricing
spring.cloud.gateway.routes[1].uri=http://pricing:8080
spring.cloud.gateway.routes[1].predicates[0]=Path=/prices*
spring.cloud.gateway.routes[1].predicates[1]=Header=Referer, http://catalog.me

IMHO، باید به یک پیکربندی سلسله مراتبی مانند YAML پایبند بود – و به یاد داشته باشید که من خیلی به YAML علاقه ندارم. در اینجا همان پیکربندی بالا است:

spring.cloud.gateway.routes:
  - id: products
    uri: http://catalog:8080
    predicates:
      - Path=/v1/products*
    filters:
      - StripPrefix=1
  - id: pricing
    uri: http://pricing:8080
    predicates:
      - Path=/prices*
      - Header=Referer, http://catalog.me

من معتقدم نسخه YAML فضای کمتری را برای خطاها، به ویژه در مورد شاخص ها، باقی می گذارد.

هشدار داده شود که برنامه‌های Spring به‌صورت پیش‌فرض پیکربندی خود را مجدداً بارگیری نمی‌کنند. در حالی که ممکن است – و در واقع، چند گزینه در دسترس است – نیاز به کدگذاری دارد. در اینجا یک آموزش خوب در مورد چگونگی دستیابی به آن وجود دارد.

همانطور که برای Apache APISIX، شما همچنین می توانید به روز رسانی و حذف مسیرها به صورت پویا از طریق /actuator نقطه پایانی با این حال، API ارائه نمی دهد PATCH روش: در صورت بروز رسانی باید کل مسیر را به روز کنید.

مقایسه ویژگی ها

آپاچی APISIX ویژگی ها را با پلاگین ها، در حالی که Spring Cloud Gateway آنها را با آن پیاده سازی می کند فیلترها. در حالی که مقایسه جامع و دقیق ویژگی به ویژگی فراتر از محدوده یک پست وبلاگ است، ما هنوز هم می توانیم یک نمای کلی خوب داشته باشیم.

ویژگی	دروازه بهار	آپاچی APISIX
درخواست دستکاری هدرها	`AddRequestHeader` `AddRequestHeadersIfNotPresent` `RemoveRequestHeader` `SetRequestHeader` `MapRequestHeader` `SecureHeaders` `FallbackHeaders` `SetRequestHostHeader` `PreserveHostHeader` `AddRequestParameter` `RemoveRequestParameter`	`proxy-rewrite`
دستکاری مسیر	`StripPrefix` `PrefixPath` `RewritePath` `SetPath`	`proxy-rewrite`
دستکاری هدر پاسخ	`AddResponseHeader` `DedupeResponseHeader` `RewriteLocationResponseHeader` `RemoveResponseHeader` `RewriteResponseHeader` `SetResponseHeader` `SetStatus`	`response-rewrite`
تغییر مسیر	`RedirectTo`	`redirect`
رمزگذاری JSON gRPC	`JsonToGrpc`	`grpc-transcode`
دستکاری بدن	`ModifyRequestBody` `ModifyResponseBody` فقط از طریق کد موجود است	`response-rewrite` فقط پاسخ را می توان تغییر داد
تاب آوری		`api-breaker`
	`RequestRateLimiter` بدون پیکربندی از طریق نماد “میانبر”.	`limit-count` `limit-conn` `limit-request`
	–	`fault-injection`
ذخیره سازی	`LocalResponseCache`	`proxy-cache`

Apache APISIX و Spring Cloud Gateway کمابیش مجموعه ویژگی های مشابهی را ارائه می دهند. با توجه به ویژگی‌های مشترک، روش Spring بسیار دانه‌دارتر است، با یک فیلتر اختصاصی برای هر عملیات. در مقابل، APISIX یک پلاگین منفرد با گزینه‌های پیکربندی متعدد اما برای محدود کردن نرخ ارائه می‌کند.

برخی از افزونه ها مخصوص بهار هستند، به عنوان مثال، SaveSession – APISIX چنین ادغامی ندارد. برعکس، APISIX پلاگین های زیادی را برای احراز هویت با سرویس های شخص ثالث مختلف ارائه می دهد. به عنوان مثال، KeyCloak، OpenId Connect، و غیره. Spring Cloud Gateway از طریق وابستگی Spring Security، یک موضوع کامل، به آن دست می یابد.

اگر یک ویژگی خارج از جعبه در دسترس نباشد، توسعه یک افزونه سفارشی در Lua برای APISIX، به زبان JVM برای Spring امکان پذیر است.

قابلیت مشاهده

پیاده سازی قابلیت مشاهده بین Spring Cloud Gateway و Apache APISIX بسیار متفاوت است.

اولین مورد به Actuator متکی است که بسیاری از ویژگی های مرتبط با قابلیت مشاهده را ارائه می دهد. برای استفاده از آن در هر پروژه Spring Boot، فقط وابستگی را اضافه کنید:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>3.1.0</version>
</dependency>

برای ارائه معیارهای مصرف پرومتئوس، وابستگی میکرومتر زیر را اضافه کنید:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <version>1.11.0</version>
</dependency>

از سوی دیگر، Apache APISIX از سیستم پلاگین مشابهی برای ویژگی‌های قابل مشاهده استفاده می‌کند:

برای ردیابی: zipkin، skywalking، و opentelemetry
برای معیارها: prometheus، node-status، و datadog
برای ورود به سیستم: تعداد زیادی برای فهرست کردن کامل نیست، اما با Kafka، Elasticsearch، Splunk، Google Cloud، ClickHouse و غیره ادغام می شود.

هر دو محصول سه رکن مشاهده پذیری را پوشش می دهند و ادغام های زیادی را با باطن های شخص ثالث ارائه می دهند.

مستندات

IMHO، مستندات اسپرینگ بی نظیر است. Spring Cloud Gateway نیز از این قاعده مستثنی نیست. به مجموعه Spring تعلق دارد و ساختار مشابهی را ارائه می دهد: یک نمای کلی، مستندات مرجع (کامل)، یک راهنمای شروع، و دو پروژه نمونه سازماندهی شده بر اساس نسخه.

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

من در مورد مستندات Apache APISIX نظری نمی دهم زیرا من مسائل را به خوبی می دانم. با این حال، اگر بازخورد سازنده ای دارید، من همه گوش هستم. لطفا در زیر نظر دهید.

قابلیت استفاده

قابلیت استفاده کاملاً ذهنی است، اما من تفاوت قابل توجهی در نسخه ی نمایشی خود مشاهده نکردم. در اینجا طرح کلی است که وانمود می کند معماری میکروسرویس را تقلید می کند.

نمونه نمای کلی معماری

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

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

پرومتئوس معیارهای دروازه را حذف می کند. Apache APISIX یک پورت و رشته اختصاصی را ارائه می دهد، بنابراین مسیریابی و مشاهده منظم از هم جدا می شوند. همچنین می توانید مسیر رسیدن به نقطه پایانی را سفارشی کنید. Spring Cloud Gateway از همان پورت اما یک مسیر خاص استفاده می کند. /actuator، که می توانید آن را سفارشی کنید. شما همچنین می توانید پورت را تغییر دهید کل محرک از طریق management.server.port ویژگی.

این پروژه دو شاخه، apisix و Spring ارائه می دهد. برای استفاده از آن، یکی از دو شاخه را بررسی کنید.

راه اندازی پروژه:

docker compose up

سپس آن را تست کنید:

curl localhost:8080/products

هر دو شاخه باید نتیجه یکسانی داشته باشند.

من یک داشبورد Grafana اضافه کرده ام. توجه داشته باشید که Spring one هیچ چیز قابل استفاده ای را خروجی نمی دهد، اما تقصیر من است که نتوانستم آن را به درستی پیکربندی کنم.

نتیجه

Spring Cloud Gateway و Apache APISIX دو دروازه (API) هستند که کم و بیش مجموعه ای از ویژگی ها را ارائه می دهند. با این حال، رویکرد آنها کاملاً متفاوت است.

Spring Cloud Gateway از چارچوب Spring و پلتفرم Spring Boot سرچشمه می گیرد و اساساً بر توسعه دهندگانی که قبلاً با Spring آشنا هستند تمرکز می کند. اگر در چنین سناریویی قرار دارید، با یک هشدار جزئی، به راحتی وارد آن می‌شوید، زیرا احساس می‌کند در خانه است. به دلایل عملکرد، Spring Cloud Gateway ورودی/خروجی غیر مسدود را با Spring WebFlux، که به Project Reactor متکی است، پیاده‌سازی می‌کند. اگر نیاز به کدنویسی منطق غیر پیش پا افتاده با استفاده از کد داشته باشید و با آن آشنا نباشید، یک سفر چالش برانگیز خواهد بود. Mono و Flux.

از طرف دیگر، در حالی که استفاده از آن بدون اطلاع قبلی از قسمت های داخلی Spring امکان پذیر است، گام بزرگی برای توسعه دهندگان غیراسپرینگ خواهد بود. اگر آنها توسعه دهندگان JVM نباشند، گامی عظیم تر خواهد بود و اگر اصلاً توسعه دهنده نباشند، یک جهش کامل از ایمان خواهد بود. یعنی، عملیات

Apache APISIX بیشتر برای پروفایل های معمولی Ops مناسب است و محصول را در بسته بندی هایی که با آن آشنا هستند ارائه می دهد: تصاویر Docker و نمودارهای Helm برای Kubernetes.

با تشکر ایوان لوپز برای بررسی مهربان او او همچنین به تصورات اشتباهی که در مورد Spring Cloud Gateway داشتم به من اشاره کرد. خیلی دوست دارم!

کد منبع کامل این پست را می توانید در GitHub بیابید:

فراتر رفتن:

در ابتدا در A Java Geek در 18 ژوئن منتشر شد^هفتم، 2023