淘宝,一个牛逼的高并发分布式架构演进之路!
点击上方的终端研发部,右上角选择“设为星标”
1. 概述
特别说明:本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题,并非是淘宝真正的技术演进路径
2. 基本概念
-
分布式
系统中的多个模块在不同服务器上部署,即可称为分布式系统,如Tomcat和数据库分别部署在不同的服务器上,或两个相同功能的Tomcat分别部署在不同服务器上 -
高可用
系统中部分节点失效时,其他节点能够接替它继续提供服务,则可认为系统具有高可用性 -
集群
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务,这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上,共同组成一个整体提供集中配置服务。在常见的集群中,客户端往往能够连接任意一个节点获得服务,并且当集群中一个节点掉线时,其他节点往往能够自动的接替它继续提供服务,这时候说明集群具有高可用性 -
负载均衡
请求发送到系统时,通过某些方式把请求均匀分发到多个节点上,使系统中每个节点能够均匀的处理请求负载,则可认为系统是负载均衡的 -
正向代理和反向代理
系统内部要访问外部网络时,统一通过一个代理服务器把请求转发出去,在外部网络看来就是代理服务器发起的访问,此时代理服务器实现的是正向代理;当外部请求进入系统时,代理服务器把该请求转发到系统中的某台服务器上,对外部请求来说,与之交互的只有代理服务器,此时代理服务器实现的是反向代理。简单来说,正向代理是代理服务器代替系统内部来访问外部网络的过程,反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
3. 架构演进
3.1 单机架构
随着用户数的增长,Tomcat和数据库之间竞争资源,单机性能不足以支撑业务
3.2 第一次演进:Tomcat与数据库分开部署
随着用户数的增长,并发读写数据库成为瓶颈
3.3 第二次演进:引入本地缓存和分布式缓存
缓存抗住了大部分的访问请求,随着用户数的增长,并发压力主要落在单机的Tomcat上,响应逐渐变慢
3.4 第三次演进:引入反向代理实现负载均衡
反向代理使应用服务器可支持的并发量大大增加,但并发量的增长也意味着更多请求穿透到数据库,单机的数据库最终成为瓶颈
3.5 第四次演进:数据库读写分离
业务逐渐变多,不同业务之间的访问量差距较大,不同业务直接竞争数据库,相互影响性能
3.6 第五次演进:数据库按业务分库
随着用户数的增长,单机的写库会逐渐会达到性能瓶颈
3.7 第六次演进:把大表拆分为小表
数据库和Tomcat都能够水平扩展,可支撑的并发大幅提高,随着用户数的增长,最终单机的Nginx会成为瓶颈
3.8 第七次演进:使用LVS或F5来使多个Nginx负载均衡
由于LVS也是单机的,随着并发数增长到几十万时,LVS服务器最终会达到瓶颈,此时用户数达到千万甚至上亿级别,用户分布在不同的地区,与服务器机房距离不同,导致了访问的延迟会明显不同
3.9 第八次演进:通过DNS轮询实现机房间的负载均衡
随着数据的丰富程度和业务的发展,检索、分析等需求越来越丰富,单单依靠数据库无法解决如此丰富的需求
3.10 第九次演进:引入NoSQL数据库和搜索引擎等技术
引入更多组件解决了丰富的需求,业务维度能够极大扩充,随之而来的是一个应用中包含了太多的业务代码,业务的升级迭代变得困难
3.11 第十次演进:大应用拆分为小应用
不同应用之间存在共用的模块,由应用单独管理会导致相同代码存在多份,导致公共功能升级时全部应用代码都要跟着升级
3.12 第十一次演进:复用的功能抽离成微服务
不同服务的接口访问方式不同,应用代码需要适配多种访问方式才能使用服务,此外,应用访问服务,服务之间也可能相互访问,调用链将会变得非常复杂,逻辑变得混乱
3.13 第十二次演进:引入企业服务总线ESB屏蔽服务接口的访问差异
业务不断发展,应用和服务都会不断变多,应用和服务的部署变得复杂,同一台服务器上部署多个服务还要解决运行环境冲突的问题,此外,对于如大促这类需要动态扩缩容的场景,需要水平扩展服务的性能,就需要在新增的服务上准备运行环境,部署服务等,运维将变得十分困难
3.14 第十三次演进:引入容器化技术实现运行环境隔离与动态服务管理
使用容器化技术后服务动态扩缩容问题得以解决,但是机器还是需要公司自身来管理,在非大促的时候,还是需要闲置着大量的机器资源来应对大促,机器自身成本和运维成本都极高,资源利用率低
3.15 第十四次演进:以云平台承载系统
-
IaaS:基础设施即服务。对应于上面所说的机器资源统一为资源整体,可动态申请硬件资源的层面; -
PaaS:平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护; -
SaaS:软件即服务。对应于上面所说的提供开发好的应用或服务,按功能或性能要求付费。
至此,以上所提到的从高并发访问问题,到服务的架构和系统实施的层面都有了各自的解决方案,但同时也应该意识到,在上面的介绍中,其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题,这些问题以后有机会再拿出来单独讨论
4. 架构设计总结
-
架构的调整是否必须按照上述演变路径进行?
不是的,以上所说的架构演变顺序只是针对某个侧面进行单独的改进,在实际场景中,可能同一时间会有几个问题需要解决,或者可能先达到瓶颈的是另外的方面,这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大,但业务可能很丰富的场景,高并发就不是重点解决的问题,此时优先需要的可能会是丰富需求的解决方案。 -
对于将要实施的系统,架构应该设计到什么程度? 对于单次实施并且性能指标明确的系统,架构设计到能够支持系统的性能指标要求就足够了,但要留有扩展架构的接口以便不备之需。对于不断发展的系统,如电商平台,应设计到能满足下一阶段用户量和性能指标要求的程度,并根据业务的增长不断的迭代升级架构,以支持更高的并发和更丰富的业务。 -
服务端架构和大数据架构有什么区别? 所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称,在每一个场景都包含了多种可选的技术,如数据采集有Flume、Sqoop、Kettle等,数据存储有分布式文件系统HDFS、FastDFS,NoSQL数据库HBase、MongoDB等,数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求,整合各种大数据组件组合而成的架构,一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构,底层能力往往是由大数据架构来提供。 -
有没有一些架构设计的原则? -
N+1设计。系统中的每个组件都应做到没有单点故障; -
回滚设计。确保系统可以向前兼容,在系统升级时应能有办法回滚版本; -
禁用设计。应该提供控制具体功能是否可用的配置,在系统出现故障时能够快速下线功能; -
监控设计。在设计阶段就要考虑监控的手段; -
多活数据中心设计。若系统需要极高的高可用,应考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用; -
采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug,出了问题没有商业支持可能会是一个灾难; -
资源隔离设计。应避免单一业务占用全部资源; -
架构应能水平扩展。系统只有做到能水平扩展,才能有效避免瓶颈问题; -
非核心则购买。非核心功能若需要占用大量的研发资源才能解决,则考虑购买成熟的产品; -
使用商用硬件。商用硬件能有效降低硬件故障的机率; -
快速迭代。系统应该快速开发小功能模块,尽快上线进行验证,早日发现问题大大降低系统交付的风险; -
无状态设计。服务接口应该做成无状态的,当前接口的访问不依赖于接口上次访问的状态。
回复 【idea激活】即可获得idea的激活方式
回复 【Java】获取java相关的视频教程和资料
回复 【SpringCloud】获取SpringCloud相关多的学习资料
回复 【python】获取全套0基础Python知识手册
回复 【2020】获取2020java相关面试题教程
回复 【加群】即可加入终端研发部相关的技术交流群
阅读更多
动画:一招学会TCP的三次握手和四次挥手
相信自己,没有做不到的,只有想不到的
在这里获得的不仅仅是技术!
喜欢就给个“在看”