javaweb电商系统，架构分析及演变（下）

admin

javaweb电商系统，架构分析及演变（上）

阶段六、用缓存缓解读库的压力

1、后台应用层和数据库层的缓存

随着访问量的增加，逐渐出现了许多用户访问同一部分内容的情况，对于这些比较热门的内容，没必要每次都从数据库读取。我们可以使用缓存技术，例如可以使用google的开源缓存技术guava或者使用memcacahe作为应用层的缓存，也可以使用redis作为数据库层的缓存。

另外，在某些场景下，关系型数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户登录时，如果登录错误，则记录下该用户的IP和错误次数，那么这个数据要放在哪里呢？假如放在内存中，那么显然会占用太大的内容；假如放在关系型数据库中，那么既要建立数据库表，还要简历对应的java bean，还要写SQL等等。而分析一下我们要存储的数据，无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。

2、页面缓存

除了数据缓存，还有页面缓存。比如使用HTML5的localstroage或者cookie。

优点：

值得一提的是：

缓存集群的调度算法不同与上面提到的应用服务器和数据库。最好采用“一致性哈希算法”，这样才能提高命中率。这个就不展开讲了，有兴趣的可以查阅相关资料。

加入缓存后的结构：

阶段七、数据库水平拆分与垂直拆分

我们的网站演进到现在，交易、商品、用户的数据都还在同一个数据库中。尽管采取了增加缓存，读写分离的方式，但随着数据库的压力继续增加，数据库的瓶颈越来越突出，此时，我们可以有数据垂直拆分和水平拆分两种选择。

7.1、数据垂直拆分

垂直拆分的意思是把数据库中不同的业务数据拆分道不同的数据库中，结合现在的例子，就是把交易、商品、用户的数据分开。

优点：

• 解决了原来把所有业务放在一个数据库中的压力问题。
• 可以根据业务的特点进行更多的优化
  

缺点：

问题：

解决问题方案：

• 我们应该在应用层尽量避免跨数据库的事物，如果非要跨数据库，尽量在代码中控制。
• 我们可以通过第三方应用来解决，如上面提到的mycat，mycat提供了丰富的跨库join方案，详情可参考mycat官方文档。
  

垂直拆分后的结构如下：

7.2、数据水平拆分

数据水平拆分就是把同一个表中的数据拆分到两个甚至多个数据库中。产生数据水平拆分的原因是某个业务的数据量或者更新量到达了单个数据库的瓶颈，这时就可以把这个表拆分到两个或更多个数据库中。

优点：

• 如果我们能客服以上问题，那么我们将能够很好地对数据量及写入量增长的情况。
  

问题：

• 访问用户信息的应用系统需要解决SQL路由的问题，因为现在用户信息分在了两个数据库中，需要在进行数据操作时了解需要操作的数据在哪里。
• 主键的处理也变得不同，例如原来自增字段，现在不能简单地继续使用了。
• 如果需要分页，就麻烦了。
  

解决问题方案：

• 我们还是可以通过可以解决第三方中间件，如mycat。mycat可以通过SQL解析模块对我们的SQL进行解析，再根据我们的配置，把请求转发到具体的某个数据库。
• 我们可以通过UUID保证唯一或自定义ID方案来解决。
• mycat也提供了丰富的分页查询方案，比如先从每个数据库做分页查询，再合并数据做一次分页查询等等。
  

数据水平拆分后的结构：

阶段八、应用的拆分

8.1、拆分应用

随着业务的发展，业务越来越多，应用越来越大。我们需要考虑如何避免让应用越来越臃肿。这就需要把应用拆开，从一个应用变为俩个甚至更多。还是以我们上面的例子，我们可以把用户、商品、交易拆分开。变成“用户、商品”和“用户，交易”两个子系统。

拆分后的结构：

问题：

• 这样拆分后，可能会有一些相同的代码，如用户相关的代码，商品和交易都需要用户信息，所以在两个系统中都保留差不多的操作用户信息的代码。如何保证这些代码可以复用是一个需要解决的问题。
  

解决问题：

8.2、走服务化的道路

为了解决上面拆分应用后所出现的问题，我们把公共的服务拆分出来，形成一种服务化的模式，简称SOA。

采用服务化之后的系统结构：

优点：

• 相同的代码不会散落在不同的应用中了，这些实现放在了各个服务中心，使代码得到更好的维护。
• 我们把对数据库的交互放在了各个服务中心，让”前端“的web应用更注重与浏览器交互的工作。
  

问题：

阶段九、引入消息中间件

随着网站的继续发展，我们的系统中可能出现不同语言开发的子模块和部署在不同平台的子系统。此时我们需要一个平台来传递可靠的，与平台和语言无关的数据，并且能够把负载均衡透明化，能在调用过程中收集调用数据并分析之，推测出网站的访问增长率等等一系列需求，对于网站应该如何成长做出预测。开源消息中间件有阿里的dubbo，可以搭配Google开源的分布式程序协调服务zookeeper实现服务器的注册与发现。

引入消息中间件后的结构：

十、总结

以上的演变过程只是一个例子，并不适合所有的网站，实际中网站演进过程与自身业务和不同遇到的问题有密切的关系，没有固定的模式。只有认真的分析和不断地探究，才能发现适合自己网站的架构。

下一篇，我将根据小型项目的实际情况，设计出11套具体的方案，分别对应拥有1~12机器时，如何利用这些稀少的资源搭建小型的高可用，高扩展的结构出来。

下下篇，才轮到实战，我将结合docker虚拟技术，实现快速的集群搭建。

敬请期待~

本文有什么说错的地方，希望大家指出，让我好改正过来，多谢。

参考：

《大型网站技术架构：核心原理与案例分析》——李智慧 著

《大型网站系统与Java中间件实践》——曾宪杰 著

《MySQL性能调优与架构设计》——简朝阳 著

《keepalived权威指南》

《mycat权威指南》

《dubbo用户指南》

《计算机网络》

《操作系统》