-
O último artigo desta série foi escrito para programadores comuns. Se você não estiver interessado, basta ler os últimos parágrafos deste artigo.
Antes de começar a projetar a estrutura do código, vamos revisar o que preparamos antes: temos um servidor WEB com balanceamento de carga, um servidor de banco de dados mestre-escravo e possivelmente sharding, um cache e armazenamento escalável. Todos os aspectos da organização do código estão intimamente relacionados a esses preparativos. Vou listá-los um por um, dois por três, e cada um começará com a frase clássica “mencionada acima” para facilitar a comparação.
Não se apresse em ler os padrões clássicos de frases, minha mente deu um pulo e vou inserir um parágrafo. No desenvolvimento real, sempre fazemos um compromisso entre desempenho e elegância do código. Para os computadores e intérpretes de linguagem de hoje, a questão de quantas camadas de chamadas de objetos e quantas camadas de chamadas de objetos e se declarar variáveis como Map ou HashMap é a última coisa a considerar. Sempre considere a parte mais lenta do sistema e resolva-a. da parte mais lenta. Por exemplo, veja se o ORM que você usa faz muitas coisas desnecessárias e se há chamadas de dados repetidas. O que fazemos é o desenvolvimento de aplicativos da web, não a API da estrutura subjacente. Código fácil de ler e compreensível é um aspecto muito importante para garantir a qualidade. Para que serve o seu programa? será discutido separadamente. Este artigo está muito longe do assunto. Se você quiser se comunicar, pode seguir meu Weibo : http://t.sina.com.cn/liuzhiyi .
Conforme mencionado anteriormente, o servidor WEB precisa ter balanceamento de carga e o servidor de imagens precisa ser separado. Em relação a este ponto, quando o código trata do status do cliente, não coloque o status em uma única máquina. Por exemplo, não use sessão de arquivo. Se possível, é melhor desenvolver uma interface unificada para autenticação de ponto único do usuário desde o início, incluindo como determinar o status entre domínios, como determinar o status em páginas estáticas e a definição de parâmetros de salto e retorno ao fazer login. . Forneça uma boa interface na camada inferior e aplique-a. A camada é usada diretamente (consulte o serviço ao usuário do GAE). O design do login deve considerar as características dos dispositivos móveis. Por exemplo, os computadores podem usar janelas de camada flutuante, mas o próprio navegador da NOKIA ou UCWEB não pode lidar com esta forma de expressão. O programa deve ser capaz de lidar com solicitações Ajax e diretamente através da URL. . perguntar. O servidor de imagens é separado e os arquivos de recursos são melhor colocados no servidor de imagens, ou seja, o servidor WEB atende apenas programas dinâmicos. Embora seja um pouco complicado de desenvolver e testar (porque é necessário um URI absoluto para acessá-lo), será muito mais fácil otimizar o front-end da página no futuro, e a otimização IO do seu servidor WEB também será seja muito mais fácil. Quando o programa faz referência a arquivos de recursos, deve haver um método de processamento unificado. Muitas coisas podem ser concluídas automaticamente dentro do método, como combinar CSS/js em um arquivo ou adicionar automaticamente QUERYSTRING após o URI gerado. serviço de cache é usado, gerar QUERYSTRING é a maneira mais simples de atualizar o cache do servidor e o cache do cliente.
Conforme mencionado anteriormente, o banco de dados será replicado, poderá ter vários mestres e vários escravos e poderá ser fragmentado. No processo de processamento de dados em nosso programa, é melhor abstraí-los e colocá-los em uma camada separada. Tomemos como exemplo o popular modelo MVC, que consiste em colocar uma camada de dados abaixo da camada M. Essa camada de dados não é o comumente conhecido JDBC/PDO/ActiveRecord, etc., mas sua própria camada de dados de acesso, que apenas expõe métodos para. o mundo exterior. Não tenha medo de escrever feio dentro desta camada de dados, mas ela deve fornecer todas as funções de armazenamento de dados. Não veja as palavras que tratam do banco de dados em qualquer outro nível. A razão para isso é que no caso de um único banco de dados relacional, você pode SELECT...JOIN...ou diretamente INSERT...INTO..., mas você pode armazenar algumas tabelas em um banco de dados de valores-chave, ou fragmentá-los. Depois disso, todas as declarações e métodos originais precisarão ser alterados. Se estiverem muito dispersos, será gasto muito esforço durante o transplante, ou será obtido um modelo muito grande. Em termos de design em nível de dados, tente evitar consultas JOIN. Podemos fazer mais redundância e cache. Cada tipo de dados precisa apenas de uma consulta e depois combiná-los em seu programa. Para combinações de dados mais complexas, quando os requisitos de tempo real não são altos, o processamento assíncrono pode ser usado e os usuários só obtêm os resultados processados ao acessar. Ao lidar com chaves primárias, evite usar IDs de incremento automático e use valores exclusivos gerados por certas regras como chaves primárias. Essa chave primária é a estratégia de distribuição de fragmentação mais simples. Mesmo se você usar um ID de incremento automático, é melhor usar um gerador de ID de incremento automático. Caso contrário, se o banco de dados escravo for gravado acidentalmente, a chave primária entrará em conflito facilmente.
Conforme mencionado anteriormente, existem alguns caches bloqueando a frente do nosso banco de dados. Não trate o cache de consulta do MySQL como um cache. Quando o aplicativo é um pouco complexo, QUERY CACHE se tornará um fardo. O cache está intimamente integrado ao banco de dados e aos negócios. Por estar intimamente relacionado aos negócios, não existe uma abordagem única. Mas ainda temos algumas regras a seguir. Regra 1: Quanto mais próximo do front-end, maior será a granularidade do cache. Por exemplo, a página inteira é armazenada em cache no front-end da WEB, parte da página é armazenada em cache no próximo nível e um único registro na área é armazenado em cache no próximo nível. Porque quanto mais perto estamos do backend, mais flexível é a nossa operabilidade, e o código front-end que mais muda é mais fácil de escrever. Na prática, como os requisitos do produto mudam muito rapidamente e o ciclo de iteração está ficando cada vez mais curto, às vezes é difícil distinguir claramente o Controlador e o Modelo. O cache parcial é inevitável no nível do Controlador, mas é necessário garantir que se isso acontecer. acontecer, o Controlador O cache que está sendo operado não deve afetar outros solicitantes de dados, ou seja, deve-se garantir que esses dados armazenados em cache sejam utilizados apenas por este Controlador. Regra 2: O programa não pode cometer erros sem armazenar em cache. Ao não considerar o efeito de avalanche causado pela invalidação do cache, seu programa deve ter um cache e ser o mesmo que sem cache. Não pode ser como o Sina Weibo. Uma vez que o cache falhar, o ventilador Weibo ficará vazio e todo o aplicativo estará. bagunçado. Quando o armazenamento em cache é essencial, enviar uma mensagem de erro ao usuário é melhor do que enviar uma mensagem enganosa. Regra 3: As atualizações de cache devem ser atômicas ou thread-safe. Especialmente quando o cache passivo é usado, é muito provável que o mesmo cache seja atualizado quando dois usuários o acessarem. Geralmente, isso não é um grande problema e o cache pode ser reconstruído. depois de expirar, esta pode ser uma das causas da reação em cadeia. Regra 4: O cache também tem um custo. Não apenas o custo da tecnologia, mas também o custo do tempo de trabalho. Se uma função usa cache e não o utiliza, a diferença no volume de acesso previsível é pequena, mas o uso do cache aumentará a complexidade, então não há necessidade de adicionar uma marca TODO e adicionar processamento de cache na próxima iteração.
Conforme mencionado anteriormente, o armazenamento de arquivos é independente, portanto, todas as operações de arquivos são chamadas remotas. Você pode fornecer uma interface RESTful muito simples no servidor de arquivos ou pode fornecer serviço xmlrpc ou json. Todos os arquivos gerados e processados pelo servidor WEB são notificados ao servidor de arquivos por meio da interface para processamento. para fornecer qualquer armazenamento de arquivos. Você descobrirá que o upload de imagens e o salvamento de artigos em muitos sites grandes são concluídos em duas etapas, por esse motivo.
Os "mencionados anteriormente" acima foram ditos por inúmeras pessoas. Acabei de repeti-los com minhas próprias palavras com base nos artigos anteriores. A essência da análise real é muito simples - além de uma boa camada lógica funcional, também precisamos de Design. interfaces separadas para chamadas de recursos externos, como armazenamento de banco de dados, cache, filas e serviços de arquivo. Você pode imaginar seu programa rodando no Amazon EC2 e usando todos os seus serviços da web. Seu banco de dados é seu SimpleDB. o armazenamento é o S3 dele. A única diferença é que a interface da Amazon é uma chamada remota e a sua é uma chamada interna.
A interface do serviço de suporte significa que a substituição do MySQL pelo PostgreSQL não requer alterações no programa de processamento de negócios, e a equipe de migração nem precisa se comunicar muito com a equipe de desenvolvimento de negócios, isso significa que a equipe de desenvolvimento de negócios está programando a interface; do que programar o banco de dados; isso significa que o desempenho não será prejudicado por um erro do desenvolvedor de negócios.
Se você não está interessado na alfabetização do programa, basta olhar aqui——
Após a conclusão do design do produto e a construção da estrutura do programa, podem surgir conflitos nesta conjuntura. Há reclamações constantes de designers de produtos de que suas ideias não alcançam os resultados desejados, e os programadores reclamam que os designs de produtos não são realistas. Esse tipo de reclamação se deve principalmente ao fato de o pessoal do produto não entender a tecnologia e o pessoal técnico não entender o produto. Em um sentido amplo, os produtos incluem estratégias de mercado, métodos de marketing e design funcional. Ao discutir sobre produtos e tecnologias, o foco geralmente está na função, mas o foco real está no custo de realizar essa função e nos benefícios que ela proporciona. pode trazer. Se pode ser convertido e se pode ser levado em consideração. Se possível, resolva a disputa. Se não, jogue uma moeda e veja a sorte. Existem muitos exemplos de indicadores que estouram devido ao aprimoramento de uma função ou atrasos no combate devido a atrasos no projeto. Os decisores radicais centram-se nos benefícios, os decisores conservadores centram-se nas perdas e os decisores inteligentes irão considerar se o problema é realmente tão grave.
Ninguém pode prever o que acontecerá no futuro. Caso contrário, metade do processo de abertura de um negócio depende da sorte. Mas há sempre coisas que podem ser ditas com precisão e é preciso confiar nos dados para falar por si.
Não 100%, mas 99,9% dos sites possuem código de estatísticas de acesso instalado, até mesmo o meu http://zhiyi.us não é exceção, e a Rede Xinwen sempre fala sobre tomada de decisões científicas e desenvolvimento científico. Com as estatísticas, há muitas coisas que podem ser determinadas. Por exemplo, você pode analisar quais canais têm o menor custo de aquisição per capita com base na taxa de conversão de origem-destino, adivinhar os motivos das taxas de rejeição do usuário com base no acesso ao conteúdo de origem e determinar se a posição do link é razoável com base no clique do usuário comportamento. Combine dados de diferentes maneiras para encontrar conexões internas, analisar fatores internos e externos, formular estratégias correspondentes e reduzir decisões precipitadas. Confiar em dados para apoiar as operações é uma questão muito profissional. Embora eu não entenda modelos matemáticos profundos e cálculos de fórmulas complexas, gradualmente aprendi que B é por causa de A e C é por causa de A e B. Ainda é relativamente simples. .
Autor do artigo: Liu Zhiyi (indicar o link da fonte e o autor ao reimprimir)
Fonte do artigo: http://zhiyi.us/