1. Histórico de migração do projeto
1.1 Por que você quer lançar o "Tai Sui"?
No momento, o ambiente de teste da empresa, o ambiente UAT e o ambiente de produção usam o K8s para manutenção e gerenciamento. A maioria dos projetos foram armazenados em contêineres e estão funcionando perfeitamente on-line por um longo tempo. Depois de concluir a conteinerização de projetos grandes e pequenos, as ferramentas de lançamento de teste, UAT, ambiente de produção e processo CICD gradualmente perceberam o gerenciamento unificado e desenvolveram uma plataforma de revisão de versão interna baseada em k8s, e ao mesmo tempo conectada Ferramentas de gerenciamento de projetos como Jira.
Quando a plataforma de autopesquisa é lançada, ela pode associar automaticamente o andamento do desenvolvimento do projeto e a versão de lançamento. O mais importante é que ela pode controlar a autoridade de lançamento, ferramentas de lançamento unificadas e modo de lançamento e oferece suporte à liberação de vários projetos com um clique Os vários módulos do, também incluem a reversão unificada de aplicativos com falha e a reversão de aplicativos individuais.
Como o projeto está usando o GitRunner para o lançamento desde seu início e com base na implantação da máquina virtual, ele não foi integrado à plataforma de revisão de lançamento, mas porque o projeto é mais importante e envolve mais serviços e máquinas, deve ser O projeto é conteinerizado e as ferramentas de lançamento são unificadas para melhor se adaptar ao ambiente da empresa e responder melhor ao desenvolvimento da próxima geração de computação em nuvem.
1.2 Por que devemos abandonar o Git Runner?
Primeiro, vamos dar uma olhada na página de lançamento do Git Runner. Embora pareça simples e refrescante, é inevitável que encontraremos alguns problemas.
1.2.1 Problemas de desenvolvimento paralelo de vários ramos
Quando vários branches são desenvolvidos em paralelo ou há muitos branches que podem ser liberados para o ambiente de produção, é fácil cometer erros no estágio de implantação manual ou olhar para o serial, é claro, essa probabilidade é muito pequena.
Mas podemos ver outro problema. Cada confirmação ou mesclagem acionará uma compilação. Quando usamos o fluxo de ramificação do Git Flow, pode haver muitas ramificações que estão em desenvolvimento paralelo, teste paralelo e construção paralela ao mesmo tempo. Se o Git Runner for baseado em virtual Se for criado pela máquina, é muito provável que haja uma situação de fila.Claro, esse problema de fila também pode ser resolvido.
1.2.2 Problemas de manutenção de configuração de multi-microsserviço
Em segundo lugar, se um projeto for ligeiramente maior, não é muito conveniente mantê-lo. Por exemplo, este projeto a ser migrado, um front-end e mais de 20 aplicativos de negócios, além de cerca de 30 serviços de Zuul, ConfigServer e Eureka, cada serviço corresponde a um warehouse Git e, em seguida, cada serviço está no ramo de desenvolvimento ao mesmo tempo. Existem muitos, se você deseja atualizar o script GitLab CI ou a máquina de microsserviço e deseja adicionar nós, será um trabalho tedioso.
1.2.3 Problemas de segurança
Por fim, há um problema de segurança: os scripts de CI do GitLab geralmente são integrados ao repositório de código, o que significa que qualquer pessoa com permissões Push ou Merge pode modificar o script de CI à vontade, o que levará a resultados inesperados. Ao mesmo tempo, também ameaçará a segurança do servidor e da empresa. Para o lançamento, qualquer desenvolvedor pode clicar no botão de liberação. Isso sempre pode representar um risco à segurança.
Mas isso não significa que o Git Runner seja uma ferramenta não recomendada. A nova versão do Auto DevOps integrado do GitLab e do Kubernetes integrado ainda são muito populares. Mas talvez para nós, não existam muitos projetos que usam Git Runner para lançamento, então queremos unificar ferramentas de lançamento e gerenciamento unificado de scripts de CI, então outras ferramentas de CI podem ser mais adequadas.
1.3 Por que a conteinerização?
1.3.1 Conflito de porta
Antes da conteinerização, este projeto era implantado usando máquinas virtuais. Cada máquina virtual iniciava dois ou três microsserviços. Isso encontrou um problema, ou seja, o problema de conflitos de porta. Ao adicionar novos aplicativos ao projeto, você precisa considerar o servidor. Para o problema de conflitos de portas, devemos também considerar que as portas de cada microsserviço não podem ser as mesmas, porque ao usar máquinas virtuais para implantar aplicativos, pode haver falhas no nó da máquina que exigem a migração manual de aplicativos. Se algumas portas de microsserviço forem iguais, o processo de migração Pode estar bloqueado.
Além disso, quando um projeto tem poucos aplicativos, pode não haver problemas em manter a porta.Assim como neste projeto, mais de 30 microsserviços estão envolvidos, o que pode se tornar uma coisa muito dolorosa. Ao usar a implantação de contêiner, cada contêiner é isolado um do outro, todos os aplicativos podem usar a mesma porta e não há necessidade de se preocupar com a porta.
1.3.2 Problemas de saúde do programa
A maioria das pessoas que usaram programas Java encontrou animação suspensa de programa. Por exemplo, a porta está claramente aberta, mas a solicitação não foi processada. Este é um fenômeno de animação suspensa de programa. Quando implantamos com máquinas virtuais, muitas vezes não conseguimos fazer uma boa verificação de integridade. Talvez a verificação de integridade no nível da interface não seja feita na máquina virtual. Isso causará o problema de que o programa congela e não pode ser tratado automaticamente, e está na máquina virtual. Fazer algumas verificações de integridade no nível da interface e operações de processamento não é uma coisa simples, mas também enfadonha, especialmente quando há muitos microsserviços para um projeto e a interface de verificação de integridade é inconsistente.
Mas no k8s, os probes integrados Read e Live são extremamente simples de lidar com os problemas acima. Conforme mostrado na figura, podemos ver que três métodos de verificações de integridade são atualmente suportados:
- tcpSocket : verificação de integridade da porta
- exec : de acordo com o valor de retorno do comando especificado
- httpGet : verificação de integridade no nível da interface
Ao mesmo tempo, a flexibilidade dessas verificações de integridade também é muito alta. Você pode personalizar o intervalo de verificação, o número de erros, o número de sucessos e os parâmetros de verificação do host, e a verificação de integridade no nível da interface httpGet mencionada acima também oferece suporte a nomes de host personalizados, cabeçalhos de solicitação e caminhos de verificação. Assim como a configuração de HTTP ou HTTPS, você pode ver que usar a verificação de saúde que vem com o k8s pode nos poupar muito trabalho e não precisar mais manter muitos scripts irritantes.
1.3.3 Problemas de recuperação de falhas
Ao implementar aplicativos usando máquinas virtuais, às vezes você pode encontrar falhas de host, aplicativos de nó único não podem ser usados ou aplicativos de vários nós implementados devido à indisponibilidade de outras cópias, resultando em alta pressão e atrasos no serviço. É precisamente que o host não consegue se recuperar rapidamente.Neste momento, pode ser necessário adicionar nós manualmente ou adicionar novos servidores para resolver esse tipo de problema.Este processo pode ser muito longo e talvez doloroso. Porque você precisa preparar o ambiente dependente antes de implantar seu próprio aplicativo e, às vezes, pode ser necessário alterar o script de CI. . .
Ao usar a orquestração k8s, não precisamos nos preocupar com esses problemas. Todos os mecanismos de recuperação de falhas e tolerância a desastres são feitos pelo poderoso k8s. Você pode ir tomar uma xícara de café ou apenas ligar o computador para resolver o problema, tudo foi restaurado. Como sempre.
1.3.4 Outros problemas menores
Claro, a conveniência e os problemas que o k8s traz para nós são muito mais do que aqueles mencionados acima. O espelhamento de contêiner nos ajuda a resolver o problema de depender do ambiente. A orquestração de serviço nos ajuda a resolver o problema de tolerância a falhas. Podemos usar o gerenciamento de pacotes k8s. A ferramenta cria um novo ambiente com um clique. Podemos usar a descoberta de serviço k8s para que os desenvolvedores não precisem mais prestar atenção ao desenvolvimento da parte da rede. Podemos usar o controle de permissão k8s para que o pessoal de operação e manutenção não precise mais gerenciar as permissões de cada servidor. Você pode usar a poderosa estratégia de publicação de aplicativos do k8s para que não precisemos pensar muito sobre como obter publicação de aplicativos com tempo de inatividade zero e reversão de aplicativos, etc., todas essas conveniências estão mudando silenciosamente nosso comportamento.
2. Plano de migração
2.1 Migração azul-verde
Primeiro, olhe para a arquitetura antes da migração
Como a maioria das arquiteturas SpringCloud, NodeJS é usado como front-end, Eureka é usado para descoberta de serviço, Zuul é usado para distribuição de roteamento e ConfigServer é usado como centro de configuração. Essa arquitetura também é a arquitetura mais comum do SpringCloud na empresa. Ela não usa mais componentes adicionais, então quando migramos pela primeira vez, não pensamos muito. Ainda seguimos o plano usado na migração de outros projetos, ou seja, criar um novo no k8s Um conjunto de ambiente (o middleware não está envolvido nesta migração), ou seja, um ambiente em contêiner, configure um mesmo nome de domínio e, em seguida, adicione resolução de hosts para teste.Se não houver problema, troque o nome de domínio diretamente para concluir a migração. Este método é o método mais simples e mais comumente usado, semelhante à implantação azul-verde da versão do programa. Neste momento, um novo conjunto de ambiente correspondente ao diagrama de arquitetura em k8s é o seguinte:
Durante o teste, este projeto colocou em paralelo dois conjuntos de ambientes, um ambiente de máquina virtual e um ambiente de contêiner. O ambiente de contêiner só recebe tráfego de testadores. Os dois ambientes estão conectados ao mesmo conjunto de serviços de middleware, porque outros projetos são grandes Parte dele também foi migrada desta forma, e o projeto passou pelo mesmo processo no ambiente de teste sem problemas, portanto acredita-se que desta forma não causará problemas neste projeto. No entanto, a realidade é sempre diferente da expectativa. Durante o processo de teste, os dois conjuntos de ambientes coexistiram, o que causou alguns problemas de dados de produção. Como o ambiente do contêiner não foi testado quanto à integridade e o nome de domínio não foi forçado a mudar, todos foram desligados em uma emergência. O problema do contêiner foi restaurado. Devido a limitações de tempo, não investigamos o problema com cuidado, mas corrigimos alguns dos dados. Mais tarde, pensamos que isso poderia ser causado pela inconsistência entre alguns branches mestre de microsserviço e o código de produção durante o processo de migração. Claro, pode não ser tão simples. Para evitar a recorrência de tais problemas, o plano de migração só pode ser modificado.
2.2 Migração em escala de cinza
Devido a alguns problemas com o plano de migração acima, um plano foi redefinido, o que foi um pouco mais problemático do que da última vez, usando microsserviços para migrar para k8s, semelhante ao lançamento em tons de cinza de lançamentos de aplicativos.
Quando um único aplicativo é migrado, é necessário garantir que o código do ambiente do container e do ambiente da máquina virtual sejam consistentes.Durante a migração, os microsserviços adotam o método de registro de nomes de domínio. Ou seja, cada microsserviço é configurado com um nome de domínio interno e registrado no Eureka através do nome de domínio, ao invés de usar o IP e a porta do contêiner para registrar (porque o IP interno do k8s e a máquina virtual não estão conectados), o ambiente neste momento é mostrado na figura abaixo :
Neste momento, há um nome de domínio service-c.interservice.k8s apontando para ServiceC e, em seguida, quando ServiceC se registra no Eureka, ele modifica seu endereço para este nome de domínio (o padrão é a porta IP + do host) e, em seguida, outros aplicativos chamam ServiceC através deste endereço. Quando o ServiceC testa Depois que não houver problema, o ServiceC na máquina virtual ficará offline e a arquitetura final será mostrada na figura:
Além de Zuul, interface de usuário front-end e Eureka, outros serviços são migrados para k8s em escala de cinza, que é mais complicado do que a forma azul-verde. É necessário criar um serviço e nome de domínio separados para cada microsserviço e excluí-lo após a conclusão da migração. Após essa etapa, todos os serviços, exceto Eureka, foram implantados no k8s e a migração do Eureka envolve mais detalhes.
2.3 Migração Eureka
Após esta etapa, não há outros problemas com o acesso ao serviço. Outros serviços além do Eureka foram implantados no k8s e o projeto de migração de transição do Eureka pode ter mais problemas. Porque não podemos implantar diretamente um conjunto de clusters Eureka altamente disponíveis em k8s e, em seguida, alterar diretamente o endereço de registro de microsserviço no ConfigServer para o endereço Eureka em k8s, porque neste momento os dois clusters Eureka são zonas independentes e as informações de registro não são Não será compartilhado, isso vai perder as informações cadastrais no processo de alteração da configuração.Neste momento, o diagrama da arquitetura pode aparecer da seguinte forma:
Ou seja, no processo de substituição da configuração, pode haver ServiceA registrado para o Eureka anterior, e ServiceB registrado para o Eureka em k8s, o que fará com que o ServiceA não encontre o ServiceB e vice-versa.
Portanto, depois de construir um cluster Eureka em k8s, você precisa configurar um nome de domínio temporário para cada instância Eureka e, em seguida, alterar a configuração da zona do cluster Eureka anterior e do cluster Eureka em k8s, de modo que Eureka em k8s e Eureka na máquina virtual formem um novo Desta forma, as informações de registro serão sincronizadas. Independentemente de estar registrado no Eureka, o serviço não será encontrado. O diagrama da arquitetura neste momento é o seguinte (neste momento, todos os serviços ainda estão registrados no cluster Eureka original):
A próxima coisa a fazer é alterar a configuração do microsserviço. Existem três lugares para alterar neste momento:
- O endereço do microsserviço registrado no Eureka é mais IP de contêiner e porta, e o registro de nome de domínio não é mais usado porque os microsserviços já estão em k8s e podem ser conectados diretamente por meio do IP do Pod interno;
- Altere o endereço Eureka registrado pelo serviço para o endereço de serviço de k8s Eureka. Eureka usa StatefulSet para implantar e você pode se conectar diretamente por meio de eureka-0/1 / 2.eureka-headless-svc;
- Após a migração de todos os microsserviços, altere a zona do cluster k8s Eureka para: eureka-0/1 / 2.eureka-headless-svc e exclua o serviço e os nomes de domínio de outros microsserviços.
O diagrama final da arquitetura é o seguinte:
3. Resumo
Para garantir a disponibilidade do serviço, adotamos com relutância o método da escala de cinza para migração, que é muito mais problemático do que o método azul-verde, e há muitos problemas a serem considerados. Partindo do pressuposto de que não há problemas com o programa, recomenda-se a utilização do método azul-verde para a migração, pois além de haver menos problemas, a migração também é mais conveniente e rápida. Obviamente, o método da escala de cinza pode ser mais seguro para projetos de grande escala ou projetos que não podem ser interrompidos, porque alternar tudo de uma vez pode perder áreas que precisam ser testadas. Claro, não importa de que maneira, a conteinerização de aplicativos e a migração para o Kubernetes são coisas mais importantes. Afinal, a computação em nuvem é o futuro e o Kubernetes é o futuro da computação em nuvem.
Link original: https://www.cnblogs.com/dukuan/p/13285941.html