好物优选点击查看详情 京东购买

暂无内容

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

一、架构演变

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

 

初级阶段

单体阶段

常见场景:项目初期

部署特点:所有应用服务都在一台主机

应用特点:开发简单

 

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

 

 

 

应用/数据分离阶段

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

部署特点:应用和数据库单独部署

应用特点:开发简单

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

 

 

  

页面动静分离阶段

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

部署特点:剥离用户读请求和写请求操作

应用特点:开发简单

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

 

   

页面/数据缓存阶段

常见场景:项目初期,用户访问有压力

部署特点:代理和数据库前面增加缓存组件

应用特点:开发简单

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

 

 

中期阶段

应用服务集群阶段

常见场景:项目初期,用户访问有压力

部署特点:应用服务所在主机做集群负载均衡

应用特点:业务中等

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

 

 

数据库读写分离化

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

部署特点:对数据库集群做读写分离,静态文件做共享存储

应用特点:业务中等

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

 

 

存储分布式

常见场景:项目中期,数据存储有压力

部署特点:对数据库分库/分表扩展,数据文件使用分布式存储

应用特点:业务中等

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

 

 

 

业务应用拆分

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

部署特点:项目应用进行拆分

应用特点:业务复杂

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

 

 

 

中后期阶段

业务拆分

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

部署特点:所有功能以服务形式单独部署,引入配置管理管理中心、消息中间件,搜索引擎等功能

应用特点:业务复杂

 

微服务阶段

常见场景:项目后期,精益求精

部署特点:所有服务都可以自由部署

应用特点:业务复杂

 

 项目架构&架构部署&网站分析&网站优化插图8 项目架构&架构部署&网站分析&网站优化插图9

 

 

 

二、架构部署

通用架构

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

 

一级定位:核心组成部分

web 数据库、存储层

二级定位:功能增强部分

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

 

部署项目

部署项目时,遵循主次原则:

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

 

 

三、网站分析

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

特点:同一个IP无论访问多少网页,独立IP数均为1

PVPage view页面浏览量,指一天内网站的浏览次数,它是衡量网站用户访问页面的数量。

特点:用户每打开一个页面就记录一次,就算访问同一页面多次,就记录多次

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

特点:一天内,同一访问用户的多次访问只记录1次

VVVisit View 用户访问网站次数,指一天内某个用户访问了多少次网站

特点:打开网页A,浏览完毕后关闭该页面,表示一次访问

BRBounce Rate 跳出率,指一天内访问用户中,用户打开网站后没有做任何事情,一会就离开了的比例

特点:如果跳出率很高,说明我们的网页没有什么吸引力,网页设计效果不怎么好

CRConversion Rate 转化率,指一天内访问用户中,打开网站后,继续浏览该网站其他页面的比例

特点:转化率一般体现在项目的关键流程的部分,而它对网站的某些关键流程优化是一个很重要的直播

 

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

 

 

 

四、网站优化

缓存层方面

问题描述:

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

解决思路:

最常见的是自建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资源的访问质量?结合前段缓存的功能,在代码或者代理部分设置合理的资源缓存过期时间,定时/实时推送相关信息到前段的缓存层。

 

数据层方面

问题描述:

用户访问数据有压力

解决思路:

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

对于数据频繁写入压力的话,可以考虑数据库集群、读写分离、分库分表、增加数据管理层等方法

开发角度:关注数据库表的设计,表的索引合理、查询的时候,尽量使用条件查询

 

存储层方面:

问题描述:

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

解决思路:

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

 

原文链接:https://www.cnblogs.com/hsmwlyl/p/10822278.html

© 版权声明
THE END
喜欢就支持一下吧
点赞14 分享