Sistema de visualização inteligente Evolução da arquitetura de serviço Atom

Autor: Bump Man - Manjiz

O que é o Atom? O Atom é uma plataforma que integra todos os tipos de designers seniores de comércio eletrônico do setor e fornece uma página inteligente profissional completa e serviços de design de pequenos programas. Após 2 anos de iterações compactas, o projeto está ficando cada vez maior, os requisitos estão constantemente mudando e otimizando, a lógica interna é complicada e os custos de manutenção estão subindo acentuadamente. Ao mesmo tempo, o Atom prestará cada vez mais serviços e prestará serviços a mais usuários e comerciantes internos.Para se adaptar a essas mudanças, a atualização da arquitetura tornou-se um assunto urgente na época. Para expandir mais facilmente os cenários de negócios.

O servidor Atom passou por três versões da iteração, este artigo se concentra na análise da terceira versão.

Arquitetura 1.0

Esta é a versão mais antiga do Atom. Nesta versão, apenas a função da página do canal é planejada. O objetivo é liberar os desenvolvedores do complicado desenvolvimento da página do canal. Como o objetivo da função é puro, a complexidade do sistema é baixa. O servidor é desenvolvido diretamente usando a estrutura Koa. Este é um serviço monolítico.Todo o código é executado em um processo.

Em termos de implantação, uma operação manual muito original é usada: o desenvolvedor efetua login na máquina, extrai o código, instala e inicia de forma semelhante ao ambiente local e repete esse processo em máquinas diferentes.

Além disso, a versão antiga do Quark usa componentes nomeados.Os componentes nomeados limitam a escalabilidade do próprio Quark em certa medida e não serão expandidos aqui.

Arquitetura 2.0

Da plataforma de criação de página de canal à plataforma de criação de página de vários cenários, o Atom usou menos de um ano, componentes mais ricos, mais modelos, mais cenas, mais designers participantes, mais usuários, produtos O desenvolvimento está se tornando mais especializado, e a operação e manutenção manual simples não são mais aplicáveis, portanto o front end e o servidor passaram por uma grande troca de sangue. O servidor é reconstruído com o Salak . O Salak é uma estrutura de servidor muito boa e nos trouxe Para a função de geração automática de documentos de interface, o front-end e o servidor dependem do Talos (uma plataforma interna de implantação em contêiner) para implantação. O servidor entrou gradualmente na era industrial.

No entanto, nesta fase, o extenso método de desenvolvimento não foi resolvido e a falta de planejamento macro expôs cada vez mais os seguintes problemas:

• Altamente concentrado

  Mais de 90% dos serviços estão concentrados em uma única arquitetura, o negócio é cada vez mais complexo, o volume do código está aumentando, a legibilidade, a capacidade de manutenção e a escalabilidade do código estão diminuindo, o custo do acesso do desenvolvedor está aumentando e o negócio está em expansão O custo aumentou exponencialmente, dificultando a manutenção da capacidade de entrega contínua. Com mais e mais usuários, a simultaneidade que o programa suporta é cada vez maior, e a capacidade de simultaneidade da aplicação da arquitetura monolítica é limitada. À medida que a complexidade do sistema aumenta, a dificuldade de testar se torna cada vez mais difícil.

• Alto acoplamento

  Os módulos individuais no monômero dependem um do outro, afetam um ao outro e interferem entre si, resultando em baixa reutilização de código.O desenvolvimento de novas funções geralmente escolhe reescrever devido ao ovo oculto na lógica do acoplamento, que não é o que queremos ver!

• Confusão lógica

  Além da confusão lógica causada pelo acoplamento, o Atom, como uma plataforma que cresceu do zero, acumulou muitas necessidades históricas, algumas não são mais usadas e outras quase não são.Essas lógicas de código dão aos desenvolvedores uma grande quantidade de Desafio: Não se atreva a alterar o código facilmente, mantendo o código. Além disso, ele precisa ser compatível com versões anteriores na iteração, para que o servidor tenha uma carga histórica pesada.

• Redundância de código

  Como a estrutura não definiu os padrões de especificação no estágio inicial, a verificação do código foi rigorosamente seguida durante o processo de desenvolvimento, e a lógica e as constantes do código foram definidas repetidamente, o que também dificultou a manutenção do projeto. A premissa é modificar vários locais ao mesmo tempo.

Novos objetivos de arquitetura

De acordo com as vantagens e desvantagens da arquitetura original, definimos os objetivos dessa atualização da arquitetura:

• Modularidade de serviço
• Generalização de serviço
• Site de plug-in
• Cenário de plug-in
• Padrões e especificações

Explicação dos termos:

• Site: dissociando o servidor da plataforma, do serviço original como plataforma, para fornecer o mesmo serviço para várias plataformas isoladas uma da outra.

• Cenários: conceitos configurados em resposta a diferentes tipos de negócios.Os cenários diferentes têm diferentes métodos e processos de gerenciamento.

Arquitetura geral

A arquitetura geral é dividida em 4 partes: camada de aplicativo da Web, camada de interface, camada de serviço e camada de dados, para que a divisão possa alcançar entrada unificada, a implantação de ponto único na implantação torna a publicação mais conveniente e a implantação independente reduz o impacto no serviço geral :

• Camada de aplicativos da Web: incluindo a plataforma Atom e outros aplicativos de plataforma
• Camada de interface: fornece serviços de gateway, e as solicitações da camada de aplicativo são controladas e encaminhadas via gateway
• Camada de serviço:
  • Comunicação de serviço: MQ para comunicação assíncrona e HTTP para comunicação RPC
  • Módulo de negócios: código principal, desmontando muitos aplicativos de pequenos módulos
  • Serviço básico: controle unificado de usuários e permissões
  • Gerenciamento de serviços: melhore a estabilidade, robustez e flexibilidade dos serviços
• Camada de dados: armazenamento de dados principal

O gateway serve como entrada de tráfego de todo o servidor, processa todo o tráfego, intercepta solicitações ilegais, analisa o status de login e o transmite para o downstream, verifica permissões de interface e respostas de tempo limite, etc., e controla-os uniformemente, reduzindo a pressão do downstream.

Implementar

Plano / preparação / avaliação

Antes de entrar oficialmente no desenvolvimento da atualização, a equipe discutiu a necessidade e a viabilidade da atualização da arquitetura por meio de uma reunião.O motivo direto para solicitar a atualização são os novos requisitos de site e de cenário da plataforma. Se esse requisito for realizado na arquitetura original, será definitivamente Adicione mais lógica de acoplamento à lógica caótica original e a razão indireta, ou seja, a necessidade de atualização, é tornar o sistema modular, padronizado e generalizado, tornar a lógica do sistema mais clara e melhorar a capacidade de manutenção de todo o sistema. .

Após nossa discussão repetida, o sistema original foi dividido de acordo com as funções e, em seguida, com base nas funções, foi dividido de acordo com a versatilidade, o trabalho de suporte da nova arquitetura foi adicionado, a carga de trabalho e o tempo estimado desse trabalho foram avaliados e, finalmente, as tarefas foram realizadas. A distribuição é liberada.

Implementar

Modular

Por que modular? À medida que a plataforma cresce cada vez mais, queremos tornar as funções de cada parte mais independentes, claras e claras, minimizar o impacto entre cada parte, operar e manter cada parte separadamente e evitar a situação de puxar todo o corpo de uma só vez. .

Essa atualização divide o projeto em mais de 10 módulos, de acordo com a função e a versatilidade: como um módulo dedicado à compilação, um módulo dedicado ao gerenciamento de modelos, um módulo responsável pelas tarefas agendadas, um gateway para entrada e assim por diante.

Entre eles, vários serviços gerais são divididos.O serviço geral é um serviço independente do sistema Atom e pode fornecer serviços para o Atom e outros sistemas.

A coisa mais problemática na desmontagem do projeto é interromper a lógica associada.A remoção e reparo do módulo inevitavelmente causam um problema - o mesmo código aparece repetidamente em diferentes módulos. Para resolver esse problema, colocamos alguns desses códigos no pacote npm da ferramenta, incluindo: constantes, definições de tipo TypeScript, mapeamento de permissões, definições de esquema do Mongoose, plug-ins Salak e métodos de ferramenta, etc.

Outra questão é que, na arquitetura original, os módulos podem ser chamados diretamente por código.Como "restaurar" essa função na nova arquitetura? Para garantir o grau de dissociação, apenas algumas funções na nova arquitetura que precisam ser chamadas imediatamente são chamadas diretamente através da interface entre os módulos e o restante é comunicado ao banco de dados através da fila de mensagens do MQ.

Para comunicação MQ, aqui está um exemplo: compilar. A compilação no servidor geralmente leva muito tempo, e a ocupação a longo prazo da conexão afetará o desempenho do serviço, e o resultado da compilação não exige resposta síncrona. Para o módulo de compilação, se o visitante recusar, haverá muita pressão no serviço. Por isso, decidimos usar a fila de mensagens para concluir a comunicação entre os vários módulos:

1. O módulo do projeto chama diretamente o módulo de liberação através da interface para iniciar a operação de liberação;
2. O módulo de publicação envia uma mensagem "Eu quero compilar" para o pool de mensagens;
3. Depois que o módulo de compilação recebe a mensagem, ele julga se pode entrar na compilação por sua própria situação; caso contrário, não responderá primeiro;
4. Cada estado de compilação também é enviado por mensagem;
5. Finalmente, o módulo do projeto faz vários processamentos após receber a mensagem de status da compilação.

Generalização

Como mencionado anteriormente, no trabalho de modularização, desmontamos quatro módulos de serviço geral.O serviço geral é independente do sistema Atom e pode fornecer serviços para o Atom e outros sistemas. A generalização do módulo é baseada em duas considerações:

1. Enriquecer os serviços do departamento e reduzir a duplicação de funções de desenvolvimento
2. Elimine o código não essencial do Atom e torne o sistema mais fino

Uma pergunta que acompanha é digna de nossa consideração: como considerar se uma função é digna de generalização? Deveríamos tentar o nosso melhor para evitar cair em um mal-entendido: modularização do sistema é desmontar o sistema da melhor maneira possível. Se a divisão for muito boa, a carga de trabalho de operação e manutenção aumentará inevitavelmente. Ao dividir os módulos, consideramos se as funções de um módulo são completas e independentes e a demanda do departamento ou da empresa por esse serviço comum, e realmente atingimos baixo acoplamento e alta coesão .

Padronização

No nível do código, a seguir é uma comparação simples:

Contraste	Arquitetura antiga	Nova arquitetura
Idioma principal	Javascript	TypeScript
Detecção de código	Não conformidade	Obrigatório
Nome da interface	Variedade	Formulário unificado
Saída de interface	Flores desabrochando	Formulário unificado

O TypeScript é bom As pessoas que trabalham com front-end sabem que isso nos proporciona o preenchimento automático e o sistema de tipos opcional, para que possamos usar mais novos recursos de JavaScript etc. Para mais, consulte " Por que escolher o TypeScript ". Quais são as razões para os três pontos a seguir? A arquitetura antiga passou por um processo de zero a 1. O projeto carecia de planejamento inicial e não tinha tempo suficiente para corrigir o sistema nos estágios intermediário e tardio.O duplo papel das mudanças de tempo e demanda causou a paralisação do código.

Para isso, enfatizamos a padronização do código no desenvolvimento da nova arquitetura: cada envio deve ser submetido à inspeção do código e, em seguida, à interface unificada da variedade:

• Unified caminho de interface: a antiga arquitetura, o caminho pode ser uma lista de interfaces /xxx/list, pode ser /xxx/xxxes, e assim por diante, baseado em regras API RESTful caminho de recurso de substantivos e semântica do protocolo HTTP definido na nova interface arquitetura unificada;
• Nome do parâmetro uniforme: uma lista de parâmetros, tais como o número de página pode ser chamada pageSizepode ser chamado count, então vamos colocá-la em um nome unificado, necessário para dar cumprimento à presente convenção em desenvolvimento;
• saída unificada: os dados de saída para o processamento de dados front-end pré-triagem, incluindo abate _ide __vassim por diante dados não relacionados, na forma de saída tem feito um unificada, todos os requisitos de saída são substituídos _id aparecem em nome de ID, etc.

O benefício da padronização de código é facilitar a manutenção do código, os desenvolvedores podem localizar rapidamente o código de interface correspondente e, para o front-end, reduz a memória de identificação da interface.

Site de plug-in

Como mencionado anteriormente, o motivo direto dessa atualização da arquitetura são os requisitos do site e do cenário. Se os requisitos do site forem iterados sob a arquitetura antiga, isso aumentará ainda mais o grau de acoplamento. Por esse motivo, adicionamos um módulo de gerenciamento de sites, adicionamos campos de sites a quase todos os itens de dados e adicionamos parâmetros de sites a quase todas as consultas ao banco de dados. Com esses esforços, agora o novo site precisa apenas adicionar um novo site através do módulo do site e, em seguida, fazer algumas configurações iniciais para concluir.

Além dos requisitos mais altos para as funções Atom, o conceito de site também apresenta novos desafios ao sistema de permissão original. Na versão pré-atualização, as permissões do usuário são apenas um conjunto.Para obter permissões diferentes para cada site, existem apenas duas perspectivas:

1. Permissão que significa divisão (forneça um conjunto separado de permissões para cada site)
2. As permissões do usuário adicionam uma camada de abstração (as permissões do usuário mudam para várias coleções para alternar de acordo com o site)

Depois de comparar as duas modificações, o significado das permissões divididas é mais fácil de entender e o código não mudou muito. No entanto, aumenta bastante a dificuldade de manter a tabela de permissões, o que equivale a adicionar um conjunto de permissões para novos cenários, que não podem ser conectáveis. Finalmente, na camada de gateway
, a lógica para alternar o conjunto de permissões de acordo com o acesso do usuário ao site é adicionada .

Cenário de plug-in

A cena é uma latitude abaixo do site. Existem várias cenas principais de atividades, canais, testes psicológicos, SNS e lojas existentes.Se uma nova cena for adicionada sob a arquitetura antiga, ela precisará ser agendada para desenvolvimento. Cenas diferentes if-else. Para expandir e manter a cena de forma mais conveniente e sem preocupações, desmontamos o código relacionado à cena da perspectiva do gerenciamento de recursos.

recursos átomo em cada cena tem principalmente 模板/项目/标签/权限quatro categorias:

标签       页面
 |         |
模板------>项目

权限     

introduz estrutura do projeto módulo de diretório, os códigos do projeto módulo de base modelo de política de organização, lógica de negócios para cada grupo cena em arquivos separados, chamado diretamente por uma lógica programador para evitar doping nos diferentes cenários.

• O arquivo do planejador é nomeado base_资源_service
• O arquivo de estratégia de cena é nomeado 场景小写_资源_service
• O arquivo de políticas gerais é chamado common_资源_service

Quando um usuário entra, o planejador chama diretamente o método no arquivo de estratégia correspondente de acordo com a condição da consulta ( geralmente, não é permitido chamar diretamente a estratégia da cena especificada, a menos que seja confirmado que não estará relacionado aos dados de outras cenas ), quando o planejador não encontrar a cena correspondente a próxima estratégia irá chamar o padrão common_servicelógica, de modo que cada cena precisa de herdar common_service. Para serviços de gestão página, por exemplo, o programador para o src/service/pagediretório base_page_service, a lógica comum common_page_service, a lógica cena página do canal ch_page_service.

Para a unidade de métodos públicos abstratas de cenário, método de serviço de interfaces CRUD comumente usados colocados no AbstractServiceClassarquivo

├── src
│   ├── service
│   │   └── {resource}
│   │       ├── base_{resource}_service 策略文件调用器,controller/mq 直接调用
│   │       ├── common_{resource}_service 通用策略文件，例如列表查询共用的参数处理
│   │       └── {scene}_{resource}_service 场景策略文件，场景特殊的

Implantar

Migração de dados

Tendo em vista as mudanças drásticas nesta atualização, devemos ter cuidado ao alternar entre as versões nova e antiga. Além do grande número de ajustes conjuntos feitos pelo front end e pelo servidor para essa finalidade, também realizamos a migração de compatibilidade dos dados. O principal método é transferir os dados antigos por meio do script de migração. Faça o processamento múltiplo de acordo com as necessidades da nova arquitetura e, em seguida, grave-o no novo banco de dados.

Implantação ininterrupta

Em uma arquitetura monolítica, cada implantação de versão de serviço causará alguns minutos de janelas vazias.

Para evitar essa situação, no ambiente de produção, garantimos que cada módulo tenha pelo menos dois contêineres. Durante a implantação, alguns dos contêineres são removidos do balanceamento de carga e, em seguida, o contêiner é detectado ciclicamente se há tráfego e não é atualizado até que não haja tráfego. Depois que a operação é iniciada, o serviço é adicionado novamente ao balanceador de carga e, em seguida, a mesma operação é executada nos contêineres restantes.A vantagem disso é que todo o processo de implantação é garantido e o serviço é ininterrupto, evitando lacunas no processo de implantação.

O & M

Para evitar repetir a má experiência de operação e manutenção e o gerenciamento de código de projeto sob a arquitetura antiga, organizamos um documento de operação e manutenção para a nova arquitetura, incluindo detalhes de acesso rápido, desenvolvimento, depuração e implantação.

Adicionado monitoramento no sistema para monitorar o desempenho e a disponibilidade de cada interface.

Efeito

Após essa atualização, os resultados planejados foram basicamente alcançados:

• Clareza: penteado lógico, remoção de redundância, reconstrução TS, ESNext
• Modularidade: desacoplar mais de 10 módulos, operar de forma independente; vários métodos de comunicação, como HTTP, MQ, camada de dados, etc.
• Padronização: especificação de código forte; interface unificada; resposta unificada
• Generalização: 4+ módulos universais, independentes de plataforma; extrair bibliotecas públicas, configurações, plug-ins, middleware, etc.
• Migração fácil: inicialização de uma chave; ponto único de uma chave, implantação independente; entrada unificada
• Fácil de expandir: + adicionar recursos de expansão do site; ajustar a expansão da cena; economizar custos de tempo de trabalho em 95%
• Fácil de manter: adicione logs; implantação com um clique; implantação ininterrupta
• Fácil encaixe: documentação completa do Joi; registros detalhados de alterações na interface; o máximo de compatibilidade possível

Ferramentas / Métodos / Colaboração

As ferramentas têm um impacto muito importante no bom andamento do projeto; portanto, nesta atualização, tentamos várias ferramentas.

Para garantir que os membros do projeto tenham uma compreensão clara de seus próprios módulos responsáveis ​​e uma imagem clara da transformação dos módulos, a equipe introduziu ferramentas de fluxograma para classificar os módulos da arquitetura antiga e dividir o trabalho, classificar a lógica dentro de cada módulo da nova arquitetura etc.

Em termos de agendamento, usamos o gráfico de Gantt na prática. O gráfico de Gantt foi usado para dividir as tarefas de acordo com o módulo e depois atribuído à pessoa responsável e definir o horário agendado. O progresso geral era sincronizado todos os dias. No gráfico de Gantt, você pode Um entendimento claro da alocação e programação de recursos do projeto, bem como a comparação entre o plano do projeto e a situação real, ajuda a controlar o progresso geral do projeto.

O gráfico de Gantt inicialmente divide a tarefa de atualização do projeto.Para uma divisão mais detalhada, colocamos o IssueBoard.O IssueBoard é como uma versão simplificada do painel de tarefas, mas é mais do que suficiente para nós. O motivo também inclui: ele suporta a vinculação com confirmações do git, adequado para os desenvolvedores usarem e pode fechar o problema correspondente com cada confirmação.

Resumo reflexão

Nesse processo de atualização, algumas deficiências também foram expostas, refletidas principalmente no cronograma e nas expectativas e na comunicação antecipada.

• Horários e expectativas

  O cronograma no início do plano de atualização era otimista demais e não foram feitas mais alterações durante o processo de atualização. Isso foi causado por razões objetivas. A equipe deve concluir a atualização dentro do período de janela de demanda limitada para evitar a manutenção de duas versões ao mesmo tempo, o que leva a A conseqüência é que a equipe deve gastar mais tempo todos os dias do que o planejado.

• Comunicar

  Quando o servidor foi atualizado, não havia detalhes específicos comunicados com o front end, e essa atualização não é totalmente compatível com versões anteriores, portanto, o front end causou alguns problemas e inconvenientes durante a depuração conjunta.

Referência

• Atom ：https://ling.jd.com/atom
• Salak: https://salakjs.github.io/docs/docs/zh-cn/introduction.html
• API RESTful: http://www.ruanyifeng.com/blog/2014/05/restful_api.html

Endereço original: https://aotu.io/notes/2020/04/21/atom-services-upgrade/

---

Bem-vindo ao blog do Bump Lab: aotu.io

Ou siga a conta pública do AOTULabs (AOTULabs) e envie artigos periodicamente: