简述一个大型交易网站的发展旅程

   一、功能定义： 

 

– 商品 ： 展示商品， 商品管理，……

– 交易 ： 创建交易， 交易管理， ……

– 用户 ： 注册用户， 信息查询， 用户 管理， ……

  

   二、技术发展

第一版：简单基础版

      出于快速开发的考虑，第一版往往采用 单台机器构建（这里采用java技术，下同），这样开发方便而且快速，采用的技术甚至可以是最简单的jsp,servlet等。

      它的技术特点：

     • 三 个功能模块

     • 一个数据库中的三个表

     • 连接数据库使用了 JDBC

     • 模块之间的调用是 JVM 内部的方法调用

第二版：应用和数据库分离

     随着访问量的上升，这台机器的负载越来越高，这时可以说是该网站遇到的第一个性能问题，此时一般的解决方案很简单， 将应用 (App) 和数据库 (DB) 拆分到两台机器上

       这种改造实现了应用服务器和数据服务器的分离， 对开发、测试、部署，没什么影响。

第三版：多台应用服务器

     访问量持续上升，应用服务器的压力也变的很大，第二版的简单设计已经不能支撑这么大的访问量，所以不得不继续对其进行改造。

     它的设计方案就是将 应用从 1 台拆分到了两台，甚至多台。但此时会遇到的问题——session。 Session 的数据保存在服务器中，服务器拆分前后，如何维护session的一致性？比如，下图中，将应用服务器拆分为A应用服务器和B应用服务器，当一个顾客先访问A服务器，然后经过通过页面跳转到了B服务器，此时A中有该用户的session，而B没有，造成访问有误。

    

它的解决方案：

• 解法 1 ： Session-Sticky

           一个用户访问了一次后，同一个session周期内，所有的请求都定向到这个服务器，只有当游览器关闭或者服务器挂掉，session才会丢失

• 解法 2 ： Session Replication

         session replication 策略是复制会话，即一个用户访问了一次就把session复制到所有的服务器或这一部分服务器。这样的好处是如果正访问的服务器down了， 用户可以自动被转到别的服务器session不丢失。缺点当然是效率低。  

• 解法 3 ：基于 Cookie

• 解法 4 ： Session 数据集中独立存储

特别强调：

      1. Web中的Session指的就是用户在浏览某个网站时，从进入网站到游览器关闭所经过的这段时间，也就是用户浏览这个网站所花费的时间。 A用户和C服务器建立连接时所处的Session同B用户和C服务器中建立连接时所处的Sessions是两个不同的Session。

      2. 当用户在相同机器的应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。

第四版：读写分离

    随着业务的发展，数据库会成为瓶颈，读写比例很高（相当于读数据库的人很多，而写数据库的人相对而言少）

    解决方案，通过读写分离，降低主库的压力

第五版：

      1.为了方便用户更快地找到商品，系统引入搜索引擎；为了减轻数据库的访问压力和提高访问速度，引入了缓存；为了解决海量数据存储，引入了分布式文件存储。系统架构如下

    

      2. 引入CDN系统， CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

第六版：数据库拆分

     虽然读写分离了，但虽这业务的增长，主库还是会遇到瓶颈。这时，我们可以根据功能，对数据库进行切分。具体如下图，原先的数据库中包含了所有数据，现在将其进行“垂直切分”——就是不同的数据库存储不同类型的表。

     

     这个交易系统中，就是分库为商品表，交易表，用户表。

     这时需要注意的问题包括：

     1. 对之前的一些有事务的SQL，可能造成影响

     2. 对之前的多表join的SQL，可能造成影响。

      原先多张表是在同一数据库中，用join操作是相当容易的，现在不同的表在不同的数据库中，一个join操作要用到在不同的表，此时就需要访问不同的服务器。

ps：

事务讲解： http://blog.csdn.net/lengyuhong/archive/2010/11/02/5981872.aspx

第七版：

      用垂直拆分后，能够缓解很大的问题，但如果数据库和访问量地原因，造成单台数据库还是不能够去负担。这时就需要对数据库进行水平拆分。 具体如下图中的用户表。

      水平切分和垂直切分的不同在于扩展方式上，举例而言，原先一台服务器一个数据库三张表TA，TB,TC。垂直切分就是三台服务器，每台服务器一个数据库，服务器A中存TA表，服务器B存TB表，服务器C存TC表。水平切分也是三台服务器，每台服务器一个数据库，服务器A，B，C中都存有TA,TB,TC三张表。

     这杨拆分后，还是带来了新的问题：

     1. 路由

         比如有两台服务器，都存有用户数据，当我们要插入一条用户信息时，应该插入到哪台服务器的数据库上；当我们要检索一条用户信息时，我们应该到哪台服务器上查找。

     2. 分页

     3. 合并

     个人觉得2,3两种情况通常会一起发生，比如我们要查出前一百名的用户（具体比如在网站购物最多的用户），此时可能的情况是这前100名中60个在数据库A，40个在数据库B。

     4. 唯一主键

     用户表分布在两台数据库中，如何做到两台数据库中的用户表有唯一主键。

第八版：

     引入服务化

       它可以解决两个问题：

       1. 解决了业务核心的稳定和一致的问题

       2. 解决了重要数据库的连接数的问题

第九版：

      引入消息中间件

      – 解耦

      – 异步   

      三、技术总结     

最后系统的架构：

大致总结这个网站的技术发展过程：

1 台 机器 +1 个应用 +1 一个 DB

应用和 DB 分到两个机器

应用部署多机器，走入集群

DB 读写分离

引入搜索

引入 Cache

引入分布式存储

引入 CDN

数据库垂直拆分

数据库水平拆分

应用的拆分

服务化

引入消息中间件

 

 

     这篇文章来源于自己最近在淘宝参加的一个培训课程——《java中间件》，当中介绍“一个交易网站的旅程”的内容，自己特别收益，所以在它的基础上整理出这篇文章。