项目架构&架构部署&网站分析&网站优化

1、架构演变

一个项目至少由三层内容组成：web访问层、数据库层、存储层

 

初级阶段

单体阶段　　　　　　　　　　　　　　　　　　　　

常见场景：项目初期

部署特色：全部应用服务都在一台主机

应用特色：开发简单

 

 

 

 

 

应用/数据分离阶段　　　　　　　　　　　　　　　　

常见场景：项目初期，用户访问数据库有压力

部署特色：应用和数据库单独部署

应用特色：开发简单

 

 

  

页面动静分离阶段

常见场景：项目初期，用户访问页面有压力

部署特色：剥离用户读请求和写请求操做

应用特色：开发简单

 

   

页面/数据缓存阶段

常见场景：项目初期，用户访问有压力

部署特色：代理和数据库前面增长缓存组件

应用特色：开发简单

 

 

中期阶段

应用服务集群阶段

常见场景：项目初期，用户访问有压力

部署特色：应用服务所在主机作集群负载均衡

应用特色：业务中等

 

 

数据库读写分离化

常见场景：项目初期，用户访问数据有压力

部署特色：对数据库集群作读写分离，静态文件作共享存储

应用特色：业务中等

 

 

 

存储分布式

常见场景：项目中期，数据存储有压力

部署特色：对数据库分库/分表扩展，数据文件使用分布式存储

应用特色：业务中等

 

 

 

 

业务应用拆分

常见场景：项目中期，业务访问/团队管理有压力

部署特色：项目应用进行拆分

应用特色：业务复杂

 

 

 

 

中后期阶段

业务拆分

常见场景：项目中后期，业务处理有压力

部署特色：全部功能以服务形式单独部署，引入配置管理管理中心、消息中间件，搜索引擎等功能

应用特色：业务复杂

 

微服务阶段

常见场景：项目后期，精益求精

部署特色：全部服务均可以自由部署

应用特色：业务复杂

 

 　　　　

 

 

 

2、架构部署

通用架构

 

一级定位：核心组成部分

　　web 、数据库、存储层

二级定位：功能加强部分

　　web缓存、代理、数据库缓存

 

部署项目

部署项目时，遵循主次原则：

• 架构层中的一级角色，部署原则是：站在用户访问资源角度，从后向前依次部署。
• 架构层中的二级角色，部署原则是：站在用户访问资源压力角度，须要部署哪里，就部署哪里，注意先后的信息交流。

 

 

3、网站分析

IP: 独立IP数，指一天内使用不一样IP地址的用户访问网站的数量。

　　特色：同一个IP不管访问多少网页，独立IP数均为1

PV：Page view页面浏览量，指一天内网站的浏览次数，它是衡量网站用户访问页面的数量。

　　特色：用户每打开一个页面就记录一次，就算访问同一页面屡次，就记录屡次

UV：Unique Visitor 访问网站的用户，指一天内访问某站点的人数，以cookie/客户端为依据

　　特色：一天内，同一访问用户的屡次访问只记录1次

VV：Visit View 用户访问网站次数，指一天内某个用户访问了多少次网站

　　特色：打开网页A，浏览完毕后关闭该页面，表示一次访问

BR：Bounce Rate 跳出率，指一天内访问用户中，用户打开网站后没有作任何事情，一会就离开了的比例

　　特色：若是跳出率很高，说明咱们的网页没有什么吸引力，网页设计效果不怎么好

CR：Conversion Rate 转化率，指一天内访问用户中，打开网站后，继续浏览该网站其余页面的比例

　　特色：转化率通常体如今项目的关键流程的部分，而它对网站的某些关键流程优化是一个很重要的直播

 

常见分析工具：服务器服务日志、公司内部监控平台、互联网网站分析工具包括站长工具、百度统计、云平台监控等

 

 

 

4、网站优化

缓存层方面

问题描述：

怎么在现有的主机资源状况下，花最小的代价抗住大量的用户访问量？

解决思路：

最多见的是自建Web缓存，或者购买CDN，将用户常常访问的、更新频率低的资源存放起来，这样用户再次请求相同资源的时候，就不会对后端的服务形成影响。若要防止互联网上的恶意访问/爬虫，应该作好相应的安全措施。缓存之类的措施必定要适合公司的当前业务，若是是项目的静态资源不少，只要购买的CDN足够好，就能抗住足够的用户访问量。

 

代理层方面

问题描述：

如何提升用户高质量的请求分发。

解决思路：

以Nginx代理为例，提升用户高质量的请求分发，最好的方法就是基于请求的关键字进行合理的分流。

基于请求的IP地址信息，封闭恶意IP访问，提升正常IP用户访问效率

基于请求的浏览器信息，分发到相应的后端应用，

基于请求的协议方法，作好读写分离业务的精确分流，

基于请求的路径信息，作好指定业务的精确分流，

 

问题描述：

对于前端使用nginx进行代理的项目，会随着功能的层层迭代逐渐增长数十个upstream，location规则的数量有可能达到数百个，这个时候偶尔有些 URL 会出现 404 的问题，对于这种状况怎么办？

解决思路：

1 按照功能描述，将upstream拆分到不一样的功能目录中

2 对location的匹配规则尽可能描述清楚，特别是匹配的location_match，最好使用^/$来锚定首尾字母

 

项目后端web访问

问题描述：

关于动态web请求过多，压力有些大，常见的解决方法有哪些？

解决思路：

首先分析动态的web请求主要的瓶颈点在哪里，是请求量大，仍是数据访问大

请求量大：Web缓存/CDN，或者动态web集群能够考虑一下

数据库操做多：分析请求内容是否频繁/集中，是，页面静态化考虑一下；否，参看数据库的演变思路

 

如何提升静态web资源的访问质量？结合前段缓存的功能，在代码或者代理部分设置合理的资源缓存过时时间，定时/实时推送相关信息到前段的缓存层。

 

数据层方面

问题描述：

用户访问数据有压力

解决思路：

对于热点数据读取频繁的话，能够考虑前端数据缓存、分部数据缓存、优化查询搜索等方法

对于数据频繁写入压力的话，能够考虑数据库集群、读写分离、分库分表、增长数据管理层等方法

开发角度：关注数据库表的设计，表的索引合理、查询的时候，尽可能使用条件查询

 

存储层方面：

问题描述：

如何保证咱们数据存储的质量

解决思路：

存储设备的购买质量、分布式存储、备份策略