大型电商项目的服务端架构

大型电商项目的服务端架构

假如有1亿用户的访问量,你的服务器架构是怎样的?我们以淘宝架构为例，了解下大型电商项目的服务端架构是怎样的，如图所示：

• 上面是一些安全体系系统，如数据安全体系、应用安全体系、前端安全体系等。

• 中间是业务运营服务系统，如会员服务、商品服务、店铺服务、交易服务等。

• 还有共享业务，如分布式数据层、数据分析服务、配置服务、数据搜索服务等。

• 最下面是中间件服务，如MQS即队列服务，OCS即缓存服务等。

图中也有一些看不到，例如高可用的体现、实现双机房容灾和异地机房单元化部署，为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

这是一个含金量非常高的架构，也是一个非常复杂而庞大的架构。当然这个架构不是一天两天演进而成，也不是一上来就设计并开发成这么高大上的。

这边我想说的是，小型公司要怎么做架构呢？对很多创业公司而言，很难在初期就预估到流量十倍、百倍以及千倍以后的网站架构会是一个怎样的状况。同时，如果系统初期就设计一个千万级并发的流量架构，也很难有公司可以支撑这个成本。 

因此，一个大型服务系统都是从一步一步走过来的，在每个阶段，找到对应该阶段网站服务器架构所面临的问题，然后在不断解决这些问题，在这个过程中整个架构会一直演进。 

一、单服务器-俗称all in one

从一个小网站说起。一台服务器也就足够了。文件服务器，数据库，还有应用都部署在一台机器，俗称ALL IN ONE。

随着我们用户越来越多，访问越来越大，硬盘、CPU、内存等都开始吃紧，一台服务器已经满足不了。这时看到下一步演进。

二、数据服务与应用服务分离

我们将数据服务和应用服务分离，给应用服务器配置更好的CPU和内存，给数据服务器配置更好更大的硬盘。

分离之后提高一定的可用性，例如Files Server挂了，我们还是可以操作应用和数据库等。

随着访问QPS越来越高，降低接口访问时间，提高服务性能和并发，成为了我们下一个目标，同时发现有很多业务数据不需要每次都从数据库获取。

三、使用缓存

包括本地缓存、远程缓存、远程分布式缓存。

因为 80% 的业务访问都集中在 20% 的数据上，也就是我们经常说的28法则。如果能将这部分数据缓存下来，性能一下子就上来了。而缓存又分为两种：本地缓存和远程缓存缓存，以及远程分布式缓存，我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。

思考的点

1. 具有哪种业务特点数据使用缓存？

2. 具有哪种业务特点的数据使用本地缓存？

3. 具有哪种务特点的数据使用远程缓存？

4. 分布式缓存在扩容时会碰到什么问题？如何解决？分布式缓存的算法都有哪几种？各有什么优缺点？

这个时候随着访问QPS的提高，服务器的处理能力会成为瓶颈。虽然可以通过购买更强大的硬件解决，但总会有上限，而且这个到后期成本就是指数级增长了，这时，我们需要服务器的集群来横向扩展，所以就必须加个新东西：负载均衡调度服务器。

四、使用负载均衡，进行服务器集群

增加了负载均衡、服务器集群之后，我们可以横向扩展服务器，解决了服务器处理能力的瓶颈。

思考的点

1. 负载均衡的调度策略都有哪些？

2. 各有什么优缺点？

3. 各适合什么场景？

打个比方，我们有轮询、权重、地址散列，地址散列又分为原ip地址散列hash、目标ip地址散列hash，最少连接，加权最少连接，还有继续升级的很多种策略......我们都来分析一下。

典型负载均衡策略分析

1. 轮询：优点-实现简单，缺点-不考虑每台服务器处理能力

2. 权重：优点-考虑了服务器处理能力的不同

3. 地址散列：优点-能实现同一个用户访问同一个服务器

4. 最少连接：优点-使集群中各个服务器负载更加均匀

5. 加权最少连接：在最少连接的基础上，为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重，计算出来的值小的服务器优先被选择。

继续引出问题的场景

我们登录时登录了A服务器，session信息存储到A服务器上了，假设我们使用的负载均衡策略是ip hash，那么登录信息还可以从A服务器上访问，但这个有可能造成某些服务器压力过大，某些服务器又没有什么压力，这时压力过大的机器(包括网卡带宽)有可能成为瓶颈，并且请求不够分散。

这时候我们使用轮询或者最小连接负载均衡策略，就导致了第一次访问A服务器，第二次可能访问到B服务器，这时存储在A服务器上的session信息在B服务器上读取不到。

Session管理-Session Sticky粘滞会话

打个比方，如果我们每次吃饭都要保证用的是自己的碗筷，只要我们在一家饭店里存着自己的碗筷，并且每次去这家饭店吃饭就好了。

对于同一个连接中的数据包，负载均衡会将其转发至后端固定的服务器进行处理。

解决了我们session共享的问题，但是它有什么缺点呢？

1. 一台服务器运行的服务挂掉，或者重启，上面的 session 都没了。

2. 负载均衡器成了有状态的机器，为以后实现容灾造成了羁绊。

Session管理-Session 复制

就像我们在所有的饭店里都存一份自己的碗筷。这样随意去哪一家饭店吃饭都OK，不适合做大规模集群，适合机器不多的情况。

解决了我们session共享的问题，但是它有什么缺点呢？

1. 应用服务器间带宽问题，因为需要不断同步session数据。

2. 大量用户在线时，服务器占用内存过多。

Session管理-基于Cookie

打个比方，就是我们每次去饭店吃饭，都带着自己的碗筷去。

解决了我们session共享的问题，但是它有什么缺点呢？

1. cookie 的长度限制。

2. cookie存于浏览器，安全性是一个问题。

Session管理-Session 服务器

打个比方，就是我们的碗筷都存在了一个庞大的橱柜里，我们去任何一家饭店吃饭，都可以从橱柜中拿到属于我们自己的碗筷。

解决了我们session共享的问题，这种方案需要思考哪些问题呢？

1. 保证 session 服务器的可用性，session服务器单点如何解决？

2. 我们在写应用时需要做调整存储session的业务逻辑。

打个比方，为了提高session server的可用性，我们可以继续给session server做集群。

五、中间总结

所以网站架构在遇到某些指标瓶颈、演进的过程中，都有哪些解决方案？它们都有什么优缺点？业务功能上如何取舍？如何做出选择？这个过程才是最重要的。

在解决了横向扩展应用服务器之后，我们继续回到目前的架构图：

数据库的读及写操作都还需要经过数据库。当用户量达到一定量，数据库将会成为瓶颈。又该如何解决呢？

六、数据库读写分离

使用数据库提供的热备功能，将所有的读操作引入slave 服务器，因为数据库的读写分离了，所以我们的应用程序也得做出相应的变化。我们实现了一个数据访问模块(图中的data access module)，使上层写代码的人不知道读写分离的存在。这样多数据源读写分离就对业务代码没有了侵入。同时这里引出了代码层次的演变。

思考的点

1. 如何支持多数据源？

2. 如何封装对业务没有侵入？

3. 如何使用目前业务的ORM框架完成主从读写分离？是否需要更4. 换ORM模型？ORM模型之间各有什么优缺点？

4. 如何取舍？

数据库读写分离会遇到如下问题：

1. 在master和slave复制的时候，考虑延时问题、数据库的支持、复制条件的支持。

2. 当为了提高可用性，将数据库分机房后，跨机房传输同步数据，这个更是问题。

3. 应用对于数据源的路由问题。

七、使用反向代理和CDN加速网站响应

使用 CDN 可以很好地解决不同的地区的访问速度问题，反向代理则在服务器机房中缓存用户资源。

访问量越来越大，我们文件服务器也出现了瓶颈。

八、分布式文件系统

思考的点

1. 分布式文件系统如何不影响已部署在线上的业务访问？不能让某个图片突然访问不到呀。

2. 是否需要业务部门清洗数据？

3. 是否需要重新做域名解析？

这时数据库又出现了瓶颈。

九、数据垂直拆分

数据库专库专用，如图Products、Users、Deal库。解决写数据时并发量大的问题。

思考的点

1. 跨业务的事务如何解决？使用分布式事务、去掉事务或不追求强事务。

2. 应用的配置项多了。

3. 如何跨库进行数据的join操作？

这个时候，某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈。

十、数据水平拆分

如图，我们把User拆成了User1和User2，将同一个表的数据拆分到两个数据库中，解决了单数据库的瓶颈。

思考的点

1. 水平拆分的策略都有哪些？各有什么优缺点？

2. 水平拆分的时候如何清洗数据？

3. SQL的路由问题，需要知道某个User在哪个数据库上。

4. 主键的策略会有不同。

5. 假设系统中需要查询2017年4月份已经下单过的用户名的明细，而这些用户分布在user1和user2上，我们后台运营系统在展示时如何分页？

这个时候，公司对外部做了流量导入，我们应用中的搜索量飙升，继续演进。

十一、拆分搜索引擎

使用搜索引擎，解决数据查询问题。部分场景可使用NoSQL提高性能，开发数据统一访问模块，解决上层应用开发的数据源问题。如图data access module 可以访问数据库、搜索引擎、NoSQL。

总结

本文只是一个举例演示，各个服务的技术架构需要根据自己业务特点进行优化和演进，所以大家的过程也不完全相同。

最后的这个示例也不是完美的，例如负载均衡还是一个单点，也需要集群，我们这个架构也只是冰山一角。因为在架构演进的过程中，还要考虑系统的安全性、数据分析、监控、反作弊等，同时往后继续发展，也要考虑到SOA架构、服务化、消息队列、任务调度、多机房等。

从以上对架构演进的讲解，也可以看出来，所有大型项目的架构和代码，都是一步一步根据实际的业务场景和发展情况发展演变而来，在不同的阶段，会使用的不同的技术，不同的架构来解决实际的问题，所以说，高大上的项目技术架构和开发设计实现不是一蹴而就的。

正是所谓的万丈高楼平地起。在架构演进的过程中，小到核心模块代码，大到核心架构，都会不断演进的，这个过程值得我们去深入学习和思考。

【免责声明】：部分内容、图片来源于互联网，如有侵权请联系删除，QQ：228866015