À medida que a tecnologia nativa da nuvem se desenvolve e as tecnologias relacionadas são cada vez mais utilizadas nas práticas de produção das empresas, existem duas tendências irreversíveis:
1. O número de microsserviços está aumentando. Acontece que serviços únicos gigantes são constantemente desmantelados em microsserviços. Ao mesmo tempo que facilita a reutilização de funções e a iteração eficiente, também traz muitos desafios à operação e manutenção:
Questão de custos: Como deve funcionar o ciclo de vida dos serviços e as dependências de recursos básicos? Como prevenir a existência de recursos órfãos e evitar o desperdício de recursos? Como melhorar a utilização de recursos?
Questão de eficiência: como implantar serviços unitizados de forma rápida e eficiente? Classificação de serviços e construção de lotes
Atribuição de responsabilidades: Perante um aumento de ordem de grandeza de serviços e recursos, como encontrar o responsável e a equipa a que pertence? (Como encontrar a pessoa certa para tratar e acompanhar quando há um problema? Como atribuir o custo à equipe certa?)
Nota: Este artigo concentra-se principalmente no gerenciamento de infraestrutura e na operação e manutenção de serviços e dependências de serviço, e não se concentra no gerenciamento de dependências upstream e downstream.As dependências upstream e downstream podem ser resolvidas por meio de governança de serviço (topologia de dependência), etc.
2. Os serviços estão se tornando cada vez mais complexos, dependendo de infraestruturas mais diversificadas (como salas de computadores autoconstruídas, salas de computadores em nuvem, salas de computadores híbridas, etc.) e contando cada vez mais com middleware (como sistemas autoconstruídos). dentro de empresas, grandes fornecedores de nuvem, etc.) serviços, etc.), os usuários precisam perceber as diferenças nessas infraestruturas?
Se for percebido que o custo de utilização do usuário aumentará, como as normas irão regular isso?
Como podem estas diferenças subjacentes ser mascaradas se não forem percebidas?
Soluções
Para resolver os dois problemas acima, devemos primeiro descobrir qual é a causa raiz dos problemas acima.
Problema 1: Fragmentação da informação, redundância e falta de atualização da informação
Exemplo 1:
Atualmente, Didi concentra-se internamente nos recursos de computação de um serviço (recursos de nuvem elástica) e nos atributos relacionados à operação e manutenção, como observação e alarme dos nós da árvore de serviço correspondentes. Os atributos acima estão todos relacionados através dos nós da árvore de serviço. Os recursos de armazenamento são not Não há meta-informação de associação correspondente (existe apenas na configuração do código). Não há uma perspectiva clara sobre as dependências completas que permitem que um serviço opere como um todo. Se quiser entender as dependências completas, você precisa do SRE para classificar os atributos relevantes de operação e manutenção, e do líder de serviço para verificar o código para resolver as dependências de middleware subjacentes.
Solução: Abstrair e associar recursos computacionais, recursos de armazenamento e algumas configurações parciais de operação e manutenção como um todo de acordo com a dimensão do serviço, para que o serviço tenha uma perspectiva global. Ao mesmo tempo, comparado a um único serviço, o todo pode ser melhor gerenciar o ciclo de vida e evitar recursos órfãos. Prevenir o desperdício de recursos. Consulte o exemplo de aplicação na figura para ver todos os recursos IaaS e recursos PaaS dos quais uma aplicação depende.
Ao mesmo tempo, observando o uso geral de recursos do serviço, problemas de baixa utilização de recursos ou recursos insuficientes podem ser descobertos em tempo hábil e medidas responsivas podem ser tomadas para otimização.
Abstração de composição de aplicativo
Exemplos de aplicação
Visão de governança de recursos de aplicativo
Exemplo 2:
Para cenários de construção de sites e entrega de unidades, o processo de classificação manual dos recursos de serviço (recursos de computação, recursos de armazenamento, configuração de operação e manutenção, etc., uma série de dados), depois entregá-los em lotes, um por um, e finalmente montar recursos um por um ocupa grande parte do tempo e, como muitas vezes há muitas pessoas envolvidas (a pontualidade da entrega não pode ser garantida e a coordenação da mão de obra é particularmente difícil), é demorado e trabalhoso. Se houver problemas como omissões neste processo, em primeiro lugar, causará retrabalho, reentrega e montagem e, em segundo lugar, a etapa de aceitação trará uma série de problemas imprevisíveis (o tempo para solução de problemas e reparo é incontrolável).
Solução: Com base na abstração geral e na associação dos serviços acima, a carga de trabalho da classificação manual pode ser reduzida e, em seguida, a entrega unificada pode ser realizada. Novas configurações de ambiente podem até ser geradas automaticamente e o ambiente pode ser entregue automaticamente. Isto reduz muito o penteado manual, as omissões e a intervenção manual.
Comparação de modelos de entrega antigos e novos
Exemplo 3:
Cada recurso dependente (nuvem elástica, RDS, etc.) possui seu próprio conjunto de controles de gerenciamento e meta-informações, que são separados e não sincronizados. Por exemplo, nuvem elástica e RDS têm seu próprio responsável e equipe de atribuição de custos. A grande quantidade de redundância nos dados dificulta a atualização dos dados: quando as informações mudam, as informações relevantes de todas as plataformas de recursos precisam ser atualizadas ao mesmo tempo, e cada recurso não tem correlação (é extremamente difícil conseguir atualizações de correlação) .
As alterações de dados carecem de mecanismo de atualização, por exemplo, o aluno responsável pelo serviço pediu demissão, mas o responsável pela plataforma de recursos correspondente não foi alterado ou transferido por causa disso. Com o tempo, essas metainformações de serviço tornam-se dados sujos.Quando precisam ser usados, só podemos adivinhar manualmente o pessoal e a afiliação organizacional por meio de vários dados, como pessoal anterior e informações da organização.
Solução: Com base nos problemas acima, primeiro é necessário simplificar os dados redundantes de cada sistema em uma cópia unificada, fundi-los no nível de serviço e reduzir a redundância. Em segundo lugar, estabelecer um mecanismo de circulação de dados para monitorizar regularmente os dados anormais e desencadear uma série de processos de circulação para garantir que os dados possam ser actualizados em tempo útil.
Gerenciamento abstrato do proprietário do recurso
Problema 2: Falta de abstração de dimensão superior
A revolução da tecnologia nativa da nuvem trazida pelo Kubernetes reside na padronização e abstração da camada de infraestrutura, mas essa camada de abstração ainda está muito distante da P&D empresarial, da operação e manutenção. O exemplo mais típico é que até hoje não existe o conceito de "aplicativo" no Kubernetes. Ele fornece primitivas de "carga de trabalho" mais refinadas, como Deployment ou DaemonSet. No ambiente real, um aplicativo geralmente é composto por uma série de componentes independentes, como um serviço de pedido composto por um "contêiner de aplicativo Java" e uma "instância de banco de dados" ou um "Deployment + StatefulSet + HPA + Service + Ingress" Aplicativos de microsserviços.
Os SREs de P&D e operação de negócios foram forçados a se tornarem "especialistas em contêineres" da noite para o dia, enquanto aprendiam vários conceitos na área de "Infraestrutura como Código (Infraestrutura como Código)" que não deveriam ser sua preocupação (como: declarações API, controlador, etc. ), enquanto reclama que o Kubernetes é muito complicado e o design é muito estranho. Portanto, precisamos fornecer uma maneira padronizada que todos possam seguir para definir abstrações da camada de aplicativo de nível superior e tomar a "separação de interesses" como a ideia central deste modelo de definição.
Especificamente, o OAM padroniza as especificações de definição de aplicativos com base no modelo de recursos da API Kubernetes, que enfatiza que um aplicativo moderno é uma coleção de vários componentes, em vez de uma simples carga de trabalho ou operador K8s. Portanto, no contexto do OAM, um contêiner Java, o banco de dados do qual ele depende e os vários serviços em nuvem que ele precisa usar são todos componentes de um aplicativo de “serviço de pedido”. Além disso, o OAM considera a "estratégia de operação e manutenção" exigida por esta aplicação como parte de uma aplicação, como a HPA (estratégia de expansão automática horizontal) exigida por este contêiner Java.
Exemplo de modelo de serviço OAM
Este paradigma de definição de aplicativo independente de plataforma permite que os desenvolvedores de aplicativos descrevam seus aplicativos apenas por meio de especificações OAM, e os aplicativos podem ser executados em qualquer cluster Kubernetes ou plataforma de aplicativo sem servidor ou até mesmo em ambiente de borda sem a necessidade de modificar a descrição do aplicativo.
Com a capacidade de abstração do modelo OAM, o provedor de serviços básicos (equipe da plataforma) encapsula principalmente os serviços básicos fornecidos aos usuários internos com base em serviços autoconstruídos, serviços em nuvem e serviços de fornecedores de nuvem terceirizados: como nuvem elástica interna, RDS , Redis, etc., protegendo as diferenças entre vários fornecedores de nuvem e diferentes plataformas. Para pesquisa e desenvolvimento de negócios (usuário final), concentra-se no design de lógica de negócios e fornece serviços externos orquestrando nuvem elástica, RDS e outras infraestruturas, reduzindo assim o custo de aprendizagem da relevância da plataforma.
Perspectivas de P&D de plataforma e P&D de negócios
prática interna
abstração de negócios
Com base na análise das questões acima, investigamos práticas relevantes na indústria. KubeVela é um mecanismo de orquestração de aplicativos nativos da nuvem de código aberto que usa o modelo Open Application Model (OAM) para descrever e gerenciar a implantação e operação de aplicativos.
OAM é um padrão aberto para aplicativos nativos da nuvem que visa fornecer uma maneira unificada de descrever e gerenciar a portabilidade, escalabilidade e observabilidade de aplicativos. O modelo OAM fornece uma maneira declarativa de descrever os componentes, dependências e configuração de um aplicativo. Ele separa os aplicativos da infraestrutura subjacente, permitindo que os desenvolvedores se concentrem mais no aplicativo em si, em vez de se preocuparem com o ambiente de tempo de execução subjacente. Essa abstração aumenta a produtividade do desenvolvedor e simplifica o desenvolvimento e a implantação de aplicativos.
Modelo OAM
Resumindo, os modelos KubeVela e OAM fornecem uma forma de simplificar o desenvolvimento e o gerenciamento de aplicações. Conforme mostrado na figura acima, é um componente aproximado de uma aplicação, que pode ser um pouco abstrato. Vamos usar serviços específicos dentro da empresa como um exemplo:
Exemplos de aplicação de OAM
Tomemos como exemplo o aplicativo de serviço localPII, que consiste nos seguintes componentes:
Componente de serviço: inclui cluster de cluster de nuvem elástica (carga de trabalho) e três características ( módulo de implantação responsável pela atualização do código , corte de log CutLog para limpeza de log e estratégia de observação );
Componente RDS: Contém instância RDS (Workload), incluindo informações de instância, tipo de negócio, informações de pacote e informações de conexão (VIP+Port, nome de usuário, senha);
Componente S3: assim como o componente RDS, o bucket S3 (carga de trabalho) contém o nome do bucket, o tipo de permissão do bucket e as informações de conexão;
Componente BizConfig: contém um conjunto de configurações Yaml e informações de conexão de componentes RDS e componentes S3. Em última análise, é consumido e usado pelo SDK para gerar a configuração do ambiente de serviço.
Com base nisso, podemos abstrair a topologia de dependência de serviço e, em seguida, integrar a manutenção de metainformações, como serviços e recursos, na dimensão do aplicativo, reduzindo assim a fragmentação e redundância de dados, aumentando os processos de mudança de informações relacionados (demissão, serviços de transferência de água viva), e resolução de problemas de nuvem.Problema de atualização de informações.
Topologia de recurso de serviço
separação de preocupações
O módulo de negócios é abstraído com base nos modelos KubeVela e OAM. Ao mesmo tempo, à medida que a tecnologia nativa da nuvem é implementada dentro da empresa, a complexidade da infraestrutura e dos serviços básicos também aumenta. Tomando como exemplo o serviço básico RDS: a forma atual de a empresa tem Ao construir RDS, serviços fornecidos com base nas definições de serviço K8S e serviços RDS de vários fornecedores de nuvem, se os detalhes subjacentes relacionados à P&D de negócios não forem protegidos, então cada P&D de negócios precisa entender as diferenças de cada produto e o técnico detalhes do K8S, resultando em custos de aprendizagem elevados e crescentes, enquanto muitos padrões e especificações não podem ser garantidos.
Portanto, é necessário separar as preocupações do Dev de negócios e do Dev de plataforma, e iterar os recursos subjacentes sem intervenção de negócios e ser usado diretamente pelo Aplicativo.
Engenheiro de Plataforma: Concentre-se na abstração e definição de serviços básicos e, ao mesmo tempo, proteja as diferenças na infraestrutura subjacente dos negócios da camada superior para reduzir o custo de aprendizagem da pesquisa e desenvolvimento de negócios da camada superior.
Engenheiro de P&D de negócios: concentre-se na lógica de negócios, orquestre os serviços básicos subjacentes conforme necessário e não precise prestar atenção às diferenças na infraestrutura subjacente.
Separação de preocupações do serviço
A entrega geral de um aplicativo é a seguinte: O fornecedor da plataforma, a P&D e o SRE concentram-se em suas respectivas responsabilidades e preocupações para garantir que o serviço funcione normalmente e eficientemente como um todo.
Provedor de plataforma: A plataforma de infraestrutura e operação e manutenção fornece definições de componentes e serviços de componentes
P&D: Use o centro de aplicativos para orquestrar a arquitetura de serviços e organizar os componentes necessários para os negócios
SRE: orquestrar recursos e capacidades de operação de serviço por meio do centro de aplicativos
RD + SRE: diferenças comuns no ambiente de configuração
Centro de entrega: Fornece ambiente de serviço, incluindo recursos e características de operação e manutenção, etc.
Novo modelo de prestação de serviços
Implementação real do produto
Com base na análise acima e no design geral, podemos dividi-lo aproximadamente em quatro produtos funcionais principais.
mercado de componentes
O mercado de componentes fornece principalmente definição de produto e registro para vários serviços básicos dentro da empresa.Por exemplo, líderes de componentes como RDS, Kedis e Fusion definem suas próprias capacidades de serviço no mercado de componentes e são responsáveis pela manutenção da função do componente e multi-base. -adaptação à nuvem. Através de plugável O método fornece recursos para o centro de aplicativos, e o pessoal de P&D da empresa organiza recursos e monta funções no centro de aplicativos de acordo com suas próprias necessidades de serviço, fornecendo assim serviços externos.
mercado de componentes
centro de aplicação
O Application Center é uma plataforma de gerenciamento do ciclo de vida de aplicativos que vincula dependências de recursos e instalações de operação e manutenção a serviços. Ele fornece uma descrição completa dos aplicativos e recursos de entrega rápida, facilitando o gerenciamento de recursos e melhorando a eficiência da entrega.
Primeiro, integra a árvore organizacional do centro de custo como base para determinar a atribuição dos custos do serviço e as funções de transferência relacionadas. Os atributos da aplicação incluem o responsável pela aplicação, a equipe responsável e o centro de custos a que pertencem.Estabelecer mecanismos de atribuição de responsabilidades de aplicação e atualização e transferência de atribuição de custos e se esforçar para fornecer serviços às pessoas, atribuição às equipes e custos para departamentos.
Página inicial do centro de aplicativos
Informações básicas do Application Center
Em segundo lugar, fornece recursos de orquestração de componentes de serviço. O pessoal de P&D de negócios pode montar os componentes de recursos necessários de acordo com suas próprias necessidades de serviço para alcançar funções de serviço; através do gerenciamento de ambiente do centro de aplicativos, os clusters de serviços podem ser entregues como um todo e a replicação do cluster de serviços pode ser realizado.
Orquestração de componentes do Application Center
Centro de Aplicação-Gestão Ambiental
Plataforma nativa de operação e manutenção em nuvem
Reorganizar as funções de gerenciamento e controle de operação e manutenção (implantação/nuvem elástica/observação) com o aplicativo (módulo de serviço) como centro e combinar o centro de aplicativos com o centro de aplicativos para vincular e manter o relacionamento entre o aplicativo (módulo de serviço) e recursos para resolver o gerenciamento do ciclo de vida e outras questões.
Plataforma nativa de operação e manutenção em nuvem
Centro de construção de sites
O centro de construção de sites é uma plataforma de entrega para sites de negócios completos construídos com base no centro de aplicativos. A capacidade de entrega depende do centro de aplicativos. Ele também fornece gerenciamento de links, gerenciamento de processos e outros recursos no processo de entrega para melhorar a eficiência de entrega do site completo.
Centro de construção de sites
Implementação de linha de negócios
Negócios internacionais
Levando em consideração as características de negócios dos negócios internacionais, que exigem entrega mais frequente de salas de informática e maior eficiência de entrega, cooperamos com a arquitetura de negócios internacionais para resolver a integração de meta-informação, a abstração geral de serviços e o CaC (configuração) de negócios internacionais por meio do Centro de aplicação, ou seja, implementação de tecnologia de código (configurações diferenciadas de salas de informática são geradas automaticamente) para melhorar globalmente a eficiência da prestação de serviços de toda a sala de informática. Atualmente, existem dois grandes benefícios da internacionalização:
Por meio da hospedagem do centro de aplicativos (geração automática de topologia de recursos e aplicação automática de recursos de serviço), a classificação manual e a participação na entrega são reduzidas. A implementação da tecnologia CaC reduz a participação do desenvolvimento de negócios na modificação de configuração e nos processos on-line. A entrega geral da sala de informática pode economizar mais mais de 30% do investimento humano.
O centro de aplicativos gerencia o ciclo de vida dos recursos como um todo e fornece recursos como atribuição e transferência de custos, que resolvem os problemas anteriores de recursos órfãos e incapazes de encontrar interfaces, fornecem observação de custos dimensionais do aplicativo e fornecem um importante ponto de partida para subsequentes gerenciamento de custos.
Negócios domésticos
A promoção de negócios nacionais aproveitará oportunidades de projetos como a construção de salas de informática multiativas domésticas e redução de custos e melhoria de eficiência este ano:
Utilize os recursos do centro de aplicativos e do centro de construção de sites para melhorar a eficiência da construção de recursos de computação em salas de computadores multiativas e a consistência da entrega da construção de sites.
Utilize os recursos de manutenção e transferência de líderes de aplicativos, equipes atribuídas e centros de custos atribuídos fornecidos pelo centro de aplicativos para promover o cálculo de custos e atribuir responsabilidades às equipes para ajudar no avanço dos projetos de redução de custos.
Conversa noturna nativa da nuvem
Como você usa o KubeVela em projetos reais? Que desafios e melhores práticas foram encontrados? Bem-vindo a deixar uma mensagem na área de comentários. Se precisar se comunicar conosco, você também pode enviar uma mensagem privada diretamente para o backend.
O autor selecionará uma das mensagens mais significativas e enviará um cross-pack multifuncional personalizado pelo Didi, e o prêmio será sorteado às 21h do dia 14 de setembro.
