淘宝架构变迁历程(淘宝架构的前世今生是什么)

近日正在写高并发,找到一篇关于高并发架构演变的好文章,受益匪浅,故与各位共勉,我想各位看官必有所得

1.概述

以淘宝为例,描述了服务端在100级至千万级并发时架构的进化过程,并在此基础上列出各个进化阶段所遇到的有关技术,使我们能够全面地了解架构的进化,并在文末总结了架构设计中的若干原理。

特别声明:本论文以淘宝为例只是方便解释演进过程中可能会出现的问题,而不是淘宝真实技术演进路径

2,基本概念

在引入架构前,为避免有些读者不理解架构设计的某些理念,现将一些最基本的理念简介如下:

分布式的

一个系统的几个模块部署到不同服务器,就可以说是分布式系统了,比如Tomcat与一个数据库被单独部署到不同服务器或者是两个功能完全相同的Tomcat被单独部署到了不同服务器

高可用

当系统的某些节点发生故障,而另一些节点又能接替其继续服务的时候,就可以认为该系统是可用的

集群中

某个特定领域中的软件被部署到多个服务器中,以整体的形式提供某类业务,该整体叫做集群。例如, Zookeeper内部Master与Slave被单独部署到多个服务器并一起构成一个整体来提供集中配置服务。这样就可以通过一台服务器实现多个客户端同时访问同一个集群。本文将主要探讨集群技术及其应用。一、集群概述集群是分布式系统(Distributed System)的简称。在普通簇内,客户端通常可以与任一节点相连以获取服务,而当簇内某一节点发生掉线后,另一节点通常可以自动接替其继续服务,此时表明簇内存在高可用性

负载均衡

当请求被送到系统后,以一定方式将其均匀地分配给若干节点,使得系统内各节点都能对请求负载进行均匀地处理,那么就可以认为该系统达到了负载均衡

正向代理与反向代理当系统内需要接入外部网络的时候,请求会被统一地通过一台代理服务器转发给外部网络,从外部网络的角度来看,这是代理服务器启动的接入,这时代理服务器就已经实现了正向代理,而外部请求输入系统后,代理服务器会将请求转发给系统内的某一台服务器,而对于外部请求而言,与其进行互动的仅有代理服务器,这时代理服务器已经实现了反向代理,即反向代理。因此,在正向代理和反向代理人之间存在着转换关系。正向代理是对内部代理进行管理,而反向代理则是对外部用户进行管理。本文主要研究了正向代理和反向代理商间的转换问题。通俗地说,正向代理就是代理服务器在系统内替代以接入外部网络,反向代理就是当外部要求接入系统后经由代理服务器向内部服务器进行转发。

3,架构演进

3.1单机架构

图片[1]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

以淘宝为例。网站初期应用数量和用户数均比较小,可将Tomcat及数据库部署到同一台服务器。但是随着用户的不断增多,对电子商务网站性能提出了更高的要求。为了使用户能及时地获得所需信息,我们需要通过Internet网络向客户提供Web服务,其中一个重要功能就是网页浏览。浏览器向www.taobao.com发出请求后,先通过DNS服务器(域名系统)将域名转换成实际IP地址10.102.4.1.1.浏览器转到IP相应的Tomcat上。

在用户数增加的情况下, Tomcat与数据库争夺资源,单机性能无法满足业务支持

3.2首次演变:将Tomcat和数据库单独部署

图片[2]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

Tomcat与数据库各自对服务器资源的独占显著提升了二者各自的性能。

随着用户数量的增加,并发读写数据库成了一个瓶颈问题

3.3二次演进:本地缓存与分布式缓存的介绍

图片[3]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

向Tomcat同一个服务器或者同一个JVM添加本地缓存和向外添加分布式缓存来缓存热门商品信息或者热门商品html页面等等。最后对本文提出的改进方案进行了测试和分析。结果表明:该算法可以有效地提高数据访问效率;同时还具有较好的扩展性和可扩展性;并且降低了系统开销。提高了用户体验。缓存可以有效地减少读写数据库的时间和降低数据库压力。

所涉及到的技术主要有:memcached被用作本地缓存, Redis被用作分布式缓存,这将涉及到缓存一致性,缓存穿透-击穿,缓存雪崩和热点数据集中故障。

缓存抵抗绝大部分访问请求,并发压力随用户数增加主要落入单机Tomcat,且响应渐缓

3.4第三次演进,引入反向代理,达到负载均衡

图片[4]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

将Tomcat单独部署于多个服务器,并利用反向代理软件Nginx向各Tomcat均匀地发布请求。如果每台服务器之间的负载不平衡,则可以通过调整客户端和服务器端之间的通信关系来解决。实验结果表明,这种方法能够有效地提高系统的性能。2.研究了多副本策略。3。这里假定Tomcat最多可以支持100次并发而Nginx最多可以支持50000次并发,则Nginx理论上在500次Tomcat中发布请求可以抵御50000次并发。

所涉及到的技术有:Nginx, HAProxy等,它们均为反向代理软件工作于网络第七层,支持http协议为主,会涉及到session共享和文件上传下载等。

反向代理使得应用服务器所能支持的并发量显着增加,但是并发量增加也就意味着更多的请求渗入了数据库中,单机上的数据库终于变成了一个瓶颈

3.5第四次演变:数据库读写分离

图片[5]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

将数据库分为读库与写库两部分,读库中可以存在若干个,利用同步机制将写库中的数据与读库进行同步,针对要查询最近写入数据的场景,可以在缓存中增加一个,并利用缓存来获取最近的数据。

所涉及技术有:Mycat作为数据库中间件可以通过其对数据库进行分离读写、分库分表等组织,客户端也可以通过其对下层数据库进行访问,这就涉及到了数据同步、数据一致性等问题。

业务逐步变多,各业务间访问量相差悬殊,各业务对数据库直接争夺,互相影响表现

3.6第5次演变:数据库按照业务进行分库

图片[6]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

将不同操作的数据分别保存在不同数据库内,从而减少了操作间对资源的竞争,对访问次数较多的操作,可部署较多服务器进行支持。但是在很多情况下,由于数据量太大,不能满足存储要求,只能采用分布式存储方式进行存储;而如果数据量较小,则可选择集中式存储模式。但是这种方式会产生大量冗余数据文件。这也就造成了跨业务的表格不能直接进行关联分析而需采用其它方式进行求解,但是这并不是本论文探讨的关键,感兴趣的可自己去寻找解决方案。

随着用户数增加,单机写库将逐步进入性能瓶颈

3.7第6次演变:将大表拆成小表

图片[7]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

例如对于评论数据可以根据商品ID执行hash并路由至相应表格中保存;对于支付记录可以按小时建立表格并将每小时表格不断拆成小表并利用用户ID或者记录编号实现数据路由。另外,本文还介绍了如何根据不同的应用场景和需求选择合适的数据库访问技术。(4)对整个系统架构做了详细说明,并给出了具体实现方法。针对实时操作,可根据需要对不同类型的表数据量进行处理,并将处理结果返回给服务器进行分析和比较,从而实现对小表和数据库的水平扩展。Mycat在实现过程中采用了先从大表到小表的顺序进行访问控制。

数据库运算量大,DBA工作时间长。4.针对上述问题,本文提出一种基于MPP的分布式数据库解决方案。该方案以ORACLE为基础,使用J2EE框架技术进行开发。当数据库被设计成这样的结构后,它就已可被称为分布式数据库了,但它仅仅是一个合乎逻辑的数据库总体,数据库中的不同部分分别通过不同部件完成,例如分库分表管理与请求分发、通过Mycat完成、通过单机上的数据库完成SQL解析、通过网关与消息队列完成读写分离、通过数据库接口层完成查询结果汇总等,该结构实际上就是MPP(大规模并行处理)结构中的一种。

当前开源与商用均已拥有相当数量的MPP数据库,开源方面较为热门的包括Greenplum, TiDB, Postgresql XC, HAWQ,商用方面如南大通用(GBase),睿帆科技(雪球DB),华为(LibrA),等

不同MPP数据库重点各有不同,例如TiDB更加关注分布式OLTP情景, Greenplum更加关注分布式OLAP情景,这类MPP数据库基本上提供与Postgresql, Oracle, MySQL相似的SQL标准支持,可以将一个查询解析成分布式执行计划发布给璟机并行执行并最后通过数据库自身汇总数据返回出去,同时还提供权限管理,分库分表,事务和数据副本功能,且多数可以支持100多个节点集群运行,极大地降低了运维成本和扩展水平。

无论是数据库还是Tomcat均可以实现水平扩展并能支持并发显着提升,而随着用户数量增加,单机Nginx终将成为一个瓶颈

3.8第七次演进:采用LVS或者F5实现多台Nginx的负载均衡

图片[8]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

因为瓶颈是Nginx,所以不能用两层Nginx对多个Nginx负载均衡。为此提出了基于三层结构的多客户端服务器系统(MDAS),该系统结构简单,易于扩展。详细介绍了其各层模块设计方法并给出了一个应用实例。图9幅,表4个。图1中LVS及F5为工作于网络第4层上负载均衡解决方案, LVS为软件且运行于操作系统内核态下,可以转发TCP请求或者更高一级网络协议,所以支持协议更加丰富且性能比Nginx高得多,可以推测单机LVS可以支持数十万个并发请求转发, F5为负载均衡硬件且具有LVS所提供容量相近、性能较LVS高但是成本较高。

因为LVS为单机版软件,如果LVS所处服务器宕机将造成整个后端系统不可接入,所以需要一个备用节点。

可以利用keepalived软件包模拟虚拟IP,再将虚拟IP与多个LVS服务器进行绑定,浏览器获取虚拟IP后由路由器将其重定向至真实LVS服务器端,主LVS服务器端宕机后keepalive软件包自动更新路由器内部路由表并将虚拟IP重定向至另一普通LVS服务器端以实现LVS服务器端高可用。

这里要说明上图所示是从Nginx层至Tomcat层这一绘制方式并不能表示所有Nginx转发了所有Tomcat请求,实际应用中可能有多个Nginx下连接了部分Tomcat.这几个Nginx间通过keepalived达到了高可用状态,而另一些Nginx则连接了另一个Tomcat,这可以使可访问Tomcat次数倍增。

因为LVS又是单机,当并发数增加到数十万以后, LVS服务器终将到达瓶颈,这时用户数已达千万级乃至数亿级,而且用户遍布各个区域,离服务器机房的远近不一样,造成接入的时延也将有显着差异

3.9第8次进化:DNS轮询,机房间负载均衡

图片[9]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

DNS服务器上可以配置1个域名与若干个IP地址相对应,各IP地址分别与不同机房内虚拟IP相对应。通过对这些信息进行分析,可以发现网络上存在着一些特殊的地址组合。利用这些特定的地址组合来实现对用户身份认证和访问控制是一种非常有效的方法。用户在访问www.taobao.com的时候DNS服务器采用轮询策略或者其它策略选择特定的IP让用户进入。

该方法可以使机房之间达到负载均衡状态,此时系统可以实现机房级别横向拓展,千万级别至亿级别并发量均可以通过添加机房解决,请求在系统入口并发已经不是一个难题。

随着资料的丰富程度及业务的开展,人们对检索,分析等方面的要求也在不断丰富,仅靠数据库是不能解决这种丰富要求的

3.第10次进化:介绍NoSQL数据库、搜索引擎及其他技术

图片[10]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

当数据库内数据多达到一定大小后,数据库不适合进行复杂查询,通常只满足一般查询场景。为了提高数据库效率,可以考虑采用一些特殊算法来解决这个问题,比如使用索引机制和压缩存储技术。但是这类方法会造成性能下降甚至无法运行。例如,在一些大型的统计报表中,由于数据量大,对复杂查询和全文检索都是一个挑战,而采用基于内容的可变数据结构来存储这些庞大的数据又会增加数据库的负担。所以有必要根据具体场景介绍适当的方案。

比如针对海量文件存储可以采用分布式文件系统HDFS来求解,针对keyvalue类数据可以采用HBase、Redis来求解,针对全文检索情景可以采用搜索引擎ElasticSearch来求解,针对多维分析情景可以采用Kylin、Druid来求解。

当然引入较多组件也增加了系统复杂度、不同组件所保存数据需同步进行、需兼顾一致性、需具备较多运维手段对其进行管理等等。

引入更多的组件来解决丰富需求,可以大大拓展业务维度,伴随而来的就是一款应用含有过多业务代码而难以进行业务升级迭代

3.11第10次进化:将大应用拆解为小应用

图片[11]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

根据业务板块对应用代码进行分割,使得个别应用责任更加明确,彼此之间能够实现自主升级迭代。如果需要将某一模块迁移到其他系统中,只需在一个服务器上部署新模块即可。随着软件规模和复杂度越来越大,分布式计算成为了主流,对软件性能也提出了越来越高的要求。此时应用间可能涉及一些公共配置的问题,可采用分布式配置中心Zookeeper的方法进行处理。

不同的应用有共享的模块,应用分别管理将造成同一代码有多个,从而造成公共功能升级中所有应用代码必须随之升级

3.12第11次进化:重用功能被抽离为微服务

图片[12]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

例如用户管理,订单,支付,鉴权等等功能存在于各种应用当中,则可将这些功能代码分别提取出来组成独立的服务进行管理,这类服务被称为微服务(MPC).应用与服务间通过HTTP, TCP或者RPC请求进行各种公共服务访问,每类独立服务可被独立团队进行管理。

另外,还可借助Dubbo, SpringCloud框架进行服务治理,限流,熔断和降级,以增强其稳定性与可用性。

不同的服务接口接入方式是不一样的,应用代码要适配各种接入方式才能够利用服务,另外应用在接入服务时,服务间可能会互相接入,调用链就会很复杂、逻辑就会很乱

3.第13次演进,介绍企业服务总线ESB屏蔽服务接口接入差异

图片[13]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

接入协议转换由ESB统一分配,后端业务由应用统一分配,业务和业务也由ESB互相调用以减少系统耦合。最后在此基础上提出一种基于Saa S模式的分布式数据库管理系统模型,它可以实现分布式数据库系统中的数据集成、数据共享和信息发布等功能。本文还介绍了该分布式数据库系统的关键技术及其特点。1。本文从多个角度对公共服务和企业消息总线进行研究分析,提出了基于SOA(面向服务)的微服务架构,并且给出了具体的实现方法及相应的表现形式。

从个人观点来看,微服务架构多指将系统内公共服务提取出来进行单独运维管理, SOA架构是将服务进行拆分,使得服务接口访问趋于一致的架构思想, SOA架构蕴含着微服务思想。

业务持续开展,应用与服务也会越来越多,而应用与服务部署也越来越复杂,在同一台服务器中部署多种服务也要处理好运行环境之间的矛盾,另外针对如大促这一类要求动态扩缩容、要求对服务性能进行水平扩展的场景,还要求在新增加的服务中做好运行环境准备、服务部署等工作,运行维护难度也会越来越大

3.14第13次进化:引进容器化技术,对运行环境进行隔离和动态服务管理

图片[14]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

当前最为热门的容器化技术有Docker,最为热门的容器管理服务有Kubernetes(K8S).应用/服务可封装成Docker镜像并通过K8S实现镜像的动态发布与部署。但这些技术并不能完全解决应用/服务在迁移过程中遇到的问题,因为它们只是提供了一些基本的解决方案,而不是真正的解决问题。Docker镜像中包含了所有与应用/服务有关的信息,包括操作系统、应用/服务的运行代码以及运行环境等。

如果没有“操作系统”这个镜像,Docker镜像是无法正常工作的,也会给运维带来很大的麻烦。

大促前,可将服务器从已有机器集群中分割出来启动Docker镜像以加强服务性能,大促结束后镜像可关闭而不会影响机器中其它服务(3.14节前服务运行到新机器时需修改系统配置以适应服务,大促会使机器中其它服务所需运行环境受到破坏)。

当采用容器化技术时,服务动态扩缩容的问题就迎刃而解了,但机器仍然要由企业自己去管,当不是大促时,仍然要有很多空闲的机器资源去处理大促问题,而且机器本身的费用和运维成本也是极其高昂,资源利用率也不高

3.15第14次进化:基于云平台的承载系统

图片[15]-淘宝架构变迁历程(淘宝架构的前世今生是什么)-【聚禄鼎】一站式企业服务平台

该系统可以部署于公有云之上,借助公有云大量机器资源解决动态硬件资源问题,实现大促期间云平台内暂时应用较多资源,并联合Docker, K8S等技术实现服务快速部署,大促完成时资源释放,实现真正意义上按需支付,极大提高资源利用率,也极大地降低运维成本。

云平台是指将大量机器资源通过资源的统一管理抽象成资源整体,上面可以根据需要动态地应用硬件资源(例如CPU,内存和网络),而且上面还提供了通用操作系统,并提供了用户可以利用的常用技术组件(例如Hadoop技术栈和MPP数据库),甚至还可以提供已经开发完成的应用程序,用户可以无需关系到应用程序内采用何种技术来解决各种需求(例如音视频转码,邮件服务和个人博客)。

云平台上将涉及到以下一些概念:

IaaS:基础设施就是服务基础设施包括硬件和软件两部分。硬件是指设备,如计算机,打印机,传真机等,软件则主要指人与机器之间的交互过程及相关信息传输系统。机器资源指的是整个系统中的所有资源,它包括了从硬件到软件的全部资源,也就是我们通常所说的资源整体和硬件资源。

对应于上面所述的基于Paa S(平台与服务相结合)模式,可以灵活地部署应用;从这一意义上说,软件就是为客户提供一种服务的工具或手段。在这个定义下,我们可以把一个软件开发过程看作是一个平台建设的过程。具体地讲,它包括以下几个方面。与上述内容相对应,提供了常见技术组件,便于系统开发与维护;

对应于上面所述的基于Saa S(软件即服务)模式下的用户付费;从广义上讲,它包括硬件、系统软件和应用软件等方面。狭义的“软件产品”是指硬件产品及与之配套的各种软件,如操作系统、数据库等。软件产业就是以软件开发为基础的新兴产业。与上文描述的所提供的已开发应用或者服务相对应的是根据功能或者性能需求支付相应费用。

至此,上文所述从高并发接入问题到业务的构架及系统的实现层面均已有自己的解决思路,但是也应清醒地看到,上文所述实际上故意忽视了跨机房数据同步,分布式事务实现等现实问题,今后还有机会将其拿出另行探讨

4,架构设计概述

架构的重组一定要遵循以上演变路径吗?我们可以从三个角度来理解这个变化:第一是从原来的一个系统到现在的多个系统;第二是从原来的一个应用扩展为多应用;第三是从原来的单一功能拓展为多功能。不对,上面说的架构演变顺序,只对某一个方面分别做了改进,而在真实场景下,也许同一时间有多个问题要处理,也许最先到达瓶颈的就是另一个方面,此时要根据真实问题来切实处理。例如:对于政府类的应用来说,由于其业务种类繁多、并发量大,特别是一些高并发的应用,此时就需要根据不同类型的应用提出相应的具有丰富需求的解决方案。

对即将执行的系统应在多大程度上进行架构设计?

对于已经实现的系统,在满足一定的性能指标基础上进行架构设计,使其能够适应新的需求,同时也要考虑到随着时间的推移可能会出现的新问题以及新的性能指标对现有的扩展架构提出了挑战;在需求分析过程中需要对功能进行细化分解,使其易于实现;针对不同类型的用户群体,可以有针对性地配置功能模块;通过引入新技术或改进现有技术来提高系统性能。系统与其他电商平台相比,其最大的特点是它的用户量非常庞大,而这些用户又都需要在规定时间内完成对系统各项性能指标的测试,因此采用迭代升级架构来解决这个问题显得尤为必要:那么如何保证系统的并发?

服务端架构与大数据架构之间有何不同?

所谓“大数据”,实际上就是海量数据获取清洗与转换,数据存储,数据分析和数据服务场景解决方案的总称,每个场景中包含各种可选技术,例如数据获取包括Flume, Sqoop和Kettle,数据存储包括分布式文件系统HDFS, FastDFS和NoSQL数据库HBase, MongoDB,数据分析包括Spark技术栈和机器学习算法。

大数据架构主要包括大数据组件、分布式存储、分布式计算、多维分析、数据仓库和机器学习算法等等。大数据处理包括了三个方面:即数据采集、数据分析和数据管理。服务端架构作为整个应用组织中最重要的一个部分,它的性能直接影响着整个系统的性能,所以我们需要对底层能力进行优化和提升,那么如何构建一个高效的大数据架构呢?

有什么架构设计原理吗?

N+1设计模式。系统各部分要实现无单点故障;

回滚设计。即对原有的系统进行重新定义和修改后再使用的过程。它是一种将旧设备改造成符合新要求的设备,从而使之发挥最大功效的方法。保证系统能够前向兼容,系统升级时应该能够有方法的对版本进行回滚;

禁用设计。要确保产品使用过程中不会对用户造成伤害和损害;必须采用可靠有效的安全机制保证产品的安全性。应给出控制特定功能可利用与否的组态,当系统发生故障时能迅速将功能下线;

监控设计。设计阶段就应考虑监控手段问题;

多活数据中心设计是关键;在数据中心内部署多个可扩展的服务器集群是一种非常有效的技术方案,但同时也带来了许多挑战和风险。当系统出现故障时,如服务器失效或网络中断等会导致大量数据丢失。如果系统对高可用要求极高,则要考虑多个地方执行数据中心多活,当至少有机房停电时,系统仍可使用;

利用成熟技术。将不同领域和行业的各种应用集成到一起。并提供多种接口供用户选择。已经成为IT界的趋势之一。但是如何实现真正意义上的整合?目前还不是很清楚。刚刚发展起来或者开源技术通常都有许多隐藏bug,出现问题如果得不到商业支持就有可能成为灾难;

资源隔离设计。要避免单一业务对所有资源的侵占;

架构应能水平扩充和升级;从整体上看,目前我国的电子政务系统普遍存在着“信息孤岛”现象:一个部门拥有多个不同类型和功能的信息系统,这些信息系统之间缺乏互联互通,无法实现资源共享、业务协同。该体系只有达到能够水平扩展的程度才能够有效地规避瓶颈;

非核心是买。核心则开发,而不是在核心之外寻求更多的发展空间。企业的战略选择取决于其对市场机会和竞争态势的判断。当市场环境发生变化时,企业应根据变化做出相应调整。非核心功能如需占用大量研发资源来解决时,考虑采购成熟产品;

采用商用硬件。商用硬件可以有效地减少硬件故障发生几率;

快速迭代。随着市场上不断推出新产品和业务需求变化越来越快,对软件企业提出了更高的要求。软件开发过程中需要解决的核心问题就是如何提高软件产品质量、缩短研发周期及降低开发成本。系统应迅速开发出小功能模块并尽早上线验证,及早发现问题极大地降低了系统投运风险;

无状态设计。即在一个系统中,当一个或几个组件处于正常工作时,它所需要的操作都是正常的,而不是由于其他原因造成的。这样可以节省资源并提高工作效率。应将服务接口制作为无状态,且当前界面的存取与界面上的次存取状态无关。

原文链接:http://www.sfdkj.com/22259.html

© 版权声明
THE END
喜欢就支持一下吧
点赞7 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片