Microservices Engine:Service governance quick start (Java)

Visão geral da demonstração

A demonstração utiliza o Nacos como registro e contém dois gateways: SpringCloudGateway e Zuul. Recomenda-se o SpringCloudGateway para novos projetos; o Zuul está disponível para compatibilidade com sistemas legados. É possível ativar ou desativar qualquer um dos gateways. O rastro de chamada padrão é A->B->C, e tanto A quanto C possuem versões canary. Obtenha o código da aplicação no repositório de código.

Baixe o pacote Helm da demonstração

Baixe o pacote Helm da demonstração. O pacote Helm e as imagens são atualizados periodicamente.

Na página Releases do repositório GitHub aliyun/alibabacloud-microservice-demo, localize a versão mais recente (por exemplo, MSE Simple Demo V3.1.0). Na seção Assets, clique em mse-simple-demo.zip para baixar o arquivo.

Implante usando o CloudShell no ACK

Implante o mse-simple-demo usando o CloudShell no ACK

1. Compacte os arquivos do mse-simple-demo.

2. Faça login no console de gerenciamento de clusters ACK. Selecione o cluster desejado. Na página Cluster information, clique em Manage Cluster with Workbench.

3. Carregue o pacote Helm.

   Na barra de ferramentas do CloudShell, clique no ícone de gerenciamento de arquivos e selecione Upload no menu exibido.

4. Execute o comando unzip mse-simple-demo.zip para descompactar a demonstração.

5. Execute o comando kubectl create namespace mse-demo para criar um namespace, correspondente a --namespace.

helm upgrade mse-simple-demo mse-simple-demo \
--set mse.namespace=mse-demo \
--set gateway.springcloud=true  \
--install \
--namespace mse-demo \
--values mse-simple-demo/values.yaml

Canary release ponta a ponta

Caminho de navegação: faça login no console do MSE Microservices Governance e escolha Microservices Governance > End-to-end Canary Release na barra de navegação à esquerda.

Crie um grupo de lanes

Na página End-to-end Canary Release:

1. Clique em Create Lane Group and Lane. Se já existir um grupo de lanes no namespace de microsserviço selecionado, clique em + Create Lane Group.

2. Na página Create Lane Group, defina as configurações abaixo e clique em OK.

   • Lane Group Name: insira um nome, por exemplo, demo.

   • Entry Type: selecione Java Service Gateway. Também é possível escolher Cloud Native API Gateway, MSE cloud-native gateway ou outro gateway.

   • Lane Group Traffic Entry: selecione a aplicação de entrada de tráfego, por exemplo, spring-cloud-gateway.

   • Applications in Lane Group: selecione as aplicações envolvidas no grupo de lanes, por exemplo, spring-cloud-a, spring-cloud-b e spring-cloud-c.

Crie uma lane

Na parte inferior da página End-to-end Canary Release:

1. Clique em Create First Split Lane. Caso já exista uma lane no namespace de microsserviço selecionado, clique em Create Lane.

2. No painel Create Lane, configure as definições da lane de tráfego e clique em OK.

   • Lane Name e Lane Tag: defina ambos como gray.

   • Confirm Matching Relationship: inclua spring-cloud-a e spring-cloud-c.

   • Lane Status: Enabled.

   • Grayscale Mode: selecione By Content.

   • Grayscale Condition: selecione All of the following conditions are met e adicione uma linha de parâmetro: defina Parameter Type como Parameter, Parameter como name, Condition como == e Value como xiaoming.

     Após a criação da lane, a seção Traffic Allocation da página do product do grupo de lanes exibe as informações da lane, incluindo o nome (gray), a tag, a lista de aplicações associadas (spring-cloud-a e spring-cloud-c), a condição de correspondência (param:[name]==xiaoming) e o status de ativação. A área de monitoramento de QPS acima mostra o número de requisições e as linhas de tendência para o tráfego baseline e o tráfego canary.

Encaminhe requisições regulares para a versão baseline

Para encontrar o endereço SLB do gateway:

1. Faça login no console do Container Service for Kubernetes (ACK).

2. Acesse a página do product do cluster criado.

3. No painel de navegação à esquerda, escolha Workload > Stateless.

4. Na página Deployments, clique em spring-cloud-gateway.

5. Na página de detalhes, clique em Access Method.

6. Na coluna External Endpoint da seção Service, anote o endereço IP e a porta.

   Em um navegador, acesse o endereço SLB do gateway e envie as seguintes requisições.

Insira /A/a na caixa de entrada e clique em Start Calling. O rastro de chamada retornado é A[192.168.100.48] [config=base] -> B -> C[192.168.100.235], onde o nó B alterna entre as instâncias 192.168.100.51 e 192.168.100.53. Isso indica que requisições regulares usam roteamento baseado em tags com a tag config=base, e o tráfego é distribuído uniformemente entre as duas instâncias baseline de B.

Solicite o caminho /A/dubbo sem uma tag canary (param:null) e clique em Start Calling. Os logs de rastro de chamada mostram que a maioria das requisições é encaminhada para nós baseline: A[192.168.100.48] -> B[192.168.100.53] -> C[192.168.100.235]. Algumas requisições passam por B[192.168.100.51], e uma requisição é roteada para o nó canary Cgray[192.168.100.12].

Encaminhe requisições canary para a versão canary

Enter the URL: /A/a?name=xiaoming
2025-3-4 16:22:19 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.53] -> Cgray[192.168.100.12]
2025-3-4 16:22:20 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.53] -> Cgray[192.168.100.12]
2025-3-4 16:22:20 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.53] -> Cgray[192.168.100.12]
2025-3-4 16:22:21 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.51] -> Cgray[192.168.100.12]
2025-3-4 16:22:21 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.53] -> Cgray[192.168.100.12]
2025-3-4 16:22:22 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.51] -> Cgray[192.168.100.12]
2025-3-4 16:22:22 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.51] -> Cgray[192.168.100.12]
2025-3-4 16:22:23 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.51] -> Cgray[192.168.100.12]
2025-3-4 16:22:23 Returned Agray[192.168.100.52] [config=base] -> B[192.168.100.53] -> Cgray[192.168.100.12]

Acesse a operação /A/dubbo?name=xiaoming. O log de rastro de chamada canary é o seguinte:

2025-3-4 16:23:59 Returned Agray[192.168.100.52] -> B[192.168.100.51] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:23:59 Returned Agray[192.168.100.52] -> B[192.168.100.51] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:24:0 Returned Agray[192.168.100.52] -> B[192.168.100.53] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:24:1 Returned Agray[192.168.100.52] -> B[192.168.100.53] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:24:1 Returned Agray[192.168.100.52] -> B[192.168.100.51] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:24:2 Returned Agray[192.168.100.52] -> B[192.168.100.53] param:null -> Cgray[192.168.100.12] param:null
2025-3-4 16:24:2 Returned Agray[192.168.100.52] -> B[192.168.100.51] param:null -> Cgray[192.168.100.12] param:null

Para mais informações, consulte Implement end-to-end canary release based on a self-managed Spring Cloud Gateway or Zuul gateway.

Inicialização e encerramento graceful

Caminho de navegação: faça login no console do MSE Microservices Governance e escolha Microservices Governance > Application Governance na barra de navegação à esquerda. Na página Applications, clique na aplicação que deseja gerenciar para acessar a página de visão geral da aplicação.

Configure a inicialização e o encerramento graceful

Na barra de navegação à esquerda da página de visão geral da aplicação, escolha Traffic Governance. Alguns recursos de inicialização e encerramento graceful estão disponíveis por padrão. Para utilizar todas as funcionalidades, ative e configure a inicialização e o encerramento graceful no console.

Na página Traffic Governance, clique na aba Graceful Start and Shutdown. Na seção Configuration Information, visualize o status de ativação de Graceful Start e Graceful Shutdown, além da configuração de Proactive Notification. Clique em Modify à direita para ajustar as definições.

Visualize eventos e processos

A parte superior da página Graceful Start and Shutdown exibe as configurações atuais: status de ativação da inicialização graceful, duração do registro atrasado, duração do aquecimento com pouco tráfego, status de ativação do encerramento graceful e status da notificação proativa. Na aba Start/Shutdown Events, a lista de eventos à esquerda mostra cada registro, incluindo horário, IP-PID do nó, nome do evento (encerramento de aplicação de microsserviço, registro de microsserviço, início de aquecimento de microsserviço ou encerramento graceful de microsserviço), tipo de framework e detalhes do evento. Clique em um evento, como encerramento graceful de microsserviço, para exibir o gráfico de linhas de QPS do nó correspondente à direita. Nele, é possível observar o tráfego diminuindo suavemente do nível normal até zero quando o service for retirado de operação.

Para mais informações, consulte Graceful Start and Shutdown.

Regras de limitação de taxa

Caminho de navegação: faça login no console do MSE Microservices Governance e escolha Microservices Governance > Application Governance na barra de navegação à esquerda. Na página Applications, clique na aplicação que deseja gerenciar para acessar a página de visão geral da aplicação.

Configure uma regra de limitação de taxa

Na barra de navegação à esquerda da página de visão geral da aplicação, escolha Traffic Governance. Na página Traffic Governance, escolha Traffic Protection > Interface Flow Control e clique em Add Rules.

Na etapa Configure Protection Rule do assistente Add Throttling Protection Rule, a barra de informações no topo exibe o nome da API, o tipo de proteção e o tipo de API. Defina as seguintes configurações:

• Enable: ative a chave para habilitar a regra.

• Single-instance QPS Threshold: defina o limite máximo de requisições por segundo, por exemplo, 5.

• Throttling Effect: selecione Fail-fast ou Wait in Queue. A opção Fail-fast retorna a mensagem padrão de limitação de taxa para tráfego que excede o limiar.

  Clique em Show Advanced Options para expandir mais configurações. Após concluir as definições, clique em Next para avançar para a etapa de configuração do comportamento de proteção.

Verifique o efeito da limitação de taxa

Em um navegador, acesse o endereço SLB do gateway e envie a seguinte requisição.

Defina a URI da requisição como /A/flow e clique em Start Calling. A maioria das requisições retorna Blocked by Sentinel (flow limiting), e apenas algumas passam e retornam o rastro de invocação do service Tracing Analysis: A[192.168.100.45][config=base] -> B[192.168.100.53] -> C[192.168.100.235].

A aplicação A possui um único nó e seu limiar de limitação de taxa por instância é 5; portanto, o QPS aprovado estabiliza em 5.

Para mais informações, consulte What is traffic protection?.

Integração de aplicações

Nesta demonstração, o rótulo msePilotAutoEnable: "on" é adicionado explicitamente ao Deployment de cada aplicação que você deseja conectar. Em produção, é possível ativar o Microservices Governance para um namespace de um cluster Kubernetes no centro de operações do MSE para conectar aplicações em massa.

Para mais informações, consulte Connect Java applications in ACK and ACS clusters to MSE Microservices Governance.

Requisições de exemplo

As requisições de exemplo abaixo utilizam localhost:20000 como endereço do gateway. Substitua localhost:20000 pelo endereço SLB e porta do gateway obtidos anteriormente. Também é possível enviar essas requisições de dentro do pod do gateway.

  # Regular request
  http://localhost:20000/A/a
  A[10.0.0.47][config=base] -> B[10.0.0.39] -> C[10.0.0.48]
  # Canary request
  http://localhost:20000/A/a?name=xiaoming
  Agray[10.0.0.41][config=base] -> B[10.0.0.55] -> Cgray[10.0.0.30]
  # Regular request (Feign)
  http://localhost:20000/A/aByFeign
  A[10.0.0.47][config=base] -> B[10.0.0.55]
  # Regular request (A sends requests directly to C, and then A requests B which requests C)
  http://localhost:20000/A/a2bc
  A[10.0.0.47][config=base] -> C[10.0.0.48]
  A[10.0.0.47][config=base] -> B[10.0.0.55] -> C[10.0.0.49]
  # Dubbo request
  http://localhost:20000/A/dubbo
  A[10.0.0.44] -> B[10.0.0.39]name:A -> C[10.0.0.49] params:A
  # Dubbo canary request
  http://localhost:20000/A/dubbo?name=xiaoming
  Agray[10.0.0.41] -> B[10.0.0.39]name:A -> Cgray[10.0.0.30] params:A
  # Requests for throttling tests
  http://localhost:20000/A/flow
  A[10.0.0.17][config=base] -> B[10.0.0.39] sleepTime:9 -> C[10.0.0.48] sleepTime:8 code:200
  http://localhost:20000/A/dubbo-flow
  A[10.0.0.17] -> B[10.0.0.55]name:A -> C[10.0.0.48] params:A
  http://localhost:20000/A/isolate
  A[10.0.0.42][config=base] -> B[10.0.0.55] sleepTime:504 -> C[10.0.0.48] sleepTime:8 code:200
  http://localhost:20000/A/dubbo-isolate
  A[10.0.0.17] -> B[10.0.0.55]name:isolate -> C[10.0.0.49] params:isolate
  http://localhost:20000/A/params/hot
  A[10.0.0.17][config=base] params:hot -> B[10.0.0.55] sleepTime:5 params:hot -> C[10.0.0.49] sleepTime:6 params:hot code:200
  http://localhost:20000/A/dubbo-params/hot
  A[10.0.0.17] params:hot -> B[10.0.0.55]name:hot -> C[10.0.0.49] params:hot
  # Database request
  http://localhost:20000/A/sql?command=query&id=1
  A[10.0.0.44][config=base] -> B[10.0.0.39] result:{"age":1,"email":"emailUpdate%40demo.com","id":1,"name":"name1Update"}
  http://localhost:20000/A/sql?command=update&name=name1Update&email=emailUpd***@demo.com&age=1&id=1
  A[10.0.0.44][config=base] -> B[10.0.0.55] result:true
  # Spring Boot request
  http://localhost:20000/spring_boot

Configure o auto scaling para a demonstração

Se a inicialização e o encerramento graceful não foram ativados durante a implantação inicial, mas você deseja observá-los posteriormente, ative-os da seguinte maneira.

• Para usar os recursos detalhados de inicialização e encerramento graceful, faça login no console do Container Service for Kubernetes (ACK), acesse a página de informações do cluster, escolha Operations Management > Add-ons na barra de navegação à esquerda, pesquise por cronhpa na caixa de pesquisa e clique em Install.

• Utilize o YAML abaixo para criar uma tarefa de dimensionamento agendado. O campo namespace deve corresponder ao namespace do Kubernetes selecionado durante a instalação do pacote Helm.

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: CronHorizontalPodAutoscaler
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: cronhpa-deployment-spring-cloud-b
  namespace: mse-demo # Note: the namespace field must be the same as the k8s namespace selected during helm install
spec:
  jobs:
  - name: Scale-out
    schedule: 0 0/6 * * * *
    targetSize: 6
  - name: Scale-in
    schedule: 0 5/6 * * * *
    targetSize: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: spring-cloud-b

Configuração de requisições automáticas do gateway

O envio automático de várias requisições vem ativado por padrão. Para alterar a configuração, faça login no console do Container Service for Kubernetes (ACK), acesse a página de informações do cluster e escolha Workload > Stateless no painel de navegação. Na página Deployments, clique na aplicação spring-cloud-gateway. Na página do product, clique em Edit no canto superior direito. Em seguida, configure as seguintes variáveis de ambiente para controlar o envio automático dos diversos tipos de requisição.