Path और Header से Routing

नियम, क्रम से मूल्यांकित

Gateway host (api.example.com), path prefix (/orders/), method और headers से मेल करके backend चुनता है। Path routing आम मामला है: /orders/* orders service को और /users/* users service को जाता है। Header-आधारित routing opt-in canaries और आंतरिक परीक्षण संभव बनाता है: X-Canary: 1 वाला अनुरोध नए version को जाता है जबकि बाक़ी सब stable पर रहते हैं। ध्यान रखें कि clients आंतरिक headers गढ़ न सकें: उन्हें edge पर हटाएँ या overwrite करें। क्रम और विशिष्टता मायने रखते हैं, इसलिए परखें कि सबसे विशिष्ट नियम जीतता है।

Routing नियम

map X-Canary header से upstream pool चुनता है, और proxy_pass नतीजे का उपयोग करता है। Gateway config का अंश।

map $http_x_canary $orders_pool { default orders_stable; "1" orders_canary; }

upstream orders_stable { server orders-v1:8080; }
upstream orders_canary { server orders-v2:8080; }

location /pick/ { proxy_pass http://$orders_pool/; }

Header routing, चलाकर

मैंने यह Docker में असली nginx 1.27 gateway पर चलाया, upstreams के रूप में छोटी Node.js services के साथ (पूरा setup केस स्टडी में)। Header के बिना अनुरोध v1 से परोसा जाता है; X-Canary: 1 के साथ वह v2 तक पहुँचता है।

# client side (see the test client): two calls to /pick/x
GET /pick/x                      -> version
GET /pick/x   X-Canary: 1        -> version

Output:

v1 v2

Client के दिए routing headers पर भरोसा न करें

सार्वजनिक client X-Canary: 1 या X-User-Id भेज सके, तो वे अप्रकाशित कोड तक पहुँच सकते हैं या users की नकल कर सकते हैं। ऐसे headers सिर्फ़ भरोसेमंद callers से स्वीकारें, या authentication के बाद ख़ुद सेट करें।

त्वरित जाँच: Header-आधारित routing का एक जोखिम क्या है?

• यह auth की ज़रूरत हटाता है
• Headers पढ़े नहीं जा सकते
• यह TLS को असंभव बनाता है
• सार्वजनिक clients header गढ़कर अनपेक्षित backends तक पहुँच सकते हैं