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
fonte
Respostas:
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.
fonte
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
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:
Eu ficaria interessado em ver nos votos, qual é o uso mais comum!
fonte
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.
fonte
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.
fonte