Il tuo app mobile funziona bene durante i test locali. Gli utenti di Londra l'aprono e tutto sembra veloce. Gli utenti di Tokyo aprono la stessa versione e si lamentano che il caricamento è lento, le aggiornamenti richiedono troppo tempo e alcuni contenuti sembrano ritardati. Non hai modificato l'app per una regione e non per l'altra. La differenza è la distanza.
Quello è il motivo pratico per cui gli sviluppatori finiscono per chiedere What è un rete di edge. Non perché vogliono un nuovo buzzword, ma perché le app globali espongono i limiti di inviare ogni richiesta, asset e aggiornamento a un posto lontano.
Per i team mobili, questo diventa dolorosamente evidente durante le rilascio. È necessario inviare una correzione JavaScript, una copia aggiornata o un piccolo cambiamento di asset. Alcuni utenti lo ottengono velocemente. Altri aspettano più a lungo, riprovano o superano i tempi di attesa a seconda di dove si trovano e quanto il richiesta deve viaggiare. La rete di edge esiste per ridurre quel divario.
Indice
- Perché la tua app è veloce a Londra ma lenta a Tokyo
- L'architettura di base di una rete di edge
- Rete di edge vs CDN vs calcolo di edge
- The Benefits Chiave per la tua Applicazione
- Utilizzo reale di casi di rete di edge
- Come implementare una strategia di edge
Perché la tua app è veloce a Londra ma lenta a Tokyo
Un utente premendo l'icona della tua app a Londra. L'app controlla per nuove configurazioni, carica alcuni asset e continua. Un utente a Tokyo fa la stessa cosa, ma ogni richiesta deve viaggiare più lontano per raggiungere la tua infrastruttura. Anche se ogni richiesta si sente solo un po' più lenta, le app mobili fanno spesso più di una richiesta in sequenza. È quando gli utenti iniziano a descrivere l'app come “lenta in modo casuale”
The concept mancante è la latenza di rete. Se desideri un rinfresco pratico, questa guida alla la latenza di rete nei dispositivi mobili collega direttamente l'idea al comportamento degli sviluppatori di app che debuggano.
Un rete di edge risolve questo spostando la rete e il processamento più vicino all'utente. Invece di costringere ogni dispositivo a parlare con un'origine remota distante, il sistema può servire le richieste da un luogo vicino. Intel descrive una rete di edge come un'architettura distribuita che sposta le funzioni di calcolo, archiviazione e rete da un cloud centrale in punti di presenza geograficamente più vicini, riducendo la distanza che i dati devono percorrere per ogni richiesta, come spiegato nell'overview di Intel sull'.
architettura di rete di edge
Perché questo conta di più ora Questo non è più un'infrastruttura di nicchia. Una proiezione dice che entro il 2025, il 75% dei dati generati dalle imprese sarà creato e elaborato al di fuori di un centro dati centralizzato o cloude il mercato di calcolo all'orlo è previsto crescere da 47,0 miliardi di dollari nel 2023 a 171,0 miliardi di dollari entro il 2031secondo le proiezioni dell'industria di calcolo all'orlo I tuoi utenti non esperiscono “architettura”. Esperiscono aspettare, riprovare e comportamenti non coerenti per regione..
Per un sviluppatore mobile, ciò si traduce in una semplice regola. Se il tuo app ha utenti globali, il tuo sistema di rilascio, le tue risorse e il percorso di aggiornamento devono comportarsi a livello globale. Altrimenti, il tuo app è veloce solo per le persone che accadono a vivere vicino all'infrastruttura.
L'Architettura di Base di una Rete di Edge
La maniera più facile per comprendere una rete di edge è fermarsi a pensare a server e iniziare a pensare a logistica.
Un setup cloud tradizionale funziona come un
magazzino centrale __CAPGO_KEEP_0__. Tutto vive in un unico magazzino principale. Non importa dove si trova il cliente, ogni ordine spedisce da quel luogo. È semplice da gestire, ma non è ideale quando i clienti sono sparsi su continenti diversi.
Un rete di edge assomiglia di più a un sistema di magazzini locali o negozi di dettaglio. Il magazzino principale esiste ancora, ma gli articoli comuni e alcune operazioni locali avvengono più vicino al cliente.
Nuvola centrale contro punti di presenza vicini
Nel networking di edge, quei luoghi locali sono spesso chiamati punti di presenza, o PoP,. Sono luoghi geograficamente distribuiti dove il traffico può essere ricevuto, elaborato, protetto e a volte memorizzato in cache prima di dover toccare il sistema centrale.
Per un'app mobile, significa che un utente in Giappone non deve sempre aspettare di essere servito da infrastrutture situate in Europa o in Nord America. La sua richiesta può entrare nella rete in un punto più vicino e essere gestita con meno lunghe traversate della rete internet.
Questo conta anche per le aggiornamenti. Se il tuo app controlla per una nuova bundle web, file di configurazione o pacchetto di risorse all'avvio, ogni round trip aggiuntivo si riflette nel comportamento di avvio. Le squadre che monitorano questo solitamente traggono vantaggio dall'impostazione della monitoraggio delle prestazioni nei app Capacitor così possono confrontare le regioni al posto di affidarsi al testing locale da solo.
Caching, routing e elaborazione locale
Tre pezzi fanno clic sul modello per la maggior parte degli sviluppatori:
- Il caching memorizza contenuti frequenti vicino. Se molti utenti richiedono le stesse risorse dell'app o il pacchetto di aggiornamento, la posizione di rete può tenere una copia pronta al posto di prenderla ogni volta dal punto di origine.
- Il routing invia gli utenti al punto di ingresso più vicino. Pensa a questo come al controllo del traffico. La rete cerca di evitare di inviare un utente su un percorso lungo o congestionato quando esiste un percorso più vicino.
- L'elaborazione locale gestisce il lavoro semplice prima che il cloud centrale sia coinvolto. Ciò può includere la filtrazione, le verifiche di autenticazione, il trattamento delle richieste o la preparazione dei dati prima che vengano spediti verso l'alto.
Regola pratica: If illo stesso oggetto viene richiesto ripetutamente dagli utenti in molti luoghi, probabilmente non dovrebbe essere recuperato da un'origine remota per ogni singola richiesta.
Questa è la risposta di base a “cosa è la rete di edge” in inglese semplice. È un modo distribuito per collocare funzioni di rete più vicine agli utenti, in modo che le richieste comuni si completino più velocemente e con meno possibilità di fallimento.
Il cloud non scompare. Il cloud diventa il magazzino principale, mentre le posizioni di edge diventano i negozi vicini che eliminano la distanza dall'esperienza utente.
Rete di Edge vs CDN vs Calcolo di Edge
I tre termini vengono confusi costantemente e la confusione è comprensibile perché si sovrappongono in prodotti reali.
Un sviluppatore sente che un fornitore ha “distribuzione di edge”, “calcolo di edge” e “CDN globale”, e tutto sembra la stessa cosa. Non è così.
Dove gli sviluppatori li confondono
A Un CDN è di solito il concetto più facile da capire. Il suo compito è principalmente di cache e distribuire contenuti come immagini, file JavaScript, fogli di stile, segmenti di video e asset scaricabili da posizioni vicine agli utenti. CDN è l'acronimo di Content Delivery Network.
Calcolo di rete di bordo è più ampio. Significa eseguire la logica dell'applicazione o il trattamento dei dati vicino all'utente o al dispositivo, non solo memorizzare file di cache lì.
Il rete di bordo è il layer di connettività distribuita sottostante che rende possibili questi pattern. Neos Networks descrive l'effetto principale di prestazioni comeritardo fine-anima fine inferiore , e spiega che elaborando i dati sui server di bordo prima che raggiungano la cloud centrale, le reti di bordo consentono ai carichi di lavoro sensibili alla latenza come l'analisi in tempo reale e l'inferenza AI nella sua spiegazione di.
rete di bordo e riduzione del ritardo
- Quella distinzione conta per i team di app: se desiderate una consegna di immagini o bundle più veloce, potreste aver bisogno solo di caching di tipo CDN.
- Se desiderate il trattamento delle richieste o la presa di decisioni vicino agli utenti, siete nell'area di calcolo di edge.
- Se desiderate che l'intero percorso sia geograficamente più vicino e con bassa latenza, state parlando di rete di edge.
Se lavorate sul comportamento di rilascio, percorsi di avvio o tempi di richiesta, questa raccolta di articoli su le prestazioni della rete per gli squadre di app è un argomento di discussione utile di contorno.
Edge Network vs. CDN vs. Edge Computing in una visione d'insieme
| Attributo | Rete di Edge | CDN (Network di distribuzione di contenuti) | Calcolo di Edge |
|---|---|---|---|
| Lavoro principale | Spostate le funzioni di rete più vicine agli utenti e ai dispositivi | Cache e distribuisce contenuti in modo efficiente | Esegui code o elabora dati vicino agli utenti o dispositivi |
| Carico di lavoro tipico | Routing delle richieste, gestione del traffico, servizi di rete locale | Asset statici, file scaricabili, consegna dei media | Logica API, filtraggio, inferenza, elaborazione in tempo reale |
| Dove avviene il lavoro | Presso punti distribuiti vicino agli utenti | Presso posizioni di cache distribuite | Presso server o dispositivi di edge vicino alla fonte |
| Migliore modello mentale | Il sistema stradale e i punti di ingresso vicini | The local shelf con articoli popolari già disponibili | The worker locale che gestisce compiti sul posto |
| Cosa notano gli sviluppatori di dispositivi mobili | Minore ritardo lungo l'intero percorso di richiesta | Carichi di asset più veloci e download | Decisioni più rapide senza chiamare sempre l'origine |
Un CDN può far parte di una strategia di edge, ma non significa automaticamente che il tuo'applicazione stia facendo il calcolo di edge.
Quella frase chiarisce la maggior parte dei dibattiti sull'architettura.
I benefici chiave per la tua applicazione
Una volta che l'architettura clicca, i benefici diventano più facili da giudicare. Non stai comprando 'edge' come un etichetta. Stai scegliendo un modo per ridurre la distanza, eliminare i viaggi di ritorno non necessari e mantenere le app utilizzabili quando le reti non sono perfette.
Risposte più veloci che gli utenti possono sentire
IBM descrive la rete di edge come il trasferimento di molti compiti di elaborazione lontano dal trattamento dei dati-centri verso i dispositivi di edge, migliorando la velocità, la larghezza di banda e la affidabilità riducendo la latenza. Un esempio IBM nota velocità di download che raggiungono __CAPGO_KEEP_0__ 384 Kbpso o circa 2-3 volte più veloce rispetto alle reti regolari per quel scenario, come descritto nell'analisi di IBM su come le reti di edge migliorano la velocità.
Il tempo di caricamento dei dispositivi mobili non si pensa in Kbps. Si pensa in momenti:
- La schermata di caricamento scompare prima.
- L'aggiornamento di controllo si completa senza aspettative scomode.
- L'app sembra meno fragile su reti deboli.
- Un piccolo hotfix arriva prima che le richieste di supporto si accumulino.
Se il tuo team sta cercando di conseguire l'invio di app full-stack velocementeRicorda che la velocità di consegna non è solo un problema di flusso di lavoro del developer. È anche un problema di percorso dell'infrastruttura.
Piu resilienza quando le reti si fanno confuse
Il sistema distribuito può continuare a servire il traffico anche quando un percorso o una posizione ha problemi. In pratica, ciò significa che gli utenti non dipendono tanto da un'origine remota raggiungibile, veloce e non congestionata in ogni momento.
Per le squadre di app, ciò si manifesta durante le finestre di rilascio e la risposta agli incidenti. Se hai bisogno di distribuire asset aggiornati o configurazioni globalmente, una posizione di rete di edge vicina spesso dà agli utenti una maggiore possibilità di ottenere ciò di cui hanno bisogno senza un lungo viaggio di ritorno al core.
Un buon passo successivo è revisionare il tuo proprio elenco di controllo di ottimizzazione delle prestazioni dell'app e segnala le parti che sono realmente problemi di distanza di rete piuttosto che code problemi.
Il controllo di sicurezza più vicino al traffico
Il sistema di rete di edge può anche migliorare la posizione di sicurezza perché il filtraggio e l'esecuzione possono avvenire più vicino a dove il traffico entra. Ciò può aiutare a fermare alcuni traffici non desiderati prima che raggiungano il sistema centrale.
Tenere il lavoro semplice vicino all'utente e tenere i sistemi di origine sensibili lontani dal trattamento di ogni singolo richiesta direttamente.
Questo non significa che la rete di edge magica renda un'app sicura. Significa che puoi collocare le protezioni più vicino al percorso e ridurre il raggio d'azione dei sistemi centrali.
Usi reali di rete di edge
La via più facile per rendere concreto il networking di edge è guardare ai prodotti che le persone usano ogni giorno.
Streaming e giochi fanno facile da vedere
Le piattaforme di streaming video si affidano alla consegna vicina affinché gli utenti possano iniziare la riproduzione velocemente e evitare la buffering. La libreria di contenuti di base può essere centralizzata, ma il contenuto popolare viene distribuito più vicino agli utenti.
I giochi online hanno un problema simile con un sintomo diverso. Invece della buffering, i giocatori notano la lag, le reazioni ritardate o il comportamento multiplayer non coerente. Più il percorso di rete è lungo, peggiorano quei ritardi.
Quelle esempi aiutano perché sono visibili. Puoi sentire il beneficio immediatamente quando un video inizia più velocemente o un gioco si sente più rispondente.
Perché gli aggiornamenti degli app mobili sono un problema di edge
Gli aggiornamenti degli app mobili sono meno evidenti, ma lo stesso problema di architettura è presente.
Quando il tuo app controlla per un aggiornamento live, scarica gli asset web modificati, li verifica e li applica alla prossima avviatura, il percorso di aggiornamento diventa parte della qualità del prodotto. Un utente non si cura di sapere se il ritardo è venuto dallo size del pacchetto, dalla geografia di rete o dalla congestione di origine. Sanno solo che la correzione non è arrivata quando ne avevano bisogno.
È per questo che la consegna di edge conta per gli aggiornamenti live. Un servizio di aggiornamento distribuito globalmente può ottenere i pacchetti modificati più vicini ai dispositivi affinché il percorso di richiesta sia più breve e meno dipendente da un'origine.
A un esempio pratico è Capgo, che fornisce aggiornamenti in tempo reale per le applicazioni CapacitorJS e Electron attraverso una rete di edge globale e consente agli squadre di pubblicare pacchetti web firmati, canali di destinazione e distribuire correzioni senza dover attendere la revisione dell'app store. Gli squadre che lavorano su rilasci controllati possono abbinare questo con aggiornamenti in tempo reale utilizzando la segmentazione degli utenti
per evitare di inviare ogni rilascio a ogni utente una volta.
Esempio di un walkthrough che aiuta a visualizzare dove si colloca la consegna di edge nella flusso di rilascio:
Quando una correzione è piccola ma urgente, il percorso della rete verso l'utente conta quasi quanto la correzione stessa.
Questa è la risposta centrata sullo sviluppatore che la maggior parte degli articoli di edge futuristici trascurano. Le reti di edge non sono solo per scenari IoT futuristici. Risolvono un problema mobile molto ordinario: fornire l'aggiornamento giusto all'utente giusto velocemente, ovunque si trovi.
Come implementare una strategia di edge
Scegliere una strategia di edge inizia con i punti di bottiglia dell'app, non con la pubblicità del fornitore. Se il principale dolore è la consegna lenta degli asset statici, un approccio focalizzato sulla cache potrebbe essere sufficiente. Se il dolore è il ritardo delle richieste, l'incoerenza regionale o la affidabilità degli aggiornamenti in tempo reale, potrebbe essere necessario un setup di edge più ampio.
Utilizza una lista di selezione che si mappa direttamente sul comportamento del tuo'applicazione:
- Area geografica: La tua provider dovrebbe avere copertura dove sono i tuoi utenti, non solo dove è basato il tuo team.
- Gestione del traffico: Cerca routing, caching e controlli di consegna che corrispondono al tuo carico di lavoro. Gli asset dell'app, le chiamate API e i pacchetti di aggiornamento non comportano tutti nello stesso modo.
- Modello di sicurezza: Controlla come il provider gestisce il controllo di accesso, l'encryption, le esigenze di conformità e la filtratura di edge-side.
- Visibilità operativa: Hai bisogno di log, metriche e osservabilità sufficiente per spiegare perché una regione è più lenta di un'altra.
- Flusso di lavoro del developer: Gli API, le integrazioni CI/CD, i controlli di rollback e la versione di targeting contano quanto il disegno di rete netto.
Un buon processo di selezione inizia con alcune domande concrete:
- Dove vivono i nostri utenti più lenti?
- Quali richieste avvengono al avvio dell'app?
- Cosa può essere cacheato in modo sicuro?
- Quali parti devono ancora tornare all'origine?
- Come risolveremo un problema di consegna regionale?
Quando l'edge non è la risposta giusta
Non ogni app ha bisogno di infrastruttura di edge distribuita. Akamai nota che il termine “edge” può essere vago, e che non è una soluzione miracolosa . Il caso d'affari dipende dal carico di lavoro, dalla complessità operativa e dalla governance, e per alcune applicazioni i guadagni di latenza possono non giustificare l'overhead di gestione di un'architettura distribuita, come discusso nell'entry del glossario di Akamai sucosa è e non è una rete di edge __CAPGO_KEEP_0__.
That’s a useful reality check.
Se il tuo app serve un pubblico geografico ristretto, ha poco traffico di rete al momento del lancio o non dipende dalla consegna veloce di asset e aggiornamenti, l'edge potrebbe aggiungere complessità senza un sufficiente ritorno.
Piu' location significa piu' parti in movimento. Più parti in movimento significano più decisioni sul comportamento della cache, sulla consistenza della distribuzione, sulla politica di sicurezza e sulla monitoraggio.
La domanda giusta non è 'Dovremmo utilizzare l'edge perché le moderne app lo fanno?' È 'Quali richieste sono attualmente troppo lontane dall'utente e ridurre quella distanza vale la spesa operativa?' Capgo __CAPGO_KEEP_0__
