中大型网站的架构是如何演变的？( 五 ) _网站

还有一种拆分方式是这样的，比如说我们的用户表数据量非常非常大，一张表数据达到了8千万，那我们查询读取这张表的时候会不会特别慢，即便你已经垂直拆分到了一个服务器上进行管理，但是你仍然不能解决一张表8千万的问题，那么如何解决呢？聪明的你会想到分表存放，这种方式就是水平拆分方式，将用户表分成表1、表2、表3......,通过这样的方式你可以将这8千万的用户分到子表中，而具体的分表方式可以采用很多种方案，例如进行ID取模，具体方式由于篇幅问题不再描述。
3.MyCat
分库分表之后，你会发现数据库压力真的变小了很多，但是也会有很多不方便的事情，比如说

分布式事务提交问题
分库分表的运维和获取问题
跨数据库的join聚合查询问题
Mysql中自增字段（AUTO_INCREMENT)还能用吗？
某些约束条件在分库分表的环境下会不会特别复杂了？

这个时候你会用到分库分表中间件-MyCat，它是一个彻底开源的，面向企业应用开发的大数据库集群，支持事务、ACID、可以替代MySQL的加强版数据库，一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群，一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server，结合传统数据库和新型分布式数据仓库的新一代数据库中间件产品。

八、分布式文件系统

文章插图

在系统的发展过程中，会发现有一些图片、视频、Excel等不同格式的大文件也需要做出处理，比如说大型系统中的用户头像，8千万的用户就需要有8千万的头像，每张头像都需要占用一定的存储空间（一般来说4K到几百M都有可能），那么如何去处理这些文件的存储呢？保存到数据库中技术上完全可以，但是仅限于说说哈，如果实际这么做了可能你的系统会面临很大的压力。
为了解决这种问题，就出现了分布式文件系统这样的技术，典型比较通用的包括MogileFS、FastDFS 。
MogileFS是一个开源的分布式文件存储系统，是由LiveJournal旗下的Danga Interactive公司开发。目前使用MogileFS的公司非常多，如日本排名先前的几个互联公司以及国内的Yupoo(又拍)、digg、豆瓣、大众点评、搜狗等，分别为所在的组织或公司管理着海量的图片。以大众点评为例，用户全部图片均有MogileFS存储，数据量已经达到500TB以上。
FastDFS是由阿里数据库大神开发，是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

九、应用服务化拆分 + 消息中间件

文章插图

如果思考过京东、美团、淘宝等等这些大型互联网公司的业务模块，你会发现他们每增加一块业务，其实就是在增加一个业务组件，比如说某生活服务公司的业务分布如图所示：

文章插图

在上图中会发现业务组件部分包括了用户、支付、搜索、推荐、地理位置等等，其中的每一个业务组件其实都对应着一项服务，而且都有专门的数据库服务器进行维护管理，也就是之前提到的分库分表，而分库分表拆分的是数据，那如何对业务进行拆分，将每一种业务分成一种服务，需要什么服务就去调用什么服务，从而让系统更加的专一和精确，如果对应到我们的架构上，就需要在数据层和应用层添加一个层面——服务组件层，其实这种架构方式就是应用服务化拆分。
提到应用服务化拆分，就不得不提及服务化治理框架，这里就需要引入三种主流的应用服务化技术：Zookeeper、Dubbo以及消息解耦异步的消息中间件技术——MQ消息队列.
1.Zookeeper
一般来说，Zookeeper常常跟dubbo是配合使用的，因为Dubbo需要进行服务注册，而ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到 ZooKeeper 中心，服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。
2.Dubbo
提到服务治理，dubbo绝对是一个优秀的服务治理框架，它可以通过透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置即可，这样不管是扩展了几种业务组件，都可以像调用本地方法一样调用其他的业务方法，使用起来非常方便，用过的人一般都知道，只需要加一个注解就可以使用其方法，而且调用的效率非常高。