本文以淘宝后台架构设计为例，介绍从100并发到最大并发的情况。服务器端架构的14个演进过程，同时列出了每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认识。文章***总结了架构设计的一些原则。1.作者简介华秀欧：毕业于广东工业大学，计算机科学与技术专业硕士，大数据开发工程师。在大数据领域有多年的开发经验，对常用的大数据技术有一定的了解，在架构设计、高并发、分布式等方面有一定的经验。我喜欢学习新技术并分享它们。欢迎大家关注本博客。2.基本概念在介绍架构之前，为了防止部分读者对架构设计中的一些概念一无所知，下面先介绍一些最基本的概念。1）什么是分布式的？系统中的多个模块部署在不同的服务器上，可以称为分布式系统。比如Tomcat和数据库部署在不同的服务器上，或者两个功能相同的Tomcat部署在不同的服务器上。2）什么是高可用性？当系统中的某些节点发生故障时，其他节点可以接管并继续提供服务，则可以认为系统具有高可用性。3）什么是集群？一个特定领域的软件部署在多台服务器上，作为一个整体提供一类服务，称为集群。例如Zookeeper中的Master和Slave分别部署在多台服务器上，形成一个整体，提供集中的配置服务。在一个普通的集群中，客户端往往可以连接到任意一个节点获取服务，当集群中的一个节点掉线时，其他节点往往可以自动接管并继续提供服务，这说明集群具有高可用性。4）什么是负载均衡？当向系统发送请求时，如果通过某种方式将请求均匀分布到多个节点，使得系统中的每个节点都能平均处理请求负载，则可以认为系统是负载均衡的。5)什么是正向代理和反向代理？当系统要访问外网时，通过代理服务器转发请求。从外网的角度来看，就是代理服务器发起的访问。此时代理服务器实现正向代理；当外部请求进入系统后，代理服务器将请求转发给系统中的某个服务器。对于外部请求，只有代理服务器与之交互。这时候代理服务器就实现了反向代理。简单来说，正向代理就是代理服务器代替内部系统访问外部网络的过程，反向代理就是外部访问系统的请求通过代理服务器转发到内部服务器的过程。3.纯真年代：单机架构以淘宝为例：网站初期，应用和用户都很少，所以可以将Tomcat和数据库部署在同一台服务器上。当浏览器向www.taobao.com发起请求时，首先通过DNS服务器（DomainNameSystem）将域名转换为实际IP地址10.102.4.1，然后浏览器访问该IP对应的Tomcat。架构瓶颈：随着用户数量的增加，Tomcat与数据库争夺资源，单机性能不足以支撑业务。4.第一次进化：Tomcat和数据库分开部署Tomcat和数据库分别独占服务器资源，显着提高了两者的性能。架构瓶颈：随着用户数量的增长，对数据库的并发读写成为瓶颈。5、第二次进化：引入本地缓存和分布式缓存。在同一个Tomcat服务器或同一个JVM中添加本地缓存，在外部添加分布式缓存，缓存热门商品信息或热门商品的html页面。通过缓存，可以在读写数据库之前拦截大部分请求，大大减轻数据库的压力。涉及的技术包括：使用memcached作为本地缓存，使用Redis作为分布式缓存，还涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集失效等问题。架构瓶颈：缓存抵挡了大部分的访问请求。随着用户数量的增加，并发压力主要落在单机Tomcat上，响应逐渐变慢。6、第三次进化：引入反向代理实现负载均衡，将Tomcat分别部署在多台服务器上，使用反向代理软件（Nginx）将请求平均分配给各个Tomcat。这里假设Tomcat最大支持100并发，Nginx最大支持5万并发。理论上，Nginx可以通过将请求分发到500个Tomcat来抵抗50,000并发。涉及到的技术包括：Nginx和HAProxy，都是工作在第七层网络的反向代理软件。它们主要支持http协议，也涉及session共享、文件上传下载等。架构瓶颈：反向代理大大增加了应用服务器支持的并发量，但并发量的增加也意味着更多的请求渗透到数据库中，单机数据库最终成为瓶颈。7.第四次进化：数据库读写分离将数据库分为读写数据库。可以有多个阅读数据库。写数据库中的数据通过同步机制同步到读数据库中。对于那些需要查询和写入数据的场景，通过在缓存中多写一份，可以通过缓存获取到最新的数据。涉及的技术包括：Mycat，它是一个数据库中间件，通过它可以组织数据库和分库分表的单独读写。客户端可以通过它来访问底层数据库，同时也会涉及到数据同步和数据一致性的问题。.架构瓶颈：业务数量逐渐增加，不同业务的访问量差异较大。不同的业务直接与数据库竞争，影响彼此的性能。8、第五次进化：数据库根据业务划分为不同的数据库，不同业务的数据存储在不同的数据库中，减少业务间的资源竞争。对于访问量大的业务，可以部署更多的服务器来支撑。这也导致无法直接对跨业务的表进行关联分析，需要通过其他方式解决，但这不是本文的重点。有兴趣的可以自行搜索解决方案。架构瓶颈：随着用户量的增长，单机写库会逐渐达到性能瓶颈。9.第六次进化：将大表拆分成小表。比如对于评论数据，可以根据产品ID进行哈希处理，路由到对应的表中存储；对于支付记录，可以按小时建表，每个小时的表继续拆分成小表，使用用户ID或记录号来路由数据。只要实时操作的表数据量足够小，请求可以均匀分布到多台服务器上的小表上，数据库就可以通过水平扩展来提高性能。前面提到的Mycat也支持大表拆分成小表时的访问控制。这种方式大大增加了数据库运维的难度，对DBA的要求也更高。当数据库设计成这种结构时，已经可以称为分布式数据库，但这只是一个整体上的逻辑数据库。数据库中不同的组件由不同的组件实现，比如分库分表的管理和请求。分发由Mycat实现，SQL解析由单机数据库实现，读写分离可能由网关和消息队列实现，查询结果汇总可能由数据库接口层实现等。架构实际上是一个MPP（large-scaleAclassofimplementationsoftheParallelProcessing）架构。目前，无论是开源还是商业用途的MPP数据库都有很多。开源比较流行的有Greenplum、TiDB、PostgresqlXC、HAWQ等，商用的有NTUGeneral的GBase、瑞帆科技的SnowballDB、华为的LibrA等，不同的MPP数据库各有侧重。比如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景。这些MPP数据库基本上都提供了类似于Postgresql、Oracle、MySQL的SQL标准支持能力。它可以将查询解析成分布式执行计划，分发到每台机器上并行执行。最后由数据库自己汇总数据并返回。还提供权限管理、分库分表、事务、数据拷贝等能力。可支持100个以上节点的集群，大大降低数据库运维成本，使数据库实现水平扩展。架构瓶颈：数据库和Tomcat都可以横向扩展，支持的并发量大大增加。随着用户数量的增加，单机版的Nginx最终会成为瓶颈。10.第七次进化：使用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的一部分。通过keepalived实现高可用，另外一个Nginx连接另一个Tomcat，这样可以访问的Tomcat数量翻倍。架构瓶颈：由于LVS也是单机的，随着并发数增加到几十万，LVS服务器最终会达到瓶颈。此时的用户量达到几千万甚至上亿。用户分布在不同的地区，距离机房的距离不同，造成的访问延迟也会有明显差异。11、第八次进化：通过DNS轮询实现机房负载均衡。在DNS服务器中，可以配置一个域名对应多个IP地址，每个IP地址对应不同机房的一个虚拟IP。当用户访问www.taobao.com时，DNS服务器会采用循环策略或其他策略来选择一个IP供用户访问。这种方法可以实现机房的负载均衡。至此，系统可以实现机房级别的水平扩展。1亿到1亿的并发可以通过增加机房来解决。系统入口的并发请求不再是问题。.架构瓶颈：随着数据的丰富和业务的发展，对检索和分析的需求越来越丰富。仅靠数据库无法解决如此丰富的需求。12.第九次进化：引入NoSQL数据库和搜索引擎等技术。当数据库的数据量达到一定规模时，数据库就不适合做复杂的查询，往往只满足普通的查询场景。对于统计报表场景，数据量大时可能无法运行结果，其他查询运行复杂查询时会变慢。对于全文检索、可变数据结构等场景，数据库本来就不适合。因此，有必要针对特定??场景引入合适的解决方案。比如对于海量文件存储，可以通过分布式文件系统HDFS来解决；对于key-value类型的数据，可以通过HBase、Redis等方案解决；对于全文检索场景，可以通过ElasticSearch等搜索引擎解决；对于多维分析场景，可以通过Kylin或者Druid等解决方案解决。当然，引入更多的组件也会增加系统的复杂度。不同组件保存的数据需要同步，需要考虑一致性问题，需要更多的运维方式来管理这些组件。架构瓶颈：更多组件的引入解决了丰富的需求，业务维度可以得到极大的扩展。那么，一个应用包含过多的业务代码，导致业务难以升级迭代。13、第十次进化：大应用拆分成小应用，按照业务部门划分应用代码，让单体应用的职责更加清晰，相互独立升级迭代。这时候应用之间可能会涉及到一些通用的配置，可以通过分布式配置中心Zookeeper来解决。架构瓶颈：不同应用之间存在共享模块，由应用单独管理会导致同一代码多副本，导致公共功能升级时所有应用代码都升级。14.第十一次进化：多路复用的功能分离成微服务。比如用户管理、下单、支付、认证等功能存在于多个应用中，那么可以将这些功能的代码单独抽取出来，形成一个单一的服务，这样的服务就是所谓的微服务。应用程序和服务通过HTTP、TCP或RPC请求等多种方法访问公共服务。每个单独的服务都可以由单独的团队管理。此外，还可以利用Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。架构瓶颈：不同的服务有不同的接口访问方式，应用代码需要适配多种访问方式才能使用服务。另外，当应用程序访问服务时，服务之间也可能相互访问，调用链会变得非常复杂，逻辑也会变得混乱。15、第十二次演进：引入企业服务总线（ESB），通过ESB统一访问协议转换，屏蔽服务接口的访问差异，应用通过ESB统一访问后端服务，以及服务之间通过ESB相互调用，从而降低系统的耦合度。将这个单体应用拆分成多个应用，将公共服务抽取出来单独管理，使用企业消息总线解耦服务之间的耦合。这就是所谓的SOA（面向服务）架构，类似于微服务。体系结构令人困惑，因为表示非常相似。个人理解，微服务架构更多指的是将系统中的公共服务抽取出来进行单独运维管理的思想，而SOA架构则是指将服务拆分，统一服务接口访问的架构思想。SOA架构包含了微服务的思想。架构瓶颈：随着业务的不断发展，应用和服务会越来越多，应用和服务的部署也会变得复杂。在同一台服务器上部署多个服务还需要解决运行环境冲突的问题。另外，对于像大促动态扩缩容这样的场景，需要对服务进行横向扩展性能，需要为新增服务准备运行环境，部署服务等.,运维会变得很困难。16、第十三次进化：引入容器化技术实现运行环境隔离和动态服务管理目前最先进的容器化技术是Docker，最先进的容器管理服务是Kubernetes（K8S）。应用/服务可以打包为Docker镜像，通过K8S动态分发部署镜像。Docker镜像可以理解为一个可以运行你的应用/服务的最小操作系统，里面包含了应用/服务的运行代码，运行环境根据实际需要设置。将整个“操作系统”打包成镜像后，可以分发到需要部署相关服务的机器上，直接启动Docker镜像即可启动服务，让服务的部署和运维更加简单.大促之前，可以在现有的机器集群上划分服务器，启动Docker镜像来提升服务的性能。大促后可以关闭镜像，不影响本机其他服务（18节前，新加入机器上运行的服务需要修改系统配置适配服务，会破坏镜像所需的运行环境机上的其他服务）。架构瓶颈：使用容器技术可以解决服务动态扩缩容的问题，但是机器还是需要公司自己管理。运维成本极高，资源利用率低。17、第十四次进化：云平台承载系统。系统可部署在公有云上，利用公有云的海量机器资源解决动态硬件资源问题。大促期间，在云平台上临时申请更多资源，结合Docker和K8S快速部署服务，大促结束后释放资源，真正做到按需付费，大大提高资源利用率，大大提高降低运行和维护成本。所谓云平台就是将海量的机器资源通过统一的资源管理抽象成一个整体的资源，在云平台上可以按需动态申请硬件资源（如CPU、内存、网络等），并提供通用操作其上系统提供了常用的技术组件（如Hadoop技术栈、MPP数据库等）、邮件服务、个人博客等）。云平台涉及以下几个概念：1）IaaS：基础设施即服务。对应上面提到的将机器资源统一为一个整体的资源，可以动态申请硬件资源的高低；2）PaaS：平台即服务。对应上述提供常用的技术组件，方便系统开发和维护；3）SaaS：软件即服务。对应于提供上述开发的应用程序或服务，按功能或性能要求进行付费。至此：上述问题从高并发接入到服务架构和系统实现都有了自己的解决方案。但同时也应该意识到，在上面的介绍中，有意忽略了跨机房数据同步、分布式事务实现等实际问题，这些问题以后会单独讨论。18.架构设计经验总结1)架构的调整是否一定要按照上面的演进路径？不是的，上面说的架构演进顺序只是针对某个方面的单一改进。在实际场景中，可能有几个问题需要同时解决，也可能是另一个方面先达到瓶颈。这时候，应该根据实际问题来解决。比如在政府类的并发量可能不大，但业务可能比较丰富的场景下，高并发并不是要解决的重点问题。这时候优先考虑的可能是需求丰富的解决方案。2）对于要实现的系统，架构应该设计到什么程度？对于一个实现一次，性能指标明确的系统，设计架构来支持系统的性能需求就足够了，但是应该留一个接口来扩展架构，以备不时之需。对于一个不断演进的系统，比如电商平台，在设计上应该满足下一阶段用户量和性能指标的要求，并根据业务增长迭代升级架构，以支持更高的并发和更丰富的业务。3）服务端架构和大数据架构有什么区别？所谓“大数据”，其实是对海量数据采集、清洗转换、数据存储、数据分析、数据服务等场景解决方案的统称。每个场景包含多种可选技术，比如数据采集用Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS、NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说，大数据架构是根据业务需求，将各种大数据组件集成在一起的架构，一般提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。服务端架构更多指的是应用组织层面的架构，底层能力往往由大数据架构提供。4）架构设计有什么原则？A。N+1设计：系统中的每个组件都应该没有单点故障；b.回滚设计：保证系统向前兼容，系统升级时应该有回滚版本的方法；C。DisableDesign：应该提供配置来控制特定功能的可用性，当系统出现故障时该功能可以快速下线；d.监测设计：在设计阶段就要考虑监测的手段；e.对于高可用，应考虑在多地实现多活数据中心，至少在一个机房掉电时系统仍然可用；F。采用成熟的技术：新开发或开源的技术往往存在很多隐藏的bug，如果没有商业支持出现问题可能就是一场灾难；G。资源隔离设计：避免单一业务占用所有资源；H。.购买非核心功能：如果非核心功能需要大量研发资源解决，可以考虑购买成熟产品；j.使用商用硬件：商用硬件可以有效降低硬件故障概率；k.快速迭代：系统要快速开发小功能模块，尽快上线验证，及早发现问题，大大降低系统交付风险；湖。无状态设计：服务接口要做到无状态，当前接口的访问不依赖于接口上次的访问状态。
