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