项目架构&架构部署&网站分析&网站优化
一、架构演变
一个项目至少由三层内容组成：web访问层、数据库层、存储层
初级阶段
单体阶段
常见场景：项目初期
部署特点：所有应用服务都在一台主机
应用特点：开发简单
应用/数据分离阶段
常见场景：项目初期，用户访问数据库有压力
部署特点：应用和数据库单独部署
应用特点：开发简单
页面动静分离阶段
常见场景：项目初期，用户访问页面有压力
部署特点：剥离用户读请求和写请求操作
应用特点：开发简单
页面/数据缓存阶段
常见场景：项目初期，用户访问有压力
部署特点：代理和数据库前面增加缓存组件
应用特点：开发简单
中期阶段
应用服务集群阶段
常见场景：项目初期，用户访问有压力
部署特点：应用服务所在主机做集群负载均衡
应用特点：业务中等
数据库读写分离化
常见场景：项目初期，用户访问数据有压力
部署特点：对数据库集群做读写分离，静态文件做共享存储
应用特点：业务中等
存储分布式
常见场景：项目中期，数据存储有压力
部署特点：对数据库分库/分表扩展，数据文件使用分布式存储
应用特点：业务中等
业务应用拆分
常见场景：项目中期，业务访问/团队管理有压力
部署特点：项目应用进行拆分
应用特点：业务复杂
中后期阶段
业务拆分
常见场景：项目中后期，业务处理有压力
部署特点：所有功能以服务形式单独部署，引入配置管理管理中心、消息中间件，搜索引擎等功能
应用特点：业务复杂
微服务阶段
常见场景：项目后期，精益求精
部署特点：所有服务都可以自由部署
应用特点：业务复杂
二、架构部署
通用架构
一级定位：核心组成部分
web 、数据库、存储层
二级定位：功能增强部分
web缓存、代理、数据库缓存
部署项目
部署项目时，遵循主次原则：
- 架构层中的一级角色，部署原则是：站在用户访问资源角度，从后向前依次部署。
- 架构层中的二级角色，部署原则是：站在用户访问资源压力角度，需要部署哪里，就部署哪里，注意前后的信息交流。
三、网站分析
IP: 独立IP数，指一天内使用不同IP地址的用户访问网站的数量。
特点：同一个IP无论访问多少网页，独立IP数均为1
PV：Page view页面浏览量，指一天内网站的浏览次数，它是衡量网站用户访问页面的数量。
特点：用户每打开一个页面就记录一次，就算访问同一页面多次，就记录多次
UV：Unique Visitor 访问网站的用户，指一天内访问某站点的人数，以cookie/客户端为依据
特点：一天内，同一访问用户的多次访问只记录1次
VV：Visit View 用户访问网站次数，指一天内某个用户访问了多少次网站
特点：打开网页A，浏览完毕后关闭该页面，表示一次访问
BR：Bounce Rate 跳出率，指一天内访问用户中，用户打开网站后没有做任何事情，一会就离开了的比例
特点：如果跳出率很高，说明我们的网页没有什么吸引力，网页设计效果不怎么好
CR：Conversion 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资源的访问质量？结合前段缓存的功能，在代码或者代理部分设置合理的资源缓存过期时间，定时/实时推送相关信息到前段的缓存层。
数据层方面
问题描述：
用户访问数据有压力
解决思路：
对于热点数据读取频繁的话，可以考虑前端数据缓存、分部数据缓存、优化查询搜索等方法
对于数据频繁写入压力的话，可以考虑数据库集群、读写分离、分库分表、增加数据管理层等方法
开发角度：关注数据库表的设计，表的索引合理、查询的时候，尽量使用条件查询
存储层方面：
问题描述：
如何保证我们数据存储的质量
解决思路：
存储设备的购买质量、分布式存储、备份策略
最新文章
- C#运算符大全_各种运算符号的概述及作用
- PHP的学习--Traits新特性
- judge remote file exist
- Java集合---LinkedList源码解析
- jQquery.validate自定义规则的使用案例
- POJ 1704 Staircase Nim 阶梯博弈
- 发送消息执行记事本的“另存为”菜单功能（通过WM_COMMAND控制使用别的程序的菜单命令）
- Java双向链表实现
- wordpress 如何从后台数据库修改theme(图文教程)
- CGContext
- IOS7学习之路十（百度地图API环境搭建）
- 开发H5基本知识摘要
- Linux-Shell编程之数组操作
- 05-树9 Huffman Codes及基本操作
- 用上了Godaddy的美国主机
- JSTL、JSTL核心标签库——流程处理标签
- Booting dircetly into Redlink FW from flash
- Day14 作业
- Python -- 网络编程 -- Socket简单网络通信
- FastAdmin Bootstrap-table 特定某行背景变红