De que maneira os serviços a jusante e a montante?

45

Para um sistema que consiste em vários serviços que se chamam (por exemplo, Front-End -> Back-end -> Armazenamento), ouvi muitas pessoas usando terminologia como serviços "downstream" ou "upstream". Não estou claro em que direção isso significa. Os dados fluem nas duas direções. As solicitações fluem de um serviço mais voltado para o usuário para mais serviços de back-end, mas as respostas fluem na direção oposta; portanto, parece-me que uma das maneiras pode ser discutida

architecture terminology

— user69715
fonte

3

Curiosamente, a especificação HTTP RFC 7230 inclui definições dos termos "upstream" e "downstream" na Seção 2.3: tools.ietf.org/html/rfc7230#section-2.3

— Jack

56

Os serviços downstream são os que consomem o serviço upstream. Em particular, eles dependem do serviço upstream. Portanto, o front-end fica a jusante do back-end, porque depende do back-end. O back-end pode existir significativamente sem o front-end, mas o front-end não faz sentido sem o back-end.

A dependência não precisa ser tão forte quanto eu fiz no parágrafo anterior. De maneira mais geral, os serviços upstream não precisam saber ou se preocupar com a existência de serviços downstream. Os serviços downstream se preocupam com a existência de serviços upstream, mesmo que apenas os consumam opcionalmente.

— Derek Elkins
fonte

Eu acho que deveria ser "serviços a jusante" em vez de "serviços a jusante" .

— Nawaz

8

Infelizmente, existem diferenças de opinião sobre o significado de montante / jusante. Ao falar sobre arquitetura do sistema, eu o defino da seguinte forma:

Dado um sistema de preocupação, os sistemas que iniciam a troca de mensagens / dados para o sistema de preocupação são sistemas upstream e os sistemas dos quais o sistema de preocupação depende (ou seja, aqueles nos quais meu sistema inicia a troca de dados) são sistemas downstream.

Este link da ibm que descreve interações com um de seus produtos corrobora esta visão: Integração com sistemas upstream e downstream https://www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

Um sistema upstream é qualquer sistema que envia dados para o sistema Collaboration Server. Um sistema downstream é um sistema que recebe dados do sistema Collaboration Server.

Dada a terminologia 'rio acima' e 'rio abaixo', pode ser útil fazer uma analogia com um rio. Se você soltar uma mensagem (dados) no rio, ela flui do rio acima (iniciador) para o rio abaixo (receptor).

Curiosamente, eu descobri que arquitetos e desenvolvedores de middleware usam essa definição e desenvolvedores da Web o contrário (talvez devido a 'upload').

Com as linhas de tempo do evento, um evento fica a montante quando ocorre antes de um ponto na linha do tempo (ou seja, dispara outro evento) e a jusante quando ocorre depois (ou seja, recebeu o evento). O que é upstream e o downstream em uma sequência de eventos, portanto, depende de onde você está na linha do tempo. Um evento pode ser a jusante e a montante, dependendo se o seu ponto de partida é anterior ou posterior a ele.

Como @jack observa RFC7230 tools.ietf.org/html/rfc7230#section-2.3 tem essa:

Os termos "upstream" e "downstream" são usados para descrever
requisitos direcionais em relação ao fluxo de mensagens: todas as
mensagens fluem de upstream para downstream

Eu ficaria interessado em ver nos votos, qual é o uso mais comum!

— roj
fonte

1

Isso é confuso porque você está confuso sobre o assunto. Não há discrepância, apenas uma diferença de ponto de vista.

— Martin Maat

@ MartinMaat Não concordo com sua primeira frase e concordo com sua segunda.

— roj 17/01

3

A melhor maneira de pensar sobre isso é pensar em um rio.

A parte a jusante do rio não pode receber água a menos que venha da montante, isto é, a jusante depende da montante da água.

Se alguém destruísse a parte a jusante do rio, isso não teria impacto a montante. Se alguém destruísse a parte a montante do rio, isso afetaria a jusante, isto é, não receberia água.

Portanto, os serviços downstream dependem dos serviços upstream. Se os serviços upstream forem removidos, os serviços downstream não funcionarão corretamente.

— Gaz_Edge
fonte

E pelo pouco mais de clareza; em um relacionamento cliente-servidor CRUD padrão, as duas extremidades são a montante e a jusante uma da outra. O cliente não pode obter dados ou atualizações se o servidor estiver inoperante e o servidor não tiver instruções para executar se não houver um cliente.

— Delioth

1

@Delioth discorda. O back-end pode ter muitos clientes, mas não depende de nenhum deles. Se você removesse um cliente, o back-end ainda funcionaria. O cliente pode ter muitos back-end que poderia usar. Se um back-end for removido sem que o cliente saiba, o cliente não poderá funcionar corretamente. O cliente está a jusante. O back-end é upstream.

— Gaz_Edge

1

Isso pode ser mais um problema lingüístico e geográfico do que técnico.

O pedido de informações sobe a montante. Vem de um sistema a jusante.
A resposta ao pedido de informação (a informação solicitada) vai a jusante e é enviada por um sistema a montante.

Não há diferença entre a visualização clássica da IBM e o uso dos termos pela comunidade da web de hoje.

Um provedor de serviços (servidor) estará localizado a montante em comparação com um consumidor de serviço e envia informações a jusante para o consumidor.
Um consumidor de serviço (cliente) será localizado a jusante em comparação com o provedor de serviços e envia solicitações a montante para o provedor.

Teoricamente, os papéis dos sistemas físicos podem mudar instantaneamente, assim como a direção do fluxo entre esses sistemas. Em uma rede ponto a ponto, esse pode ser o caso.

Os termos upload e download são termos centrados no cliente. Da perspectiva do cliente, uma solicitação é carregada e uma resposta é baixada, o que é consistente com a metáfora do fluxo.

— Martin Maat
fonte