Cổng API so với proxy ngược

Để đối phó với kiến ​​trúc microservice, nó thường được sử dụng cùng với Reverse Proxy (chẳng hạn như nginx hoặc apache httpd) và đối với các mối quan tâm cắt ngang, mẫu cổng API triển khai được sử dụng . Đôi khi Reverse proxy thực hiện công việc của cổng API.
Sẽ rất tốt nếu thấy sự khác biệt rõ ràng giữa hai cách tiếp cận này. Có vẻ như lợi ích tiềm năng của việc sử dụng cổng API là gọi nhiều dịch vụ nhỏ và tổng hợp kết quả. Tất cả các trách nhiệm khác của cổng API có thể được thực hiện bằng cách sử dụng Reverse Proxy, chẳng hạn như:

• Xác thực (Nó có thể được thực hiện bằng cách sử dụng các tập lệnh nginx LUA);
• An ninh vận tải. Chính nó là nhiệm vụ Reverse Proxy;
• Cân bằng tải
• ....

Vì vậy, dựa trên điều này, có một số câu hỏi:

1. Có hợp lý không khi sử dụng cổng API và proxy ngược một cách đồng thời (ví dụ: request-> Api gateway-> reverse proxy (nginx) -> cụ thể mictoservice)? Trong những trường hợp nào?
2. Sự khác biệt nào khác có thể được triển khai bằng cách sử dụng cổng API và không thể được triển khai bằng Reverse proxy và ngược lại?

Sẽ dễ dàng hơn để nghĩ về chúng nếu bạn nhận ra chúng không loại trừ lẫn nhau. Hãy coi cổng API như một kiểu triển khai proxy ngược cụ thể.

Liên quan đến câu hỏi của bạn, không có gì lạ khi thấy cả hai được sử dụng kết hợp trong đó cổng API được coi như một cấp ứng dụng nằm sau proxy ngược để cân bằng tải và kiểm tra tình trạng. Một ví dụ sẽ giống như một kiến ​​trúc sandwich WAF trong đó Tường lửa ứng dụng web / Cổng API của bạn được kẹp bởi các tầng proxy ngược, một cho chính WAF và một cho các microservices mà nó nói chuyện.

Về sự khác biệt, chúng rất giống nhau. Nó chỉ là danh pháp. Khi bạn thực hiện thiết lập proxy ngược cơ bản và bắt đầu củng cố nhiều phần hơn như xác thực, giới hạn tốc độ, cập nhật cấu hình động và khám phá dịch vụ, mọi người có nhiều khả năng gọi đó là cổng API.

Tôi tin rằng, API Gateway là một proxy ngược có thể được định cấu hình động thông qua API và có thể thông qua giao diện người dùng, trong khi proxy ngược truyền thống (như Nginx, HAProxy hoặc Apache) được định cấu hình thông qua tệp cấu hình và phải được khởi động lại khi cấu hình thay đổi. Do đó, API Gateway nên được sử dụng khi các quy tắc định tuyến hoặc cấu hình khác thường xuyên thay đổi. Đối với câu hỏi của bạn:

1. Nó có ý nghĩa miễn là mọi thành phần trong chuỗi này phục vụ mục đích của nó.
2. Sự khác biệt không nằm ở danh sách tính năng mà ở cách áp dụng các thay đổi cấu hình.

Ngoài ra, API Gateway thường được cung cấp dưới dạng SAAS, như Apigee hoặc Tyk chẳng hạn.

Ngoài ra, đây là hướng dẫn của tôi về cách tạo API Gateway đơn giản với Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Hy vọng nó giúp.

Cổng API thường hoạt động như một cấu trúc L7.

Cổng API cung cấp chức năng bổ sung so với proxy ngược đơn giản. Nếu bạn xem xét một số cổng thông tin ngoài kia, họ có thể cung cấp:

• Quản lý vòng đời API đầy đủ bao gồm tài liệu
• một cổng thông tin có thể được sử dụng làm nguồn trung thực cho các ứng dụng khách khác nhau và nơi bạn có thể cung cấp quản trị ứng dụng khách, giới hạn tỷ lệ, v.v.
• định tuyến đến các phiên bản API khác nhau bao gồm cả phiên bản canary / beta
• phát hiện các kiểu sử dụng, đăng ký ứng dụng, truy xuất thông tin đăng nhập của khách hàng, v.v.

Tuy nhiên, với sự ra đời của các lưới dịch vụ như Istio, rất nhiều chức năng của Cổng API sẽ bị gộp lại bởi các lưới.