Routing av en HTTP -begäran från en klient till rätt tjänst på en server involverar flera steg och beror starkt på serverns arkitektur. Här är en uppdelning av de gemensamma tillvägagångssätten:
1. Load Balancer (ofta det första stoppet):
* Många system använder en lastbalanser som ingångspunkt. Detta är en dedikerad server som distribuerar inkommande förfrågningar över flera backend -servrar (de faktiska tjänsterna). Load Balancer bestämmer vilken server som ska vidarebefordra begäran till baserat på faktorer som serverbelastning, hälsokontroller och eventuellt till och med begär egenskaper (t.ex. med hjälp av en teknik som kallas innehållsmedveten routing).
* Load Balancer arbetar vanligtvis vid nätverkslagret (skikt 4) eller applikationslagret (skikt 7). Skikt 4 -belastningsbalanserare tittar på saker som IP -adresser och portar, medan lager 7 Belastbalanserare inspekterar själva HTTP -begäran (rubriker, URL, etc.) innan de fattar ett routningsbeslut.
2. Omvänd proxy (ofta efter lastbalansen):
* En omvänd proxy sitter framför en eller flera backend -servrar. Den tar emot förfrågningar från lastbalansen (eller direkt från klienter om det inte finns någon lastbalanser) och vidarebefordrar dem till rätt tjänst.
* Omvända proxyer hanterar ofta uppgifter som cachning, SSL -avslutning (dekryptering av HTTPS -trafik) och begär modifiering innan du skickar begäran till backend.
* Nginx och Apache är populära exempel på omvända proxyer.
3. Routing på serversidan (inom applikationen):
* När begäran når servern (efter att ha potentiellt passerat en lastbalanserare och omvänd proxy) måste servern själv bestämma vilken specifik tjänst eller applikation som ska hantera den. Detta görs vanligtvis med en av följande metoder:
* url Path: Den vanligaste metoden. Servern undersöker sökvägskomponenten i URL (delen efter domännamnet). Till exempel kan `/användare/123 'dirigeras till en användartjänst, medan`/Products/Search' kan gå till en produktkatalogtjänst. Ramverk som Express.js (Node.js), Spring Boot (Java) och Django (Python) tillhandahåller mekanismer för att definiera rutter baserade på URL -vägar.
* värdnamn/domän: Olika tjänster kan distribueras på olika underdomäner eller värdnamn (t.ex. `user.example.com` vs.` produkter.example.com`). Servern kan använda värdnamnet för att bestämma lämplig tjänst.
* huvudbaserad routing: Begäran kan innehålla rubriker som innehåller information om den avsedda tjänsten. Servern kan kontrollera dessa rubriker för att dirigera begäran i enlighet därmed.
* Begär innehåll: I vissa fall kan innehållet i själva förfrågningsorganet bestämma vilken tjänst som ska hantera det. Detta är mindre vanligt eftersom det kräver mer bearbetning och kan vara mindre effektiv.
4. Service Discovery (för mikroservicesarkitekturer):
* I mikroservicarkitekturer distribueras och skalas tjänster ofta dynamiskt. Mekanismer för upptäckt av tjänster, som konsul, etcd eller Kubernetes, hjälper till att hitta de aktuella instanserna för varje tjänst. När en begäran kommer in, frågar routingmekanismen (t.ex. en omvänd proxy- eller API -gateway) serviceupptäcktssystemet för att hitta adressen till lämplig serviceinstans och vidarebefordra begäran.
Sammanfattningsvis: Processen är en kedja av potentiellt flera komponenter. En begäran flyter vanligtvis som denna:
Klient -> (Load Balancer) -> (omvänd proxy) -> server -> (Serviceupptäckt, om tillämpligt) -> specifik service
Den exakta implementeringen beror starkt på systemets komplexitet och den specifika tekniken som används. Enkla applikationer kanske bara involverar URL-sökväg på en enda server, medan storskaliga system använder en kombination av lastbalanserare, omvänd proxyer, upptäckt av service och sofistikerade routingregler.
