以淘宝为例，解析大型电商服务端架构！( 三 ) _架构

随着访问量过大，数据量过大，某个业务的数据库数据量和更新量已经达到了单个数据库的瓶颈了，这个时候就需要进行数据库的水平拆分，例如把 user 拆分成了 user1 和 user2，就是将同一个表的数据拆分到两个数据库当中，这个时候我们解决了单数据库的瓶颈。
水平拆分时候又要注意哪些点，都有哪几种水平拆分的方式。进行了水平拆分后，又会遇到几个问题，第一 sql 路由的问题，假设有一个用户，我们如何知道这个用户信息是存在了 user1 还是 user2 数据库中，由于分库了，我们的主键策略也会有所不同，同时会面临分页的问题，假设我们要查询某月份已经下单的用户明细，而这些用户又分布在 user1 和 user2 库中，我们后台运营管理系统对它进行展示的时候还要进行分页。这些都是我们在使用这个架构时需要解决的问题。

文章插图

搜索引擎与 NoSQL在网站发布并进行了大规模的推广后，导致我们应用服务器的搜索量又飙升，我们把应用服务器的搜索功能单独抽取出来做了一个搜索引擎，同时部分场景可以使用 NoSQL来提高性能。同时我们开发一个数据统一的访问模块，同时连着数据库集群、搜索引擎和 NoSQL，解决上层应用开发的数据源问题。

文章插图

后序这里只是简单举例，并没有依据什么实际的业务场景。事实上各个服务的架构是要根据实际的业务特点进行优化和演进的，所以这个过程也不是完全相同的。当然这个架构也不是最终形态，还存在很多要提升的地方。
例如负载均衡服务器目前是一个单点的，如果负载均衡服务器访问不了，那么后续的包括服务器集群等也就无法访问了。所以可以将负载均衡服务器做成集群，然后做一些主从的双机热备，同时做一个自动切换的解决方案。
在整个架构的演进过程中，其实还包含更多需要关注的内容，比如安全性、数据分析、监控、反作弊......针对一些特定的场景例如交易、充值、流计算等使用消息队列、任务调度......整个架构继续发展下去，做成 SOA 架构、服务化 (微服务)、多机房......
最后，我想说高大上的项目技术架构和开发设计实现绝不是一僦而就的。