当前位置:主页 > SEO优化 >

假如有1亿用户的访问量你的服务器架构是怎样的?

作者: 奕星SEO 分类: SEO优化 发布时间: 2019-09-26 14:43 内容来源:网络整理阅读量:

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

  我们以淘宝架构为例,了解下大型电商项目的服务端架构是怎样的,如图1所示:

假如有1亿用户的访问量你的服务器架构是怎样的?

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

假如有1亿用户的访问量你的服务器架构是怎样的?

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

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

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

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

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

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

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

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

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

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

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

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

  保证 session 服务器的可用性,session服务器单点如何解决?

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

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

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

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

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

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

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

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


本文链接地址:http://www.seohuizhou.com/seoyouhua/8246.html
上一篇:<<自建食品网站 外卖平台分支 两种情况网售食品 扬州将备案
下一篇:上网被“劫持”问题出在哪儿>>