常见的javaweb中间件（学习分享之大型网站系统与Java中间件实践）
常见的javaweb中间件（学习分享之大型网站系统与Java中间件实践）图4应用服务集群后会引出一个问题，哪台服务器给客户端提供服务？可以通过DNS解决，另一种是在集群前面增加负载均衡设备。图23.应用服务集群图3
本篇文章是对曾宪杰老师《大型网站系统与Java中间件实践》书中内容的部分总结，该书主要讲解随着网站数据量、访问量的增长而引发的架构变迁，在架构升级过程中引入的各种解决方案及带来的问题。感兴趣的话可以看看曾老师的书讲的通俗易懂。
1.单体构建应用服务
图1
2.数据库与应用拆分
图2
3.应用服务集群
图3
应用服务集群后会引出一个问题，哪台服务器给客户端提供服务？可以通过DNS解决，另一种是在集群前面增加负载均衡设备。
图4
应用集群后的另一个问题，session数据不一致？看看下面的解决方案的好与坏。
3.1 session sticky
图5
Session sticky该方案是在负载均衡器上做了"手脚"，让相同的请求访问同一应用服务器，
该方案带来的问题：
- 一台服务器重启或宕机，则该机器上的session数据丢失；
- Session是应用层信息，负载均衡器要将同一请求访问同一服务器，则要对应用层(7层)解析，开销比第四层大。
- 负载均衡器变为有状态节点，需要保存客户端和服务端的映射，内存消耗要大。
3.2 session replication
图6
Session replication将session数据同步到集群的其它服务器上。
该方案带来的问题：
- 同步session占用网络带宽，并且随着集群数量增加开销越大；
- 集群中的每个节点都存储所有session数据，如果访问的客户端越多则session占用的资源越多。
3.3 session集中存储
图7
Session集中存储和session replication相比，没有了同步session数据操作，也没有了大量重复session数据，集群中的任意节点对session的修改、删除都操作的同一份数据。
该方案带来的问题：
- 对session的读写从本地操作变为了网络操作；
- 如果存储session的机器出现问题会影响使用。
4.数据库的变化
4.1读写分离
图8
增加一个读库，该库不承担应用写入只提供读取。
该方案带来的问题：
- 数据的复制问题；
- 应用对多数据源的选择。
4.2增加搜索引擎
图9
增加搜索引擎解决了站内某些查询的问题，提供更高的效率，可以认为搜索引擎是个读库。
4.3增加缓存
图10
缓存、搜索引擎和读库的功能很类似，用来分担数据库读的压力。
5.数据库变化二
读写分离后应用所有模块的数据仍在一个库里。
5.1 专库专用，垂直拆分
图11
该方案带来的问题：
多数据源问题；
单机事务变为分布式事务或不追求强事务支持。
5.2 水平拆分
水平拆分是把同一个表的数据拆分到两个数据库中，水平拆分的原因是数据表的数据量或更新量达到单个库的瓶颈。
与读写分离的区别：读写分离解决读压力大的问题，对于数据量或更新量大不起作用。
与垂直拆分的区别：垂直拆分是把不同的表拆分到不同的库。
图12
该方案带来的问题：
- SQL路由问题，操作数据前须知道数据分布在哪；
- 主键自增问题，例如mysql不能直接使用表上的自增字段，并且不能使用数据库的限制来保证主键不重复。
6.服务化之路
图13
通过服务化无论是API层还是服务中心都可以由固定的小团队维护，能更好地提供稳定性。
服务化后系统分为三层：
API层：调用一个或多个service层的服务然后组装数据，注重与前端提交互，不必关注过多业务逻辑；
Service层：相当于服务中心，聚焦自己模块的核心逻辑以及为API层和Service层提供服务；
DB层：业务数据库。
该方案带来的问题：
- 引入RPC远程调用，不再是单机的内部方法调用。
