服务端高并发分布式架构演进之路
架构设计架构分布式高并发服务端
公布于 2019-03-23
- 概述
本文以淘宝作为例子，介绍从一百个到千万级并发状况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相干技术，让大家对架构的演进有一个整体的认知，文章最初汇总了一些架构设计的准则。
特地阐明：本文以淘宝为例仅仅是为了便于阐明演进过程可能遇到的问题，并非是淘宝真正的技术演进门路
- 基本概念
在介绍架构之前，为了防止局部读者对架构设计中的一些概念不理解，上面对几个最根底的概念进行介绍：
- 分布式
零碎中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库别离部署在不同的服务器上，或两个雷同性能的Tomcat别离部署在不同服务器上 - 高可用
零碎中局部节点生效时，其余节点可能接替它持续提供服务，则可认为零碎具备高可用性 - 集群
一个特定畛域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave别离部署在多台服务器上，独特组成一个整体提供集中配置服务。在常见的集群中，客户端往往可能连贯任意一个节点取得服务，并且当集群中一个节点掉线时，其余节点往往可能主动的接替它持续提供服务，这时候阐明集群具备高可用性 - 负载平衡
申请发送到零碎时，通过某些形式把申请平均散发到多个节点上，使零碎中每个节点可能平均的解决申请负载，则可认为零碎是负载平衡的 - 正向代理和反向代理
零碎外部要拜访内部网络时，对立通过一个代理服务器把申请转发进来，在内部网络看来就是代理服务器发动的拜访，此时代理服务器实现的是正向代理；当内部申请进入零碎时，代理服务器把该申请转发到零碎中的某台服务器上，对外部申请来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简略来说，正向代理是代理服务器代替零碎外部来拜访内部网络的过程，反向代理是内部申请拜访零碎时通过代理服务器转发到外部服务器的过程。
- 架构演进
3.1 单机架构
以淘宝作为例子。在网站最后时，利用数量与用户数都较少，能够把Tomcat和数据库部署在同一台服务器上。浏览器往www.taobao.com发动申请时，首先通过DNS服务器（域名零碎）把域名转换为理论IP地址10.102.4.1，浏览器转而拜访该IP对应的Tomcat。
随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以撑持业务
3.2 第一次演进：Tomcat与数据库离开部署
Tomcat和数据库别离独占服务器资源，显著进步两者各自性能。
随着用户数的增长，并发读写数据库成为瓶颈
3.3 第二次演进：引入本地缓存和分布式缓存
在Tomcat同服务器上或同JVM中减少本地缓存，并在内部减少分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数申请在读写数据库前拦挡掉，大大降低数据库压力。其中波及的技术包含：应用memcached作为本地缓存，应用Redis作为分布式缓存，还会波及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中生效等问题。
缓存抗住了大部分的拜访申请，随着用户数的增长，并发压力次要落在单机的Tomcat上，响应逐步变慢
3.4 第三次演进：引入反向代理实现负载平衡
在多台服务器上别离部署Tomcat，应用反向代理软件（Nginx）把申请平均散发到每个Tomcat中。此处假如Tomcat最多反对100个并发，Nginx最多反对50000个并发，那么实践上Nginx把申请散发到500个Tomcat上，就能抗住50000个并发。其中波及的技术包含：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，次要反对http协定，还会波及session共享、文件上传下载的问题。
反向代理使应用服务器可反对的并发量大大增加，但并发量的增长也意味着更多申请穿透到数据库，单机的数据库最终成为瓶颈
3.5 第四次演进：数据库读写拆散
把数据库划分为读库和写库，读库能够有多个，通过同步机制把写库的数据同步到读库，对于须要查问最新写入数据场景，可通过在缓存中多写一份，通过缓存取得最新数据。其中波及的技术包含：Mycat，它是数据库中间件，可通过它来组织数据库的拆散读写和分库分表，客户端通过它来拜访上层数据库，还会波及数据同步，数据一致性的问题。
业务逐步变多，不同业务之间的访问量差距较大，不同业务间接竞争数据库，相互影响性能
3.6 第五次演进：数据库按业务分库
把不同业务的数据保留到不同的数据库中，使业务之间的资源竞争升高，对于访问量大的业务，能够部署更多的服务器来撑持。这样同时导致跨业务的表无奈间接做关联剖析，须要通过其余路径来解决，但这不是本文探讨的重点，有趣味的能够自行搜寻解决方案。
随着用户数的增长，单机的写库会逐步会达到性能瓶颈
3.7 第六次演进：把大表拆分为小表
比方针对评论数据，可依照商品ID进行hash，路由到对应的表中存储；针对领取记录，可依照小时创立表，每个小时表持续拆分为小表，应用用户ID或记录编号来路由数据。只有实时操作的表数据量足够小，申请可能足够平均的散发到多台服务器上的小表，那数据库就能通过程度扩大的形式来进步性能。其中后面提到的Mycat也反对在大表拆分为小表状况下的访问控制。
这种做法显著的减少了数据库运维的难度，对DBA的要求较高。数据库设计到这种构造时，曾经能够称为分布式数据库，然而这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件独自来实现的，如分库分表的治理和申请散发，由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负载平衡
因为瓶颈在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上面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其余的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的减少。
因为LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户散布在不同的地区，与服务器机房间隔不同，导致了拜访的提早会显著不同
3.9 第八次演进：通过DNS轮询实现机房间的负载平衡
在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚构IP。当用户拜访www.taobao.com时，DNS服务器会应用轮询策略或其余策略，来抉择某个IP供用户拜访。此形式能实现机房间的负载平衡，至此，零碎可做到机房级别的程度扩大，千万级到亿级的并发量都可通过减少机房来解决，零碎入口处的申请并发量不再是问题。
随着数据的丰盛水平和业务的倒退，检索、剖析等需要越来越丰盛，单单依附数据库无奈解决如此丰盛的需要
3.10 第九次演进：引入NoSQL数据库和搜索引擎等技术
当数据库中的数据多到肯定规模时，数据库就不适用于简单的查问了，往往只能满足一般查问的场景。对于统计报表场景，在数据量大时不肯定能跑出后果，而且在跑简单查问时会导致其余查问变慢，对于全文检索、可变数据结构等场景，数据库天生不实用。因而须要针对特定的场景，引入适合的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等计划解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等计划解决。
当然，引入更多组件同时会进步零碎的复杂度，不同的组件保留的数据须要同步，须要思考一致性的问题，须要有更多的运维伎俩来治理这些组件等。
引入更多组件解决了丰盛的需要，业务维度可能极大裁减，随之而来的是一个利用中蕴含了太多的业务代码，业务的降级迭代变得艰难
3.11 第十次演进：大利用拆分为小利用
依照业务板块来划分利用代码，使单个利用的职责更清晰，相互之间能够做到独立降级迭代。这时候利用之间可能会波及到一些公共配置，能够通过分布式配置核心Zookeeper来解决。
不同利用之间存在共用的模块，由利用独自治理会导致雷同代码存在多份，导致公共性能降级时全副利用代码都要跟着降级
3.12 第十一次演进：复用的性能抽离成微服务
如用户治理、订单、领取、鉴权等性能在多个利用中都存在，那么能够把这些性能的代码独自抽取进去造成一个独自的服务来治理，这样的服务就是所谓的微服务，利用和服务之间通过HTTP、TCP或RPC申请等多种形式来拜访公共服务，每个独自的服务都能够由独自的团队来治理。此外，能够通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等性能，进步服务的稳定性和可用性。
不同服务的接口拜访形式不同，利用代码须要适配多种拜访形式能力应用服务，此外，利用拜访服务，服务之间也可能互相拜访，调用链将会变得非常复杂，逻辑变得凌乱
3.13 第十二次演进：引入企业服务总线ESB屏蔽服务接口的拜访差别
通过ESB对立进行拜访协定转换，利用对立通过ESB来拜访后端服务，服务与服务之间也通过ESB来互相调用，以此升高零碎的耦合水平。这种单个利用拆分为多个利用，公共服务独自抽取进去来治理，并应用企业音讯总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混同，因为表现形式十分相似。集体了解，微服务架构更多是指把零碎里的公共服务抽取进去独自运维治理的思维，而SOA架构则是指一种拆分服务并使服务接口拜访变得对立的架构思维，SOA架构中蕴含了微服务的思维。
业务一直倒退，利用和服务都会一直变多，利用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境抵触的问题，此外，对于如大促这类须要动静扩缩容的场景，须要程度扩大服务的性能，就须要在新增的服务上筹备运行环境，部署服务等，运维将变得十分困难
3.14 第十三次演进：引入容器化技术实现运行环境隔离与动静服务治理
目前最风行的容器化技术是Docker，最风行的容器治理服务是Kubernetes(K8S)，利用/服务能够打包为Docker镜像，通过K8S来动静散发和部署镜像。Docker镜像可了解为一个能运行你的利用/服务的最小的操作系统，外面放着利用/服务的运行代码，运行环境依据理论的须要设置好。把整个“操作系统”打包为一个镜像后，就能够散发到须要部署相干服务的机器上，间接启动Docker镜像就能够把服务起起来，使服务的部署和运维变得简略。
在大促的之前，能够在现有的机器集群上划分出服务器来启动Docker镜像，加强服务的性能，大促过后就能够敞开镜像，对机器上的其余服务不造成影响（在3.14节之前，服务运行在新增机器上须要批改系统配置来适配服务，这会导致机器上其余服务须要的运行环境被毁坏）。
应用容器化技术后服务动静扩缩容问题得以解决，然而机器还是须要公司本身来治理，在非大促的时候，还是须要闲置着大量的机器资源来应答大促，机器本身老本和运维老本都极高，资源利用率低
3.15 第十四次演进：以云平台承载零碎
零碎可部署到私有云上，利用私有云的海量机器资源，解决动静硬件资源的问题，在大促的时间段里，在云平台中长期申请更多的资源，联合Docker和K8S来疾速部署服务，在大促完结后开释资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维老本。
所谓的云平台，就是把海量机器资源，通过对立的资源管理，形象为一个资源整体，在之上可按需动静申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供罕用的技术组件（如Hadoop技术栈，MPP数据库等）供用户应用，甚至提供开发好的利用，用户不须要关系利用外部应用了什么技术，就可能解决需要（如音视频转码服务、邮件服务、集体博客等）。在云平台中会波及如下几个概念：
- IaaS：基础设施即服务。对应于下面所说的机器资源对立为资源整体，可动静申请硬件资源的层面；
- PaaS：平台即服务。对应于下面所说的提供罕用的技术组件不便零碎的开发和保护；
- SaaS：软件即服务。对应于下面所说的提供开发好的利用或服务，按性能或性能要求付费。
至此，以上所提到的从高并发拜访问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在下面的介绍中，其实是无意疏忽了诸如跨机房数据同步、分布式事务实现等等的理论问题，这些问题当前有机会再拿进去独自探讨
- 架构设计总结
- 架构的调整是否必须依照上述演变门路进行？
不是的，以上所说的架构演变程序只是针对某个侧面进行独自的改良，在理论场景中，可能同一时间会有几个问题须要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该依照理论问题理论解决。如在政府类的并发量可能不大，但业务可能很丰盛的场景，高并发就不是重点解决的问题，此时优先须要的可能会是丰盛需要的解决方案。 - 对于将要施行的零碎，架构应该设计到什么水平？
对于单次施行并且性能指标明确的零碎，架构设计到可能支持系统的性能指标要求就足够了，但要留有扩大架构的接口以便不备之需。对于一直倒退的零碎，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的水平，并依据业务的增长一直的迭代降级架构，以反对更高的并发和更丰盛的业务。 - 服务端架构和大数据架构有什么区别？
所谓的“大数据”其实是海量数据采集荡涤转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都蕴含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是依据业务的需要，整合各种大数据组件组合而成的架构，个别会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是利用组织层面的架构，底层能力往往是由大数据架构来提供。 有没有一些架构设计的准则？
- N+1设计。零碎中的每个组件都应做到没有单点故障；
- 回滚设计。确保零碎能够向前兼容，在系统升级时应能有方法回滚版本；
- 禁用设计。应该提供管制具体性能是否可用的配置，在零碎呈现故障时可能疾速下线性能；
- 监控设计。在设计阶段就要思考监控的伎俩；
- 多活数据中心设计。若零碎须要极高的高可用，应思考在多地施行数据中心进行多活，至多在一个机房断电的状况下零碎仍然可用；
- 采纳成熟的技术。刚开发的或开源的技术往往存在很多暗藏的bug，出了问题没有商业反对可能会是一个劫难；
- 资源隔离设计。应防止繁多业务占用全副资源；
- 架构应能程度扩大。零碎只有做到能程度扩大，能力无效防止瓶颈问题；
- 非核心则购买。非核心性能若须要占用大量的研发资源能力解决，则思考购买成熟的产品；
- 应用商用硬件。商用硬件能无效升高硬件故障的机率；
- 疾速迭代。零碎应该疾速开发小功能模块，尽快上线进行验证，早日发现问题大大降低零碎交付的危险；
- 无状态设计。服务接口应该做成无状态的，以后接口的拜访不依赖于接口上次访问的状态。