您的位置:首页 > 游戏

从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路

时间:2019-07-29
葡京真人现场网

  本文以设计淘宝网的后台架构为例,介绍从一百个并发到服务器端架构的14个演进过程在数千万个并发案例的情况下,同时列举了每个演进阶段将遇到的相关技术,以便每个人都能全面了解架构的演变。本文最后总结了一些建筑设计的原则。

(本文同时发表于:

华寿:广东工业大学计算机科学与技术硕士,大数据开发工程师。他在大数据领域有多年的开发经验,对常见的大数据技术有很好的理解,并且在架构设计,高并发性和分布式方面有一定的经验。我喜欢学习新技术,并乐于分享它们。欢迎大家关注此博客。

《新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》

《一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》

《达达O2O后台架构演进实践:从0到4000高并发请求背后的努力》

《小米技术分享:解密小米抢购系统千万高并发架构的演进和实践》

《通俗易懂:如何设计能支撑百万并发的数据库架构?》

在介绍架构之前,为了避免一些读者不理解架构设计中的一些概念,以下是一些最基本的概念。

1)什么是分发?

系统中的多个模块部署在不同的服务器上,可称为分布式系统。例如,Tomcat和数据库部署在不同的服务器上,或者两个具有相同功能的Tomcats部署在不同的服务器上。

2)什么是高可用性?

当系统中的某些节点发生故障时,其他节点可以接管并继续提供服务,则可以认为系统具有高可用性。

3)什么是集群?

特定于域的软件部署在多个服务器上,并提供一类服务作为整体,统称为集群。

例如,Zookeeper中的Master和Slave部署在多个服务器上以形成集中配置服务。

在公共集群中,客户端通常可以连接到任何节点以获取服务,并且当集群中的一个节点脱机时,其他节点可以自动接管并继续提供服务。这表明群集具有高可用性。

4)什么是负载平衡?

当请求发送到系统时,请求以某种方式均匀分布到多个节点,这样系统中的每个节点都可以统一处理请求负载,系统可以视为负载均衡。

5)什么是正向和反向代理?

当内部网络要访问外部网络时,请求将通过代理服务器转发。外部网络似乎是代理发起的访问。此时,代理服务器实现转发代理;

当外部请求进入系统时,代理服务器将请求转发到系统中的服务器。对于外部请求,只有代理服务器与之交互,代理服务器实现反向代理。

简单来说,转发代理是代理服务器替换系统内部以访问外部网络的过程,反向代理是当外部请求访问外部请求时通过代理服务器转发到内部服务器的过程。系统。

以淘宝为例:在网站的开头,应用程序和用户较少,您可以在同一台服务器上部署Tomcat和数据库。当浏览器发起请求时,域名首先通过DNS服务器(域名系统)转换为实际IP地址10.102.4.1,浏览器访问与IP对应的Tomcat。

架构瓶颈:随着用户数量的增长,Tomcat与数据库之间的资源竞争,独立性能不足以支持业务。

Tomcat和数据库分别占用服务器资源,显着提高了各自的性能。

架构瓶颈:随着用户数量的增长,并发读写数据库成为瓶颈。

在Tomcat或JVM上向服务器添加本地缓存,并在外部添加分布式缓存,缓存流行产品信息或热门产品的html页面。通过缓存,可以在读取和写入数据库之前拦截大多数请求,从而大大降低数据库压力。涉及的技术包括将memcached用作本地缓存,将Redis用作分布式缓存。它还涉及缓存一致性,缓存渗透/故障,缓存雪崩和热数据集故障等问题。

架构瓶颈:缓存可抵御大多数访问请求。随着用户数量的增长,并发压力主要落在独立的Tomcat上,响应逐渐减慢。

在多台服务器上部署Tomcat。使用反向代理软件(Nginx)将请求均匀分配给每个Tomcat。这假设Tomcat最多支持100个并发,而Nginx最多支持50,000个并发。从理论上讲,Nginx可以向500只雄猫分发请求,可以抵抗50,000个并发。

涉及的技术包括:Nginx和HAProxy,它们都是在网络的第七层工作的反向代理软件。它们主要支持http协议,还涉及会话共享和文件上传和下载。

架构瓶颈:反向代理大大增加了应用服务器可以支持的并发数量,但并发性的增加也意味着更多的请求渗透到数据库中,并且单机数据库最终成为瓶颈。

数据库分为读库和写库。可能存在多个读取库,并且写入库的数据通过同步机制与读取库同步。对于需要查询最新写入数据的场景,可以在缓存中写入一个副本。缓存获取最新数据。涉及的技术包括:Mycat,它是一个数据库中间件,可用于组织数据库以进行单独的读写和子数据库子表。客户端通过它访问底层数据库,还涉及数据同步和数据一致性。

架构瓶颈:业务逐渐变得越来越多,不同服务之间的差距也越来越大。不同的服务直接与数据库竞争并影响彼此的性能。

将不同服务的数据保存到不同的数据库,从而减少服务之间的资源竞争。对于流量较大的服务,可以部署更多服务器来支持。同时,跨业务表不能直接与分析相关,需要通过其他方式解决,但这不是本文的重点。如果您有兴趣,可以自己搜索解决方案。

架构瓶颈:随着用户数量的增长,单机写库将逐渐达到性能瓶颈。

例如,对于评论数据,可以根据产品ID执行散列,并且将路线存储在相应的表中;对于支付记录,可以根据小时创建表,每小时表继续拆分成小表,并且用户ID或记录号用于路由数据。只要实时操作的表数据量足够小,可以在多个服务器上的小表之间均匀分布请求,就可以扩展数据库以提高性能。当大表拆分成小表时,前面提到的Mycat也支持访问控制。

这种方法显着增加了数据库操作和维护的难度,并且对DBA有更高的要求。当数据库设计为此结构时,它可以称为分布式数据库,但这只是一个逻辑数据库。数据库的不同组件由不同的组件实现,例如子数据库的管理和请求。分发,由Mycat实现,SQL解析由单机数据库实现,读写分离可以由网关和消息队列实现,查询结果的摘要可以由数据库接口层等实现。这种架构是实际上MPP(大规模并行处理)一种架构的实现。

目前,开源和商业中有许多MPP数据库。开源领域的热门产品包括Greenplum,TiDB,PostgresqlXC,HAWQ等。商用,如Nanda General的GBase,瑞帆科技的Snowball DB,华为的LibrA等.MPP数据库的重点也不同。例如,TiDB更多地关注分布式OLTP场景。 Greenplum专注于分布式OLAP场景。这些MPP数据库基本上提供了Postgresql,Oracle和MySQL等SQL标准支持功能。将查询解析为分布式执行计划被分发到每台机器以进行并行执行。最后,数据库本身汇总了返回的数据。它还提供权限管理,子数据库分区,事务,数据副本等功能,其中大多数可以支持超过100个节点的集群,大大降低了数据库操作和维护的成本,并使数据库能够扩展水平。

架构瓶颈:数据库和Tomcat都可以横向扩展,可支持的并发性大大提高。随着用户数量的增长,最终的独立Nginx将成为瓶颈。

由于瓶颈在Nginx中,因此不可能通过两层Nginx实现多个Nginx的负载平衡。图中的LVS和F5是在网络的第四层上工作的负载平衡解决方案。 LVS是在操作系统内核状态下运行的软件,它可以转发TCP请求或更高级别的网络协议,因此支持的协议更丰富,性能远高于Nginx,可以假设单个LVS可以支持成千上万的并发请求转发; F5是一种负载均衡硬件,类似于LVS提供的功能,性能高于LVS,但价格昂贵。由于LVS是软件的独立版本,如果LVS所在的服务器关闭,整个后端系统将无法访问,因此需要备用节点。您可以使用keepalived软件模拟虚拟IP,然后将虚拟IP绑定到多个LVS服务器。当浏览器访问虚拟IP时,它将被路由器重定向到真正的LVS服务器。当主LVS服务器关闭时,keepalived软件将自动更新路由器中的路由表,并将虚拟IP重定向到另一个正常的LVS服务器,从而实现LVS服务器的高可用性。

这里应该注意的是,上图中从Nginx层到Tomcat层的绘制并不意味着所有Nginx都会将请求转发给所有Tomcat。在实际使用中,它可能是Nginx下的一些Tomcats。这些Nginx高可用性是通过keepalived实现的,而其他Nginx连接到另一个Tomcat,因此可以访问的Tomcats数量可以成倍增加。

架构瓶颈:由于LVS也是独立的,随着并发连接数量增长到数十万,LVS服务器最终将达到瓶颈。此时,用户数量达到数千万甚至数亿。用户分布在与服务器机房不同的区域和距离。访问的差异明显不同。

可以在DNS服务器中配置域名以对应多个IP地址,并且每个IP地址对应于不同机房中的虚拟IP地址。当用户访问时,DNS服务器使用轮询策略或其他策略来选择用于用户访问的IP。这样,可以实现机房的负载平衡。此时,系统可以实现机房水平的水平扩展,并且可以通过增加机房来解决1000万到1亿的并发数量。系统入口处的请求并发不再是问题。

架构瓶颈:随着数据的丰富和业务的发展,检索和分析的要求越来越丰富,单靠数据库无法解决如此丰富的需求。

当数据库中的数据超过一定大小时,数据库不适合复杂查询,并且通常只满足普通查询的情况。对于统计报告方案,当数据量很大时,结果可能无法用完,而在运行复杂查询时,其他查询可能会变慢。对于全文搜索,可变数据结构等,数据库不适合自然使用。因此,有必要为特定场景引入合适的解决方案。对于海量文件存储,可以通过分布式文件系统HDFS解决。对于keyvalue类型数据,可以通过HBase和Redis解决。对于全文搜索场景,可以通过搜索引擎(如ElasticSearch)来解决。对于多维分析场景,解决方案如Kylin或Druid。

当然,引入更多组件会增加系统的复杂性,不同组件存储的数据需要同步,需要考虑一致性问题,并且需要更多的操作和维护手段来管理这些组件。

架构瓶颈:引入更多组件来解决丰富的需求,业务维度可以大大扩展,然后应用程序包含太多的业务代码,并且业务的升级迭代变得困难。

根据业务部门划分应用程序代码,使各个应用程序的职责更加清晰,独立的升级迭代。此时,应用程序之间可能涉及一些常见配置,这可以由分布式配置中心Zookeeper解决。

架构瓶颈:不同应用程序之间存在共享模块。如果单独管理应用程序,则会生成相同代码的多个副本,以便在升级公共功能时升级所有应用程序代码。

如果在多个应用程序中存在诸如用户管理,订单,支付和认证之类的功能,则可以单独提取这些功能的代码以形成要管理的单独服务。这些服务是所谓的微服务,应用程序和服务。公共服务以多种方式访问,包括HTTP,TCP或RPC请求,每个单独的服务可由单独的团队管理。此外,Dubbo和SpringCloud等服务可用于实现服务管理,限流,融合和降级,以提高服务稳定性和可用性。

架构瓶颈:不同的服务有不同的接口访问方法。应用程序代码需要适应多种访问方法才能使用服务。此外,应用程序访问服务也可以相互访问。调用链将变得非常复杂,逻辑变得混乱。

通过ESB统一接入协议转换,应用程序通过ESB统一访问后端服务,服务和服务也通过ESB相互调用,从而降低了系统的耦合度。

这个单一的应用程序分为多个应用程序,公共服务分别提取管理,企业消息总线用于解耦服务之间的体系结构。这就是所谓的SOA(面向服务)架构,这种架构和微服务。该架构令人困惑,因为演示文稿非常相似。

个人理解,微服务架构更多地是指从系统中提取公共服务以分离操作和维护管理的想法,而SOA架构是指分割服务并使服务接口访问统一的体系结构思想。 SOA架构它包含微服务的概念。

架构瓶颈:企业不断发展,应用程序和服务不断变化,应用程序和服务变得越来越复杂,多个服务部署在同一台服务器上以解决操作环境冲突。此外,针对此类需求动态扩展和缩小的方案。如果需要横向扩展服务性能,则需要在新添加的服务上准备运行环境,部署服务等,操作和维护将变得非常困难。

最流行的容器化技术是Docker。最受欢迎的集装箱管理服务是Kubernetes(K8S)。应用程序/服务可以打包为Docker映像,K8S可以用于动态分发和部署映像。 Docker镜像可以理解为一个最小的操作系统,可以运行您的应用程序/服务,运行应用程序/服务的代码,并根据实际需要设置运行时环境。在将整个“操作系统”打包到镜像中之后,可以将其分发到需要部署相关服务的机器。直接启动Docker映像可以启动服务并简化服务部署和操作维护。

在大促销之前,您可以在现有机器群集上对服务器进行分区以启动Docker镜像,提高服务性能,然后在升级后关闭镜像,而不会影响计算机上的其他服务(在第18节之前) )新添加的机器上运行的服务需要修改系统配置以适应服务,这将导致机器上其他服务的运行环境被破坏。

架构瓶颈:使用集装箱化技术后,可以解决动态扩展和服务扩展的问题,但机器仍然需要由公司自己管理。当它不大时,仍然需要闲置大量机器资源来应对大幅增加,机器本身的成本和运维成本极高,资源利用率低。

该系统可以部署在公有云上,利用公有云的海量云资源来解决动态硬件资源的问题。在大促销期间,暂时在云平台上申请更多资源,并与Docker和K8S一起快速部署服务。大促销结束后,资源被释放,实际支付按需提供,资源利用率大大提高,运维成本大大降低。

所谓的云平台是通过统一的资源管理将大量的机器资源抽象为整个资源。最重要的是,您可以根据需要动态应用硬件资源(如CPU,内存,网络等),并在其上提供常用操作。该系统提供通用技术组件(如Hadoop技术堆栈,MPP数据库等)供用户使用,甚至提供开发的应用程序。用户无需在应用程序内部使用任何技术即可解决要求(如音频和视频转码服务)。邮件服务,个人博客等)。

云平台涉及以下概念:

1)IaaS:基础设施即服务。对应上述机器资源统一为资源整体,可动态申请硬件资源水平;

2)PaaS:平台即服务。对应上述提供的通用技术组件,便于系统的开发和维护;

3)SaaS:软件即服务。对应于上述提供的开发应用程序或服务,支付功能或性能要求。

此时:从高并发访问问题到服务架构和系统实现的上述解决方案都有自己的解决方案。然而,同时应该认识到,在上面的介绍中,它实际上是故意忽略了诸如计算机房间的数据同步,分布式事务实现等实际问题,并且这些问题必须在下面单独讨论。未来。

1)架构的调整是否必须遵循上述的演进路径?

不,上述架构的演变顺序只是某个方面的单一改进。在实际场景中,可能有几个问题需要同时解决,或者可能首先达到另一个方面。它应该根据实际问题切实解决。例如,在基于政府的并发可能很小的情况下,但业务可能非常丰富,高并发性不是关键问题,而优先需求可能是一种丰富需求的解决方案。

2)架构应该在多大程度上为系统实施?

对于单个实现和定义良好的系统,设计架构以满足系统的性能要求就足够了,但是在不需要的情况下保留扩展架构的接口。对于不断发展的系统(如电子商务平台),它们应设计为满足下一阶段用户量和性能指标的要求,并根据业务增长继续迭代升级架构,以支持更高的并发性和更丰富服务。

3)服务器端架构和大数据架构有什么区别?

所谓的“大数据”是场景解决方案的通用术语,例如海量数据收集和清理转换,数据存储,数据分析和数据服务。每个场景都包含各种可选技术,例如Flume用于数据收集。 Sqoop,Kettle等,数据存储分布式文件系统HDFS,FastDFS,NoSQL数据库HBase,MongoDB等,数据分析具有Spark技术堆栈,机器学习算法。通常,大数据架构是基于业务需求的各种大数据组件的组合。它通常提供分布式存储,分布式计算,多维分析,数据仓库,机器学习算法和其他功能。服务器体系结构更多地涉及组织级体系结构,而底层功能通常由大数据体系结构提供。

4)建筑设计有什么原则吗?

a.N + 1设计:系统中的每个组件都应该没有单点故障;

湾回滚设计:为了确保系统可以向前兼容,应该有一种方法在系统升级时回滚版本;

C。禁用设计:应提供控制特定功能是否可用的配置,并在系统出现故障时快速脱机;

d。监测设计:在设计阶段应考虑监测手段;

即多实时数据中心设计:如果系统需要极高的可用性,请考虑为多个活动实施多个数据中心,至少在一个机房电源故障的情况下;

F。采用成熟技术:新开发或开源技术往往存在许多隐患。如果出现问题,没有商业支持可能是灾难;

G。资源隔离设计:应避免单个业务占用所有资源;

H。架构应该能够水平扩展:如果系统可以水平扩展,系统只能有效地避免瓶颈;

一世。非核心购买:如果非核心功能需要占用大量的研发资源来解决,可以考虑购买成熟的产品;

学家使用商用硬件:商用硬件可以有效降低硬件故障的概率;

。快速迭代:系统应该快速开发小功能模块并尽快上线进行验证。及早发现问题可以大大降低系统交付的风险;

湖无状态设计:服务接口应该是无状态的。当前接口的访问权限不依赖于上次访问接口的状态。

[1]更多相关的架构设计相关文章:

《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践》

《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》

《新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路》

《达达O2O后台架构演进实践:从0到4000高并发请求背后的努力》

《优秀后端架构师必会知识:史上最全MySQL大表优化方案总结》

《小米技术分享:解密小米抢购系统千万高并发架构的演进和实践》

《一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等》

《通俗易懂:如何设计能支撑百万并发的数据库架构?》

《多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了》

《从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路》

>>更多类似的文章.

[2]关于IM架构设计的文章:

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑:架构设计、通信协议和客户端》

《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》

《一套原创分布式即时通讯(IM)系统理论架构方案》

《从零到卓越:京东客服即时通讯系统的技术架构演进历程》

《蘑菇街即时通讯/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信技术总监谈架构:微信之道——大道至简(演讲全文)》

《如何解读《微信技术总监谈架构:微信之道——大道至简》“

《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》

《17年的实践:腾讯海量产品的技术方法论》

《移动端IM中大规模群消息的推送如何保证效率、实时性?》

《现代IM系统中聊天消息的同步和存储方案探讨》

《IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?》

《IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议》

《IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token》

《WhatsApp技术实践分享:32人工程团队创造的技术神话》

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等》

《IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?》

《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》

《以微博类应用场景为例,总结海量社交系统的架构设计步骤》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践》

《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》

《IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列》

《微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)》

《微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)》

《新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》

《阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路》

《社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等》

《社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进》

《社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节》

《社交软件红包技术解密(四):微信红包系统是如何应对高并发的》

《社交软件红包技术解密(五):微信红包系统是如何实现高可用性的》

《社交软件红包技术解密(六):微信红包系统的存储层架构演进实践》

《社交软件红包技术解密(七):支付宝红包的海量高并发技术实践》

《社交软件红包技术解密(八):全面解密微博红包技术方案》

《社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等》

《即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?》

《即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途》

>>更多类似的文章.

(本文同时发表于:

日期归档
  • 友情链接:
  • 葡京真人app 版权所有© www.julianoelgoldman.com 技术支持:葡京真人app| 网站地图