部署串讲/项目问题解决方法

第 5 章 部署串讲

5.1 部署项目

学习目标：

了解 网站架构演变流程

了解 网站架构部署原则

5.1.1 架构演变

这一节的目的就是让大家来了解一下，互联网的软件项目架构一般的发展过程。

项目的架构

一般来说，任何一个项目至少有三层内容来组成：

web访问层、数据库层、存储层

 

初级阶段

单体阶段

常见场景：项目初期

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

应用特点：开发简单

 

 

 

应用/数据分离阶段

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

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

应用特点：开发简单

 

 

 

页面动静分离阶段

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

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

应用特点：开发简单

  

 

 

页面/数据缓存阶段

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

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

应用特点：开发简单

 

 

 

中期阶段

应用服务集群阶段

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

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

应用特点：业务中等

 

 

 

数据库读写分离化

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

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

应用特点：业务中等

 

 

 

存储分布式

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

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

应用特点：业务中等

 

 

 

业务应用拆分

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

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

应用特点：业务复杂

 

 

 

中后期阶段

业务拆分

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

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

应用特点：业务复杂

 

微服务阶段

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

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

应用特点：业务复杂

 

 

5.1.2 架构部署

通用架构

 

 

 

一级定位：核心组成部分

web 、数据库、存储层

二级定位：功能增强部分

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

部署项目

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

对于架构层中的一级角色，我们的部署原则是：

站在用户访问资源角度，从后向前依次部署。

对于架构层中的二级角色，我们的部署原则是：

站在用户访问资源压力角度，需要部署哪里，就部署哪里，注意前后的信息交流。

5.2 项目运营

学习目标：

了解 常见网站质量分析指标及其特点

知道 常见网站优化思路

5.2.1 网站分析

常见术语

我们在日常生活中经常会听说，XX网站日PV多少，日UV多少，每日访问峰值是多少之类的话，而这些名词都是项目正常运营的过程中，为了更好的对项目的运行维护，我们对网站进行分析必须知道一些常用的网站分析术语。

IP: 独立IP数

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

特点：

同一个IP无论访问多少网页，独立IP数均为1

PV：Page view页面浏览量

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

特点：

用户每打开一个页面就记录一次，就算访问同一页面多次，就记录多次

UV：Unique Visitor 访问网站的用户

指一天内访问某站点的人数，以cookie/客户端为依据

特点：

一天内，同一访问用户的多次访问只记录1次

VV：Visit View 用户访问网站次数

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

特点：

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

BR：Bounce Rate 跳出率

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

特点：

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

CR：Conversion Rate 转化率

指一天内访问用户中，打开网站后，继续浏览该网站其他页面的比例

特点：

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

 

网站分析术语多如牛毛，每个公司的业务方向不一样，评判标准也不一样，上面只是举例了几种常见的术语，这些术语的常用场景如下：

口语描述：

术语：IP、PV、UV

人员：所有岗位

网站质量：

术语：跳出率和转化率

人员：产品、开发

常见分析工具

服务器服务日志、公司内部监控平台、等

互联网网站分析工具：

站长工具、百度统计、云平台监控等

 

5.2.2 网站优化

网站优化思路

关于项目正常运行，就是网站运行过程中，不论遇到什么问题，我们都能应对下去。一般来说就是用户访问量变化的时候我们做的优化等工作。那么我们就站在开发的角度，从网站的分层上面来看一下常见问题及其解决方案。

 

缓存层方面

问题描述：

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

解决思路：

很常见的就是自建Web缓存，或者购买CDN，将用户经常访问的、更新频率低的资源存放起来，这样用户再次请求相同资源的时候，就不会对后端的服务造成影响。当然防止互联网上的恶意访问/爬虫，我们应该做好相应的安全措施。

缓存之类的措施一定要适合公司的当前业务，如果是项目的静态资源很多，只要我们购买的CDN够好，那么用户访问量随便。

 

代理层方面

问题描述：

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

解决思路：

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

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

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

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

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

 

问题描述：

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

解决思路：

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

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

 

项目后端web访问

问题描述：

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

解决思路：

可以根据架构演变的思路，我们合理的调整页面访问的关键流程，在技术方面我们可以这么做：

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

请求量大：

Web缓存/CDN，或者动态web集群可以考虑一下

数据库操作多：

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

 

问题描述：

如何提高静态web资源的访问质量？

解决思路：

结合前段缓存的功能，在代码或者代理部分设置合理的资源缓存过期时间，定时/实时推送相关信息到前段的缓存层。

 

数据层方面

问题描述：

用户访问数据有压力

解决思路：

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

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

 

开发角度：

关注数据库表的设计，表的索引合理、查询的时候，尽量使用条件查询

 

存储层方面：

问题描述：

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

解决思路：

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