### 前言
在开篇之前，我们先来聊下各自项目所遇到的问题，
在项目实际维护过程中，对于一个初创过后，踏入稳定发展期的项目，都会遇到以下一系列的问题：
1、项目拿到融资了
2、项目往好的方向发展了
3、怎么应用的运行速度越来越慢？
4、服务器经常被DDOS，导致请求堵塞，严重的时候会整个应用瘫痪数小时
5、并发量大时，通常挂掉的不是nginx，而先是mysql？运维人员高峰期一直在线，默默的`kill`掉大量`select`进程？

很多公司遇到这种情况，通常都会这样应对：
1、开启分布式服务器，用2台或多台服务器通过主服务器进行nginx请求转移，也就是俗称的负载均衡处理。
2、使用数据库主从读写分离，通过mysql的主从复制特性，将数据库自动copy成N个，新增修改操作转向主库，然后从库分发请求进行查询操作，简单mysql压力。

上面方案的想象都是美好的，并且是一段时间内有用的。

为什么我们要说一段时间内有用？

接下来我们继续思考下：
1、假设我们是一个主APP应用，又或者是主WEB应用，所有的请求都还是通过HTTP协议进行。
2、一个域名我们只能解析到一个IP地址，通常是主服务器。

这时候问题来了。

假设某天，你的机房电缆被挖断了？你的云服务器IP大量瘫痪，官方让你等待3小时后修复，你的应用怎么办？假设你放假了，外出了，没电脑在身边怎么办？应用要停掉3小时？这样的事情发生多几次，项目初期积累到的所有信誉都会被逐渐消耗掉，最终项目就会垮掉，投资者撤资，项目解体，大家捡包袱走人。

当然，这些不可抗的事情我们无法人力阻挡，但我们再往下想想，假设我们只有2台分布服务器，被DDOS之后，我们只能靠防火墙抵御(这是现今最好的抵御方案)，但当我们抵御不了怎么办？你的应用就要关了？如果一直挡不住，你这项目还要不要了？

还有我们再想，当一段业务期疯涨的时候，主从读写库单表数据量已经上涨到亿级数据，这时候mysql的查询瓶颈就会出现，就算你加了索引、单表不做`join`关联，查询速度都会下降到`0.1`秒级，正常我们是`0.0001`秒级，这是一个什么概念？
原来mysql在1秒内可以处理完1000个查询请求，现在只能处理10个，并发量一上来，再加上应用层程序本身写得可能并不算好，数据库连接释放缓慢，mysql瞬间就会堵塞瘫痪，最终导致的是所有分布式服务器（如果你的主从数据库是跟你的服务器一起的）就会一起垮掉。

做为一名及格的架构师，我们要做的就是细思恐危，提前预知将来发生的一切可能导致应用彻底瘫痪的隐患，并定制应对方案。

### 应对方案

下面我们来总结上面所存在的一些问题：
1、物理主服务，或者云主服务器突然崩溃，域名解析所对应的主服务器将会导致应用彻底瘫痪。
2、被DDOS，防火墙扛不住，分布式服务器也扛不住的时候，该怎么办。
3、当数据量达到千万级时，mysql的应用瓶颈出现，查询性能会出现几何式下降。

##最终我们得到一个这样的应对架构以及应用方案：

### 1、物理主服务，或者云主服务器突然崩溃，域名解析所对应的主服务器将会导致应用彻底瘫痪。
该问题的核心是主服务器挂掉之后，域名解析ping不通，会导致应用请求瘫痪。
这样我们的应对方案就要从域名解析跟应用自动转发进行处理：
1、使用域名商提供的域名解析API，我们用一台定时服务器(与应用无关的服务器)，定时1秒对主域名和所有分布式服务器进行ping检测，当域名ping不通时，就调用域名商的API对其进行域名解析修改。
上面的方案只是解决了域名自动解析的问题，而通常情况下，一个域名的解析修改或者删除后重新解析，延迟都可能高达1分钟到24小时内的延迟，所以应用还是会在一段时间内挂掉，这并不是我们想要的。
对于WEB网页应用来说，我们无法彻底避免这样的事情，但对于APP应用来说，我们还有救。
我们的APP只需要对于API在请求调用前，进行一个Ping解析，当域名解析失败时，我们自动使用分布式服务器的IP对其进行二次复用，这样应用就不会彻底垮掉了。
对应用户而言，可能是这次的请求怎么突然变慢了一点，可以称之为无感知故障自动切换。

### 2、被DDOS，防火墙扛不住，分布式服务器也扛不住的时候，该怎么办。
这是一个很严重，也是很无奈的问题。
这个问题最好的解决方案是看双方谁的钱多，DDOS的核心技术是请求堵塞，也就是通过肉鸡瞬间对你服务器发起大量请求，直至你所有的服务器垮掉。这种流量攻击可使用流量防火墙抵御，但这样需要耗费大量的资金。之所以说看双方谁的钱多，只指攻击者所购买的肉鸡也是需要钱的，他对你发起攻击的同时，他也在浪费钱。
我们就不在继续扯了，看看应对方案，通常对于这种情况，我们只能准备1-2台备用服务器，该服务器数据库不存于主从读写，但参与主库同步。
当我们所有服务器都被攻击跨掉的时候，我们可以让APP应用请求像ping检测一样，自动转发到这些备用服务器中。
一般这种服务器性能都不高，所以我们还是需要运维人员一直在电脑前`kill`掉一部分`select`进程，以保证应用可以运行，不会彻底垮掉。

### 3、当数据量达到千万级时，mysql的应用瓶颈出现，查询性能会出现几何式下降。
这个问题有2个解决方案：
1、不重构应用的数据层，在这个前提下加入人工分表，对大数据量的表进行水平分表，比如id在1-500W的数据就分为表1，一个表就500W数据，这样进行分表存储，之后的查询可以使用id做为查询条件提前预测出在哪个表中就好，这种方案对应用层的代码修改最少。

2、重构应用的数据层，在这个前提下，我们可以编写一套数据库分表代码，对需要分表的表进行自动hash分表，跟nginx hash ip转发请求的含义一样。但这种是建立在重构数据库的，我们需要对旧数据读处理一条条hash，然后转到分表中，然后还需要修改应用层的代码进行分表后的查询写入。这种方案今后不需要再人工维护分表数据跟分表代码，按起步的改动工作量会比方案1大很多。

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺