web服务端的架构演变

最近Lofter项目碰到很多性能上的问题，特别是数据库相关的，每次推送后，告警就会第一时间到来。这些问题随着产品的不断扩展，我想大家肯定都遇到过。目前我们解决性能问题一般都是两种方法：一是加缓存，减少数据库压力；二嘛，就是加服务器了。如果产品的规模继续迅速增长，我们应该怎么做？靠增加服务器肯定不能解决根本问题，应该从架构上着手考虑。今天整理下web服务端架构从简单到复杂的一个演变过程，为今后Lofter的架构调整积累下经验吧。

    第一阶段：web服务器和数据库分离

    好吧，我们的产品肯定不在这个阶段。。。这个大家都知道就不多说了，直接上图：

                 

    第二阶段：增加缓存

       一段时间之后我们发现我们的网站越来越慢， 查找原因，发现是数据库的操作太频繁，导致数据连接竞争激烈，所以响应变慢，这个时候自然的会想到使用数据缓存,如redis、memcache等（最近lofter把memcache换成了nkv），减少对数据库的访问。另一方面，web服务器的负载也越来越大，我们需要对静态资源做缓存，可以使用反向代理服务器（通常的使用apache或nginx，lofter使用的是nginx）；有时需要对某些特定的请求做缓存，比如lofter投放在网易163首页的iframe，访问量很大，也需要缓存，使用的是varnish。加入了这些缓存之后，架构变成如下：

                         

     第三阶段：增加服务器

     这个阶段和上个阶段往往是同时进行的。需要注意的几个问题是： 1 、 负载均衡，这个一般使用apache或nginx的负载均衡方案 ； 2 、如何保持状态信息的同步 ，可选的方案有 cookie 或统一 session服务器 等； 3 、如何保持数据缓存信息的同步，一般使用分布式缓存，如前面提到的memcache等

      Lofter目前正处于这个阶段。这个阶段完了之后，架构如下图：

                 

    第四阶段：数据库分库、分表、读写分离

    随着业务的不断增长，最先达到瓶颈的往往都是数据库，这个阶段基本上都是在解决数据库的性能问题。常用的方法就是：

    1.先按业务逻辑分库，把不同业务的表放在不同的数据库中，降低数据库压力；

    2.分库之后发现数据库的压力又慢慢上去了，往往都是大表造成的，这时候需要对大表进行分表，将大表拆成若干个小表；

    3.如果数据库的读写比很高，通常还会考虑读写分离的方案

    这个阶段需要注意的问题主要有：分库分表方案、数据如何路由、分布式事务如何处理等，大家可以参考淘宝的解决方案TDDL。这个阶段完了之后的架构图如下：

                 

   第五阶段：分布式时代