本文是学习大型分布式网站架构的技术总结。对高性能、高可用、可伸缩、可扩展的分布式网站的架构进行了总体描述，并给出了架构参考。文章一部分是阅读笔记，一部分是个人经验总结，对大型分布式网站架构有很好的参考价值。一、大型分布式网站架构技术1、大型网站的特点是用户多、分布广、流量大、高并发海量数据、服务可用性高、安全环境差、易受网络攻击、功能多、速度快更改和频繁发布。逐步发展是??以用户为中心的免费服务、付费体验2、大型网站架构目标高性能：提供快速的访问体验。高可用：网站服务始终可以正常访问。Scalable：增加/减少，通过硬件增加/减少处理能力。安全性：提供安全网站访问、数据加密和安全存储的策略。可扩展性：通过添加/删除轻松添加/删除新功能/模块。敏捷性：随需应变，快速响应；3、大型网站架构模型分层：一般可分为应用层、服务层、数据层、管理层和分析层；segmentation：一般按照业务/模块/功能特性来划分，比如应用层分为首页和用户中心。分布式：分别部署应用（如多台物理机），通过远程调用协同工作。集群：部署一个应用/模块/功能的多个副本（如多台物理机），通过负载均衡共同提供对外访问。缓存：将数据放在离应用程序或用户最近的位置，以加快访问速度。异步：使同步操作异步。客户端发出请求，不等待服务器响应，服务器处理完成后，通过通知或轮询的方式通知请求者。一般指：请求-响应-通知模式。冗余：增加副本以提高可用性、安全性和性能。安全：已知问题有有效的解决方案，未知/潜在问题有发现和防御机制。自动化：使用机器通过工具完成不需要人类参与的重复性工作。敏捷：主动接受需求变更，快速响应业务发展需求。4、高性能架构，以用户为中心，提供快速的网页访问体验。主要参数是响应时间短，并发处理能力大，吞吐量高，性能参数稳定。可以分为前端优化、应用层优化、代码层优化和存储层优化。前端优化：网站业务逻辑之前的部分；浏览器优化：减少HTTP请求次数，使用浏览器缓存，启用压缩，CSSJS定位，JS异步，减少cookie传输；CDN加速、反向代理；应用层优化：网站业务的处理服务器。使用缓存、异步、集群代码优化：合理的架构、多线程、资源复用（对象池、线程池等）、良好的数据结构、JVM调优、单例、Cache等；存储优化：缓存、固态硬盘、光纤传输、优化读写、磁盘冗余、分布式存储（HDFS）、NoSQL等5.高可用架构大型网站应随时可访问，提供外部服务正常。由于大型网站、分布式、廉价服务器、开源数据库、操作系统等的复杂性，保证高可用性非常困难，这意味着网站故障在所难免。如何提高可用性是一个亟待解决的问题。首先需要在架构层面考虑，在规划时要考虑可用性。业界一般用几个9来表示可用性指标，比如四个9（99.99），一年内允许的不可用时间为53分钟。不同级别采用不同的策略，一般采用冗余备份和故障转移来解决高可用问题。应用层：一般设计成无状态的，对每次请求使用哪个服务器没有影响。一般采用负载均衡技术（需要解决Session同步问题）来实现高可用。服务层：负载均衡、分级管理、快速故障（超时设置）、异步调用、服务降级、幂等设计等数据层：冗余备份（冷、热备[同步、异步]、暖备）、故障转移（确认、转移、恢复）。著名的数据高可用性理论基础是CAP理论（持久性、可用性、数据一致性[强一致性、用户一致性、最终一致性]）6.可扩展架构可扩展性是指在不改变原有架构设计的情况下保持原有架构的能力.，通过增加/减少硬件（服务器）来增加/减少系统的处理能力。应用层：垂直或水平拆分应用程序。然后为单个功能（DNS、HTTP[反向代理]、IP、链路层）进行负载平衡。服务层：类似于应用层；数据层：分库、分表、NoSQL等；通用算法Hash，一致性Hash。7.可扩展的架构可以轻松地添加/删除功能模块，在代码/模块级别提供良好的可扩展性。模块化和组件化：高内聚、低耦合，提高可重用性和可扩展性。稳定接口：定义稳定接口。在界面不变的情况下，内部结构可以“随意”改变。设计模式：应用面向对象的思想和原则，使用设计模式，在代码层面进行设计。消息队列：模块化系统，通过消息队列进行交互，解耦模块之间的依赖关系。分布式服务：为公共模块提供服务，提供其他系统使用，提高可重用性和可扩展性。8.安全架构对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。对于安全问题，首先要提高安全意识，建立有效的安全机制，从政策和组织层面确保，比如服务器密码不能泄露，密码每月更新一次，三年内不能重复。次；每周安全扫描等制度化，加强安全体系建设。同时，需要注意与安全相关的各个方面。安全问题不容忽视，包括基础设施安全、应用系统安全、数据机密安全等。基础设施安全：硬件采购、操作系统、网络环境安全。一般通过正规渠道购买优质产品，选择安全的操作系统，及时修补漏洞，安装杀毒软件和防火墙。防止病毒、后门程序。设置防火墙策略，建立DDOS防御系统，使用攻击检测系统，进行子网隔离等手段。应用系统安全：在程序开发过程中，使用正确的方法在代码层面解决已知的常见问题。防止跨站脚本（XSS）、注入攻击、跨站请求伪造（CSRF）、错误信息、HTML注释、文件上传、路径遍历等。也可以使用Web应用防火墙（如ModSecurity）进行扫描针对安全漏洞等措施加强应用层安全。数据保密与安全：存储安全（存储在可靠的设备中，实时、定期备份）、存储安全（重要信息加密存储、选择合适的人员进行复杂的存储和检测等）、传输安全（防止数据被窃取）和数据篡改）；常用的加解密算法（单一哈希加密[MD5、SHA]、对称加密[DES、3DES、RC]）、非对称加密[RSA]等。9.敏捷性网站的架构设计和运维管理应适应变化并提供高可扩展性和可扩展性。方便应对业务快速发展、大流量接入骤增等需求。除了上面介绍的架构要素外，还需要介绍一下敏捷管理和敏捷开发的思想。统一业务、产品、技术、运维，按需快速响应。10.大型架构示例以上采用七层逻辑架构，第一层客户层，第二层前端优化层，第三层应用层，第四层服务层，第五层数据存储层，第六层大数据存储层，第七层大数据处理层。客户端层：支持PC浏览器和手机APP。不同的是手机APP可以直接通过IP访问，反向代理服务器。前端层：使用DNS负载均衡、CDN本地加速和反向代理服务；应用层：网站应用集群；按业务垂直拆分，如商品应用、会员中心等；服务层：提供公共服务，如用户服务、订单服务、支付服务等；数据层：支持关系型数据库集群（支持读写分离）、NOSQL集群、分布式文件系统集群；和分布式缓存；大数据存储层：支持应用层和服务层的日志数据采集，关系型数据库和NOSQL数据库的结构化和半结构化数据采集；大数据处理层：通过Mapreduce进行离线数据分析或Storm实时数据分析，将处理后的数据存入关系数据库。（在实际使用中，离线数据和实时数据会根据业务需求进行分类处理，存储在不同的数据库中，供应用层或服务层使用）。2、大型电子商务网站系统架构的演进过程。一个成熟的大型网站（如淘宝、天猫、腾讯等）的系统架构，从一开始设计的时候，并不具备完整的高性能、高可用性、高扩展性。随着用户的增加和业务功能的扩展而逐步演进和完善。在这个过程中，开发模式、技术架构、设计思路也发生了很大的变化。甚至技术人员也从几个人发展到一个部门甚至一条产品线。所以一个成熟的系统架构是随着业务的扩大而逐步完善的，不是一蹴而就的；不同业务特点的系统都会有自己的侧重点，比如淘宝，需要解决海量商品信息的搜索、下单、支付；比如腾讯要解决亿级用户的实时消息传输；百度必须处理大量的搜索请求。它们都有自己的业务特点，系统架构也不一样。但是，我们也可以从这些不同的网站背景中找出共享的技术。这些技术和手段广泛应用于大型网站系统的架构中。下面通过介绍大型网站系统的演进过程来了解这些技术和方法。方法。一、网站初期架构初期架构、应用、数据库、文件都部署在一台服务器上，如图：2、应用、数据、文件分离随着业务的扩大，一台服务器不再满足性能需求，因此应用程序、数据库和文件都部署在独立的服务器上，并根据服务器的用途配置不同的硬件，以达到最佳性能。3、利用缓存提升网站性能在优化硬件性能的同时，也利用软件来优化性能。在大多数网站系统中，都会使用缓存技术来提高系统性能。缓存的使用主要是因为热点数据的存在。有些网站的访问遵循28原则（即80%的访问请求以20%的数据结束），所以我们可以缓存热点数据，减少这些数据的访问路径，提高用户体验。缓存的常见实现方式有本地缓存??和分布式缓存。当然还有CDN、反向代理等，后面再说。本地缓存，顾名思义就是将数据缓存在应用服务器本地，可以保存在内存中，也可以保存在文件中。OSCache是一个常用的本地缓存组件。本地缓存的特点是速度快，但是由于本地空间有限，缓存的数据量也有限。分布式缓存的特点是可以缓存海量数据，而且非常容易扩展。常用于门户网站，速度没有本地缓存??快。常用的分布式缓存有Memcached和Redis。4、使用集群提高应用服务器性能。应用服务器作为网站的入口，会承担大量的请求。我们经常使用应用服务器集群来共享请求数。应用服务器前端部署负载均衡服务器，对用户请求进行调度，并根据分发策略将请求分发到多个应用服务器节点。常用的负载均衡技术硬件有F5，价格比较贵，软件有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服务器。Nginx和HAProxy是七层负载均衡，可以根据报文内容选择内部服务器。因此，LVS的分发路径比Nginx和HAProxy更好，性能更高。Nginx和HAProxy可配置性更强，比如可以用于动静分离（根据请求报文的特点，选择静态资源服务器或应用服务器）。5、数据库读写分离，分库分表随着用户量的增加，数据库成为最大的瓶颈。提高数据库性能的常用方法是进行读写分离，分库分表。读写分离，顾名思义就是将数据库分为读写数据库，通过主备功能实现数据同步。分库分表分为两种：水平分拆和垂直分拆。水平拆分就是拆分一个非常大的数据库表，比如用户表。纵向拆分就是按照不同的业务进行拆分，比如用户业务和商品业务相关的表放在不同的数据库中。6、使用CDN和反向代理提高网站性能如果我们的服务器部署在成都机房，四川用户访问速度较快，而北京用户访问速度较慢。北京属于中国电信和中国联通的不同发达地区。北京的用户需要经过很长的一段路径通过互联网路由器访问成都的服务器，返回路径相同，所以数据传输时间比较长。针对这种情况，往往会使用CDN来解决问题。CDN将数据内容缓存在运营商机房，用户访问时首先从最近的运营商处获取数据，大大减少了网络访问的路径。更专业的CDN运营商有蓝讯、网速。反向代理部署在网站机房。当用户请求到达时，首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户。如果没有缓存数据，会继续访问应用服务器获取。这样做可以降低获取数据的成本。反向代理包括Squid和Nginx。7、使用分布式文件系统的用户日益增多，业务量越来越大，产生的文件也越来越多。单一的文件服务器已经不能满足需求。这时候就需要分布式文件系统的支持了。常用的分布式文件系统包括GFS、HDFS和TFS。8、使用NoSQL和搜索引擎对于海量数据的查询和分析，我们可以通过使用NoSQL数据库和搜索引擎来获得更好的性能。并非所有数据都应放在关系数据中。常用的NoSQL有MongoDB、HBase、Redis等，搜索引擎有Lucene、Solr、Elasticsearch等。9.将应用服务器拆分成业务。随着业务的进一步扩大，应用程序变得非常臃肿。这时候我们就需要把应用程序拆分成业务。例如，百度分为新闻、网页、图片等服务。每个业务应用负责相对独立的业务操作。企业通过消息或共享数据库进行通信。10、构建分布式服务这时候我们发现，每个业务应用都会用到一些基本的业务服务，比如用户服务、订单服务、支付服务、安全服务等。这些服务是支持每个业务应用程序的基本元素。我们将这些服务抽取出来，使用分布式服务框架来构建分布式服务。阿里的Dubbo是一个不错的选择。3.电子商务架构图4.大型电子商务网站架构案例1.电子商务案例原因分布式大型网站。目前主要有几种：大型门户网站，如网易、新浪等；SNS网站，如校园网、开心网等；电子商务网站，如阿里巴巴、京东、国美在线、汽车之家等。大型门户网站一般都是新闻类信息，可以通过CDN、静态等方式进行优化，开心网交互性更强，可能会引入更多的NoSQL、分布式缓存、高性能通信框架。电子商务网站具有以上两种类型的特点。比如产品详情可以使用CDN，静态的、交互性强的需要使用NoSQL等技术。因此，我们以电子商务网站为例进行分析。2、电子商务网站需求客户需求：建立全品类电子商务网站（B2C），用户可以在线购买商品、在线支付或货到付款；用户购买时可在线与客服沟通；用户收到商品最后可以对商品进行打分评价；目前有成熟的进销存体系；需要与网站连接；希望能够支持3到5年的业务发展；预计3-5年用户数将达到1000万；定期举办双11、双12、3月8日男士节等活动；其他功能请参考京东、国美在线等网站。顾客就是顾客，不会告诉你他想要什么，只会告诉你他想要什么。我们经常要引导和挖掘客户的需求。幸运的是，提供了一个清晰的参考站点。所以，下一步就是要进行大量的分析，结合行业，参考网站，为客户提供解决方案。需求-功能矩阵需求管理传统上使用用例图或模块图（需求列表）来描述需求。这往往会忽略一个非常重要的需求（非功能需求），所以建议大家使用需求-功能矩阵来进行需求描述。本电子商务网站的需求矩阵如下：3、网站的一级结构。一般的网站，一开始就是三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统。这是近几年比较传统的做法。看到一个会员超过10万的网站，一个垂直的服装设计门户，还有很多图片。服务器用于部署应用程序、数据库和图像存储。有很多性能问题。如下图：然而，目前主流的网站架构已经发生了翻天覆地的变化。通常，集群用于高可用性设计。至少看起来是这样的：利用集群让应用服务器冗余，实现高可用；（负载均衡设备可与应用一起部署）采用数据库主备模式，实现数据备份和高可用；4、系统容量估算步骤：注册用户数-日均UV量-日PV量-日并发量；峰值预估：平时音量的2~3倍；根据并发量（concurrency，事务数）和存储容量计算系统容量。根据客户需求：3~5年用户数达到1000万注册用户，每秒并发数可估算：每天200万个UV（28原则）；每天30次点击；PV量：200*30=6000万；集中访问：24*0.2=4.8小时会有6000万*0.8=4800万（二十八原则）；每分钟并发量：4.8*60=288分钟，4800/288=16.7每分钟访问量万（约等）；每秒并发数：167,000/60=2780（约等）；假设：高峰期是平时值的3倍，则每秒并发数可达8340次。1毫秒=1.3次访问；你后悔没学好数学吗？！（不知道上面的计算有没有错，呵呵~~）服务器预估：（以tomcat服务器为例）根据一个web服务器，支持每秒300个并发计算。通常，需要10个服务器（大约相等）；【tomcat默认配置150台】，高峰期需要30台服务器；容量估算：70/90原则系统CPU一般保持在70%左右的水平，高峰期达到90%的水平，不浪费资源，比较稳定。内存和IO类似。以上预估仅供参考，因为服务器配置、业务逻辑复杂度等都有影响。这里CPU、硬盘、网络等不再评价。5、网站架构分析根据以上估算，存在几个问题：需要部署大量服务器，高峰期可能部署30台web服务器。而这30台服务器仅仅用来闪杀和活动，浪费很大。所有应用都部署在同一台服务器上，应用之间的耦合度很高。需要垂直拆分和水平拆分。大量应用程序中存在冗余代码。ServerSession同步会消耗大量内存和网络带宽。数据需要频繁访问数据库，数据库访问压力巨大。大型网站一般需要做如下架构优化（优化是在设计架构时考虑的，一般在架构/代码层面解决。调优主要是简单参数的调整，比如JVM调优；如果调优涉及到大量代码修改，不是调优，是重构）：业务拆分应用集群部署（分布式部署、集群部署和负载均衡）多级缓存单点登录（分布式会话）数据库集群（读写分离、分流）数据库和分表）面向服务的消息队列其他技术六、网站架构优化（1）业务拆分按业务属性纵向拆分，分为商品子系统、购物子系统、支付子系统、评论子系统、客服子系统、界面子系统系统（与外部系统连接，如发票、SMS等）。根据业务子系统的层次定义，可分为核心系统和非核心系统。核心系统：商品子系统、购物子系统、支付子系统；非核心：评论子系统、客服子系统、界面子系统。业务拆分的作用：升级到一个子系统可以有专门的团队和部门负责，专业的人做专业的事，解决模块之间的耦合和扩展性问题；每个子系统单独部署，避免集中部署导致应用挂掉。所有应用程序都不可用。等级定义功能：用于在流量突发时保护关键应用，实现优雅降级；以保护关键应用程序不受影响。拆分架构图：参考部署方案2，如上图所示，每个应用单独部署，核心系统和非核心系统一起部署（2）应用集群部署（分布式、集群、负载均衡）分布式deployment：拆分业务最终应用单独部署，应用直接通过RPC远程通信；集群部署：电商网站的高可用要求，每个应用至少要部署两台服务器进行集群部署；负载均衡：是高可用系统所必需的，一般应用通过负载均衡实现高可用，分布式服务通过内置负载均衡实现高可用，关系型数据库通过主备方式实现高可用。集群部署后的架构图：(3)多级缓存缓存按照存储位置一般可以分为本地缓存和分布式缓存两种。本例采用二级缓存来设计缓存。一级缓存是本地缓存，二级缓存是分布式缓存。（还有pagecaches，fragmentcaches等，都是更细粒度的划分）Level-1cache，缓存数据字典，以及常用的热点数据等基本不可变/经常变化的信息，Level-2cache缓存所有需要的缓存。当一级缓存过期或不可用时，访问二级缓存中的数据。如果没有二级缓存，则访问数据库。缓存比例一般为1:4，可以考虑使用缓存。（理论上是1:2）。根据业务特点，可以采用以下缓存过期策略：缓存自动过期；缓存触发过期；(4)单点登录（分布式会话）系统分为多个子系统。独立部署后，难免会遇到session管理问题。一般可以使用Session同步、Cookies、分布式Session方式。电子商务网站通常使用分布式会话来实现。进一步，可以基于分布式会话建立完整的单点登录或账户管理系统。流程描述当用户第一次登录时，将session信息（用户ID和用户信息），如以用户ID为key写入分布式session；用户再次登录时，获取分布式session，是否有session信息，如果没有则传到登录页面；一般由Cache中间件实现，推荐使用Redis，因此具有持久化功能，方便分布式Session宕机后从持久化存储中加载Session信息；保存session时，可以设置session的保留时间，比如15分钟，超过后自动超时；结合Cache中间件，实现的分布式Session可以很好的模拟Session会话。（5）数据库集群（读写分离，分库分表）大型网站需要存储海量数据。为了实现海量数据存储、高可用性和高性能，系统通常采用冗余方式设计。一般有读写分离和分库分表两种方式。读写分离：一般解决读比写远大于写的场景，可以采用一主一备，一主多备，或者多主多备。本案例在业务拆分的基础上，结合了分库分表和读写分离。如下图所示：业务拆分后：每个子系统需要一个单独的库；如果单独的库太大，可以根据业务特点重新划分，如商品分类库、产品库；分库后，如果表中数据量大，分表，一般按照Id，时间等；（高级用法是一致Hash）在分库分表的基础上，进行读写分离；相关中间件可以参考Cobar（阿里，不再维护）、TDDL（阿里）、Atlas（奇虎360）、MyCat。分库分表后的顺序问题、JOIN、事务问题等会在分库分表的主题分享中介绍。(6)服务化提取多个子系统的公共功能/模块，作为公共服务使用。例如，本例中的会员子系统可以提取为公共服务。(7)消息队列消息队列可以解决子系统/模块之间的耦合，实现异步、高可用、高性能的系统。它是分布式系统的标准配置。在这种情况下，消息队列主要用于购物和送货。用户下单后，写入消息队列，然后直接返回给客户端；库存子系统：读取消息队列信息，完成库存缩减；分发子系统：读取消息队列信息，并进行投递；目前使用的MQ有ActiveMQ、RabbitMQ、ZeroMQ、MSMQ等，需要根据具体业务场景选择。推荐研究一下RabbitMQ。(8)除上述业务拆分、应用集群、多级缓存、单点登录、数据库集群、面向服务、消息队列外的其他架构（技术）。还有CDN、反向代理、分布式文件系统、大数据处理等系统。这里就不详细介绍了，大家可以问度娘/谷歌，有机会再分享给大家。7.架构总结大型网站的架构都是根据业务需求不断改进的，会根据不同的业务特点进行具体的设计和考虑。本文仅介绍常规大型网站中涉及的一些技术和方法，希望能给您带来启发。作者介绍烂猪皮，拥有十多年工作经验。曾在谷歌等外企工作多年。精通Java、分布式架构、微服务架构和数据库。最近在研究大数据和区块链，希望能有更高的突破。高境界。
