Reforma do sistema: aplicação prática do modelo de design de cadeia de responsabilidade (explosão, o período de desenvolvimento foi reduzido de 45 dias para 1 dia)

APP China de código aberto, comece! Esta é uma versão totalmente nova que você nunca viu antes.”

Este artigo apresenta o histórico e a experiência do uso do padrão de design da cadeia de responsabilidade, para que os leitores possam aprofundar sua impressão sobre esse padrão de design e até mesmo se inspirar para "renovar" os projetos nos quais estão atualmente envolvidos e pelos quais são responsáveis, melhorando assim o "facelift" do sistema. Compartilhe cada detalhe do seu trabalho.

1. Fundo

Existe um módulo no sistema pelo qual sou responsável, o módulo de partição. Se você olhar diretamente para esta palavra, acredito que muitas pessoas ficarão confusas ou até mesmo mal interpretadas. descreverei brevemente o que é "roteamento".

Acredito que todos já tiveram experiência de compra online. Sempre que fazemos um pedido, podemos verificar o status de rastreamento logístico do pedido a qualquer hora e em qualquer lugar. O conceito de "roteamento" mencionado acima refere-se a: o transporte do pedido do ponto A ao ponto. B. Linha de rota, por exemplo, o pedido pedido1 precisa ser transportado de A para o destino F. Pode ir de A->B->D->F, ou de A->D->F Quanto a qual rota deve. ser tomada, depende de As rotas configuradas no sistema e as regras correspondentes são filtradas.

Por muito tempo, a configuração e as regras de roteamento do sistema foram estáticas (as chamadas estáticas significam que foram configuradas antecipadamente e são quase fixas. A desvantagem dessa abordagem é óbvia, ou seja, o custo não pode). ser controlado, conforme mencionado acima, obviamente há oportunidades para que a rota de transporte seja reduzida ou mesmo entregue diretamente (as mercadorias de A a F podem obviamente encher N caminhões, mas devem ser transportadas de acordo com a rota). estabelecidos no sistema), mas são bloqueados pelo sistema Devido às regras de roteamento fixas, só podemos pegar mais estradas, o que aumenta o custo das operações de mão de obra e transporte.

Com base nisso, um especialista descobriu uma oportunidade de negócio para reduzir custos e aumentar a eficiência: ativar esta linha de roteamento e regras, para que o sistema possa ser compatível de forma mais flexível com as situações acima e alcançar a utilização final dos recursos. por exemplo, se houver muitos pedidos, todos são destinados de A ao destino F. A configuração da linha estática no sistema é apenas A->B->D->F. Porém, após monitoramento e cálculo do sistema, constatou-se que o. quantidade de mercadorias de A a F pode encher dois caminhões. Nesse momento, uma nova rota é gerada temporariamente para esses pedidos de A a F. Ao mesmo tempo, as mercadorias são recebidas e expedidas no site A. Qualquer link prático. envolvendo correspondência de linha de roteamento é compatível com este cenário de roteamento temporário, de modo que O custo geral pode ser reduzido sem alterar os hábitos do usuário, e a eficiência do transporte até o destino também foi bastante melhorada.

O plano proposto por este especialista foi muito bom e foi amplamente reconhecido e elogiado por todos. Depois que o projeto foi estabelecido, ele entrou em um estágio de desenvolvimento vigoroso e tive a sorte de receber a importante tarefa de liderar o desenvolvimento e a entrega de. este projeto.

Vale ressaltar que as alterações no circuito de roteamento percorrem todo o processo de operação real do pedido, bem como algumas consultas auxiliares ponta a ponta, relatórios estatísticos e outras funções. Existem muitos cenários envolvidos, portanto a pressão ainda é. bastante alto, embora seja verdade que durante o período fizemos muitos desvios, mas o resultado final foi bom. Mesmo depois, houve várias necessidades semelhantes de mudança de rota. Mas com base nessa transformação, podemos facilmente lidar com isso. . Isso será discutido mais adiante neste artigo e será refletido no efeito.

Dito isso, você acha que é tudo bobagem Haha, é realmente um pouco prolixo. A seguir, vamos dar uma olhada na Estrada Menghui e reproduzir todo o processo de transformação que é fragmentado, mas tem uma sensação de realização. .

2. Ideias e métodos

O particionamento mencionado nos artigos subsequentes é o significado das regras de correspondência para roteamento

Primeiro, vejamos um diagrama esquemático simples do processo de operação prática.

As regras de correspondência de partição estarão envolvidas no processo de operação real de cada site. Ao mesmo tempo, as regras de correspondência de roteamento também estarão envolvidas na função de consulta ou função de relatório de algumas operações auxiliares, portanto, uma vez que as regras de correspondência de partição precisem ser alteradas, então você enfrentará os seguintes pontos problemáticos

◦Em primeiro lugar, no nível empresarial, quase todo o processo será executado, seja avaliação, desenvolvimento, teste, etc., enfrentará o problema de uma enorme carga de trabalho.

◦Mais uma vez, do nível do sistema, o status atual desta parte do código também é muito hostil, refletido principalmente em:

▪As principais regras de negócios de correspondência de partições são consistentes, mas o código é escrito de forma diferente e disperso, dificultando a leitura e a manutenção, além de acarretar o risco de perder cenários.

▪A função de correspondência de partição é atualmente escrita por cada instância e acoplada em cada cenário de uso. Uma vez que as regras mudam, o custo da modificação é muito alto.

Com base nos pontos problemáticos acima, decidi reestruturar e retificar este módulo. Em primeiro lugar, irei melhorar através deste desafio e, em segundo lugar, também prepararei o caminho para a possibilidade de alterar esta regra novamente no futuro. devo fazer especificamente? Como resolver os pontos problemáticos mencionados acima? Isto é o que eu fiz

1. Fazer uma avaliação minuciosa no nível de negócio: refletida no desenho detalhado do empreendimento (como estou muito familiarizado com as regras de negócio, essa é minha vantagem haha), como ordenação de cena, modificação do plano, e até em o design O esquema lógico de modificação e a localização do código de funções específicas (cliques em botões, acionamentos de pressionamento de enter após a entrada na caixa de entrada, etc.) foram detalhados, para que todos os desenvolvedores participantes possam usar isso como um guia para rápida desenvolvimento, e os testadores podem usá-lo. Isso serve como um guia para escrever casos de uso, e o pessoal do produto usa isso como um dicionário para aprofundar sua própria compreensão deste negócio, etc. Não parece incrível? Hahaha, é um pouco de orgulho aqui. Este artigo não se concentrará nisso. Ele apresenta principalmente o padrão de design.

2. Este é o nosso destaque no nível do sistema, ele se reflete principalmente no código. Afinal, não importa o quão bem você diga isso, se você não conseguir implementar o código e ver o efeito, será tudo em vão. estamos em uma posição. Ok, sem muita bobagem. Diga, continue assistindo meu desempenho haha.

▪Primeiro , os módulos principais correspondentes à partição são unificados e apenas uma instância é retida no sistema para fornecer serviços. Isso pode não apenas resolver o problema de altos custos de manutenção de código disperso, mas também evitar o risco de cenários perdidos.

Vendo isso, algumas pessoas podem perguntar, isso trará outro problema: Embora as cenas não sejam perdidas, uma vez alcançada uma mudança de código, todas as cenas entrarão em vigor, mas as cenas originais de algumas cenas serão alteradas? Acho que os alunos aqui são realmente muito cuidadosos. Se o fechamento for forçado, esse novo problema realmente surgirá. Portanto, o fechamento unificado deve suportar expansão e reserva de ganchos para apoiar o processamento diferenciado de cada cena. Isso é bastante abstrato: por exemplo, a regra geral do cenário é que todos os pedidos sejam transportados de acordo com as regras de zoneamento da configuração estabelecida do sistema, mas agora alguns comerciantes abriram alguns serviços para entrega rápida no destino, então para estes. pedidos dos comerciantes Não é mais possível usar as regras gerais existentes para correspondência de partições e transporte. É necessário realizar a correspondência de partições de acordo com as novas regras para atingir o objetivo de transporte rápido. Essa é a diferença interna.

▪Reutilizar estruturas de dados existentes, adicionar tipos de partição e ajustar SQL e serviços de serviço correspondentes (este não é o foco deste artigo, portanto não entrarei em detalhes) e apoiar a expansão de regras de partição com base na compatibilidade com lógica de produção existente.

▪Ajuste a estrutura do código das regras de correspondência de partição com base na ideia de padrões de design: adote o padrão de cadeia de responsabilidade (aqui é o foco deste artigo)

Então, qual é exatamente o modelo de cadeia de responsabilidade?

A definição dada por Daniel: dar a múltiplos objetos a oportunidade de processar solicitações, evitando assim a relação de acoplamento entre o remetente e o destinatário da solicitação. Esses objetos são conectados em uma cadeia e a solicitação é passada ao longo da cadeia até que um objeto a trate.

Vamos falar sobre como aplicá-lo com base no negócio real do sistema existente: já apresentei no fundo do capítulo de abertura que as regras de correspondência de partição existentes são correspondência de partição estática (como um certo ponto de negócio a ponto, um certo ponto de negócios para uma área de alcance) Espere, não entrarei em detalhes específicos de negócios, apenas saiba que há muitas regras de correspondência aqui.) Agora precisamos adicionar uma nova regra para dar suporte à dinâmica (também é uma variedade). de correspondência, então não entrarei em detalhes). Aqui eu defino cada regra de partição como um tipo de partição e cada tipo de partição como um nó de partição. Tecle esses nós em uma cadeia, para que cada solicitação possa encontrar uma linha correspondente. esta cadeia.

Como os detalhes do negócio são relativamente sensíveis, eles não serão divulgados detalhadamente no artigo, o que não afetará a compreensão da aplicação dos principais padrões de projeto.

Combinando a definição e a análise acima, a situação real é adequada para usar o padrão de design da cadeia de responsabilidade? Acredito que, desde que os pontos problemáticos acima possam ser resolvidos e os benefícios gerais superem as desvantagens, então será aplicável. Primeiro, as vantagens de usar este modelo para transformar são as seguintes:

◦Solicitações e processamento separados (livre de acoplamento com operações de negócios, não se preocupe com a origem da solicitação, concentre-se apenas nas regras de partição correspondentes)

◦Melhorou a flexibilidade e escalabilidade do sistema (se houver novas regras, você só precisa adicionar nós)

É claro que este modelo também tem algumas deficiências: quando a cadeia de responsabilidade é relativamente longa, uma vez que cada solicitação percorrerá toda a cadeia, pode haver problemas de desempenho. Ao mesmo tempo, a depuração pode ser mais complicada para os alunos que não entendem. o negócio.

No geral, a vantagem é que ele resolve nossos problemas atuais e facilita a expansão subsequente, enquanto a parte de desempenho das desvantagens pode ser ignorada combinando as funções de gancho reservadas no modo de modelo (se a solicitação atual não for adequada para o nó de partição atual regras) para minimizar o impacto dos problemas de desempenho e, ao mesmo tempo, também é necessário que os desenvolvedores entendam o negócio. Portanto, parece que no geral as vantagens superam as desvantagens.

Dito isso, vamos primeiro dar uma olhada em um diagrama de comparação simples do módulo de partição antes e depois da transformação.

Embora o diagrama seja muito simples, o significado da comparação ainda é óbvio antes da transformação: a correspondência de partição e o processamento de negócios são acoplados após a transformação: a correspondência de partição é uma cadeia e não há processamento de lógica de negócios nela; Extensões liberadas de acoplamento também são suportadas. Algumas pessoas podem ficar confusas depois de ver isto: O texto acima não disse que apenas uma regra de correspondência dinâmica foi adicionada? Por que há tantos nós na cadeia e ainda existem duas cadeias? Deixe-me explicar um pouco aqui: as duas cadeias atuais passaram por muitas mudanças na versão de demanda. No momento, parece que a diferença não é grande, principalmente porque os cenários especificados pelo negócio de origem que elas fornecem são diferentes. outros interferindo em suas respectivas operações, os nós introduzidos em muitos lugares neste artigo também foram adicionados posteriormente e ainda são as regras de nós usadas no sistema até agora (isso é o que mencionei no início do artigo: E se houver). são mudanças nas regras mais tarde. Com certeza, ainda é Por mais inteligente que eu seja, a "profecia" se tornou realidade, direi a importância de apoiar a expansão aqui para encurtar o período de construção).

3. Processo prático

Acredito que muitos leitores descobrirão que o texto acima fala sobre fechamento unificado e combinação com o modo de modelo para evitar ao máximo o impacto no desempenho, portanto, sua cadeia de responsabilidade não pode ser suportada por um modo de design.

Sim, você está certo, Smart. É verdade que apenas usar um único padrão de design de cadeia de responsabilidade está longe de alcançar o efeito mencionado acima. Aqui combinamos os padrões de fábrica, modelo e cadeia de responsabilidade. obter o bean da cadeia O modelo é usado para definir métodos gerais, chamadas entre métodos e switches, pré e pós-processamento, diferenciação e outros métodos reservados para implementação de subclasses. são alguns exemplos simples. O nó exibe o diagrama de classes como segue.

Esta seção é relativamente simples, afinal, é apenas codificação. O diagrama de classes acima é quase uma aplicação prática no código e também é a parte central do código. correspondência de partição.

4. Reflexões sobre o processo de prática e avaliação de efeitos

Os resultados após a transformação refletem-se principalmente na expansão e manutenção subsequentes. Conforme mencionado no início do artigo, uma vez alteradas as regras de correspondência de partições, haverá dois pontos problemáticos. primeira vez para realizar este bloco Ao alterar os requisitos para novas regras de roteamento, o período geral de construção real é de 45 dias no lado de P&D, sem mencionar que, uma vez encontrado um BUG, o período de teste não é garantido (correspondente aos nós dinâmicos nos nós da figura acima)

Mas não muito depois, novos requisitos para regras de correspondência foram adicionados novamente (correspondendo ao nó de carona no nó acima, o período de construção foi reduzido quase pela metade e os 45 dias ideais foram reduzidos para 27 dias). O requisito também inclui Para a transformação de outros módulos não particionados, é claro, a transformação da primeira versão teve alguns aspectos perfeitos. Após esse período, foi otimizada de acordo com as necessidades de.

Os próximos dois realmente incorporam o que é chamado de desaparecimento do período de construção. Um é o primeiro requisito da regra de zoneamento do conselho e o outro é a regra de zoneamento direto nos recentes requisitos de integração da rede B.

◦O período de construção para distribuição direta é de 2 dias

◦O período de construção do primeiro zoneamento é de apenas 1 dia

Para ser honesto, não esperava um efeito tão grande quando não olhei para os dados agora, também estou chocado. Quem poderia imaginar que a aplicação de um padrão de projeto pode encurtar o período de construção. 45 dias para 1 Deus, isso é incrível.

Claro, também existem algumas áreas que podem ser melhoradas e atualizadas. Atualmente, a montagem dos nós da cadeia de responsabilidade é especificada manualmente e pode ser alterada para montagem automática (já implementei na transformação de outro cenário de negócios, e é). também será realizada aqui. Transformação síncrona), outra é controlar o número de nós. Se o número for muito grande, pode ser necessário considerar uma solução de compatibilidade.

Como diz o ditado, não leva um dia para perfurar uma gota de água, e não leva um dia para congelar um metro de gelo. Certamente é viável buscar ferramentas poderosas e novas tecnologias, mas não faça isso. Não se esqueça das pequenas mudanças no trabalho diário. Em pouco tempo, você pode não conseguir ver nada, mas uma vez que as mudanças quantitativas levem a mudanças qualitativas, acredito que os resultados serão muito impressionantes.