Điểm:1

NGINX có thể gọi một dịch vụ khác trước khi gửi đi không

lá cờ us

Chúng tôi đang sử dụng NGINX làm proxy ngược, nó gửi các cuộc gọi từ bên ngoài đến các vi dịch vụ Java nội bộ của chúng tôi:

nhập mô tả hình ảnh ở đây

Chúng tôi muốn thêm một dịch vụ đặc biệt đóng vai trò là "người trung gian", nhưng chỉ dành cho phần yêu cầu. Mục đích của nó là để tô điểm cho yêu cầu ban đầu (xác thực, thêm/sửa đổi tiêu đề HTTP, xác minh quyền truy cập). "Nhiệm vụ trang trí" liên quan đến logic nghiệp vụ phức tạp không thể định cấu hình trên chính NGINX.

Chúng tôi muốn dịch vụ được gọi đầu tiên, sau đó chuyển tiếp phản hồi của nó (đặc biệt là các tiêu đề HTTP!) dưới dạng yêu cầu tới một trong các dịch vụ siêu nhỏ. Cũng có thể tùy chọn gọi các dịch vụ đã gửi với phần thân ban đầu, nhưng với các tiêu đề HTTP được trả về từ dịch vụ trang trí.

Khi dịch vụ trả về lỗi HTTP, dịch vụ sẽ trả về trực tiếp cho người gọi mà không gửi đi.

Dịch vụ này được triển khai dưới dạng ứng dụng Java Spring Boot. Nó là một dịch vụ web thông thường.

Có thể định cấu hình trong NGINX không và bằng cách nào?

Để rõ ràng: Tôi không hỏi về cách triển khai dịch vụ cụ thể này.Điều tôi cần chỉ là biết liệu NGINX có thể được cấu hình (và bằng cách nào) để nó gọi một dịch vụ khác trước khi gửi cuộc gọi hay không và NGINX đó chuyển các tiêu đề (và có thể cả phần thân, nhưng không nhất thiết) được trả về từ dịch vụ này cho cuộc gọi.

nhập mô tả hình ảnh ở đây

lá cờ in
Những gì có thể được sử dụng để thực hiện logic kinh doanh của bạn? Điều đó sẽ quyết định phần còn lại của thiết lập.
lá cờ in
nginx có thể được mở rộng khá rộng rãi với các tập lệnh. Tài liệu này chứa các ví dụ về ủy quyền, bạn đã thực sự thử điều này chưa?
lá cờ in
Bạn sẽ không nhận được bất kỳ đề xuất sản phẩm nào ở đây, điều đó lạc đề.
Honza Zidek avatar
lá cờ us
@GeraldSchneider Tôi đang hỏi cách định cấu hình NGINX để gọi một dịch vụ web khác trước khi gửi cuộc gọi, **không nhận bất kỳ đề xuất sản phẩm nào**. Và chúng ta dễ dàng viết logic nghiệp vụ bằng Java hơn là viết kịch bản bằng NGINX. Cuối cùng nhưng không kém phần quan trọng, đối với bất kỳ thay đổi nào trong NGINX, chúng tôi cần hỏi nhóm quản trị viên hệ thống - chúng tôi muốn linh hoạt và tự mình thực hiện các thay đổi. NGINX chịu trách nhiệm cho nhiều thứ khác, không chỉ các ứng dụng của chúng tôi. Hoạt động này bao gồm đọc từ DB, lưu trữ dữ liệu vào bộ đệm và các quy tắc kinh doanh nằm ngoài phạm vi trách nhiệm của proxy ngược.
lá cờ in
Xin lỗi, sau đó tôi đã hiểu nhầm câu hỏi của bạn. Có vẻ như bạn đang tìm kiếm một dịch vụ thực hiện logic. Sau đó quay lại câu hỏi: Bạn đã thử [ví dụ từ tài liệu](https://github.com/nginx/njs-examples/) chưa? Nếu bạn gặp sự cố với chúng, bạn nên thêm nó vào câu hỏi của mình.
Honza Zidek avatar
lá cờ us
@GeraldSchneider Tôi đã chỉnh sửa câu hỏi để tránh sự hiểu lầm này :) Bạn có thể hướng dẫn tôi cách chi tiết hơn trong các ví dụ không? Tôi không quen thuộc với thuật ngữ NGINX và sẽ rất hữu ích nếu bạn chuyển trực tiếp cho tôi đến phần liên quan đến vấn đề của tôi. (Xin lỗi nếu nghe có vẻ lười biếng nhưng tôi là một lập trình viên Java và tôi không có tham vọng trở thành một syadmin :))
Điểm:3
lá cờ it

Vâng, nó là có thể.

Hãy xem cái này ví dụ. Tóm lại, bạn có thể sử dụng auth_request lệnh để tìm nạp các tiêu đề bổ sung mong muốn. Sử dụng proxy_set_header để thêm các tiêu đề bổ sung vào yêu cầu chính.

Paul avatar
lá cờ cn
Chào mừng đến với Lỗi máy chủ! Câu trả lời của bạn gợi ý một giải pháp khả thi cho câu hỏi có sẵn thông qua một trang web khác. Dòng trang web Hỏi & Đáp của Stack Exchange [thường cau mày với loại câu trả lời này](https://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers ). Vui lòng đọc [Làm cách nào để viết câu trả lời hay?](http://serverfault.com/help/how-to-answer) và xem xét sửa đổi câu trả lời của bạn để bao gồm các bước cần thiết để giải quyết vấn đề. Và đừng quên tham gia [tham quan trang web](http://serverfault.com/tour).

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.