最近Lofter项目碰到很多性能上的问题,特别是数据库相关的,每次推送后,告警就会第一时间到来。这些问题随着产品的不断扩展,我想大家肯定都遇到过。目前我们解决性能问题一般都是两种方法:一是加缓存,减少数据库压力;二嘛,就是加服务器了。如果产品的规模继续迅速增长,我们应该怎么做?靠增加服务器肯定不能解决根本问题,应该从架构上着手考虑。今天整理下web服务端架构从简单到复杂的一个演变过程,为今后Lofter的架构调整积累下经验吧。
第一阶段:web服务器和数据库分离
好吧,我们的产品肯定不在这个阶段。。。这个大家都知道就不多说了,直接上图:
![](https://i-blog.csdnimg.cn/blog_migrate/cad9b4304f088f9fca6f974c9c2e0345.png)
第二阶段:增加缓存
一段时间之后我们发现我们的网站越来越慢,
查找原因,发现是数据库的操作太频繁,导致数据连接竞争激烈,所以响应变慢,这个时候自然的会想到使用数据缓存,如redis、memcache等(最近lofter把memcache换成了nkv),减少对数据库的访问。另一方面,web服务器的负载也越来越大,我们需要对静态资源做缓存,可以使用反向代理服务器(通常的使用apache或nginx,lofter使用的是nginx);有时需要对某些特定的请求做缓存,比如lofter投放在网易163首页的iframe,访问量很大,也需要缓存,使用的是varnish。加入了这些缓存之后,架构变成如下:
![](https://i-blog.csdnimg.cn/blog_migrate/44d360faca52b7b25f522bb2f4dacc77.png)
第三阶段:增加服务器
这个阶段和上个阶段往往是同时进行的。需要注意的几个问题是:
1
、
负载均衡,这个一般使用apache或nginx的负载均衡方案
;
2
、如何保持状态信息的同步
,可选的方案有
cookie
或统一
session服务器
等;
3
、如何保持数据缓存信息的同步,一般使用分布式缓存,如前面提到的memcache等
Lofter目前正处于这个阶段。这个阶段完了之后,架构如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/42d32292dc8f1e8b1e8e4c3fa9e02943.png)
第四阶段:数据库分库、分表、读写分离
随着业务的不断增长,最先达到瓶颈的往往都是数据库,这个阶段基本上都是在解决数据库的性能问题。常用的方法就是:
1.先按业务逻辑分库,把不同业务的表放在不同的数据库中,降低数据库压力;
2.分库之后发现数据库的压力又慢慢上去了,往往都是大表造成的,这时候需要对大表进行分表,将大表拆成若干个小表;
3.如果数据库的读写比很高,通常还会考虑读写分离的方案
这个阶段需要注意的问题主要有:分库分表方案、数据如何路由、分布式事务如何处理等,大家可以参考淘宝的解决方案TDDL。这个阶段完了之后的架构图如下:
![](https://i-blog.csdnimg.cn/blog_migrate/354d575ff3e72127e39fd5ab01f6f39c.png)
第五阶段:分布式时代