visão geral
Este artigo toma o Taobao como exemplo para apresentar o processo de evolução da arquitetura do lado do servidor de cem simultaneidades para dezenas de milhões de simultaneidades. Ao mesmo tempo, lista as tecnologias relacionadas que serão encontradas em cada estágio de evolução, para que todos podem ter uma compreensão geral da evolução da arquitetura.Cognição, o artigo conclui com um resumo de alguns princípios do projeto arquitetônico.
conceito básico
Antes de apresentar a arquitetura, para evitar que alguns leitores ignorem alguns conceitos do projeto de arquitetura, apresentamos a seguir os conceitos mais básicos:
1. Distribuído
Vários módulos do sistema são implantados em servidores diferentes, que podem ser chamados de sistema distribuído.Por exemplo, o Tomcat e o banco de dados são implantados em servidores diferentes, ou dois Tomcats com a mesma função são implantados em servidores diferentes.
2. Alta disponibilidade
Quando alguns nós do sistema falham, outros nós podem assumir o controle e continuar a fornecer serviços, então o sistema pode ser considerado como tendo alta disponibilidade.
3. Aglomerado
Um software específico de domínio é implantado em vários servidores e fornece uma classe de serviços como um todo, chamada cluster. Por exemplo, o Master e o Slave no Zookeeper são implantados em vários servidores respectivamente, formando um todo para fornecer serviços de configuração centralizados. Em um cluster comum, o cliente geralmente pode se conectar a qualquer nó para obter serviços e, quando um nó no cluster fica offline, outros nós podem assumir automaticamente o controle e continuar a fornecer serviços, o que indica que o cluster tem alta disponibilidade.
4. Balanceamento de carga
Quando uma solicitação é enviada ao sistema, o sistema pode ser considerado com balanceamento de carga se a solicitação for distribuída uniformemente para vários nós de alguma forma, de modo que cada nó no sistema possa lidar com a carga da solicitação de maneira uniforme.
5. Proxy de encaminhamento e proxy reverso
Quando o sistema deseja acessar a rede externa, a solicitação é encaminhada através de um servidor proxy. Do ponto de vista da rede externa, é o acesso iniciado pelo servidor proxy. Neste momento, o servidor proxy implementa um proxy de encaminhamento; quando a solicitação externa entra no sistema, o servidor proxy envia A solicitação é encaminhada para um servidor no sistema. Para solicitações externas, apenas o servidor proxy interage com ele. Neste momento, o servidor proxy implementa um proxy reverso. Simplificando, proxy de encaminhamento é um processo no qual um servidor proxy substitui o sistema interno para acessar a rede externa, e proxy reverso é um processo no qual solicitações externas de acesso ao sistema são encaminhadas para o servidor interno por meio do servidor proxy.
evolução da arquitetura
arquitetura autônoma
Veja o Taobao como exemplo. No início do site, o número de aplicações e usuários era pequeno, então o Tomcat e o banco de dados podiam ser implantados no mesmo servidor. Quando o navegador inicia uma solicitação para www.taobao.com, ele primeiro converte o nome de domínio no endereço IP real 10.102.4.1 por meio do servidor DNS (Domain Name System) e, em seguida, o navegador acessa o Tomcat correspondente a este IP.
À medida que o número de usuários aumenta, o Tomcat e o banco de dados competem por recursos, e o desempenho de uma única máquina não é suficiente para suportar o negócio
A primeira evolução: o Tomcat é implantado separadamente do banco de dados
O Tomcat e o banco de dados monopolizam os recursos do servidor respectivamente, melhorando significativamente seu respectivo desempenho.
À medida que o número de usuários aumenta, leituras e gravações simultâneas no banco de dados tornam-se um gargalo
A segunda evolução: a introdução do cache local e do cache distribuído
Adicione um cache local no mesmo servidor Tomcat ou na mesma JVM e adicione um cache distribuído externamente para armazenar informações de produtos populares ou páginas HTML de produtos populares, etc. Através do cache, a maioria das solicitações pode ser interceptada antes da leitura e gravação no banco de dados, reduzindo bastante a pressão no banco de dados. As tecnologias envolvidas incluem: usar memcached como cache local, usar Redis como cache distribuído e também envolve questões como consistência de cache, penetração/quebra de cache, avalanche de cache e invalidação de conjuntos de dados importantes.
O cache resiste à maioria das solicitações de acesso.À medida que o número de usuários aumenta, a pressão de simultaneidade recai principalmente sobre o Tomcat autônomo e a resposta diminui gradualmente.
A terceira evolução: a introdução do proxy reverso para alcançar o balanceamento de carga
Implante o Tomcat em vários servidores e use software de proxy reverso (Nginx) para distribuir uniformemente as solicitações para cada Tomcat. Presume-se aqui que o Tomcat suporta até 100 simultaneidades e o Nginx suporta até 50.000 simultaneidades.Em teoria, o Nginx pode resistir a 50.000 simultaneidades distribuindo solicitações para 500 Tomcats. As tecnologias envolvidas incluem: Nginx e HAProxy, ambos softwares de proxy reverso que funcionam na sétima camada da rede. Eles suportam principalmente o protocolo http e também envolvem compartilhamento de sessão, upload e download de arquivos.
O proxy reverso aumenta muito a simultaneidade que o servidor de aplicativos pode suportar, mas o aumento na simultaneidade também significa que mais solicitações penetram no banco de dados, e o banco de dados independente eventualmente se torna o gargalo
A quarta evolução: separação de leitura e gravação do banco de dados
Divida o banco de dados em bancos de dados de leitura e gravação. Pode haver vários bancos de dados de leitura. Os dados no banco de dados de gravação são sincronizados com o banco de dados de leitura por meio do mecanismo de sincronização. Para a cena em que você precisa consultar os dados gravados mais recentes, você pode escrever um cópia extra no cache. O cache obtém os dados mais recentes. As tecnologias envolvidas incluem: Mycat, que é um middleware de banco de dados, por meio do qual a leitura e gravação separadas do banco de dados e das subtabelas do sub-banco de dados podem ser organizadas. O cliente pode acessar o banco de dados subjacente por meio dele, e também envolverá dados problemas de sincronização e consistência de dados.
Há cada vez mais empresas e há uma grande lacuna no número de visitas entre diferentes empresas. Diferentes empresas competem diretamente com o banco de dados e afetam o desempenho umas das outras.
Quinta Evolução: Segmentação de Banco de Dados por Negócios
Salve os dados de diferentes empresas em diferentes bancos de dados para reduzir a competição de recursos entre as empresas. Para empresas com um grande número de visitas, mais servidores podem ser implantados para apoiá-las. Isso também impossibilita a realização direta de análises de correlação em tabelas cross-business e precisa ser resolvido por outros meios, mas esse não é o foco deste artigo. Os interessados podem buscar soluções por conta própria.
Com o aumento do número de usuários, a biblioteca de gravação de máquina única atingirá gradualmente o gargalo de desempenho
A sexta evolução: dividir a mesa grande em mesas pequenas
Por exemplo, para dados de comentários, eles podem ser hash de acordo com o ID do produto e roteados para a tabela correspondente para armazenamento; para registros de pagamento, uma tabela pode ser criada por hora, e cada tabela de horas pode ser dividida em pequenas tabelas, e o usuário ID ou número de registro podem ser usados para rotear dados. Contanto que a quantidade de dados da tabela para operações em tempo real seja pequena o suficiente e as solicitações possam ser distribuídas uniformemente para pequenas tabelas em vários servidores, o banco de dados poderá melhorar o desempenho por meio da expansão horizontal. O mencionado Mycat também suporta controle de acesso quando tabelas grandes são divididas em tabelas pequenas.
Essa abordagem aumenta significativamente a dificuldade de operação e manutenção do banco de dados e possui requisitos mais elevados para DBAs. Quando o banco de dados é projetado com esta estrutura, ele já pode ser chamado de banco de dados distribuído, mas este é apenas um banco de dados lógico como um todo.Diferentes componentes do banco de dados são implementados por diferentes componentes, como o gerenciamento e solicitação de sub-banco de dados e subtabela. A distribuição é implementada pelo Mycat, a análise SQL é implementada por um banco de dados independente, a separação leitura-gravação pode ser implementada por um gateway e uma fila de mensagens, e o resumo dos resultados da consulta pode ser implementado por uma interface de banco de dados camada, etc. Esta arquitetura é na verdade uma arquitetura MPP (classe A de implementações de processamento paralelo em larga escala).
Atualmente, existem muitos bancos de dados MPP em código aberto e uso comercial. Greenplum, TiDB, Postgresql XC, HAWQ, etc. são mais populares em código aberto, e os comerciais incluem GBase de NTU General, Snowball DB de Ruifan Technology, LibrA da Huawei, etc. Diferentes bancos de dados MPP têm ênfases diferentes. Por exemplo, TiDB se concentra mais em cenários OLTP distribuídos e Greenplum se concentra mais em cenários OLAP distribuídos. Esses bancos de dados MPP basicamente fornecem recursos de suporte padrão SQL semelhantes a Postgresql, Oracle e MySQL. Ele pode analisar uma consulta em um plano de execução distribuído e distribuí-lo para cada máquina para execução paralela. Finalmente, o próprio banco de dados resume os dados e os retorna. Ele também fornece recursos como gerenciamento de autoridade, subtabela de subbanco de dados, transação, e cópia de dados.Ele pode suportar clusters de mais de 100 nós, reduzindo significativamente o custo de operação e manutenção do banco de dados e permitindo que o banco de dados alcance expansão horizontal.
Tanto o banco de dados quanto o Tomcat podem ser expandidos horizontalmente e a simultaneidade suportada aumenta bastante.À medida que o número de usuários cresce, o Nginx autônomo acabará se tornando o gargalo
A sétima evolução:
Use LVS ou F5 para balancear a carga de vários Nginx
Como o gargalo é o Nginx, é impossível obter balanceamento de carga de vários Nginxes por meio de duas camadas do Nginx. LVS e F5 na figura são soluções de balanceamento de carga que trabalham na quarta camada da rede. LVS é um software que roda no estado do kernel do sistema operacional e pode encaminhar solicitações TCP ou protocolos de rede de nível superior. Portanto, os protocolos suportados são mais É rico e seu desempenho é muito superior ao do Nginx. Pode-se presumir que um LVS de máquina única pode suportar centenas de milhares de encaminhamento de solicitações simultâneas; F5 é um tipo de hardware de balanceamento de carga, semelhante ao recursos fornecidos pelo LVS e tem desempenho superior ao LVS, mas é caro. Como o LVS é um software independente, se o servidor onde o LVS está localizado falhar, todo o sistema back-end ficará inacessível, portanto, é necessário um nó de backup. Você pode usar o software keepalived para simular um IP virtual e, em seguida, vincular o IP virtual a vários servidores LVS. Quando o navegador acessar o IP virtual, ele será redirecionado para o servidor LVS real pelo roteador. Quando o servidor LVS principal for desativado, o software keepalived atualizará automaticamente a tabela de roteamento no roteador e redirecionará o IP virtual para outro servidor LVS normal, de modo a obter o efeito de alta disponibilidade do servidor LVS.
Deve-se notar aqui que o desenho da camada Nginx para a camada Tomcat na figura acima não significa que todos os Nginx encaminham solicitações para todos os Tomcats.No uso real, pode ser que vários Nginxes estejam conectados a uma parte do Tomcat. A alta disponibilidade é alcançada através do keepalived, e outro Nginx é conectado a outro Tomcat, para que o número de Tomcats que podem ser acessados possa ser duplicado.
Como o LVS também é independente, à medida que o número de simultaneidade aumenta para centenas de milhares, o servidor LVS acabará atingindo o gargalo. Neste momento, o número de usuários atinge dezenas de milhões ou mesmo centenas de milhões. Os usuários são distribuídos em regiões diferentes e a distância da sala do servidor é diferente, resultando em A latência do acesso será significativamente diferente
A oitava evolução:
Realize o balanceamento de carga da sala de computadores por meio de round robin de DNS
Um nome de domínio pode ser configurado no servidor DNS para corresponder a vários endereços IP, e cada endereço IP corresponde a um IP virtual em uma sala de computadores diferente. Quando um usuário visita www.taobao.com, o servidor DNS usará uma estratégia round-robin ou outras estratégias para selecionar um IP para o usuário visitar. Este método pode realizar o equilíbrio de carga da sala de computadores. Até agora, o sistema pode alcançar a expansão horizontal do nível da sala de computadores. O volume simultâneo de dezenas de milhões a centenas de milhões pode ser resolvido adicionando a sala de computadores. O concorrente solicitação na entrada do sistema não é mais problema.
Com a riqueza dos dados e o desenvolvimento dos negócios, os requisitos de recuperação e análise estão se tornando cada vez mais abundantes. Depender apenas do banco de dados não pode resolver uma demanda tão rica.
Nona Evolução:
Introduzir tecnologias como bancos de dados NoSQL e mecanismos de pesquisa
Quando a quantidade de dados no banco de dados atinge uma determinada escala, o banco de dados não é adequado para consultas complexas e muitas vezes atende apenas a cenários de consultas comuns. Para cenários de relatórios estatísticos, os resultados podem não poder ser executados quando a quantidade de dados é grande, e outras consultas ficarão lentas ao executar consultas complexas.Para cenários como recuperação de texto completo e estruturas de dados variáveis, os bancos de dados são inerentemente inadequados . Portanto, é necessário introduzir uma solução adequada para um cenário específico. Por exemplo, para armazenamento massivo de arquivos, pode ser resolvido pelo sistema de arquivos distribuído HDFS; para dados do tipo chave-valor, pode ser resolvido por soluções como HBase e Redis; para cenários de recuperação de texto completo, pode ser resolvido por mecanismos de pesquisa como ElasticSearch; para cenários de análise multidimensionais, pode ser resolvido Resolver por meio de soluções como Kylin ou Druid.
É claro que a introdução de mais componentes também aumentará a complexidade do sistema.Os dados guardados pelos diferentes componentes precisam ser sincronizados, a questão da consistência precisa ser considerada e são necessários mais métodos de operação e manutenção para gerenciar esses componentes.
A introdução de mais componentes resolve os ricos requisitos, e a dimensão do negócio pode ser bastante expandida, seguida por um aplicativo que contém muitos códigos de negócio, dificultando a atualização e a iteração do negócio
A décima evolução: grandes aplicações são divididas em pequenas aplicações
Divida o código do aplicativo de acordo com o setor de negócios, para que as responsabilidades de um único aplicativo sejam mais claras e possam ser atualizadas e iteradas independentemente umas das outras. Neste momento, algumas configurações comuns podem estar envolvidas entre aplicações, que podem ser resolvidas através do centro de configuração distribuído Zookeeper.
Existem módulos compartilhados entre diferentes aplicativos, e o gerenciamento separado pelo aplicativo resultará em múltiplas cópias do mesmo código, resultando na atualização de todos os códigos do aplicativo quando as funções públicas forem atualizadas
A Décima Primeira Evolução: Funções Reutilizáveis Separadas em Microsserviços
Se o gerenciamento de usuários, pedidos, pagamentos, autenticação e outras funções existirem em vários aplicativos, então os códigos dessas funções podem ser extraídos separadamente para formar um serviço separado para gerenciamento.Esses serviços são chamados de microsserviços, aplicativos e serviços Os serviços públicos são acessados através de vários métodos, como solicitações HTTP, TCP ou RPC, e cada serviço individual pode ser gerenciado por uma equipe separada. Além disso, Dubbo, SpringCloud e outras estruturas podem ser usadas para implementar funções como governança de serviço, limitação de corrente, interrupção de circuito e downgrade para melhorar a estabilidade e disponibilidade do serviço.
Os métodos de acesso à interface de diferentes serviços são diferentes, e o código do aplicativo precisa ser adaptado a vários métodos de acesso para usar o serviço.Além disso, quando o aplicativo acessa o serviço, os serviços também podem acessar uns aos outros, e a cadeia de chamadas irá tornar-se-á muito complicado e a lógica ficará confusa.
A décima segunda evolução:
Apresente a diferença de acesso da interface de serviço de blindagem ESB
A conversão do protocolo de acesso é realizada uniformemente através do ESB, e a aplicação acessa uniformemente os serviços back-end através do ESB, e os serviços também se chamam através do ESB, de modo a reduzir o grau de acoplamento do sistema. Este aplicativo único é dividido em vários aplicativos, os serviços públicos são extraídos separadamente para gerenciamento e o barramento de mensagens corporativo é usado para dissociar o acoplamento entre os serviços. Esta é a chamada arquitetura SOA (orientada a serviços), que é semelhante aos microsserviços. As arquiteturas são confusas porque as representações são muito semelhantes. No entendimento pessoal, a arquitetura de microsserviços refere-se mais à ideia de extrair serviços públicos do sistema para gerenciamento separado de operação e manutenção, enquanto a arquitetura SOA refere-se a uma ideia arquitetônica que divide os serviços e unifica o acesso à interface do serviço. Arquitetura SOA Contém a ideia de microsserviços.
Com o desenvolvimento contínuo dos negócios, haverá cada vez mais aplicativos e serviços, e a implantação de aplicativos e serviços se tornará complicada. A implantação de vários serviços no mesmo servidor também precisa resolver o problema de conflitos no ambiente operacional. Além disso, dinâmico o dimensionamento é necessário para coisas como grandes promoções.No cenário em que a capacidade de serviço precisa ser expandida horizontalmente, é necessário preparar o ambiente operacional para o serviço recém-adicionado, implantar o serviço, etc., e a operação e manutenção serão tornar-se muito difícil.
Décima Terceira Evolução:
A tecnologia de conteinerização proporciona isolamento do ambiente operacional e gerenciamento dinâmico de serviços
Atualmente, a tecnologia de conteinerização mais popular é o Docker, e o serviço de gerenciamento de contêineres mais popular é o Kubernetes (K8S), os aplicativos/serviços podem ser empacotados como imagens Docker e as imagens podem ser distribuídas e implantadas dinamicamente por meio do K8S. A imagem Docker pode ser entendida como um sistema operacional mínimo que pode executar sua aplicação/serviço, que contém o código em execução da aplicação/serviço, e o ambiente operacional é configurado de acordo com as necessidades reais. Depois que todo o “sistema operacional” é empacotado em um espelho, ele pode ser distribuído para máquinas que precisam implantar serviços relacionados, e o serviço pode ser iniciado diretamente iniciando o espelho Docker, facilitando a implantação, operação e manutenção do serviço .
Antes da grande promoção, você pode dividir o servidor no cluster de máquina existente para iniciar a imagem Docker e melhorar o desempenho do serviço.Após a grande promoção, você pode desligar o espelho sem afetar outros serviços na máquina (antes da seção 3.14 , É necessário modificar a configuração do sistema para adaptar o serviço para executar o serviço na máquina recém-adicionada, o que destruirá o ambiente operacional exigido por outros serviços na máquina).
Após a utilização da tecnologia de conteinerização, o problema da expansão e contração dinâmica dos serviços pode ser resolvido, mas a máquina ainda precisa ser gerenciada pela própria empresa.Quando não é uma grande promoção, ainda precisa desocupar muitos recursos da máquina para lidar com a grande promoção, o custo da própria máquina e o custo de operação e manutenção Ambos são extremamente elevados, com baixa utilização de recursos
A Décima Quarta Evolução: Transportando o Sistema na Plataforma Cloud
O sistema pode ser implantado na nuvem pública, usando os enormes recursos de máquina da nuvem pública para resolver o problema de recursos de hardware dinâmicos.Durante o período de grande promoção, solicite temporariamente mais recursos na plataforma de nuvem e combine Docker e K8S para implantar serviços rapidamente, liberar recursos após o término da grande promoção, pagar verdadeiramente sob demanda, melhorar muito a utilização de recursos e reduzir significativamente os custos de operação e manutenção.
A chamada plataforma de nuvem consiste em abstrair recursos massivos de máquina em um recurso completo por meio do gerenciamento unificado de recursos, no qual recursos de hardware (como CPU, memória, rede, etc.) podem ser aplicados dinamicamente sob demanda e operações gerais são fornecidas nele O sistema fornece componentes técnicos comumente usados (como pilha de tecnologia Hadoop, banco de dados MPP, etc.), serviço de correio, blog pessoal, etc.). Os seguintes conceitos estão envolvidos na plataforma em nuvem:
IaaS: Infraestrutura como Serviço. Correspondendo à unificação dos recursos da máquina mencionada acima como um todo de recursos, o nível de recursos de hardware pode ser aplicado dinamicamente;
PaaS: Plataforma como Serviço. Correspondente ao fornecimento acima mencionado de componentes técnicos comumente utilizados para facilitar o desenvolvimento e manutenção do sistema;
SaaS: software como serviço. Correspondente à disponibilização das aplicações desenvolvidas ou dos serviços acima mencionados, o pagamento é efetuado de acordo com requisitos funcionais ou de desempenho.
Até agora, os problemas acima mencionados de alto acesso simultâneo à arquitetura de serviço e implementação de sistema têm suas próprias soluções, mas, ao mesmo tempo, deve-se perceber que na introdução acima, como questões práticas cruzadas, como sincronização de dados no sala de informática, implementação de transações distribuídas, etc., essas questões serão discutidas separadamente no futuro
Resumo do projeto de arquitetura
1. O ajustamento da estrutura tem de ser realizado de acordo com o percurso de evolução acima mencionado?
Não, a sequência de evolução arquitetônica mencionada acima é apenas uma única melhoria para um determinado aspecto. Em cenários reais, pode haver vários problemas que precisam ser resolvidos ao mesmo tempo, ou pode ser outro aspecto que chega primeiro ao gargalo. Neste momento, deve ser resolvido de acordo com os problemas reais. Por exemplo, no cenário em que a quantidade de simultaneidade na classe governamental pode não ser grande, mas o negócio pode ser rico, a alta simultaneidade não é o principal problema a ser resolvido. Neste momento, a prioridade pode ser uma solução com ricos precisa.
2. Até que ponto deve ser desenhada a arquitetura do sistema a ser implementado?
Para um sistema com uma implementação única e indicadores de desempenho claros, é suficiente projetar a arquitetura para suportar os requisitos de desempenho do sistema, mas uma interface para estender a arquitetura deve ser deixada caso seja necessário. Para um sistema em constante evolução, como uma plataforma de comércio eletrônico, ele deve ser projetado para atender aos requisitos do próximo estágio de volume de usuários e indicadores de desempenho, e atualizar iterativamente a arquitetura de acordo com o crescimento do negócio para suportar maior simultaneidade e negócios mais ricos.
3. Qual é a diferença entre arquitetura do lado do servidor e arquitetura de big data?
O chamado "big data" é na verdade um termo geral para soluções de cenário, como coleta massiva de dados, limpeza e conversão, armazenamento de dados, análise de dados e serviços de dados. Cada cenário inclui uma variedade de tecnologias opcionais, como coleta de dados com Flume, Sqoop, Kettle, etc., o armazenamento de dados inclui sistemas de arquivos distribuídos HDFS, FastDFS, banco de dados NoSQL HBase, MongoDB, etc., a análise de dados inclui pilha de tecnologia Spark, algoritmos de aprendizado de máquina, etc. Em geral, a arquitetura de big data é uma arquitetura que integra vários componentes de big data de acordo com as necessidades do negócio e geralmente fornece recursos como armazenamento distribuído, computação distribuída, análise multidimensional, data warehouse e algoritmos de aprendizado de máquina. A arquitetura do lado do servidor refere-se mais à arquitetura no nível da organização do aplicativo, e os recursos subjacentes geralmente são fornecidos pela arquitetura de big data.
4. Existem princípios de projeto arquitetônico?
Projeto N+1. Cada componente do sistema não deve ter nenhum ponto único de falha;
Projeto de reversão. Certifique-se de que o sistema seja compatível com versões futuras e que haja uma maneira de reverter a versão quando o sistema for atualizado;
Desative o projeto. Deve fornecer uma configuração para controlar a disponibilidade de funções específicas, e a função pode ser rapidamente off-line quando o sistema falhar;
Projeto do monitor. Os meios de monitorização devem ser considerados na fase de concepção;
Projeto de data center multiativo. Caso o sistema exija disponibilidade extremamente alta, deve-se considerar a implementação de data centers multiativos em múltiplos locais, para que o sistema ainda esteja disponível quando pelo menos uma sala de informática estiver desligada;
Adote tecnologia madura. As tecnologias recentemente desenvolvidas ou de código aberto muitas vezes apresentam muitos bugs ocultos e, se algo der errado sem suporte comercial, poderá ser um desastre;
Projeto de isolamento de recursos. Uma única empresa deve evitar ocupar todos os recursos;
A arquitetura deve ser capaz de escalar horizontalmente. Somente quando o sistema puder ser expandido horizontalmente o problema do gargalo poderá ser efetivamente evitado;
Compre não essencial. Se funções não essenciais exigirem muitos recursos de P&D para serem resolvidas, considere comprar produtos maduros;
Use hardware comum. O hardware comercial pode efetivamente reduzir a probabilidade de falha do hardware;
Itere rapidamente. O sistema deve desenvolver rapidamente pequenos módulos funcionais, ficar online para verificação o mais rápido possível e encontrar problemas antecipadamente para reduzir significativamente o risco de entrega do sistema;
Design sem estado. A interface de serviço deve se tornar sem estado e o acesso à interface atual não depende do estado do último acesso à interface.
Fonte do artigo:
https://segmentfault.com/a/1190000018626163
Será que você quer saber mais sobre o caso do Taobao depois de ler este artigo? Nesta sexta-feira, na estação de Shenzhen da GIAC Global Internet Architecture Conference, convidamos Tang Hongmin, um especialista sênior em teste e desenvolvimento do Taobao , para compartilhar conosco os seguintes tópicos. Mais tópicos podem ser clicados: "GIAC Full Schedule"
Além disso, o comitê organizador seleciona inovações tecnológicas de ponta e representativas da arquitetura mais popular da Internet Cloud-Native, IoT, inteligência artificial e outras tecnologias de ponta, dados e inteligência de negócios, plataformas de grande e médio porte, arquitetura clássica, cultura e gestão de engenharia. E o caso de estrutura da prática de P&D, convidou BAT, Meituan, Didi e outros especialistas técnicos empresariais para compartilhar conosco as mais recentes conquistas tecnológicas, o número de assentos na conferência agora é limitado, registre-se para participar O mais breve possível!