阿里P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程
大型网站系统的特点和架构设计
http://youzhixueyuan.com/large-website-architecture-design.html
史上最强大型分布式架构详解:高并发+数据库+缓存+分布式+微服务+秒杀
http://youzhixueyuan.com/architect
分布式架构设计(文章合集)
http://youzhixueyuan.com/distributed-architecture-design-articles-collection.html
大数据架构设计(文章合集)
http://youzhixueyuan.com/big-data-architecture-design-articles-collection.html
阶段一、单机构建网站
网站的初期,我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器,如tomcat、jetty、jboos,然后直接使用JSP/servlet技术,或者使用一些开源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis;最后再选择一个数据库管理系统来存储数据,如mysql、sqlserver、oracle,然后通过JDBC进行数据库的连接和操作。
把以上的所有软件都装载同一台机器上,应用跑起来了,也算是一个小系统了。此时系统结果如下:
阶段二、应用服务器与数据库分离
随着网站的上线,【访问量逐步上升,服务器的负载慢慢提高】,在服务器还没有超载的时候,我们应该就要做好准备,提升网站的负载能力。假如我们代码层面已难以优化,在不提高单台机器的性能的情况下,增加机器是一个不错的方式,不仅可以有效地提高系统的负载能力,而且性价比高。
增加的机器用来做什么呢?此时我们可以把数据库,web服务器拆分开来,这样不仅提高了单台机器的负载能力,也提高了容灾能力。
应用服务器与数据库分开后的架构如下图所示:
阶段三、应用服务器集群
随着访问量继续增加,单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情况下,我们可以把应用服务器从一台变成了两台甚至多台,把用户的请求分散到不同的服务器中,从而提高负载能力。多台应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务。著名的做故障切换的软件有keepalived,keepalived是一个类似于layer3、4、7交换机制的软件,他不是某个具体软件故障切换的专属品,而是可以适用于各种软件的一款产品。keepalived配合上ipvsadm又可以做负载均衡,可谓是神器。
我们以增加了一台应用服务器为例,增加后的系统结构图如下:
系统演变到这里,将会出现下面四个问题:
a、用户的请求由谁来转发到到具体的应用服务器
b、有什么转发的算法
c、应用服务器如何返回用户的请求
d、用户如果每次访问到的服务器不一样,那么如何维护session的一致性
我们来看看解决问题的方案:
1)、第一个问题即是负载均衡的问题,一般有5种解决方案:
1、http重定向。HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器,服务器根据算法要求用户重定向,用户收到重定向请求后,再次请求真正的集群
优点:简单。
缺点:性能较差。
2、DNS域名解析负载均衡。DNS域名解析负载均衡就是在用户请求DNS服务器,获取域名对应的IP地址时,DNS服务器直接给出负载均衡后的服务器IP。
优点:交给DNS,不用我们去维护负载均衡服务器。
缺点:当一个应用服务器挂了,不能及时通知DNS,而且DNS负载均衡的控制权在域名服务商那里,网站无法做更多的改善和更强大的管理。
3、反向代理服务器。在用户的请求到达反向代理服务器时(已经到达网站机房),由反向代理服务器根据算法转发到具体的服务器。常用的apache,nginx都可以充当反向代理服务器。
优点:部署简单。
缺点:代理服务器可能成为性能的瓶颈,特别是一次上传大文件。
4、IP层负载均衡。在请求到达负载均衡器后,负载均衡器通过修改请求的目的IP地址,从而实现请求的转发,做到负载均衡。
优点:性能更好。
缺点:负载均衡器的宽带成为瓶颈。
5、数据链路层负载均衡。在请求到达负载均衡器后,负载均衡器通过修改请求的mac地址,从而做到负载均衡,与IP负载均衡不一样的是,当请求访问完服务器之后,直接返回客户。而无需再经过负载均衡器。
2)、第二个问题即是集群调度算法问题,常见的调度算法有10种。
1、rr 轮询调度算法。顾名思义,轮询分发请求。
优点:实现简单
缺点:不考虑每台服务器的处理能力
2、wrr 加权调度算法。我们给每个服务器设置权值weight,负载均衡调度器根据权值调度服务器,服务器被调用的次数跟权值成正比。
优点:考虑了服务器处理能力的不同
3、sh 原地址散列:提取用户IP,根据散列函数得出一个key,再根据静态映射表,查处对应的value,即目标服务器IP。过目标机器超负荷,则返回空。
4、dh 目标地址散列:同上,只是现在提取的是目标地址的IP来做哈希。
优点:以上两种算法的都能实现同一个用户访问同一个服务器。
5、lc 最少连接。优先把请求转发给连接数少的服务器。
优点:使得集群中各个服务器的负载更加均匀。
6、wlc 加权最少连接。在lc的基础上,为每台服务器加上权值。算法为:(活动连接数*256+非活动连接数)÷权重 ,计算出来的值小的服务器优先被选择。
优点:可以根据服务器的能力分配请求。
7、sed 最短期望延迟。其实sed跟wlc类似,区别是不考虑非活动连接数。算法为:(活动连接数+1)*256÷权重,同样计算出来的值小的服务器优先被选择。
8、nq 永不排队。改进的sed算法。我们想一下什么情况下才能“永不排队”,那就是服务器的连接数为0的时候,那么假如有服务器连接数为0,均衡器直接把请求转发给它,无需经过sed的计算。
9、LBLC 基于局部性的最少连接。均衡器根据请求的目的IP地址,找出该IP地址最近被使用的服务器,把请求转发之,若该服务器超载,最采用最少连接数算法。
10、LBLCR 带复制的基于局部性的最少连接。均衡器根据请求的目的IP地址,找出该IP地址最近使用的“服务器组”,注意,并不是具体某个服务器,然后采用最少连接数从该组中挑出具体的某台服务器出来,把请求转发之。若该服务器超载,那么根据最少连接数算法,在集群的非本服务器组的服务器中,找出一台服务器出来,加入本服务器组,然后把请求转发之。
3)、第三个问题是集群模式问题,一般3种解决方案:
1、NAT:负载均衡器接收用户的请求,转发给具体服务器,服务器处理完请求返回给均衡器,均衡器再重新返回给用户。
2、DR:负载均衡器接收用户的请求,转发给具体服务器,服务器出来玩请求后直接返回给用户。需要系统支持IP Tunneling协议,难以跨平台。
3、TUN:同上,但无需IP Tunneling协议,跨平台性好,大部分系统都可以支持。
4)、第四个问题是session问题,一般有4种解决方案:
1、Session Sticky。session sticky就是把同一个用户在某一个会话中的请求,都分配到固定的某一台服务器中,这样我们就不需要解决跨服务器的session问题了,常见的算法有ip_hash法,即上面提到的两种散列算法。
优点:实现简单
缺点:应用服务器重启则session消失。
2、Session Replication。session replication就是在集群中复制session,使得每个服务器都保存有全部用户的session数据。
优点:减轻负载均衡服务器的压力,不需要要实现ip_hasp算法来转发请求。
缺点:复制时宽带开销大,访问量大的话session占用内存大且浪费。
3、Session数据集中存储:session数据集中存储就是利用数据库来存储session数据,实现了session和应用服务器的解耦。
优点:相比session replication的方案,集群间对于宽带和内存的压力减少了很多。
缺点:需要维护存储session的数据库。
4、Cookie Base:cookie base就是把session存在cookie中,有浏览器来告诉应用服务器我的session是什么,同样实现了session和应用服务器的解耦。
优点:实现简单,基本免维护。
缺点:cookie长度限制,安全性低,宽带消耗。
值得一提的是:
nginx目前支持的负载均衡算法有wrr、sh(支持一致性哈希)、fair(本人觉得可以归结为lc)。但nginx作为均衡器的话,还可以一同作为静态资源服务器。
keepalived+ipvsadm比较强大,目前支持的算法有:rr、wrr、lc、wlc、lblc、sh、dh
keepalived支持集群模式有:NAT、DR、TUN
nginx本身并没有提供session同步的解决方案,而apache则提供了session共享的支持。
好了,解决了以上的问题之后,系统的结构如下:
阶段四、数据库读写分离化
上面我们总是假设数据库负载正常,但随着访问量的的提高,数据库的负载也在慢慢增大。那么可能有人马上就想到跟应用服务器一样,把数据库一份为二再负载均衡即可。但对于数据库来说,并没有那么简单。假如我们简单的把数据库一分为二,然后对于数据库的请求,分别负载到A机器和B机器,那么显而易见会造成两台数据库数据不统一的问题。那么对于这种情况,我们可以先考虑使用读写分离的方式。
读写分离后的数据库系统结构如下:
这个结构变化后也会带来两个问题:
a、主从数据库之间数据同步问题
b、应用对于数据源的选择问题
解决问题方案:
我们可以使用MYSQL自带的master+slave的方式实现主从复制。
采用第三方数据库中间件,例如mycat。mycat是从cobar发展而来的,而cobar是阿里开源的数据库中间件,后来停止开发。mycat是国内比较好的mysql开源数据库分库分表中间件。
阶段五、用搜索引擎缓解读库的压力
数据库做读库的话,常常对模糊查找力不从心,即使做了读写分离,这个问题还未能解决。以我们所举的交易网站为例,发布的商品存储在数据库中,用户最常使用的功能就是查找商品,尤其是根据商品的标题来查找对应的商品。对于这种需求,一般我们都是通过like功能来实现的,但是这种方式的代价非常大。此时我们可以使用搜索引擎的倒排索引来完成。
搜索引擎具有以下优点:
它能够大大提高查询速度。
引入搜索引擎后也会带来以下的开销:
带来大量的维护工作,我们需要自己实现索引的构建过程,设计全量/增加的构建方式来应对非实时与实时的查询需求。
需要维护搜索引擎集群
搜索引擎并不能替代数据库,他解决了某些场景下的“读”的问题,是否引入搜索引擎,需要综合考虑整个系统的需求。引入搜索引擎后的系统结构如下:
阶段六、用缓存缓解读库的压力
1、后台应用层和数据库层的缓存
随着访问量的增加,逐渐出现了许多用户访问同一部分内容的情况,对于这些比较热门的内容,没必要每次都从数据库读取。我们可以使用缓存技术,例如可以使用google的开源缓存技术guava或者使用memcacahe作为应用层的缓存,也可以使用redis作为数据库层的缓存。
另外,在某些场景下,关系型数据库并不是很适合,例如我想做一个“每日输入密码错误次数限制”的功能,思路大概是在用户登录时,如果登录错误,则记录下该用户的IP和错误次数,那么这个数据要放在哪里呢?假如放在内存中,那么显然会占用太大的内容;假如放在关系型数据库中,那么既要建立数据库表,还要简历对应的java bean,还要写SQL等等。而分析一下我们要存储的数据,无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据,我们可以用NOSQL数据库来代替传统的关系型数据库。
2、页面缓存
除了数据缓存,还有页面缓存。比如使用HTML5的localstroage或者cookie。
优点:
减轻数据库的压力
大幅度提高访问速度
缺点:
需要维护缓存服务器
提高了编码的复杂性
值得一提的是:
缓存集群的调度算法不同与上面提到的应用服务器和数据库。最好采用“一致性哈希算法”,这样才能提高命中率。这个就不展开讲了,有兴趣的可以查阅相关资料。
加入缓存后的结构:
阶段七、数据库水平拆分与垂直拆分
我们的网站演进到现在,交易、商品、用户的数据都还在同一个数据库中。尽管采取了增加缓存,读写分离的方式,但随着数据库的压力继续增加,数据库的瓶颈越来越突出,此时,我们可以有数据垂直拆分和水平拆分两种选择。
7.1、数据垂直拆分
垂直拆分的意思是把数据库中不同的业务数据拆分道不同的数据库中,结合现在的例子,就是把交易、商品、用户的数据分开。
优点:
解决了原来把所有业务放在一个数据库中的压力问题。
可以根据业务的特点进行更多的优化
缺点:
需要维护多个数据库
问题:
需要考虑原来跨业务的事务
跨数据库的join
解决问题方案:
我们应该在应用层尽量避免跨数据库的事物,如果非要跨数据库,尽量在代码中控制。
我们可以通过第三方应用来解决,如上面提到的mycat,mycat提供了丰富的跨库join方案,详情可参考mycat官方文档。
垂直拆分后的结构如下:
7.2、数据水平拆分
数据水平拆分就是把同一个表中的数据拆分到两个甚至多个数据库中。产生数据水平拆分的原因是某个业务的数据量或者更新量到达了单个数据库的瓶颈,这时就可以把这个表拆分到两个或更多个数据库中。
优点:
如果我们能客服以上问题,那么我们将能够很好地对数据量及写入量增长的情况。
问题:
访问用户信息的应用系统需要解决SQL路由的问题,因为现在用户信息分在了两个数据库中,需要在进行数据操作时了解需要操作的数据在哪里。
主键的处理也变得不同,例如原来自增字段,现在不能简单地继续使用了。
如果需要分页,就麻烦了。
解决问题方案:
我们还是可以通过可以解决第三方中间件,如mycat。mycat可以通过SQL解析模块对我们的SQL进行解析,再根据我们的配置,把请求转发到具体的某个数据库。
我们可以通过UUID保证唯一或自定义ID方案来解决。
mycat也提供了丰富的分页查询方案,比如先从每个数据库做分页查询,再合并数据做一次分页查询等等。
数据水平拆分后的结构:
阶段八、应用的拆分
8.1、拆分应用
随着业务的发展,业务越来越多,应用越来越大。我们需要考虑如何避免让应用越来越臃肿。这就需要把应用拆开,从一个应用变为俩个甚至更多。还是以我们上面的例子,我们可以把用户、商品、交易拆分开。变成“用户、商品”和“用户,交易”两个子系统。
拆分后的结构:
问题:
这样拆分后,可能会有一些相同的代码,如用户相关的代码,商品和交易都需要用户信息,所以在两个系统中都保留差不多的操作用户信息的代码。如何保证这些代码可以复用是一个需要解决的问题。
解决问题:
通过走服务化的路线来解决
8.2、走服务化的道路
为了解决上面拆分应用后所出现的问题,我们把公共的服务拆分出来,形成一种服务化的模式,简称SOA。
采用服务化之后的系统结构:
优点:
相同的代码不会散落在不同的应用中了,这些实现放在了各个服务中心,使代码得到更好的维护。
我们把对数据库的交互放在了各个服务中心,让”前端“的web应用更注重与浏览器交互的工作。
问题:
如何进行远程的服务调用
解决方法:
我们可以通过下面的引入消息中间件来解决
阶段九、引入消息中间件
随着网站的继续发展,我们的系统中可能出现不同语言开发的子模块和部署在不同平台的子系统。此时我们需要一个平台来传递可靠的,与平台和语言无关的数据,并且能够把负载均衡透明化,能在调用过程中收集调用数据并分析之,推测出网站的访问增长率等等一系列需求,对于网站应该如何成长做出预测。开源消息中间件有阿里的dubbo,可以搭配Google开源的分布式程序协调服务zookeeper实现服务器的注册与发现。
引入消息中间件后的结构:
十、总结
以上的演变过程只是一个例子,并不适合所有的网站,实际中网站演进过程与自身业务和不同遇到的问题有密切的关系,没有固定的模式。只有认真的分析和不断地探究,才能发现适合自己网站的架构。
相关推荐
本文通过分享一个电商企业的15次架构演进案例,详细描述了中小企业如何一步步演变为能够承载亿级流量的大型互联网平台。本文中涉及的知识点主要包括企业架构演进、组织架构设计、系统架构设计、技术栈选择以及架构师...
本书全面覆盖了从初期的小型网站到应对高并发、海量数据的大型网站架构演进过程中的关键知识点,旨在为读者提供一个系统性的理解和实践指导。 大型网站架构的核心目标是保证系统的可扩展性、高可用性和性能。早期的...
在互联网的快速发展中,大型网站架构的演变是一个不断探索、创新和优化的过程。这个过程涉及到多个领域的知识,包括但不限于系统架构、数据库管理、负载均衡、分布式计算、缓存策略、安全防护以及性能优化等。本篇...
### 美团技术沙龙第38期-旅游度假预订系统架构演进实践 #### 核心知识点概述 本文档主要围绕美团旅游度假预订系统的架构演进来展开讨论,详细介绍了该系统从无到有、再到不断完善的过程,并针对不同阶段的技术挑战...
在大型网站的架构演进中,最初可能采用单体架构,所有功能模块都在同一台服务器上运行,通过JVM内部调用交互,数据库通过JDBC访问。随着流量增加,会面临单机负载告警,此时数据库与应用服务器分离,减轻单机压力。...
综上所述,大型HTTP服务器的架构演进路线包括了从简单的单体架构到复杂的服务拆分、再到负载均衡和缓存技术的应用等多个方面。这些演进路线和思路是现代大型后端服务器设计中广泛采用的方法,它们是为了应对业务量的...
作者基于在阿里巴巴等知名公司的一线经验,分享了实际工作中遇到的问题、解决方案以及技术演进的过程,旨在帮助读者理解如何从无到有、从小到大构建一个稳定、高效且可扩展的网站架构。 在大型网站的技术架构中,有...
Web网站架构的演变是一个逐步复杂化的过程,从最初的单机架构到分布式、微服务架构,目的是为了应对不断增长的用户需求和数据规模,提高系统的性能、稳定性和可扩展性。每个阶段都是对前一阶段问题的解决和优化,...
大型网站架构是指针对高并发、大流量场景下的网站系统所设计的基础架构。这类架构通常具备高度可靠性、安全性、可扩展性和易于维护等特点,旨在确保网站在面对海量用户访问时依然能够保持稳定运行和服务质量。 ####...
【京东全链路军演系统架构设计与演进】是京东在应对618和双十一等大型促销活动中,为了确保系统稳定性和高并发处理能力所采用的一种关键技术。该系统首次揭秘了全链路压测的技术细节,旨在通过模拟真实用户行为,...
总结来说,阿里云构建千万级别架构的过程是一个逐步演进的过程,从单机到分离Web和数据库,再到动静分离,利用云服务如ECS、RDS、CDN、SLB、MQ、DRDS等,解决性能、扩展性、安全性等问题,最终形成一个成熟、稳定的...
《大型网站与Java中间件实践》一书,由阿里巴巴资深工程师曾宪杰倾力撰写,深入探讨了大型网站从初期发展到复杂系统演进的历史,以及在这个过程中中间件的重要角色。书中详细阐述了如何利用各种中间件技术来解决大型...
今日头条在架构演进的过程中,选择了逐步重构服务的策略,这是一个既稳妥又高效的选择。通过私有云的构建,今日头条不仅实现了前段框架的持续迭代优化,还规划出一个三层架构模型:以PaaS层为核心,统一管理和提供...
### 企业IT高可用与容灾架构演进 #### 高可用和容灾架构的意义 在当前数字化转型的大背景下,...支付宝的发展历程为我们提供了一个从简单到复杂的架构演进案例,对于其他企业在进行IT系统规划时具有重要的参考价值。
【小米MySQL高可用架构演进】的讲解主要涵盖了小米公司在发展过程中如何逐步构建和优化其MySQL数据库系统的高可用性。小米作为一个大型互联网公司,其MIUI操作系统、云服务以及米家智能设备等业务对数据库的需求非常...
这种架构简单易懂,但是在高并发和大流量的情况下,单机架构无法满足性能和可扩展性的需求。 多机部署 多机部署是指将应用程序部署在多个服务器上,以提高性能和可扩展性。这种架构可以通过负载均衡和反向代理来...
【天猫浏览型网站静态化架构设计】是针对大型电商平台如天猫在双11等活动期间应对极高流量冲击的技术解决方案。此架构旨在确保系统在峰值请求下的可伸缩性、用户响应时间和高可用性,同时考虑安全性和成本效益。自...
大型网站的架构通常经历从单机到应用服务和数据服务分离,再到引入缓存(如本地缓存和分布式缓存),然后使用应用服务器集群来提升并发处理能力的过程。在应对高并发时,可能会采用负载均衡、反向代理等技术,以分散...