पाठ 7 / 26

Prefix हटाना और Header जोड़ना

Paths बदलें और request IDs जैसे gateway द्वारा बनाए headers जोड़ें।

Backend को जानने की ज़रूरत नहीं होनी चाहिए

सार्वजनिक URLs और आंतरिक URLs अक्सर अलग होते हैं। Gateway prefix हटा सकता है (/api/v1/users service के लिए /users बनता है), headers जोड़ सकता है (tracing के लिए X-Request-ID, client पते के साथ X-Forwarded-For, authenticated X-User पहचान), और संवेदनशील headers हटा सकता है। Edge पर बनी अनोखी request ID जो हर hop से गुज़रे, आपको एक अनुरोध का पीछा logs और services भर में करने देती है। Authentication के बाद पहचान उस header में दें जिस पर backend सिर्फ़ इसलिए भरोसा करता है कि gateway उसे सेट करता है और backend gateway (या mutual TLS) के अलावा पहुँच से बाहर है।

Rewrite और headers (config)

proxy_pass http://echo_up/; में अंत का slash nginx से मिले हुए /api/ prefix को बदलवाता है। Gateway config का अंश।

location /api/ {
  proxy_set_header X-Request-ID $request_id;
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header X-User "asha";
  proxy_pass http://echo_up/;
}

Upstream ने क्या देखा, चलाकर

मैंने यह Docker में असली nginx 1.27 gateway पर चलाया, upstreams के रूप में छोटी Node.js services के साथ (पूरा setup केस स्टडी में)। /api/v1/users?id=7 की call echo service तक /v1/users?id=7 के रूप में पहुँची (/api prefix हटा हुआ), X-User asha सेट के साथ, 32 अक्षरों की बनी request ID, और forwarded-for पते के साथ। छपे fields हैं: path, user, request id मौजूद, उसकी लंबाई, forwarded-for मौजूद।

GET /api/v1/users?id=7

Output:

/v1/users?id=7 asha true 32 true

त्वरित जाँच: Gateway पर request ID क्यों बनाएँ?

  • एक अनुरोध का पीछा logs और services भर में करने के लिए
  • Body encrypt करने के लिए
  • Rate सीमित करने के लिए
  • Path बदलने के लिए
Answer

एक अनुरोध का पीछा logs और services भर में करने के लिए — साझा ID एक अनुरोध के लिए बनी हर log पंक्ति को जोड़ती है।