1.概述本文以淘宝为例，介绍服务端架构从百并发到千万并发的演进过程。遇到的相关技术让大家对架构的演进有了一个整体的认识。文末总结了架构设计的一些原则。2.基本概念在介绍架构之前，为了防止部分读者对架构设计中的一些概念产生懵懂，下面先介绍一些最基本的概念：分布式系统中的多个模块部署在不同的服务器上，即它可以称为分布式系统。比如Tomcat和数据库部署在不同的服务器上，或者两个功能相同的Tomcat部署在不同的服务器上。当高可用系统中的某些节点发生故障时，其他节点可以接管并继续提供服务。那么可以认为系统有一个高可用集群，将特定领域的软件部署在多台服务器上，作为一个整体提供一类服务，称为集群。例如Zookeeper中的Master和Slave分别部署在多台服务器上，形成一个整体，提供集中的配置服务。在一个普通的集群中，客户端往往可以连接到任意一个节点获取服务，当集群中的一个节点掉线时，其他节点往往可以自动接管并继续提供服务，这意味着集群具有高可用的负载均衡请求发送当请求到达系统时，通过某种方式将请求平均分配给多个节点，使得系统中的每个节点都能均匀地处理请求负载，那么系统可以认为是一个负载均衡的正向代理和反向代理系统.在外网，请求统一通过代理服务器转发。从外网的角度来看，就是代理服务器发起的访问。此时代理服务器实现正向代理；当外部请求进入系统时，代理服务器将请求转发到系统中的某台服务器上，对于外部请求，只有代理服务器与之交互。这时候代理服务器就实现了反向代理。简单来说，正向代理就是代理服务器代替内部系统访问外部网络的过程，反向代理就是外部访问系统的请求通过代理服务器转发到内部服务器的过程。3.架构演进3.1单机架构以淘宝为例。建站之初，应用和用户都很少，可以将Tomcat和数据库部署在同一台服务器上。当浏览器向www.taobao.com发起请求时，首先通过DNS服务器（DomainNameSystem）将域名转换为实际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最大支持5万并发。理论上，Nginx可以通过将请求分发到500个Tomcat来抵抗50,000并发。涉及到的技术包括：Nginx和HAProxy，都是工作在第七层网络的反向代理软件。它们主要支持http协议，也涉及session共享、文件上传下载等。反向代理大大增加了应用服务器所能支持的并发量，但并发量的增加也意味着更多的请求穿透数据库，单机数据库最终成为瓶颈。3.5第四次进化：数据库读写分离将数据库分为读数据库和写数据库。可以有多个读取数据库。写数据库中的数据通过同步机制同步到读数据库中。对于需要查询最新写入数据的场景，可以在缓存中多写入一份，通过缓存获取最新数据。.涉及的技术包括：Mycat，它是一个数据库中间件，通过它可以组织数据库和分库分表的单独读写。客户端可以通过它来访问底层数据库，同时也会涉及到数据同步和数据一致性的问题。.商家越来越多，不同商家之间的访问量差距很大。不同业务直接与数据库竞争，相互影响。减少了它们之间的资源竞争，可以部署更多的服务器来支持访问量大的业务。这也导致无法直接对跨业务的表进行关联分析，需要通过其他方式解决，但这不是本文的重点。有兴趣的可以自行搜索解决方案。随着用户量的增加，单机写库会逐渐达到性能瓶颈3.7第六次进化：将大表拆分成小表比如对于评论数据，可以根据商品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最终会成为瓶颈，所以无法通过两层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服务器最终会达到瓶颈。此时的用户量达到几千万甚至上亿。用户分布在不同的地区，距离机房的距离不同，导致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来解决。不同应用之间存在共享模块，应用单独管理会导致同一代码多份，导致公共功能升级时所有应用代码都升级。用户管理、订单、支付、认证等功能存在于多个应用中，因此可以将这些功能的代码单独抽取出来，形成一个单独的服务进行管理。这样的服务就是所谓的微服务，应用程序和服务之间通过HTTP、TCP或RPC请求等多种方式访问??公共服务，每个单独的服务都可以由单独的团队管理。此外，还可以利用Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务。另外，当应用程序访问服务时，服务之间也可能相互访问，调用链会变得非常复杂，逻辑也会变得混乱。3.13十二次进化：引入企业服务总线（EnterpriseServiceBus，ESB），屏蔽服务接口的访问差异。使用ESB统一转换访问协议，应用通过ESB统一访问后端服务。服务与服务之间也通过ESB相互调用，从而降低系统的耦合度。将这个单体应用拆分成多个应用，将公共服务抽取出来单独管理，使用企业消息总线解耦服务之间的耦合。这就是所谓的SOA（面向服务）架构，类似于微服务。体系结构令人困惑，因为表示非常相似。个人理解，微服务架构更多指的是将系统中的公共服务抽取出来进行单独运维管理的思想，而SOA架构则是指将服务拆分，统一服务接口访问的架构思想。SOA架构包含了微服务的思想。随着业务的不断发展，应用和服务会越来越多，应用和服务的部署也会变得复杂。在同一台服务器上部署多个服务还需要解决运行环境冲突的问题。此外，诸如大促销之类的事情需要动态缩放。在服务需要横向扩展的场景下，需要为新增服务准备运行环境，部署服务等，运维会变得非常困难。目前最流行的动态服务管理容器化技术是Docker，最流行的容器管理服务是Kubernetes（K8S）。应用/服务可以打包为Docker镜像，通过K8S动态分发部署镜像。Docker镜像可以理解为一个可以运行你的应用/服务的最小操作系统，里面包含了应用/服务的运行代码，运行环境根据实际需要设置。将整个“操作系统”打包成镜像后，可以分发到需要部署相关服务的机器上，直接启动Docker镜像即可启动服务，让服务的部署和运维更加简单.大促之前，可以在现有的机器集群上划分服务器，启动Docker镜像来提升服务的性能。大促后可以关闭镜像，不影响本机其他服务（3.14节之前，需要修改系统配置适配服务才能在新加入的机器上运行服务，会破坏运行机器上其他服务所需的环境）。使用容器化技术后，可以解决服务动态扩缩容的问题，但是机器还是需要公司自己管理。不是大促的时候，还是需要闲置大量的机器资源来应对大促，机器本身的成本和运维成本都非常高，资源利用率低3.15第十四次演进：利用云平台承载系统，可以将系统部署在公有云上，利用公有云的海量机器资源解决动态硬件资源问题，临时在云平台申请更多资源，结合Docker和K8S快速部署服务，大促结束后释放资源，真正做到按需付费，大大提高资源利用率，大大降低运维成本。所谓云平台就是将海量的机器资源通过统一的资源管理抽象成一个整体的资源，在云平台上可以按需动态申请硬件资源（如CPU、内存、网络等），并提供通用操作其上系统提供了常用的技术组件（如Hadoop技术栈、MPP数据库等）、邮件服务、个人博客等）。云平台涉及以下概念：IaaS：InfrastructureasaService。对应上述统一的机器资源作为一个整体，可以动态申请硬件资源的高低；PaaS：平台即服务。对应上述提供常用的技术组件，方便系统的开发和维护；SaaS：软件即服务。对应于提供上述开发的应用程序或服务，按功能或性能要求进行付费。至此，上述从高并发访问到服务架构和系统实现的问题都有了自己的解决方案，但同时也应该意识到在上面的介绍中，诸如跨域中的数据同步等实际问题机房、分布式事务实现等等，这些问题以后会单独讨论。4.架构设计总结架构的调整是否一定要按照上面的演进路径？不是的，上面说的架构演进顺序只是针对某个方面的单一改进。在实际场景中，可能有几个问题需要同时解决，也可能是另一个方面先达到瓶颈。这时候，应该根据实际问题来解决。比如在政府类的并发量可能不大，但业务可能比较丰富的场景下，高并发并不是要解决的重点问题。这时候优先考虑的可能是需求丰富的解决方案。架构应该设计到什么程度才能实现系统？对于一个实现一次，性能指标明确的系统，设计架构来支持系统的性能需求就足够了，但是应该留一个接口来扩展架构，以备不时之需。对于一个不断演进的系统，比如电商平台，在设计上应该满足下一阶段用户量和性能指标的要求，并根据业务增长迭代升级架构，以支持更高的并发和更丰富的业务。服务器端架构和大数据架构有什么区别？所谓“大数据”，其实是对海量数据采集、清洗转换、数据存储、数据分析、数据服务等场景解决方案的统称。每个场景包含多种可选技术，比如数据采集用Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS、NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说，大数据架构是根据业务需求，将各种大数据组件集成在一起的架构，一般提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。服务端架构更多指的是应用组织层面的架构，底层能力往往由大数据架构提供。有没有一些架构设计的原则？N+1设计。系统中的每个组件都应该没有单点故障；回滚设计。确保系统向前兼容，系统升级时应该有回退版本的方法；禁用设计。应提供配置控制特定功能是否可用，系统故障时该功能可快速下线；监控设计。设计阶段必须考虑监测手段；多活动数据中心设计。如果系统对可用性要求极高，则应考虑在多个地方实现多活数据中心，使至少一个机房掉电时系统仍然可用；使用成熟的技术。新开发或开源的技术往往存在很多隐藏的BUG，如果没有商业支持出现问题，可能就是一场灾难；资源隔离设计。避免单个业务占用所有资源；该架构应该能够水平扩展。只有系统能够横向扩展，才能有效避免瓶颈问题；应该购买非核心的。如果非核心功能需要大量研发资源解决，考虑采购成熟产品；使用商业硬件。商用硬件可以有效降低硬件故障概率；快速迭代。系统要快速开发小功能模块，尽快上线验证，及早发现问题，大大降低系统交付的风险；无状态设计。服务接口应该是无状态的，当前接口的访问不依赖于上次访问接口的状态。
