Código-fonte deste artigo: GitHub · clique aqui || GitEE · clique aqui
1. Baseado em negócios
Os serviços de dados geralmente têm muitos modelos de negócios, o que leva a uma arquitetura de sistema e negócios complexos. Diferentes empresas têm seus próprios recursos e complexidade. O gerenciamento de dados em si não é uma tarefa fácil, portanto, no estágio inicial da arquitetura do sistema, os cenários de negócios consideram os recursos do serviço:
Serviço API: serviço de dados baseado em modo Http, que obtém dados por meio de requisição, como modelo de controle de risco, scoring, antifraude e outros serviços;
Serviços de plataforma: um sistema de integração de capacidade de serviço abrangente, com baixa demanda do cliente por serviços personalizados e recursos de serviço de dados de processo completos, como uma plataforma de marketing digital automatizada que fornece recursos de gerenciamento de processo completo para marketing;
Serviço de coleta: normalmente, os clientes enviam eventos de cliques relacionados como uma forma de enterrar pontos, e o sistema de coleta realiza uma análise resumida com base em omni-canais e fornece feedback aos clientes;
Análise visual: é dividida em duas áreas principais, análise de dados e visualização.Os dados podem ser carregados em várias fontes de dados para análise conjunta e análise altamente automatizada com base em componentes front-end, como sistemas de insight de dados comuns;
Privatização de ferramentas: Com base nas capacidades técnicas acumuladas, venda diretamente os sistemas de gerenciamento de dados aos clientes e implemente-os em seus próprios serviços locais;
No cenário de serviço de dados, empresas diferentes precisam de suporte de dados em seus respectivos cenários, mas empresas diferentes precisam das mesmas funções básicas, como operações, liquidação, pedidos, etc. Para entender diferentes cenários de negócios, é muito simples encontrar pontos e diferenças comuns A ideia: as semelhanças desenvolvem-se nos serviços públicos e os diferenciais de negócio desenvolvem-se nos serviços independentes para facilitar a expansão e evolução contínua do sistema.
Dois, arquitetura da camada de negócios
A maior diferença entre os diferentes recursos de serviço de dados é que eles precisam contar com o suporte dos dados principais. De uma perspectiva de negócios, a camada de arquitetura do sistema também requer funções públicas complexas. Elas precisam ser consideradas no estágio inicial da arquitetura, caso contrário o negócio vai se desenvolver rapidamente e está prestes a enfrentar o problema da reconstrução.
Operação do cliente: cada acesso do cliente requer um conjunto completo de procedimentos, descrições de serviço, regras de faturamento, gerenciamento de contrato, recarga, ativação e desativação de serviço, faturamento e uma série de funções de suporte. Normalmente, há duas entradas: final de login do cliente, o lado do serviço fim da operação.
Pagamento e liquidação: o módulo de sistema mais complexo que fornece recursos de pagamento, como a agregação de vários canais de pagamento para resolver a recarga e o reembolso do cliente ou as próprias necessidades de pagamento da parte do serviço, e fornece vários dados de liquidação de contas e capacidade de reconciliação de saldo.
Gerenciamento de pedidos: cada solicitação do cliente, ou o uso de cada serviço, requer registros detalhados de pedidos para ações de faturamento que envolvem preço unitário, número do pedido e tempo. Como base principal para a liquidação, são também os dados de negócios mais concentrados. O local onde ocorreu o surto.
Sistema de autoridade: No sistema de serviço de dados, o design do sistema de autoridade se concentra mais em resolver as necessidades do corpo principal da empresa. Diferentes equipes de negócios são responsáveis por diferentes operações de serviço, gestão de clientes, etc., portanto, uma gestão de autoridade clara e sistemática é necessário para funções diferentes.O pessoal de negócios aloca permissões razoáveis.
Integração de log: no sistema de log detalhado, os dados de log de negócios normais podem ser usados para análise de conclusão de dados quando o serviço é anormal, e os dados de log anormais podem ser usados para desenvolvedores analisarem problemas e gargalos do sistema para otimizar continuamente os recursos do serviço.
A divisão e o design de serviços com base em cenários de negócios, bem como a construção básica de serviços públicos, garantem que a estrutura da camada de negócios seja razoável e escalável. A consideração básica para saber se é razoável é se os novos cenários de negócios contínuos exigem revisões drásticas do sistema.Se a capacidade de serviço for continuamente enriquecida, o custo da transformação do sistema será pequeno e a estrutura natural será razoável.
3. Data Center
Diferentes cenários de serviços de negócios precisam contar com recursos de dados principais. Este é o ponto de venda do serviço. Os recursos de serviço de suporte de dados principais são geralmente implantados separadamente e fornecem vários cenários de serviço, que geralmente são entendidos como centros de dados. Ao mesmo tempo, Os próprios serviços de negócios também irão gerar vários dados., Aqui serão armazenados de forma independente de acordo com o método de implantação do serviço.
Capacidade de serviço: como uma dependência pública de várias empresas, o data center não só precisa fornecer recursos de consulta com base em dados, mas também precisa fornecer determinados sistemas de programação e computador ao processar grandes tarefas de dados.
Método de implantação: de acordo com as características dos dados, eles geralmente serão armazenados de várias maneiras, como clusters, sub-bancos de dados e tabelas, mecanismos OLAP, data warehouses, etc., e fornecerão recursos de serviço unificados com base nas características dos dados e aberto para a camada de negócios.
Atualização de dados: os dados precisam ser atualizados em tempo real ou regularmente. A origem dos dados geralmente são vários dados calculados e processados por big data e dados que são verificados incorretamente pela camada de negócios ou dados que são continuamente otimizados durante o uso.
A implantação da arquitetura independente do data center é uma operação muito necessária. A maioria dos dados está vinculada. O processamento da vinculação entre os dados não precisa ser acoplado ao nível de negócios. O fluxo de dados, correção, gerenciamento de segurança, etc. pode todos no data center. O gerenciamento unificado evita uma série de problemas complexos causados pela implantação mista de dados.
Quarto, a camada inferior do big data
O nível mais baixo de recursos de serviço de dados requer recursos de processamento de dados massivos, portanto, muitas tecnologias de componentes de big data são usadas para armazenar, calcular, analisar e mover dados.
Armazenamento de dados: o armazenamento mais comum na parte inferior do big data está na forma de arquivos, armazenamento de banco de dados estruturado, arquivos de log semiestruturados e alguns dados não estruturados.
Poder de computação: O processamento de dados massivos precisa contar com uma variedade de computação paralela, tarefas offline, computação em tempo real e outros métodos para atingir o propósito de processamento rápido.
Tratamento de dados: após a conclusão do processamento de dados, os recursos de serviço não são fornecidos diretamente na camada inferior. Os dados geralmente são sincronizados com o data center superior para fornecer recursos de serviço para a empresa. O tratamento aqui pode ser a saída de dados ou a entrada de dados a serem processados .
Os componentes subjacentes do big data são os principais recursos do sistema. O cálculo e a análise precisos dos dados garantem os recursos do serviço, e a automação contínua e o gerenciamento baseado em ferramentas da arquitetura existente são muito importantes. O processo de gerenciamento de dados massivos é mais manual. Mais significa que a eficiência é menor, especialmente no processo de envio de dados para o data center ou recebimento de dados na camada inferior, é necessário concordar com uma estratégia para garantir a transmissão automática de dados segura e estável.
Cinco, consideração geral
Para o design de um sistema complexo, o mais importante é classificar claramente o modelo de negócios, analisar o modelo de negócios e fazer a arquitetura do sistema com base nas características de negócios para evitar muitos desvios, como o sistema de serviço de dados acima:
Em primeiro lugar, de uma grande perspectiva, o sistema divide as três partes principais de serviços de negócios, data centers e recursos subjacentes de big data e exige que não haja uma relação de acoplamento forte entre cada módulo grande para garantir que os módulos possam ser expandidos independentemente;
Em segundo lugar, determine as funções básicas exigidas por cada módulo, a camada de negócios garante os recursos básicos de serviço e, em seguida, extrai e encapsula as funções básicas exigidas por cada empresa, separa os serviços de negócios e os serviços públicos e oferece suporte aos recursos de negócios;
Em seguida, determine o modo de colaboração entre os vários módulos, como os recursos de comunicação entre a empresa e o data center, padrões de interface, segurança de dados e outros detalhes, ou o modo de tratamento de dados entre o data center e o big data subjacente, para garantir capacidades de circulação de dados;
Por fim, são implementados os detalhes específicos de cada módulo. O que deve ser considerado aqui é que de acordo com o modelo de negócio, se os mesmos componentes e métodos de arquitetura podem ser selecionados, tente unificar a seleção de arquitetura e dependências de componentes, e reduzir as barreiras entre diferentes módulos;
A arquitetura completa do sistema acima mencionada leva cerca de sete meses desde o início do estabelecimento até o fornecimento de capacidades de serviço estáveis. Durante este período, está em constante evolução e atualização, e novos módulos de serviço são continuamente lançados e o monitoramento do sistema é realizado até os serviços de negócios são relativamente completos e sistemáticos, relativamente estáveis.
Seis, endereço do código-fonte
GitHub地址：知了一笑
https://github.com/cicadasmile/spring-cloud-base
GitEE地址：知了一笑
https://gitee.com/cicadasmile/spring-cloud-base
Leia o rótulo
[ Java Foundation ] [ Design Pattern ] [ Estrutura e Algoritmo ] [ Sistema Linux ] [ Banco de Dados ]
[ Arquitetura distribuída ] [ micro serviço ] [ componentes de big data ] [ SpringBoot Advanced ] [ Spring & Boot Foundation ]
[ Análise de dados ] [ Mapa técnico ] [ Local de trabalho ]
