Não discutiremos se é um ambiente PHP, JSP ou .NET aqui. Observamos o problema da perspectiva da arquitetura. Implementar linguagem não é um problema. A vantagem da linguagem está na implementação, em vez de boa ou ruim. Não importa qual idioma você escolher, a arquitetura deve enfrentar.
1. Processamento de dados maciços
Como todos sabemos, para alguns sites relativamente pequenos, a quantidade de dados não é muito grande. Selecionar e atualizar podem resolver os problemas que enfrentamos. A carga em si não é muito grande e, no máximo, alguns índices podem ser feitos. Para sites grandes, a quantidade de dados por dia pode ser de milhões. Se um relacionamento de muitos para muitos mal projetado não for problemático no estágio inicial, mas à medida que o usuário cresce, a quantidade de dados aumentará geometricamente. No momento, quando escolhemos e atualizamos uma tabela (sem mencionar a consulta conjunta de várias tabelas), o custo é muito alto.
2. Processamento de concorrência de dados
Em algum momento, o CTO 2.0 tem uma espada Shangfang, que é o cache. Para o cache, também é um grande problema quando são realizadas alta simultaneidade e alto processamento. Em todo o aplicativo, o cache é compartilhado globalmente. No entanto, quando fazemos modificações, se duas ou mais solicitações exigirem atualizações no cache ao mesmo tempo, o aplicativo morrerá diretamente. No momento, é necessária uma boa estratégia de processamento de simultaneidade de dados e estratégia de cache.
Além disso, é o problema do banco de dados do banco de dados. Talvez geralmente não sintamos que a probabilidade de impasse que ocorram em alta simultaneidade é muito alta e o cache de disco é um grande problema.
3. Problemas de armazenamento de arquivos
Para alguns sites que suportam o File Uploads 2.0, quando temos sorte de que a capacidade do disco rígido esteja ficando cada vez maior, devemos considerar mais como os arquivos devem ser armazenados e indexados de maneira eficaz. Uma solução comum é armazenar arquivos por data e tipo. No entanto, quando o volume do arquivo é enorme, se um disco rígido armazenar 500 g de arquivos triviais, o IO do disco é um enorme problema durante a manutenção e o uso. Mesmo que sua largura de banda seja suficiente, seu disco pode não responder. Se o upload estiver envolvido no momento, o disco terminará facilmente.
Talvez o uso de servidores de armazenamento RAID e dedicado possa resolver o problema atual, mas há outro problema que é o acesso aos problemas em vários lugares. Talvez o nosso servidor esteja em Pequim, talvez na velocidade de acesso de Yunnan ou Xinteng? Se for distribuído, como nosso índice de arquivos e arquitetura devem ser planejados.
Portanto, temos que admitir que o armazenamento de arquivos é um problema muito difícil
4. Processamento das relações de dados
Podemos planejar facilmente um banco de dados que esteja em conformidade com o terceiro normal, que está cheio de relacionamentos muitos para muitos e também pode substituir a coluna Indentify pelo GUID. No entanto, na ERA de 2.0, onde são inundados muitos para muitos, o terceiro normal é o primeiro que deve ser abandonado. A consulta articular com várias mesa deve ser efetivamente minimizada.
5. Problema de indexação de dados
Como todos sabemos, a indexação é a solução mais barata e fácil para melhorar as consultas de eficiência do banco de dados. No entanto, no caso de alta atualização, o custo de atualização e exclusão será alto e impensável. O autor encontrou uma situação em que leva 10 minutos para ser concluído ao atualizar um índice focado; portanto, para o site, eles são basicamente insuportáveis.
Indexação e atualização são um par de inimigos naturais. As perguntas A, D e E são os problemas que devemos considerar ao fazer arquitetura e também podem ser os problemas que levam mais tempo.
6. Processamento distribuído
Para sites 2.0, devido à sua alta interatividade, o efeito alcançado pelo CDN é basicamente 0 e o conteúdo é atualizado em tempo real, que é o nosso processamento regular. Para garantir a velocidade de acesso em vários lugares, precisamos enfrentar um enorme problema, ou seja, como realizar efetivamente a sincronização de dados e atualizar e realizar a comunicação em tempo real de servidores em vários lugares é um problema que deve ser considerado.
7. Análise dos prós e contras do Ajax
O sucesso é o Ajax, o fracasso é o Ajax, o Ajax se tornou a tendência convencional, e de repente eu achei que o post e me baseia no XMLHTTP é tão fácil. O cliente recebe ou publica os dados no servidor e o servidor retorna após receber a solicitação de dados. Esta é uma solicitação de Ajax muito normal. No entanto, ao processar o AJAX, se usarmos uma ferramenta de captura de pacotes, o retorno e o processamento dos dados ficarão claros rapidamente. Para alguns pedidos de AJAX com alto volume computacional, podemos construir um contratado, que pode matar facilmente um servidor da web.
8. Análise da segurança de dados
Para o protocolo HTTP, os pacotes de dados são transmitidos em texto simples. Talvez possamos dizer que podemos usar a criptografia, mas, para o problema G, o processo de criptografia pode ser um texto simples (por exemplo, QQ que sabemos que pode facilmente julgar sua criptografia e escrever efetivamente um método de criptografia e descriptografia como esse). Quando o tráfego do seu site não é muito grande, ninguém se preocupa com você, mas quando o tráfego surgir, os chamados plug-ins e o chamado envio de massa seguirão um após o outro (as pistas podem ser vistas a partir do envio em massa no início do QQ). Talvez possamos dizer muito que podemos usar julgamentos de nível superior ou mesmo https para conseguir isso. Observe que, quando você fizer esse processamento, você pagará muitos custos de banco de dados, IO e CPU. Para algumas transmissões em massa, é basicamente impossível. O autor já pode realizar a publicação em massa para o Baidu Space e o QQ Space. Não é difícil para todos experimentar.
9. Problemas de sincronização de dados e processamento de cluster
Quando um de nossos projetos de banco de dados está sobrecarregado, precisamos fazer cargas e clusters baseados em banco de dados. Este pode ser o problema mais problemático. Os dados são baseados na transmissão de rede. O atraso dos dados é um problema terrível e um problema inevitável. Dessa forma, precisamos usar outros meios para garantir uma interação eficaz em alguns segundos ou mais minutos desse atraso. Por exemplo, hash de dados, segmentação, processamento de conteúdo e outros problemas.
10. Canais de compartilhamento de dados e tendências do OpenAPI
O OpenAPI se tornou uma tendência inevitável, do Google, Facebook, MySpace para campi em casa, esse problema está sendo considerado. Ele pode reter com mais eficácia usuários e estimular mais interesses e permitir que mais pessoas ajudem você a fazer o desenvolvimento mais eficaz. No momento, para uma plataforma eficaz de compartilhamento de dados, a plataforma aberta de dados se torna uma maneira indispensável. Garantir a segurança e o desempenho dos dados com interfaces abertas é outra questão que devemos considerar seriamente.