In che modo sono i servizi a valle e a monte?

45

Per un sistema costituito da più servizi che si chiamano l'un l'altro (ad esempio Front End -> Backend -> Storage), ho spesso sentito persone che utilizzavano terminologie come servizi "downstream" o "upstream". Non sono chiaro quale direzione significhino. I dati scorrono in entrambe le direzioni. Le richieste scorrono da un servizio più rivolto agli utenti a un servizio più back-end, ma le risposte scorrono nella direzione opposta, quindi mi sembra che in entrambi i casi si possa discutere

architecture terminology

— user69715
fonte

3

È interessante notare che la specifica HTTP RFC 7230 include definizioni dei termini "a monte" e "a valle" nella Sezione 2.3: tools.ietf.org/html/rfc7230#section-2.3

— Jack

56

I servizi a valle sono quelli che consumano il servizio a monte. In particolare, dipendono dal servizio a monte. Quindi il front-end è a valle del back-end perché dipende dal back-end. Il back-end può esistere in modo significativo senza il front-end, ma il front-end non ha senso senza il back-end.

La dipendenza non deve essere forte come ho capito nel paragrafo precedente. Più in generale, i servizi a monte non devono conoscere o preoccuparsi dell'esistenza di servizi a valle. I servizi a valle si preoccupano dell'esistenza di servizi a monte, anche se li consumano solo facoltativamente.

— Derek Elkins
fonte

Penso che dovrebbero essere "servizi a valle" al posto di "servizi a valle" .

— Nawaz,

8

Sfortunatamente ci sono differenze di opinione sul significato di upstream / downstream. Quando parlo di architettura di sistema, la definisco come segue:

Dato un sistema di preoccupazione, i sistemi che avviano lo scambio di messaggi / dati con il sistema di preoccupazione sono sistemi a monte e i sistemi da cui dipende il sistema di preoccupazione (cioè quelli da cui il mio sistema avvia lo scambio di dati) sono sistemi a valle.

Questo link di IBM che descrive le interazioni con uno dei loro prodotti conferma questa visione: integrazione con i sistemi a monte e a valle https://www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

Un sistema upstream è qualsiasi sistema che invia dati al sistema Collaboration Server. Un sistema a valle è un sistema che riceve dati dal sistema Collaboration Server.

Data la terminologia "a monte" e "a valle", può essere utile fare un'analogia con un fiume. Se si rilascia un messaggio (dati) nel fiume, esso scorre da monte (iniziatore) a valle (ricevitore).

Aneddoticamente, ho scoperto che architetti e sviluppatori di middleware usano questa definizione e gli sviluppatori web l'opposto (forse a causa del "caricamento").

Con le linee temporali degli eventi, un evento è a monte quando si verifica prima di un punto sulla linea temporale (ovvero attiva un altro evento) e a valle quando si verifica successivamente (ovvero ha ricevuto l'evento). Ciò che è a monte e ciò che è a valle in una sequenza di eventi, quindi, dipende da dove ti trovi nella sequenza temporale. Un evento può essere sia a valle che a monte, a seconda che il punto di partenza sia precedente o successivo.

Come osserva @Jack RFC7230 tools.ietf.org/html/rfc7230#section-2.3 ha questo:

I termini "upstream" e "downstream" sono usati per descrivere i
requisiti direzionali in relazione al flusso di messaggi: tutti i
messaggi scorrono da upstream a downstream

Sarei interessato a vedere sui voti quale sia l'uso più comune!

— Roj
fonte

1

Questo è solo confuso perché sei confuso te stesso sulla questione. Non c'è discrepanza, solo una differenza dal punto di vista.

— Martin Maat,

@MartinMaat Non sono d'accordo con la tua prima frase e sono d'accordo con la tua seconda.

— Roj

3

Il modo migliore per pensarci è pensare a un fiume.

La parte a valle del fiume non può ricevere acqua a meno che non provenga da monte, cioè a valle dipende dall'upstream per la sua acqua.

Se qualcuno distruggesse la parte a valle del fiume, ciò non avrebbe alcun impatto a monte. Se qualcuno distruggesse la parte a monte del fiume, ciò avrebbe un impatto a valle, cioè non otterrebbe alcuna acqua.

Quindi i servizi a valle dipendono dai servizi a monte. Se i servizi a monte vengono rimossi, i servizi a valle non funzioneranno correttamente.

— Gaz_Edge
fonte

E per quel pizzico di chiarezza in più; in una relazione client-server CRUD standard, entrambe le estremità sono sia a monte che a valle l'una verso l'altra. Il client non può ottenere dati o aggiornamenti se il server è inattivo e il server non ha istruzioni da eseguire se non è presente un client.

— Delioth,

1

@Delioth non è d'accordo. Il back-end può avere molti client, ma non dipende da nessuno di essi. Se hai rimosso un client, il backend funzionerebbe comunque. Il client può avere molti backend che potrebbe usare. Se un back-end viene rimosso senza che il client lo sappia, il client non può funzionare correttamente. Il client è a valle. Il backend è a monte.

— Gaz_Edge

1

Questo potrebbe essere più un problema linguistico e geografico che tecnico.

La richiesta di informazioni va a monte. Proviene da un sistema a valle.
La risposta alla richiesta di informazioni (le informazioni richieste) va a valle e viene inviata da un sistema a monte.

Non vi è alcuna differenza tra la visualizzazione classica di IBM e l'utilizzo dei termini da parte della comunità Web di oggi.

Un fornitore di servizi (server) verrà posizionato a monte rispetto a un consumatore di servizi e invierà informazioni a valle al consumatore.
Un consumatore di servizi (client) verrà posizionato a valle rispetto al fornitore del servizio e invierà richieste a monte al fornitore.

Teoricamente i ruoli dei sistemi fisici potrebbero cambiare istantaneamente, così come la direzione del flusso tra tali sistemi. In una rete peer-to-peer questo può essere il caso.

I termini che caricano e scaricano sono termini centrati sul cliente. Dal punto di vista del cliente viene caricata una richiesta e viene scaricata una risposta, che è coerente con la metafora dello stream.

— Martin Maat
fonte