大型Web网站架构演变之9大阶段(3)

发布时间：2019-05-10 18:02 所属栏目：21 来源：程序猿的内心独白

导读：随着访问量的增加，逐渐出现了许多用户访问同一部分热门内容的情况，对于这些比较热门的内容，没必要每次都从数据库读� Ｎ颐强梢允褂没捍婕际酰缈梢允褂肎oogle的开源缓存技术Guava或者使用Memecahed作为应用层

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

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

页面缓存

除了数据缓存，还有页面缓存。比如使用HTML5的localstroage或者Cookie。除了页面缓存带来的性能提升外，对于并发访问且页面置换频率小的页面，应尽量使用页面静态化技术。

优点：减轻数据库的压力，大幅度提高访问速度;
缺点：需要维护缓存服务器，提高了编码的复杂性。

值得一提的是：

缓存集群的调度算法不同与上面提到的应用服务器和数据库。最好采用一致性哈希算，这样才能提高命中率。

加入缓存后的系统结构如下：

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

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

数据垂直拆分

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

优点：

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

缺点：

需要维护多个数据库的状态一致性和数据同步。

问题：

需要考虑原来跨业务的事务;
跨数据库的Join。

解决问题方案：

应该在应用层尽量避免跨数据库的分布式事务，如果非要跨数据库，尽量在代码中控制。
通过第三方中间件来解决，如上面提到的MyCat，MyCat提供了丰富的跨库Join方案，详情可参考MyCat官方文档。

数据垂直拆分后的结构如下：

数据水平拆分

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

优点：

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

问题：

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

解决问题方案：

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

数据水平拆分后的结构如下：

阶段八、应用的拆分

按微服务拆分应用

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

拆分后的结构：

问题：

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

解决问题：

通过走服务化SOA的路线来解决频繁公共的服务。

走SOA服务化治理道路

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

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

（编辑：ASP站长网）