Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Divisão de serviço:

1. Princípio de responsabilidade única: Em uma arquitetura de microsserviços, um serviço deve ser responsável apenas por uma função ou área de negócios. Cada serviço deve ter definições e limites claros e focar apenas em sua área de negócios específica.

2. Autonomia de serviço: Autonomia de serviço significa que cada microsserviço deve ter um alto grau de autonomia, ou seja, cada serviço deve ser capaz de ser desenvolvido de forma independente, testado de forma independente, construído de forma independente, implantado de forma independente e operado de forma independente.

3. Dependência unilateral

Deve haver dependência unilateral entre microsserviços, e dependências circulares e bidirecionais são estritamente proibidas.

Dependência circular: A->B->C->A

Dependência bidirecional: A->B,B->A

Exemplo:

1. Lista de pedidos

2. Lista de produtos

Serviço de pedido: forneça o ID do pedido e obtenha detalhes do pedido

Serviço do produto: retornar detalhes do produto com base no ID do produto

Ao consultar informações do pedido com base em um pedido, obtenha detalhes do produto com base no ID do produto no pedido.

concluir:

Ideia de implementação: o serviço de serviço de pedido envia uma solicitação http para o serviço de serviço de produto, mescla o resultado retornado com o resultado do pedido e o retorna ao chamador

Método de implementação: usando RestTemplate fornecido pelo Spring

1. Defina RestTemplate

@Configuração

classe pública BeanConfig{
@Feijão

público RestTemplate restTemplate{

retornar novo RestTemplate();

      }

}

2. Use restTemplate no controlador de pedido

Modelo de descanso:

Descansar(Réapresentacional State Eranfer) representa a transferência de status de recursos da camada

Recursos: Dados na Internet, como fotos, vídeos, textos, etc. são todos recursos

Camada de apresentação: a forma de representação dos recursos (por exemplo, a forma de representação do texto é txt, a forma de representação da imagem é jpg e alguns recursos são expressos em json, xml ou binário, etc.)

Transferência de estado: Quando acessamos recursos através da rede e realizamos operações sobre recursos (adicionar, modificar, excluir, etc.), isso fará com que o estado do recurso mude: REST descreve uma forma de interação entre Cliente e Servidor. na rede. REST em si não é prático, usando como projetar API RESTful (interface de rede estilo REST).

O estilo repousante geralmente possui as seguintes características:

1. Recursos

2. Interface unificada: Para operações sobre recursos, como obtenção, criação, modificação e exclusão, essas janelas correspondem aos métodos GET, POST, PUT e DELETE fornecidos pelo protocolo http. , a partir da interface Você só pode localizar seus recursos, mas não pode saber quais operações ele executou especificamente. Você precisa saber especificamente quais operações ocorreram e julgar pelo tipo de método de solicitação http (por exemplo: a mesma URL: GET/). blog/{blogId }: consulta blog DELETE/blog/{blogId} Excluir blog)

Desvantagens da API RESTful:

1. O método de operação é complicado. A API RESTful geralmente distingue as ações de operação nos recursos de acordo com GET, POST, PUT e DELETE.
O método HTTP não pode ser observado diretamente e precisa ser observado por meio de ferramentas como captura de pacotes. Será mais intuitivo se a ação for colocada na URL.
É mais propício à compreensão e comunicação da equipe.
2. Alguns navegadores não são muito amigáveis ​​no suporte a solicitações diferentes de GET e POST e exigem processamento adicional.
3. Ênfase excessiva nos recursos No entanto, as necessidades reais do negócio podem ser mais complexas e não podem ser satisfeitas simplesmente adicionando, eliminando, modificando e pesquisando.
A API RESTful aumentará a dificuldade e o custo de desenvolvimento.

Há um problema com o projeto
1. Ao ligar remotamente, o IP e o número da porta do URL são codificados (http://127.0.0.1:9090/product/).
código
2. Como o chamador pode não confiar no IP da operadora?
3. Implantação de várias máquinas, como compartilhar a pressão?
4. Ao fazer chamadas remotas, é muito fácil escrever o URL errado e a capacidade de reutilização não é alta. Como implementar chamadas remotas com elegância?
5. Todos os serviços podem chamar esta interface. Existe algum risco?