Proxy ფენები და reverse მარშრუტიზაცია

მოკლე რეზიუმე

მარიონეტული ფენა არის პლატფორმის „წინა საბურავი“: ის ასრულებს TLS- ს, დამოწმებს მომხმარებლებს, ანაწილებს ტრაფიკს, ამცირებს მწვერვალებს და გამოშვებას უსაფრთხოდ აქცევს (კანარი, ცისფერი-მწვანე). სიმწიფის მინიმალური სიმრავლე: მარიონეტული როლების მკაფიო სტრატიფიკაცია, დეტერმინისტული მარშრუტიზაციის წესები, ტაიმაუტების/რეპრესიების კონტროლი, კეში + სიმწიფე-ლიმიტი, დაკვირვება და ავტომატიზაცია.

მარიონეტული ტაქსონომია

Forward proxy - მომხმარებელთა/მომსახურების გამავალი ტრაფიკი, ფილტრები/მარცვლეული, DLP.
Reverse proxy - იღებს გარე მოთხოვნებს და ბრუნავს ზურგჩანთებზე (ჩვენი მთავარი ყურადღება).

ფენები პროდ-წრეში:

1. Edge/CDN/WAF (Anycast, bot ფილტრები, ქეში)

2. L7 Ingress/API-gateway (მარშრუტიზაცია, ავთენტიფიკაცია, პოლიტიკა)

3. მომსახურების ფენა/Mesh (sidecar) East west, mTLS და retars

4. Egress-gateway გამავალი ინტეგრაციისთვის (PSP, პარტნიორები)

მარშრუტიზაცია (L4/L7) და ალგორითმები

L4 (TCP/UDP, passthrough TLS): მინიმალური შეფერხება, HTTP გაგების გარეშე.
L7 (HTTP/1. 1, HTTP/2, HTTP/3/gRPC): წესები host/path/header/cookie, ტრანსფორმაცია, WAF, ქეში.

ალგორითმები:

Round-robin/Least-Connections/EWMA - ზოგადი შემთხვევები.
Consistent-hash (cookie/იდენტიფიკატორის მიხედვით) - sticky სესიები და ქეშის ადგილსამყოფელი.
Header/Geo-/Latency-based - მიზნობრივი მიზნობრივი რეგიონები/პროვაიდერები, სწრაფი POP.
Canary/Weighted - ეტაპობრივი rollout (5-25-50-100%).
Shadow/Mirroring - ახალი სერვისის ტრაფიკის ასლი პასუხებზე გავლენის გარეშე.

მოთხოვნის/პასუხების ტრანსფორმაცია

URLRRewrite/redirect: ბილიკების გაერთიანება, ვერსიფიკაცია ('/v1/svc/v1/').
სათაურები: ნორმალიზება 'X-Forwarded-For/Proto/Host', დაამატეთ 'traceparent '/' x-request-id ", კიდევ უფრო მეტი ფილტრაცია.
CORS/CSRF: ცენტრალიზებული gateway, არ მიიღოთ პარამეტრები თითოეულ სერვისში.
Compression/Decompression: Brotli/gzip, ტიპის კონტროლი.
Body-limits და დაცვა slowloris/oversized headers- ისგან.

ავთენტიფიკაცია და უსაფრთხოება

TLS 1. 3 + OCSP სტაპლინგი + HSTS გარე ფრონტებზე.
mTLS: admins, ოპერაციული API, პარტნიორი არხები.
OAuth2/OIDC: საავტორო უფლებები gateway- ით (token introspection/JWT-verify) - კლასებში შეღწევა upstream- ში.
API გასაღებები/ხელმოწერები (HMAC) ოფშორული და პარტნიორობისთვის.
WAF/bot ფილტრები: ხელმოწერები + ქცევითი წესები, greypass/capch.
CSP/X-Frame-Options/Referrer-Policy - უსაფრთხოების სათაურები ზღვარზე.

საიმედოობა: retrai/taimauts/SV

Taimauts: კავშირი/read/write L4/L7, ერთიანი პოლიტიკა (მაგალითად, 'კავშირი 500ms', 'read 3-5s' API- სთვის).
Retrai: მხოლოდ idempotent ('GET/HEAD'), დროის/რაოდენობის ლიმიტი, 'retry-budget'.
Circuit-breaker: შეზღუდვები ერთდროულ მოთხოვნებზე/შეცდომებზე, სწრაფი უარი და დეგრადაცია.
Outlier detection: აუზიდან „ცუდი“ ნიმუშების გამორიცხვა.
Backoff + jitter: იმისათვის, რომ არ შექმნათ „ნახირი ეფექტი“.

კეში და ტრაფიკის მენეჯმენტი

Kash L7: სტატიკა/ნახევრად დინამიკა (კატალოგები, კონფიგურაციები), 's-maxage' + 'stale-while-revalidate'.
Rate-limit/Quta: IP/ASN/Device/cookie- ის მიხედვით, განაწილებული მრიცხველი (Redis/Rate Service).
Sticky სესიები: cookie/consistent-hash; გაითვალისწინეთ failover და „tlattle“.
Request collapsing (dedupe): origin დაცვა იდენტური GET- ის „ქარიშხლისგან“.

ოქმები და მახასიათებლები

HTTP/2: მულტიპლექსაცია, პრიორიტეტები; გამართეთ 'ALPN: h2'.
HTTP/3/QUIC: დანაკარგის წინააღმდეგობა/ჯიტერი; გახსენით UDP/443, დააკვირდით MTU/PMTUD.
gRPC: health-checks, streaming, deadlines; მარიონეტებმა უნდა დაუჭირონ მხარი 'grpc-status'.
WebSocket/SSE: გრძელი ხაზები, კომპეტენტური idle Timauts და limites.

დაკვირვება და SLO

მეტრიკა:

L4/L7: `p50/p95/p99`, ошибки (`4xx/5xx/Grpc-codes`), `open_conns`, `CPS/RPS`, `retry_rate`.
TLS: ვერსია/შიფრები, p95 handshake, რეპტიცია.
მარშრუტიზაცია: აქციები მარშრუტზე/კლასტერზე, outlier-ejections.
Rate-limit/WAF: მოქმედება/FP-rate.
ლოგოები: წვდომა (PII- ის გარეშე), მარშრუტიზაციის მიზეზები, ტრეკების სათაურები.
ტრეისი: 'traceparent '/B3, სიმულაცია.

SLO (მაგალითები):

p95 TTFB API - 250-300 ms; შეცდომა L7-0. 5%.
კანარის წარმატება (მეტრიკის დეგრადაციის გარეშე) არის გაშვების 99%.
FP-rate WAF ≤ 0. 1%.

ტიპიური კონფისკაციები

Nginx (reverse proxy, HTTP/2, კანარი, შეკუმშვა)

nginx map $http_x_canary $upstream_pool {
default "stable";
~^1$ "canary";
}

upstream api_stable { zone zst 64k; server 10. 0. 1. 10:8443; server 10. 0. 1. 11:8443; keepalive 256; }
upstream api_canary { zone zcn 64k; server 10. 0. 2. 10:8443; keepalive 64; }

server {
listen 443 ssl http2 reuseport;
server_name api. example. com;

ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000" always;

basic limits/protection client_max_body_size 10m;
sendfile on; brotli on; gzip on;

location / {
proxy_http_version 1. 1;
proxy_set_header Host $host;
proxy_set_header X-Request-Id $request_id;
proxy_set_header X-Forwarded-Proto https;
proxy_connect_timeout 500ms;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 1; # Retrays are limited to proxy_pass https://api_$upstream_pool;
}
}

HAProxy (JWT-verify + mTLS backend + rate-limit)

haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1. 1 http-request set-header X-Request-Id %[unique-id]
http-request lua. jwt_verify # external verification script JWT stick-table type ip size 1m expire 10m store http_req_rate (10s)
http-request deny if { src_http_req_rate(10s) gt 100 }

default_backend be_api

backend be_api balance roundrobin option httpchk GET /healthz server s1 10. 0. 1. 10:8443 check ssl verify required ca-file /etc/haproxy/ca. pem server s2 10. 0. 1. 11:8443 check ssl verify required ca-file /etc/haproxy/ca. pem

Envoy (JWT + weighted routes + outlier detection)

yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0. 0. 0. 0, port_value: 443 } }
filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager stat_prefix: ingress route_config:
virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- { name: api-stable, weight: 95 }
- { name: api-canary, weight: 5 }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config: { "@type": type. googleapis. com/envoy. extensions. filters. http. jwt_authn. v3. JwtAuthentication }
- name: envoy. filters. http. router clusters:
- name: api-stable connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN outlier_detection: { consecutive_5xx: 3, interval: 2s, base_ejection_time: 30s }
transport_socket:
name: envoy. transport_sockets. tls
- name: api-canary connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN transport_socket:
name: envoy. transport_sockets. tls

Traefik (მარშრუტები, კონცეფცია)

yaml http:
routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1/`)"
service: api-svc tls: { certResolver: letsencrypt }
services:
api-svc:
loadBalancer:
servers:
- url: "https://10. 0. 1. 10:8443"
- url: "https://10. 0. 1. 11:8443"

მარიონეტული შესრულება

საკომუნიკაციო პაკეტი და უკანა პლანზე, კონექტორების ლიმიტი ინსტანციებზე.
Reuseport, pin CPU/IRQ, საკმარისი სოკეტების ბუფერები.
TLS: ECDSA + მოკლე ჯაჭვები, რეპლიკაცია 70%, HTTP/2/3 შედის.
ქეში მარიონეტულია „ცხელი“ პასუხებისთვის (მათ შორის 304 სავალდებულო).
Warm-up: გაათბეთ DNS/TLS/კონექტორები მწვერვალებამდე.

DR და წინააღმდეგობა

დეგრადირებული კვანძების ავტომატური ექსპოზიცია ('outlier-ejection').
ჯანმრთელობის შემოწმებები L4/L7 (ვერსიის HTTPbody მარკერი).
Fail Open/Fail-closed - შეარჩიეთ შეგნებულად გადახდის/კრიტიკული გზებისთვის.
Shadow რეჟიმი ახალ სერვისზე გადასვლამდე.
Runbooks: „კლასტერის დაშლა“, „რედაქციის მარყუჟი“, „კონექტორების გაჟონვა“, „ქარიშხლის ქარიშხალი“.

ჩეკის განხორციელების სია

სტრატიფიკაცია: Edge - Ingress/API-GW, Mesh/Egress, პასუხისმგებლობის როლები და საზღვრები.
მარშრუტიზაციის პოლიტიკა: host/path/header/weight, canary/blue-green, shadow.

უსაფრთხოება: TLS 1. 3, mTLS მგრძნობიარე გზებისთვის, JWT/OAuth2, WAF.

Taimauty/retrai/SV: ერთი მნიშვნელობა, imempotence, retry-budget.
Kash/Rate-limit/Request-collapsing იქ, სადაც შესაფერისია.
დაკვირვება: მეტრიკა/ლოგები/ტრეისი, კორელაციის იდენტიფიკატორები.
SLO: p95/შეცდომები/რესურსები; ალერტები პერიმეტრის წარუმატებლობებზე.
IaC/GitOps: ჩამორთმევა მარაგი საცავებში, კანარის გამოშვებებში, სწრაფი rollback.
ტესტები: e2e მარშრუტები, ქაოსის სცენარები, დატვირთვის წინ.

ტიპიური შეცდომები

„ჯადოსნური“ მარიონეტული კომბინაცია როლების განცალკევების გარეშე არის რთული RCA და მაღალი blast სხივი.
Retrais indempotent მოთხოვნებისთვის - გარიგების დუბლიკატები.
არ არსებობს სათაურების/URL- ის ნორმალიზება და არასწორი გასაღებები.
Sticky სესიები failover- ის გეგმების გარეშე - დეგრადირებულ ინსტანციაში ჩამოსხმა.
'traceparent '/' x-request-id' არარსებობა პრობლემების კორელაცია შეუძლებელია.
მკაცრი 301/302 მარიონეტული დონეზე, მარყუჟები და API ვერსიების კონტროლის დაკარგვა.

სპეციფიკა iGaming/fintech

გადახდები/PSP: გამოყოფილი egress-gateway mTLS- ით, მკაცრი ტაიმაუტები, idempotent გასაღებები, თეთრი სიები IP/ASN.
მწვერვალები (მატჩები/ტურნირები): კანარი/ყოველკვირეული, ნაცრისფერი ბოტების მარშრუტები, აგრესიული GET ქეში, origin დაცვა „ქარიშხლისგან“.
მარეგულირებელი/ლოჯისტიკა: ჩაწერეთ პოლიტიკოსის ვერსიები და აუდიტის ლოგოებში მარშრუტის მიზეზები; მინიმუმამდე დაიყვანეთ PII.
შინაარსის პროვაიდერები: პროვაიდერი-ჰაში პროვაიდერის საშუალებით ქეშის ადგილსამყოფელისა და თანაბრად განაწილებისთვის.

მინი ფლეიბუკები

1) კანარის გამოცემა API

1. ჩართეთ წონის 5% 'app-canary'; 2) r95/შეცდომების მონიტორინგი; 3) გააფართოვოს თავისი წილი; 4) ავტოკატასტროფა დეგრადაციის დროს.

2) დეგრადირებული კვანძის გადაუდებელი ამოღება

1. Outlier-ejection ან სახელმძღვანელო 'drain'; 2) აუზისა და ჰიტის ქეშის შემოწმება; 3) პოსტ-ინციდენტი RCA.

3) ფუნქციის მარცვალი

1. ჩართეთ shadow პასუხებზე გავლენის გარეშე; 2) შეადარეთ მეტრიკა/პასუხების რაოდენობა; 3) გადაწყვიტეთ გადართვა.

4) შტორმი რეტრაევი

1. შეამცირეთ retry-budget/დროებითი ლიმიტები; 2) ჩართოთ request-collapsing; 3) ადგილობრივი დანამატები/ქეში; 4) origin სტაბილიზაცია.

შედეგი

კარგად შემუშავებული მარიონეტული ფენა არის როლების გამიჯვნა, დეტერმინისტული მარშრუტიზაცია, საიმედო პოლიტიკოსები (Taimauts/retrais/SV), უსაფრთხოება (mTLS/JWT/WAF) და დაკვირვება. კონფიგურაციის კონსოლიდაცია IaC- ში, გამოიყენეთ კანაფები და shadow, გაზომეთ SLO - და თქვენი პლატფორმა იქნება მასშტაბური, პროგნოზირებადი და დაცული, თუნდაც ყველაზე ცხელი პიკის საათებში.