从一个小网站变成了大型网站，网站架构上到底发生了什么变化？

我不是个爱吹牛逼的人，直接上干货，只讲架构。以Java开发的网站为例。

这个时候，按照现在的行情，基本上是SpringMVC，Spring容器，然后MyBatis，然后跑在Tomcat里，数据库基本上用的是MySQL。数据库和Tomcat跑在同一台服务器上。

网站做得好，人流不会少。流量多了，服务器的负载也就相应的会变大，那么我们会采取什么行动？有人说会说负载均衡啊，那你想过没，你做负载均衡的成本是多少？你要改写多少代码？我相信没有哪家公司会狠心这么做。这个时候，最省钱，最稳妥，见效最快的办法就是把Tomcat和MySQL分离，分别放在两台服务器上跑。那么在代码层面上，只要修改下JDBC的URL就行。

调整以后，这样的结构可以缓解目前的压力，但是随着流量继续增多，那么这种架构还是需要进一步演进。

其实这个很容易理解，一台服务器不够，那我来几台，几台不够我来个集群，这样总够了吧。在这个阶段要注意的是，你会面临几个问题

1、如何避免“一核有难,九核围观”的窘境

2、Session怎么保持？

针对第一个问题，已经有很成熟的负载均衡方案了 Nginx+Keepalived+LVS。

针对第二个问题，首先解释下为什么会有Session的问题，在前面两个架构中，当用户A访问Tomcat A时，Tomat A会记录用户A的Session，这个没有问题，但是到了现在这个架构，有多个Tomcat了，我第一次访问，经过负载均衡之后访问的是Tomcat A，而第二次访问经过负载均衡之后却交给了Tomcat B来处理，可是我的Session在Tomcat A上，Tomat B并不知情。问题就在这里。

这里解决方案其实有很多，你可以把用户A的所有Session存在Cookie中，让用户随身带着，在访问Tomcat时，Tomcat从Cookie中恢复出Session；也可以把Session在每个Tomcat上都存一遍；也可以通过负载均衡根据IP Hash来让某个用户的请求只能由固定某个Tomcat来处理。

Tomcat已经是集群了，现在该轮到数据库动刀了。网站的特点决定了他的数据库基本上是读取的次数要远比写入的次数多，那么我们可以考虑让读和写分开。这里需要解决的问题是两个数据库如何才能做到数据同步。解决方案自己找，数据同步的核心问题是延迟。

已经做了读写分离了，我们还能做点什么？

数据库的数据毕竟是存在硬盘上，读写速度受限于磁头，如果数据库的数据存在内存上呢？这就是缓存。

我们这里主要谈的是数据库，那么我就单独讨论数据缓存。数据缓存可以简单的理解为一个HashMap，它根据K来找V。理解了原理那就简单了，我把数据库里访问频率最高的数据放这个HashMap里不就完了么，对啊，就是这个思路。

那就只能拆数据库咯，怎么拆？你的网站总有几个模块吧？用户模块，产品模块，就假设这两个，那我就把用户相关的表放在一个数据库里，产品相关的表再放到一个数据库里。这种思想叫垂直拆分。

我们知道，通常一个业务会设计多个模块的数据修改，但是垂直拆分之后，如何保持两个数据库的数据同时修改了呢？

1、分布式事务

2、不用事物，通过表关联查询

具体细节自己找。

如果垂直拆封也不能满足了呢？对，猜对了，就是水平拆分，说简单点，我用户表数据太多，那么我按注册时间来拆，16年前的存一个数据库，16年到现在的存一个数据库。搞定。

水平拆分带来的问题是，查询需要在两个表中都进行。

数据库折腾到这里基本上差不多了，再折腾下去就是上NoSQL了。

一个系统太庞大了，怎么办？和数据库一样，拆。我用户一个系统，产品一个系统。这两个系统只完成自己分内的事，互不干涉。应用拆分会导致一些代码冗余，那怎么办，那就是第七阶段。

我的系统还有其他很多应用，那么我把这些应用中共同的部分抽出来作为服务，比如上面提到的一个用户应用和商品应用，那么我把这两个抽出来变成用户中心和商品中心，这两个服务都只对自己的数据库操作。应用之间的通信可以通过MQ来传递。

以上。