eshop1-大型电商架构演进

1. 项目初期

 

2. 服务器分离

以上的服务分离架构，即便文件服务crash 了，可是application server 和 Database Server 继续能够访问运行

 3. 基于并发访问愈来愈高，数据库压力愈来愈大，引入分布式缓存

80%的数据访问基于20%的业务数据上，28原则

分布式缓存思考

（1）.那种业务数据适合远程分布式缓存

（2）.那种业务数据适合本地缓存

（3）.分布式缓存扩容的时候存在的问题，如何解决，算法有哪些

（4）.基于这种架构，咱们须要解决的问题

 4. QPS 访问愈来愈高，Application Server 将会出现瓶颈，增长负载均衡调度服务器

 

 思考的问题

（1）.负载均衡的调度策略有哪些，各有什么优缺点，例如轮训（实现简单，不考虑服务器的处理能力），权重（考虑服务器处理能力），地址散列（原IP地址散列，目标地址散列， 实现同一个用户访问同一个服务器）

（2）.假设一个场景，一个用户第一次访问A 服务器，session信息被存储到A服务器上，可是因为负载均衡服务器，同一个用户第二次访问的时候，访问了B服务器，可是B服务器上没有用户的session信息，所以解决session管理的问题

上图session 管理缺点

（1）.某一个application server 重启了，这时候session 所有消失

（2）.第二种session解决方案，session copy

（1）. 解决session共享问题

（2）.缺点Cookie长度是有限制的

（3）.Cookie 保存在浏览器上，不安全

所以出现了一下方案

 

缺点

（1）.Session server 是单点，如何保证系统正常的运行

（2）.咱们能够考虑session server 集群

（3）.适用于Web服务器session 服务器多的场景

 

5. 当用户量达到必定数量时，数据库就会出现瓶颈，如何解决，数据库的读写分离

 

应用接入多数据源

应用程序也应该须要相应的变化

data access module 数据写入模块，是开发人员不知道读写分离的存在，多数据源对业务代码无侵入性

当数据的IO很是大的时候，咱们的主库与附库在跨机房传输的时候，又是一个要解决的问题？

6. 增长CDN 与反向代理服务器，能够很好的解决不一样的地区访问速度的问题

反向代理能够缓存用户数据，这个时候咱们的文件服务器可能会出现了瓶颈

7. 文件服务器分布式集群

 

分布式文件系统

（1）.是否须要备份服务器

8. 这个时候，数据库又出现瓶颈，专库专用的原则（micro service的设计理念），进行数据的垂直拆分，解决写数据并发量大的问题

问题：

（1）. 跨数据库的事务

（2）.可使用分布式事务

（3）.或者去掉事务，或者不使用强制性事务

随着数据量，访问量的变大，咱们每一个业务的数据量已经达到单个数据库的瓶颈，这个时候进行数据库水平拆分

 

 解决单数据库的问题

拆分的时候注意点：

（1）. SQL的路由问题

（2）.既然user表进行了分库，可是面临的另一个涉及分页的问题

9. 当解决这以上问题以后，咱们的搜索又会出现瓶颈，把应用服务器的搜索功能独立出来，架设一个搜索引擎服务器

 

 

data access module 连接着数据库，搜索引擎，NoSQL Server

该架构也不是最后的架构，根据实际的业务来决定，例如以上的架构负载均衡服务器是一个单点，所以仍然能够继续提高优化空间