1. Visão geral do sistema de pedidos
1.1 Escopo de negócios
Linhas de negócios de serviços: entrega expressa, entrega expressa, itens de pequeno e médio porte, itens grandes, cadeia de frio, internacional, logística de contrato B2B, CLPS, Jingxi, três entradas e três saídas (compras de entrada, devoluções, alocação de entrada, vendas, retirada de suprimentos, alocação)) espere
1.2 Valor do centro de pedidos
1. Desacoplamento ( melhorando a estabilidade do sistema )
Sistema original: a transação e a produção estão acopladas e os novos requisitos de negócios envolvem vários sistemas upstream e downstream. ECLP, encomendas estrangeiras, guias de transporte, sistemas terminais, etc. A lógica de múltiplas linhas de negócios é acoplada e as mudanças nos requisitos de uma única linha de negócios envolvem a transformação associada de outras linhas de negócios no sistema original.
Novo sistema: dissociação de transações e operações de produção: as demandas relacionadas às transações são resolvidas no domínio do pedido; as demandas do lado da produção são resolvidas no domínio da produção, reduzindo as interações upstream e downstream.
Acoplamento de linhas de negócios: Diferentes linhas de negócios têm processos de negócios diferentes. As alterações nos requisitos de uma única linha de negócios só serão atualizadas iterativamente no processo específico e não afetarão outras linhas de negócios. Melhore a estabilidade de todo o processo e negócio.
2. Melhorar a velocidade de acesso de novos serviços
A central de pedidos fornece recursos padrão reutilizáveis para a recepção para aumentar a velocidade de introdução de novos negócios.
A central de pedidos divide e abstrai grandes aplicativos do sistema original em diversas combinações de aplicativos pequenos e oferece suporte à orquestração sob demanda de processos de negócios em diferentes cenários. Ao reutilizar os recursos padrão públicos da plataforma central, novas empresas podem acessar rapidamente a central de pedidos e evitar a duplicação das mesmas funções.
3. Forneça um modelo de dados global unificado
Sistema original: os pedidos pertencem a vários sistemas, incluindo pedidos externos, ECLP e sistemas de grande escala.Existem vários conjuntos de bancos de dados e a semântica de negócios não é unificada, o que torna inconveniente a construção de dados.
Novo sistema: A central de pedidos define uniformemente o modelo de dados padrão dos pedidos, permitindo que dados de diferentes negócios sejam armazenados no mesmo sistema, reduzindo a duplicação de funções relacionadas ao domínio dos pedidos, evitando desperdício de recursos e quebrando barreiras departamentais. Isso permite que dados e processos sejam gerenciados e otimizados centralmente, fornecendo dados padrão no domínio de pedidos para análise de negócios do grupo e previsão do futuro espaço de inovação da JD.com .
2. Introdução à arquitetura
2.1 Projeto geral da arquitetura
Através do projeto de atualização da arquitetura de tecnologia de ponta, o sistema de negociação é reconstruído com uma nova arquitetura de quatro camadas de execução de desempenho de transação de acesso. A ordem de transação é responsável por fechar o fluxo de documentos do contrato de serviço logístico entre logística e clientes, e também tem a responsabilidade de distribuir para o OFC downstream (camada de atendimento de pedidos).
2.2 Projeto de arquitetura de camada de dados em tempo real
2.2.1 Diagrama de interação do sistema
A interação do sistema é a seguinte:
A interface padrão da central de pedidos possui fechamento de documentos na camada superior, e também fizemos fechamento unificado na camada de dados.
Separe a arquitetura de negócios dos dados e separe projetos de alta disponibilidade e alto desempenho, como bancos de dados distribuídos, caches e consistência, do escopo da arquitetura de negócios, permitindo que a arquitetura de negócios se concentre no próprio negócio.
Sistema de persistência : usado para suportar a persistência de dados, como recebimento de pedidos, modificação de pedidos, cancelamento de pedidos, exclusão de pedidos, etc.
Sistema de pesquisa : fornece serviços como consulta de detalhes do pedido, consulta da lista de pedidos, consulta do fluxo de status do pedido e julgamento sobre se os pedidos de Baichuan são feitos.
Sistema de retransmissão : hub de dados, que grava dados de pedidos no Elasticsearch, HBase e MySQL por meio da fila de mensagens de consumo.
Sistema de reconciliação de dados : usado para comparar a consistência dos dados de vários conjuntos de middleware de armazenamento para garantir a consistência final dos dados.
Sistema de sincronização de dados : Sincronize as condições de consulta e os campos de exibição da lista necessários para a consulta da lista de pedidos do sistema antigo para a central de pedidos, que é usado para resolver o problema de paginação difícil devido aos dados de pedidos existentes nos sistemas antigo e novo durante o processo de corte.
2.2.2 Diagrama de arquitetura técnica
2.3 Vantagens de projeto
2.3.1 Alta disponibilidade
2.3.2 Alto desempenho
2.3.3 Processamento massivo de dados
2.3.4 Segurança de dados
Informações confidenciais são criptografadas e armazenadas. Log, Redis, ES, MySQL, HBase, etc., todos usam armazenamento criptografado. "Quem armazena, criptografa e quem usa, descriptografa."
3. Modelo de dados de pedido
3.1 Modelo PDM
No design do modelo de pedido, baseado nos princípios de atributos de negócios unificados, modelos gerais abstratos e indução de entidades comuns, o modelo de pedido é dividido principalmente nas informações do arquivo principal do pedido, nas informações do produto do pedido, nas informações do serviço logístico do pedido, as informações de marketing do pedido e o modelo do pedido, informações financeiras, informações do canal do cliente do pedido, informações de recebimento e entrega do pedido, informações de operação do pedido, informações estendidas do pedido, etc.
3.2 Escalabilidade do modelo
3.2.1 Projeto de extensibilidade do modelo padrão
Existem dezenas ou centenas de campos de identificação no pedido. Se novos campos forem usados todas as vezes, os atributos de negócios e o modelo de dados do pedido serão bastante expandidos, corroendo o modelo, e a eficiência do desenvolvimento será baixa, então o formato KV é usado para empreendê-lo e armazená-lo. Divida a identificação em vários domínios de negócios, como identificação de pedido, identificação de produto, identificação de marketing, etc.
3.2.2 Escalabilidade do modelo de negócios personalizado
Para negócios personalizados, é fornecido um conjunto de soluções configuráveis de gerenciamento de campos de banco de dados. Através de algumas configurações prontas para uso, quando os pedidos são enviados, modificados e consultados, diferentes modelos de dados podem ser encontrados com base na identidade comercial + tipo de negócio + campos de negócios.E codificação de expansão de dados, ou seja, encontrar qual tabela e campo armazenar. N atributos estendidos são reservados em cada tabela.Para o mesmo atributo estendido, diferentes identidades de negócios + tipos de negócios representam significados diferentes para obter armazenamento estendido.
4. Futuro e Desafios
4.1 Solicitar consulta personalizada
A demanda por consultas personalizadas aumenta, como consultas difusas, agregação em tempo real com base nas condições de consulta, etc. Se os índices ES forem colocados no mesmo cluster, isso afetará a estabilidade geral do cluster, mas após a divisão, os dados de negócios não podem ser consultado e exibido junto com outros negócios.
4.2 Arquitetura unitizada
A persistência do pedido atual TP99 é de 47ms, e o TP99 é de 20ms quando não está entre salas de computadores.Do ponto de vista dos dados, as salas entre computadores têm um grande impacto no desempenho.
A unitização permite que solicitações relacionadas do mesmo usuário sejam concluídas em um "circuito fechado" de todos os serviços em uma sala de computadores, eliminando o acesso "entre salas de computadores" . O método de implantação unificado permite que cada sala de computadores seja implantada em qualquer área e novas salas de computadores possam ser expandidas a qualquer momento. Através da unitização, continuaremos a fortalecer a base da plataforma de pedidos.
4.3 Controle de custos de hardware
O volume médio diário de pedidos continua a aumentar e a quantidade de dados está cada vez maior, seguida por um aumento nos custos de hardware.Como controlar o aumento nos custos de hardware é um desafio agora e no futuro. Planejamos reduzir os custos de armazenamento de dados por meio de arquivamento de dados, classificação de dados quentes e frios e outros métodos .
Multado em 200 yuans e mais de 1 milhão de yuans confiscados You Yuxi: A importância dos documentos chineses de alta qualidade Servidor de migração hard-core de Musk, Solon para JDK 21, threads virtuais são incríveis! ! ! O controle de congestionamento TCP salva a Internet Flutter para OpenHarmony está aqui O período LTS do kernel Linux será restaurado de 6 para 2 anos Go 1.22 corrigirá o erro da variável do loop for Svelte construiu uma "nova roda" - runas Google comemora seu 25º aniversárioAutor: Wang Weidong da JD Logistics
Fonte: JD Cloud Developer Community Ziyuanqishuo Tech Por favor, indique a fonte ao reimprimir