diga na frente
Na comunidade de leitores (50+) de Nien, um arquiteto de 40 anos , alguns amigos obtiveram recentemente qualificações para entrevistas de empresas de Internet de primeira linha, como Alibaba, NetEase, Youzan, Xiyin, Baidu, NetEase e Didi. encontrei algumas perguntas de entrevista muito importantes:
- Quais são os requisitos para um sistema de notificação de mensagens de nível empresarial? Como satisfazer?
- Como projetar a arquitetura de um sistema de notificação de mensagens de nível empresarial?
Nien lembrou que as questões relacionadas à arquitetura do sistema são o conhecimento central da arquitetura e os principais problemas online.
Portanto, aqui Nien lhe dará uma revisão sistemática e sistemática, para que você possa demonstrar plenamente seus fortes “músculos técnicos” e fazer o entrevistador “não se conter e babar” .
Esta pergunta e as respostas de referência também estão incluídas na versão V103 de nosso " Guia de entrevista Nion Java " para referência de amigos subsequentes para melhorar a arquitetura, o design e os níveis de desenvolvimento de três níveis de todos.
Para obter os PDFs mais recentes de "Nien Architecture Notes", "Nien High Concurrency Trilogy" e " Nien Java Interview Guide ", siga esta conta pública [Technical Freedom Circle] para obtê-los. Resposta: Obtenha o e-book
Diretório de artigos
-
- diga na frente
- Objetivos da arquitetura:
- A evolução das capacidades push
- A localização dos serviços push em sistemas de negócios
- Requisitos funcionais do serviço push:
- Enviar requisitos não funcionais (NFR):
- Arquitetura de design do sistema push:
-
- 1. Notifique o cliente:
- 2. Serviço de notificação:
- 3. Serviço de modelo:
- 4. Serviço de distribuição de mensagens
- 5. Fila de prioridade de eventos (fila de mensagens):
- 6. Manipulador de saída universal:
- 7. Notifique o adaptador:
- 8. Provedor de canal:
- 9. Seleção de serviços pelo usuário:
- 10. Serviço de perfil de usuário:
- 11. Serviços de análise
- 12. Rastreador de Notificação
- 13. Notificar banco de dados: cluster de banco de dados MySQL
- Diga no final
- Leitura recomendada
Objetivos da arquitetura:
Crie um serviço push básico unificado de nível empresarial que suporte push por meio de vários canais e possa integrar uniformemente e-mail, SMS, chat, DingTalk, WeChat corporativo e outros aplicativos sociais públicos:
- Bate-papo - Wechat/QQ
- Notificações push no site (dispositivos móveis e navegadores da web)
- Notificação push externa (dispositivo móvel, APP não está ativado)
- SMS (como senha de login, atividades de marketing)
- DingTalk
- WeChat Empresarial
O serviço push básico unificado de nível empresarial é um recurso geral que se aplica a todos os aplicativos distribuídos modernos, independentemente da linguagem de programação e da tecnologia usada.
A evolução das capacidades push
A primeira etapa (modularização): assuntos e embalagens separados
Dentro da empresa, o volume de negócios no início era relativamente pequeno, e cada sistema tinha basicamente seu próprio módulo push, com vários tipos:
- Módulo de bate-papo
- Módulo SMS
- Módulo de e-mail
- módulo websocket
É relativamente simples empacotar os módulos individualmente, mas é difícil conseguir a descentralização e garantir a qualidade de cada módulo do sistema de forma unificada.
A segunda etapa (enquadramento): quadro integrado
A fim de reduzir custos repetitivos de projeto e desenvolvimento, uma estrutura push unificada foi projetada
O mesmo conjunto de estruturas de microsserviços compartilha uma estrutura push unificada
A fim de resolver os problemas de implementação descentralizada acima mencionados, a empresa unificou e implementou uma biblioteca básica que integra várias funções push para que as partes empresariais possam ligar de maneira uniforme.
- Iniciador básico de bate-papo
- Iniciador básico de SMS
- Iniciador básico de e-mail
- iniciante básico do websocket
Portanto, encapsulamos a lógica do springboot-starter na estrutura de governança de serviços.Quando o serviço de microsserviço é iniciado, cada serviço executa o gerenciamento de operação e manutenção e o gerenciamento de configuração de vários starters.
A terceira etapa (servitização): serviço push
Integrado na estrutura, cada conjunto de serviços precisa resolver repetidamente três problemas de alto nível.
- O serviço push possui uma grande quantidade de dados e precisa resolver o problema de consulta entre bancos de dados
- O serviço push tem requisitos de alto desempenho e precisa resolver problemas de alta simultaneidade
Grande volume de dados e alta simultaneidade significam:
- Investimento pesado em recursos de hardware
- Altos custos de operação e manutenção
Esses serviços básicos precisam de ser precipitados, despojados e concentrados num serviço básico unificado, que seja mantido, iterado e operado por uma equipa dedicada. Reduza investimentos repetidos e custos repetidos de construção, reduzindo verdadeiramente os custos e aumentando a eficiência.
Como resultado, a estrutura push evoluiu para serviço push
A localização dos serviços push em sistemas de negócios
Um aplicativo de negócios basicamente possui muitos serviços atômicos orquestrados e integrados e, finalmente, constrói um diagrama de arquitetura completo.
- Camada de acesso , que é o portal para solicitações externas entrarem no sistema interno, e todas as solicitações devem passar pelo gateway da API.
- A camada de aplicação , também conhecida como camada de agregação, fornece interfaces de agregação para negócios relacionados e chama serviços de médio porte para combinação.
- Os serviços atômicos incluem serviços técnicos atômicos e serviços comerciais atômicos, que fornecem interfaces relevantes de acordo com as necessidades do negócio. Os serviços atômicos fornecem recursos reutilizáveis para toda a arquitetura.
Por exemplo, na plataforma do site de vídeos Bilibili, o serviço de comentários é um serviço atômico necessário para vídeos, artigos e comunidades em Bilibili. Para melhorar a reutilização, o serviço de comentários pode ser um serviço atômico independente e não pode ser usado com necessidades específicas. Fortemente acoplados.
Neste caso, o serviço de comentários precisa fornecer uma capacidade de reutilização que possa se adaptar a diferentes cenários.
NOTA: Clique na imagem para ver um diagrama arquitetônico claro!
Da mesma forma, funções como armazenamento de arquivos, armazenamento de dados, serviços push e serviços de autenticação serão precipitadas em serviços atômicos.Os desenvolvedores de negócios podem construir rapidamente aplicativos de negócios orquestrando, configurando e combinando-os com base em serviços atômicos.
Claro, este artigo se concentra apenas em serviços push. Para outros serviços atômicos, Nien, um arquiteto de 40 anos, irá apresentá-los em outros artigos. Para obter detalhes, continue prestando atenção à conta pública de Nien, Technology Free Circle.
Requisitos funcionais do serviço push:
- Enviar notificação
- Priorizar notificações
- Envie notificações com base nas preferências salvas dos clientes
- Suporta mensagens de notificação únicas/simples e mensagens de notificação em lote
- Análise de casos de uso para diversas notificações
- Relatório de mensagens de notificação
Enviar requisitos não funcionais (NFR):
- Alto desempenho : qps > 1W
- Alta disponibilidade (HA): 99,99%
- Baixa latência : TP99 abaixo de 10ms
- Altamente escalável : Design extensível/conectável para adicionar mais adaptadores e provedores, integração de API com todos os módulos de notificação e integração externa com clientes e provedores/fornecedores de serviços
- Multiplataforma : suporta dispositivos móveis Android/iOS e navegadores de desktop/laptop
- Autoescalonamento : dimensiona cargas de trabalho no local (VMware Tanzu) e em serviços de nuvem pública, como AWS, GCP ou Azure
Arquitetura de design do sistema push:
NOTA: Clique na imagem para ver um diagrama arquitetônico claro!
As considerações e componentes para esses designs de solução incluem:
1. Notifique o cliente:
Esses clientes solicitam mensagens únicas e em lote por meio de chamadas de API. Eles enviarão mensagens de notificação para os serviços de notificação simples e em massa.
- Cliente de Notificação Simples : Cliente dedicado ao envio de uma única notificação, responsável por enviar uma única notificação ao usuário. Esses clientes geralmente são usados para enviar notificações importantes a usuários específicos, como recuperação de senha ou lembretes de exceção de conta.
- Cliente de notificação em lote : um cliente dedicado ao envio de notificações em lote, responsável por enviar notificações aos usuários em lotes. Esses clientes são normalmente usados em cenários onde um grande número de usuários precisa ser notificado, como notificações corporativas internas ou campanhas de marketing.
2. Serviço de notificação:
Esses serviços, como pontos de entrada, interagem com os clientes expondo APIs REST.
Eles são responsáveis por construir mensagens de notificação chamando "serviços de modelo". Estas mensagens serão verificadas através de um “serviço de validação”.
- Serviço de notificação simples : Este serviço fornecerá uma API, responsável principalmente pelo processamento de solicitações de notificação simples, e fornecerá uma API integrada com serviços de back-end para enviar notificações aos usuários. Esse serviço normalmente é usado para lidar com menos solicitações de notificação, como notificações simples para um usuário ou evento específico.
- Serviço de notificação em lote : Este serviço fornecerá uma API, responsável principalmente pelo processamento de solicitações de notificação em lote, e fornecerá uma API integrada com serviços de back-end para enviar notificações em lote. Esse serviço geralmente é usado para lidar com um grande número de solicitações de notificação, como notificações em lote dentro de uma empresa ou envios em lote para atividades de marketing.
Este serviço também gerenciará mensagens de notificação. Ele persiste as mensagens enviadas para um banco de dados e mantém um log de atividades.
A mesma mensagem pode ser reenviada utilizando as APIs desses serviços.
Ele fornecerá API para adicionar/atualizar/excluir e visualizar mensagens novas e antigas.
Ele também fornecerá um painel da web que deverá ter opções de filtragem para filtrar mensagens com base em diferentes critérios, como intervalo de datas, prioridade, usuário do módulo, grupo de usuários, etc.
3. Serviço de modelo:
Este serviço é o principal responsável pelo gerenciamento de modelos de todas as senhas de uso único (OTP), SMS, e-mail, chat e outras mensagens de notificação push disponíveis.
Ele também fornece uma API REST para criar, atualizar, excluir e gerenciar modelos.
Além disso, fornecerá uma página de painel de interface do usuário (IU) que permite aos usuários inspecionar e gerenciar vários modelos de mensagens a partir de um console da web.
4. Serviço de distribuição de mensagens
- Serviço de distribuição programada:
O serviço fornecerá uma API para agendar notificações imediatamente ou em um horário especificado. Pode ser qualquer um dos seguintes:
- Segundo
- minuto
- por hora
- diariamente
- semanalmente
- por mês
- Por ano
- Frequência personalizada etc.
Também pode haver outros serviços acionados automaticamente, acionadores de mensagens baseados em horários programados.
- Serviço de autenticação de mensagens:
Este serviço é o único responsável por verificar as informações de notificação em relação às regulamentações comerciais e aos formatos esperados. As notificações em massa requerem o consentimento de um administrador de sistema autorizado.
- Serviço prioritário de mensagens:
Este serviço é responsável por priorizar as notificações em níveis alto, médio e baixo.
As mensagens de notificação têm prioridade mais alta e expiração com prazo determinado, e sempre serão enviadas com prioridade mais alta.
O “Processador de Saída Geral” receberá mensagens e as enviará e processará de três filas diferentes de alta, média e baixa de acordo com a mesma prioridade.
Notificações em massa podem ser enviadas com baixa prioridade fora do horário comercial.
As notificações do aplicativo durante as transações podem ser enviadas com prioridade média, como e-mail, etc. As empresas podem priorizar as notificações com base na sua importância.
5. Fila de prioridade de eventos (fila de mensagens):
Este serviço desempenha a função de central de eventos e é responsável por receber informações de alta, média e baixa prioridade do serviço de notificação.
Ele envia e recebe notificações com base nas prioridades do negócio. As empresas podem priorizar as notificações com base na sua importância.
O serviço contém três tópicos internos para recebimento e envio de notificações com base nas prioridades do negócio:
- Baixa prioridade : usado principalmente para enviar notificações em lote fora do horário comercial.
- Prioridade Média : Adequado para notificações de aplicativos enviadas durante transações, como e-mails, etc.
- Alta prioridade : As mensagens de notificação têm prioridade mais alta e expiração por tempo limitado, sempre serão enviadas com prioridade mais alta.
6. Manipulador de saída universal:
O serviço recebe informações de notificação na central de eventos pesquisando a fila de prioridade de eventos e as processa de acordo com sua prioridade.
As notificações de alta prioridade serão processadas primeiro na fila "alta" e assim por diante.
Por fim, envia as informações de notificação para o adaptador específico através do hub de eventos.
Além disso, o serviço obtém usuários/aplicativos alvo do serviço de seleção de usuários para distribuição de notificações.
Durante o processo de processamento, o processador de saída geral executará as operações correspondentes de acordo com a prioridade do evento para garantir que os eventos importantes sejam processados primeiro.
Desta forma, as empresas podem determinar a sequência de processamento com base na prioridade das notificações, melhorando assim a eficiência do processamento de notificações.
Além disso, o manipulador de saída universal pode distribuir mensagens de acordo com o tipo de canal:
Este serviço envia mensagens para vários adaptadores suportados.
Esses adaptadores são convertidos com base em diferentes dispositivos (por exemplo, desktop/móvel) e tipos de notificação (por exemplo, SMS/OTP/e-mail/chat/notificações push).
7. Notifique o adaptador:
Esses conversores receberão informações da fila de mensagens (rocketmq) e as repassarão para parceiros externos de acordo com o formato que suportam.
Aqui estão alguns conversores, mais podem ser adicionados conforme necessário:
- Serviço de adaptador de notificação QQ
- Serviço de adaptador de notificação de bate-papo WeChat
- Serviço de adaptador de notificação no aplicativo
- Serviço de adaptador de e-mail
- Serviço de adaptador SMS
- Serviço de adaptador OTP
8. Provedor de canal:
Esses são provedores de serviços externos SAAS (on-cloud/on-premises) que aproveitam sua infraestrutura e tecnologia para a entrega real de notificações.
Eles podem ser serviços de canais push pagos, como AWS SNS, MailChimp, etc.
- Serviço de integração de fornecedores QQ
- Serviço de integração de fornecedores Wechat
- Serviço de integração de fornecedor de notificação push de aplicativo
- Serviços de integração de provedor de e-mail
- Serviços de integração de provedores de SMS
9. Seleção de serviços pelo usuário:
O serviço oferece a capacidade de selecionar usuários-alvo e vários módulos de aplicativos.
Isto pode incluir o envio de mensagens em massa para grupos específicos de usuários ou para diferentes módulos de aplicativos.
Pode ser AD/IAM/eDirectory/Banco de dados de usuários/Grupos de usuários, dependendo da preferência do cliente.
Dentro do serviço, utilizará a API “User Profile Service” para consumir e verificar as preferências de notificação do cliente.
10. Serviço de perfil de usuário:
Este serviço oferece diversas funções, incluindo o gerenciamento de perfis de usuários e suas preferências.
Também gerencia o relacionamento entre IDs de usuários internos e IDs de canais externos
- A relação entre ID de usuário DingTalk e ID de usuário
- ID de usuário do Enterprise WeChat e relacionamento de associação de ID de usuário
- A relação entre usuários e caixas de correio
- etc.
Ele também fornecerá recursos como cancelar a assinatura de notificações e a frequência com que você recebe notificações.
O “Serviço de Notificação” contará com este serviço para enviar notificações com base nas preferências de notificação do usuário.
Além disso, este serviço também pode ser usado para coletar estatísticas e analisar as preferências dos usuários em relação a notificações para ajudar as empresas a otimizar estratégias de notificação.
11. Serviços de análise
O processador será responsável por realizar todas as análises, identificando o uso de notificações, tendências e gerando relatórios.
Ele extrairá todas as informações de notificação final do banco de dados analítico (Cassandra) e do banco de dados de notificação para fins de análise e geração de relatórios.
Aqui estão alguns casos de uso:
- Número total de notificações por dia/segundo
- Qual sistema de notificação é usado com mais frequência?
- Tamanho médio e frequência das mensagens
- Filtre mensagens com base na prioridade e muito mais…
12. Rastreador de Notificação
Este serviço monitorará continuamente a fila do hub de eventos e acompanhará todas as notificações enviadas.
Ele captura metadados de notificação, como tempo de transmissão, status de entrega, canal de comunicação, tipo de mensagem, etc.
13. Notificar banco de dados: cluster de banco de dados MySQL
O banco de dados de notificação é usado para armazenar todas as informações de notificação, incluindo horário de envio, status, etc.
Consiste em um cluster de banco de dados onde o líder é usado para realizar todas as operações de gravação e as operações de leitura são executadas em réplicas/seguidores de leitura.
Este cluster de banco de dados persistirá todas as notificações para análise e relatórios.
Baseia-se na filosofia de “escreva mais, leia menos”.
Ele oferece bom desempenho e baixa latência, adapta-se a um grande número de notificações, pois lida internamente com um grande número de operações de gravação e sincroniza com outros nós do banco de dados para manter alta disponibilidade e confiabilidade de dados/mensagens redundantes.
Em caso de falha de qualquer nó, as mensagens estarão sempre disponíveis.
Claro, também pode ser um banco de dados cluster NoSQL.
Diga no final
Perguntas de entrevista relacionadas a tecnologias básicas, como serviços push, são perguntas de entrevista muito comuns.
Se você conseguir responder ao conteúdo acima com fluência e familiaridade, basicamente o entrevistador ficará chocado e atraído por você.
No final, o entrevistador se apaixonou tanto que “não se conteve, babando” . A oferta está chegando.
Durante o processo de aprendizagem, se você tiver alguma dúvida, pode procurar o arquiteto Nien, de 40 anos, para se comunicar.
Leitura recomendada
" Alibaba 2: Quantos nós você implanta?" Como implantar simultaneidade de 1000W? 》
" Meituan 2 lados: cinco noves alta disponibilidade 99,999%. Como conseguir isso?" 》
" Lado NetEase: nó único 2.000 Wtps, como Kafka faz isso?" 》
" Byte Side: Qual é a relação entre compensação de transação e nova tentativa de transação?" 》
" Como estruturar vídeos curtos de bilhões de níveis? " 》
" Explodir, confiar em" se gabar "para passar pelo JD.com, salário mensal de 40 mil "
" É tão feroz que confio em" me gabar "para passar pelo SF Express, e meu salário mensal é de 30 mil "
" Explodiu ... Jingdong pediu 40 perguntas de um lado e, depois de passar, foram mais de 500.000 "
" Ele.me é muito cruel: Enfrente um Java avançado, como é um trabalho árduo e cruel "
" Depois de uma hora de perguntas malucas por Byte, o cara recebeu a oferta, é tão cruel!" 》
"Nien Architecture Notes", "Nien High Concurrency Trilogy", "Nien Java Interview Guide" PDF, acesse a seguinte conta oficial [Technical Freedom Circle] para obter ↓↓↓