<dl id="gvpps"><menu id="gvpps"></menu></dl>

<div id="gvpps"><ol id="gvpps"></ol></div>

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

        如果您有代购或者代维服务器、PHP网站建设、程序代码修改、系统开发等需求,可以联系我购买付费服务。QQ401313302

        我们以?#21592;?#26550;构为例,了解下大型电商项目的服务端架构是怎样的,如图所示:


        • 上面是一些安全体系系统,如数据安全体系、应用安全体系、前端安全体系等。
        • 中间是业务运营服务系统,如会员服务、商品服务、店铺服务、交易服务等。
        • 还有共享业务,如分布式数据层、数据分析服务、配置服务、数据搜索服务等。
        • 最下面是中间件服务,如MQS即队列服务,OCS即缓存服务等。

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

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

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

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

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


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

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

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



        三、使用缓存


        包括本地缓存、远程缓存、远程分布?#20132;?#23384;。

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

        思考的点

        • 具有哪种业务特点数据使用缓存?
        • 具有哪种业务特点的数据使用本地缓存?
        • 具有哪种务特点的数据使用远程缓存?
        • 分布?#20132;?#23384;在扩容?#34987;?#30896;到什么问题?如何解决?分布?#20132;?#23384;的算法都有哪几种?各有什么优缺点?

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


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

        思考的点

        • 负载均衡的调度策略都有哪些?
        • 各有什么优缺点?
        • 各适合什么场景?

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

        典型负载均衡策略分析

        • 轮询:优点-实现简单,缺点-不考虑每台服务器处理能力
        • 权重:优点-考虑了服务器处理能力的不同
        • 地?#39134;?#21015;:优点-能实现同一个用户访问同一个服务器
        • 最少连接:优点-使集群中各个服务器负载更加均匀
        • 加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。

        继续引出问题的场景


        Session管理-Session Sticky?#25345;?#20250;话


        打个比方,如果我们?#30475;?#21507;饭都要保证用的是自己的碗筷,只要我们在一家饭店里存着自己的碗筷,并且?#30475;稳?#36825;家饭店吃饭就好了。

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

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

        一台服务器运行的服务?#19994;簦?#25110;者重启,上面的 session 都没了。

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

        Session管理-Session 复制


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

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

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

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

        Session管理-基于Cookie


        打个比方,就是我们?#30475;稳?#39277;店吃饭,?#21363;?#30528;自己的碗筷去。

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

        cookie 的长度限制。

        cookie存于浏览器,安全性是一个问题。

        Session管理-Session 服务器



        打个比方,就是我们的碗筷?#21363;?#22312;了一个庞大的橱柜里,我们去任?#25105;?#23478;饭店吃饭,都可以从橱柜中拿到属于我们自己的碗筷。

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

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

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

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

        五、中间总结

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

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


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

        六、数据库?#21015;?#20998;离




        思考的点

        • 如何支持多数据源?
        • 如何封装对业务没有侵入?
        • 如?#38382;?#29992;目前业务的ORM框架完成主从?#21015;?#20998;离?是否需要更4. 换ORM模型?ORM模型之间各有什么优缺点?
        • 如?#31283;?#33293;?

        数据库?#21015;?#20998;离会遇到如下问题:

        • 在master和slave复制的时候,考虑延时问题、数据库的支持、复制条件的支持。
        • 当为了提高可用性,将数据库分机房后,跨机房传输同步数据,这个更是问题。
        • 应用对于数据源的路由问题。

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



        八、分布式文件系统


        思考的点

        • 分布式文件系统如何不影响已部署在线上的业务访问?不能让某个图片突然访问不到呀。
        • 是否需要业务部门清洗数据?
        • 是否需要重新做域名解析?

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

        九、数据垂直拆分



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

        思考的点

        • 跨业务的事务如何解决?使用分布式事务、去掉事务或不追求强事务。
        • 应用的配置项多了。
        • 如何跨库进行数据的join操作?

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

        十、数据水平拆分


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

        思考的点

        • 水平拆分的策略都有哪些?各有什么优缺点?
        • 水平拆分的时候如何清洗数据?
        • SQL的路由问题,需要知道某个User在哪个数据库上。
        • 主键的策略会有不同。

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

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

        十一、拆分搜索引擎

        总结

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

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

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

        未经允许不得转载:好玩吧 » 假如有1亿用户的访问量,你的服务器架构是怎样的?

        评论 0

        • 昵称 (必填)
        • 邮箱 (必填)
        • 网址
        新疆11选5开奖结果查
        <dl id="gvpps"><menu id="gvpps"></menu></dl>

        <div id="gvpps"><ol id="gvpps"></ol></div>

              <dl id="gvpps"><menu id="gvpps"></menu></dl>

              <div id="gvpps"><ol id="gvpps"></ol></div>