学习分享之《大型网站系统与Java中间件实践》

本篇文章是对曾宪杰老师《大型网站系统与Java中间件实践》书中内容的部分总结，该书主要讲解随着网站数据量、访问量的增长而引发的架构变迁，在架构升级过程中引入的各种解决方案及带来的问题。感兴趣的话可以看看曾老师的书讲的通俗易懂。

1.单体构建应用服务

2.数据库与应用拆分

3.应用服务集群

应用服务集群后会引出一个问题，哪台服务器给客户端提供服务？可以通过DNS解决，另一种是在集群前面增加负载均衡设备。

应用集群后的另一个问题，session数据不一致？看看下面的解决方案的好与坏。

3.1 session sticky

Session sticky该方案是在负载均衡器上做了"手脚"，让相同的请求访问同一应用服务器，

该方案带来的问题：

1. 一台服务器重启或宕机，则该机器上的session数据丢失；
2. Session是应用层信息，负载均衡器要将同一请求访问同一服务器，则要对应用层(7层)解析，开销比第四层大。
3. 负载均衡器变为有状态节点，需要保存客户端和服务端的映射，内存消耗要大。

3.2 session replication

Session replication将session数据同步到集群的其它服务器上。

该方案带来的问题：

1. 同步session占用网络带宽，并且随着集群数量增加开销越大；
2. 集群中的每个节点都存储所有session数据，如果访问的客户端越多则session占用的资源越多。

3.3 session集中存储

Session集中存储和session replication相比，没有了同步session数据操作，也没有了大量重复session数据，集群中的任意节点对session的修改、删除都操作的同一份数据。

该方案带来的问题：

1. 对session的读写从本地操作变为了网络操作；
2. 如果存储session的机器出现问题会影响使用。

4.数据库的变化

4.1读写分离

增加一个读库，该库不承担应用写入只提供读取。

该方案带来的问题：

1. 数据的复制问题；
2. 应用对多数据源的选择。

4.2增加搜索引擎

增加搜索引擎解决了站内某些查询的问题，提供更高的效率，可以认为搜索引擎是个读库。

4.3增加缓存

缓存、搜索引擎和读库的功能很类似，用来分担数据库读的压力。

5.数据库变化二

读写分离后应用所有模块的数据仍在一个库里。

5.1 专库专用，垂直拆分

该方案带来的问题：

多数据源问题；

单机事务变为分布式事务或不追求强事务支持。

5.2 水平拆分

水平拆分是把同一个表的数据拆分到两个数据库中，水平拆分的原因是数据表的数据量或更新量达到单个库的瓶颈。

与读写分离的区别：读写分离解决读压力大的问题，对于数据量或更新量大不起作用。

与垂直拆分的区别：垂直拆分是把不同的表拆分到不同的库。

该方案带来的问题：

1. SQL路由问题，操作数据前须知道数据分布在哪；
2. 主键自增问题，例如mysql不能直接使用表上的自增字段，并且不能使用数据库的限制来保证主键不重复。

6.服务化之路

通过服务化无论是API层还是服务中心都可以由固定的小团队维护，能更好地提供稳定性。

服务化后系统分为三层：

API层：调用一个或多个service层的服务然后组装数据，注重与前端提交互，不必关注过多业务逻辑；

Service层：相当于服务中心，聚焦自己模块的核心逻辑以及为API层和Service层提供服务；

DB层：业务数据库。

该方案带来的问题：

1. 引入RPC远程调用，不再是单机的内部方法调用。