En API-forespørgsels livscyklus — hvert hop undervejs

En API-forespørgsels livscyklus — hvert hop undervejs

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs kolonnen »Før forespørgslen« først: DNS, TCP, TLS — de tre ture frem og tilbage, der sker, før der sendes noget HTTP.
• Følg derefter forespørgslen ind i »Serverens behandling«: load balancer, handler, database, serialisering.
• Læs kolonnen »Svar« som spejlbilledet — svaret følger den samme vej tilbage til klienten.

Før forespørgslen

»Browseren slår domænet op via DNS« er den første tur frem og tilbage — domænet bliver til en IP-adresse (emnet for forklaringen om DNS). »Der etableres en TCP-forbindelse« åbner den pålidelige kanal af bytes, og »TLS-handshaket sikrer forbindelsen« krypterer den (emnet for forklaringen om HTTPS). Først derefter kommer »HTTP-forespørgslen sendes«. De tre indledende bokse er grunden til, at et koldt API-kald er synligt langsommere end et varmt.

Serverens behandling

»Load balanceren router til en applikationsserver« fordeler forespørgslen mellem sunde instanser. »Handleren validerer og behandler forespørgslen« er der, hvor applikationens kode kører, »Serveren kører en forespørgsel mod databasen« er datahoppet — som regel det langsomste — og »Serveren serialiserer svaret« er formateringen på vejen tilbage. Opdelingen i baner holder netværkskanten, applikationen og datalageret synligt adskilt, fordi de har forskellige fejlmåder og forskellige budgetter for svartid.

Svarets vej

»Svaret rejser tilbage ad den samme vej« og »Klienten parser og viser svaret« lukker cirklen. Svaret vender ikke tilbage af sig selv — det krydser den samme load balancer, det samme netværk og den samme forbindelse, som bar forespørgslen. At forstå, at vejen er den samme, er det, der forklarer, hvorfor timeouts på forespørgslen og timeouts på svaret er det samme problem, og hvorfor de to kolonner spejler hinanden.

Key relationships and takeaways

• DNS, TCP og TLS kommer før HTTP-forespørgslen — tre ture frem og tilbage, før nogen applikationskode kører.
• Load balanceren får mange servere til at ligne én adresse; klienten ser aldrig den rigtige server.
• Databaseforespørgslen er det langsomste hop i de fleste API-kald, og derfor betyder caching og indeksering noget.
• Svaret følger forespørgslens vej tilbage — begge retninger krydser det samme netværk og den samme load balancer.
• Livscyklussen sætter de andre forklaringer sammen: DNS, HTTPS og REST er alle trin på den samme rejse.

When to use this visual

• At lære en ny udvikler, at svartiden på et API er mere end serverkode — netværket og opsætningen er reelle trin.
• At fejlsøge langsomhed: lærredet navngiver de hop, du skal måle — DNS-tid, TTFB, servertid, overførselstid.
• At forankre en samtale om load balancing og caching i, hvor hver ting sidder på rejsen.

Sådan fungerer det

1. Tegn jeres rigtige infrastruktur

   Erstat den generiske load balancer, applikationsserver og database med jeres faktiske komponenter — jeres CDN, jeres instanser, jeres datalager — med én boks pr. hop.

2. Notér budgettet for svartid

   Sæt en kommentar på hvert hop med den tid, det typisk tager i jeres system — DNS-opslag, forbindelse, TLS, servertid, database — så lærredet bliver en profil over svartiden.

3. Tilføj cachelaget

   Indsæt en cacheboks mellem load balanceren og handleren med en forgrening for hit og miss i cachen, for det er det håndtag, de fleste teams trækker i først.

4. Tegn fejlgrenene

   Tilføj de faktiske fejlslutpunkter — et DNS-timeout, en TLS-fejl, en 502 fra load balanceren, et databasenedbrud — hver med et eksplicit udfald.

Ofte stillede spørgsmål

Hvilke trin består en API-forespørgsel af?

Før der sendes noget HTTP, slår klienten domænet op via DNS, åbner en TCP-forbindelse og gennemfører et TLS-handshake. Derefter rejser forespørgslen til en load balancer, som router den videre til en applikationsserver; serveren validerer og behandler den, kører en forespørgsel mod databasen og serialiserer et svar; og svaret vender tilbage ad den samme vej. Forklaringens tre kolonner er præcis de tre grupper af trin.

Hvorfor er et API-kald langsomt, før serveren gør noget som helst?

Fordi DNS-opslaget, TCP-forbindelsen og TLS-handshaket alle er reelle ture frem og tilbage, der sker, før en eneste byte HTTP sendes. På en kold forbindelse kan de tage længere tid end selve behandlingen af forespørgslen. Derfor åbner forklaringen med kolonnen »Før forespørgslen« — det meste af svartiden på den første forespørgsel er opsætning, ikke serverkode.

Hvilken rolle spiller load balanceren i livscyklussen?

Load balanceren er den stabile hoveddør, de faktiske servere står bag. Den tager imod forespørgslen, vælger en sund instans og sender trafikken videre, og den er også ofte der, hvor health checks og TLS terminerer. Klienter ved aldrig, hvilken server der betjente dem, og det er det, der gør det muligt at tilføje og fjerne servere uden at ændre klienten.

Hvorfor tager svaret den samme vej tilbage?

Fordi forbindelsen er vejen: svaret rejser over den samme TCP/TLS-forbindelse, gennem det samme netværk og den samme load balancer, som bar forespørgslen. Symmetrien betyder noget i drift — et langsomt eller ødelagt hop rammer begge retninger, og derfor tegner forklaringen svarkolonnen som spejlbilledet af forespørgselskolonnen i stedet for at gå ud fra, at returrejsen er gratis.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det lærred med livscyklussen, du ser ovenfor, som dit eget diagram, omdøb hoppene til jeres egen infrastruktur, og følg jeres rigtige forespørgsler.

Redigér dette diagram i QueryChart (FlowJam)