用Java做一个大流量，高并发的网站应该怎么样进行底层构架

JVM

JEE容器中运行的JVM参数配置参数的正确使用直接关系到整个系统的性能和处理能力，JVM的调优主要是对内存管理方面的调优，优化的方向分为以下4点：

HeapSize            

堆的大小，也可以说Java虚拟机使用内存的策略，这点是非常关键的。

2GarbageCollector  

通过配置相关的参数进行Java中的垃圾收集器的4个算法(策略)进行使用。

3StackSize             

栈是JVM的内存指令区,每个线程都有他自己的Stack，Stack的大小限制着线程的数量。

4DeBug/Log           

在JVM中还可以设置对JVM运行时的日志和JVM挂掉后的日志输出，这点非常的关键，根据各类JVM的日志输出才能配置合适的参数。

网上随处可见JVM的配置技巧，但是我还是推荐阅读Sun官方的2篇文章，可以对配置参数的其所依然有一个了解

Java HotSpot VM Options

Java HotSpot VM Options

2Troubleshooting Guide for Java SE 6 with HotSpot VMTroubleshooting Guide for Java SE 6 with HotSpot VM

另外，我相信不是每个人攻城师都是天天对着这些JVM参数的，如果你忘记了那些关键的参数你可以输入Java -X(大写X)进行提示。

JDBC

针对MySQL的JDBC的参数在之前的文章中也有介绍过，在单台机器或者集群的环境下合理的使用JDBC中的配置参数对操作数据库也有很大的影响。

一些所谓高性能的 Java ORM开源框架也就是打开了很多JDBC中的默认参数：

例如：autoReconnect、prepStmtCacheSize、cachePrepStmts、useNewIO、blobSendChunkSize 等，

2例如集群环境下：roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster。

数据库连接池(DataSource)

应用程序与数据库连接频繁的交互会给系统带来瓶颈和大量的开销会影响到系统的性能，JDBC连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用

一个现有的数据库连接，而再不是重新建立一个连接，因此应用程序不需要频繁的与数据库开关连接，并且可以释放空闲时间超过最大空闲时间的数据库连接来避免

因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。

在此我认为有一点需要说明：

连接池的使用也是需要关闭，因为在数据库连接池启动的时候就预先和数据库获得了相应的连接，之后不再需要应用程序直接的和数据库打交道，因为应用程序使用数据库连接池是一个

“借”的概念，应用程序从数据库连接池中获得资源是“借出”，还需要还回去，就好比有20个水桶放在这里，需要拿水的人都可以使用这些木桶从水池里面拿水，如果20个人都拿完水，不将水桶还回原地，那么后面来的人再需要拿水，只能在旁边等待有人将木桶还回去，之前的人用完后需要放回去，不然后面的人就会一直等待，造成资源堵塞，同理，应用程序获取数据库连接的时候Connection连接对象的时候是从“池”中分配一个数据库连接出去，在使用完毕后，归还这个数据库连接，这样才能保持数据库的连接“有借有还”准则。

数据存取

数据库服务器的优化和数据的存取，什么类型的数据放在什么地方更好是值得去思考的问题，将来的存储很可能是混用的，Cache，NOSQL，DFS，DataBase 在一个系统中都会有，生活的餐具和平日里穿衣服需要摆放在家里，但是不会用同一种类型的家具存放，貌似没有那个人家把餐具和衣服放在同一个柜子里面的。这就像是系统中不同类型的数据一样，对不同类型的数据需要使用合适的存储环境。文件和的存储，首先按照访问的热度分类，或者按照文件的大小。强关系类型并且需要事务支持的采用传统的数据库，弱关系型不需要事务支持的可以考虑NOSQL，海量文件存储可以考虑一下支持网络存储的DFS，至于缓存要看你单个数据存储的大小和读写的比例。

还有一点值得注意就是数据读写分离，无论在DataBase还是NOSQL的环境中大部分都是读大于写，因此在设计时还需考虑 不仅仅需要让数据的读分散在多台机器上，还需要考虑多台机器之间的数据一致性，MySQL的一主多从，在加上MySQL-Proxy或者借用JDBC中的一些参数(roundRobinLoadBalance、failOverReadOnly、autoReconnectForPools、secondsBeforeRetryMaster)对后续应用程序开发，可以将读和写分离，将大量读的压力分散在多台机器上，并且还保证了数据的一致性。

缓存

在宏观上看缓存一般分为2种：本地缓存和分布式缓存

本地缓存

对于Java的本地缓存而言就是讲数据放入静态(static)的数据结合中，然后需要用的时候就从静态数据结合中拿出来,对于高并发的环境建议使用 ConcurrentHashMap或者CopyOnWriteArrayList作为本地缓存。缓存的使用更具体点说就是对系统内存的使用，使用多少内存的资源需要有一个适当比例，如果超过适当的使用存储访问，将会适得其反，导致整个系统的运行效率低下。

2 分布式缓存

一般用于分布式的环境，将每台机器上的缓存进行集中化的存储，并且不仅仅用于缓存的使用范畴，还可以作为分布式系统数据同步/传输的一种手段，一般被使用最多的就是Memcached和Redis。

数据存储在不同的介质上读/写得到的效率是不同的，在系统中如何善用缓存，让你的数据更靠近cpu。

并发/多线程

在高并发环境下建议开发者使用JDK中自带的并发包(javautilconcurrent)，在JDK15以后使用javautilconcurrent下的工具类可以简化多线程开发，在javautilconcurrent的工具中主要分为以下几个主要部分：

线程池

线程池的接口(Executor、ExecutorService)与实现类(ThreadPoolExecutor、

ScheduledThreadPoolExecutor），利用jdk自带的线程池框架可以管理任务的排队和安排，并允许受控制的关闭。因为运行一个线程需要消耗系统CPU资源，而创建、结束一个线程也对系统CPU资源有开销，使用线程池不仅仅可以有效的管理多线程的使用，还是可以提高线程的运行效率。

2本地队列

提供了高效的、可伸缩的、线程安全的非阻塞 FIFO 队列。javautilconcurrent 中的五个实现都支持扩展的 BlockingQueue 接口，该接口定义了 put 和 take的阻塞版本：LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue、

PriorityBlockingQueue 和 DelayQueue。这些不同的类覆盖了生产者-使用者、消息传递、并行任务执行和相关并发设计的大多数常见使用的上下文。

　　对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。

　　操作系统

　　Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。

　　CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。

　　LAMP网站架构图

　　Web服务器、缓存和PHP加速

　　Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。

　　Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持PHP和CGI等动态语言，但支持负载均衡和容错，可和Apache配合使用，是轻量级的HTTP服务器的首选。

　　Web服务器的缓存也有多种方案，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作为分布式缓存。

　　PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动态内容缓存，提高了性能PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。使PHP程序代码执效率能提高1-10倍。

　　具体的解决方案有以下几种：

　　1、squid + Apache + PHP + eAccelerator

　　使用Apache负载PHP，使用squid进行缓存，html或的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。

　　2、nginx/Apache + PHP（fastcgi） + eAccelerator

　　使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。

　　3、nginx + Apache + PHP + eAccelerator

　　此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。

　　数据库

　　开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当访问量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。

　　当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。

　　总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access（例如月光博客）这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。

　　综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。

在实际的开发当中，我们经常需要进行磁盘数据的读取和搜索，因此经常会有出现从数据库读取数据的场景出现。但是当数据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮整个数据库，导致系统卡死等严重问题。

常规的应用系统中，我们通常会在需要的时候对数据库进行查找，因此系统的大致结构如下所示：

1缓存和数据库之间数据一致性问题

常用于缓存处理的机制我总结为了以下几种：

首先来简单说说Cache aside的这种方式：

Cache Aside模式

这种模式处理缓存通常都是先从数据库缓存查询，如果缓存没有命中则从数据库中进行查找。

这里面会发生的三种情况如下：

缓存命中：

当查询的时候发现缓存存在，那么直接从缓存中提取。

缓存失效：

当缓存没有数据的时候，则从database里面读取源数据，再加入到cache里面去。

缓存更新：

当有新的写操作去修改database里面的数据时，需要在写操作完成之后，让cache里面对应的数据失效。

关于这种模式下依然会存在缺陷。比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

Facebook的大牛们也曾经就缓存处理这个问题发表过相关的论文，链接如下:

分布式环境中要想完全的保证数据一致性是一件极为困难的事情，我们只能够尽可能的减低这种数据不一致性问题产生的情况。

Read Through模式

Read Through模式是指应用程序始终从缓存中请求数据。 如果缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。 检索数据后，缓存会自行更新并将数据返回给调用应用程序。使用Read Through 有一个好处。

我们总是使用key从缓存中检索数据, 调用的应用程序不知道数据库， 由存储方来负责自己的缓存处理，这使代码更具可读性， 代码更清晰。但是这也有相应的缺陷，开发人员需要给编写相关的程序插件，增加了开发的难度性。

Write Through模式

Write Through模式和Read Through模式类似，当数据发生更新的时候，先去Cache里面进行更新，如果命中了，则先更新缓存再由Cache方来更新database。如果没有命中的话，就直接更新Cache里面的数据。

2缓存穿透问题

在高并发的场景中，缓存穿透是一个经常都会遇到的问题。

什么是缓存穿透？

大量的请求在缓存中没有查询到指定的数据，因此需要从数据库中进行查询，造成缓存穿透。

会造成什么后果？

大量的请求短时间内涌入到database中进行查询会增加database的压力，最终导致database无法承载客户单请求的压力，出现宕机卡死等现象。

常用的解决方案通常有以下几类：

1空值缓存

在某些特定的业务场景中，对于数据的查询可能会是空的，没有实际的存在，并且这类数据信息在短时间进行多次的反复查询也不会有变化，那么整个过程中，多次的请求数据库操作会显得有些多余。

不妨可以将这些空值（没有查询结果的数据）对应的key存储在缓存中，那么第二次查找的时候就不需要再次请求到database那么麻烦，只需要通过内存查询即可。这样的做法能够大大减少对于database的访问压力。

2布隆过滤器

通常对于database里面的数据的key值可以预先存储在布隆过滤器里面去，然后先在布隆过滤器里面进行过滤，如果发现布隆过滤器中没有的话，就再去redis里面进行查询，如果redis中也没有数据的话，再去database查询。这样可以避免不存在的数据信息也去往存储库中进行查询情况。

什么是缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

如何避免缓存雪崩问题？

1使用加锁队列来应付这种问题。当有多个请求涌入的时候，当缓存失效的时候加入一把分布式锁，只允许抢锁成功的请求去库里面读取数据然后将其存入缓存中，再释放锁，让后续的读请求从缓存中取数据。但是这种做法有一定的弊端，过多的读请求线程堵塞，将机器内存占满，依然没有能够从根本上解决问题。

2在并发场景发生前，先手动触发请求，将缓存都存储起来，以减少后期请求对database的第一次查询的压力。数据过期时间设置尽量分散开来，不要让数据出现同一时间段出现缓存过期的情况。

3从缓存可用性的角度来思考，避免缓存出现单点故障的问题，可以结合使用 主从+哨兵的模式来搭建缓存架构，但是这种模式搭建的缓存架构有个弊端，就是无法进行缓存分片，存储缓存的数据量有限制，因此可以升级为Redis Cluster架构来进行优化处理。（需要结合企业实际的经济实力，毕竟Redis Cluster的搭建需要更多的机器）

4Ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。

使用 Ehcache本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，Ehcache本地缓存还能够支撑一阵。

使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。

然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。

　　高并发主要是由于网站PV访问量大，单台服务器涌承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个访问会被发送到哪台服务器，我们采取负载均衡策略，常见的技术有LVS，由于网站中有大量的静态页面，所以采用缓存服务器和反向代理技术，包括HAPROXY，REDIS,数据库可以采用数据库集群，进行读写分离，缓解数据库压力。等等。

我在Cernet做过拨号接入平台的搭建，而后在Yahoo3721负载搜索引擎前端平台开发，又在猫扑处理过大型社区猫扑大杂烩的架构升级等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。

一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的服务器，甚至很多台服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃，在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，net不是很熟悉，相信也肯定有。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨菲定律、康威定律和二八定律三大定律，而系统设计包括高并发原则、高可用和业务设计原则等。

架构设计三大定律

墨菲定律 – 任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生

康威定律 – 系统架构师公司组织架构的反映 – 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 – 如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 – 微服务架构的理论基础 – 康威定律https://yqaliyuncom/articles/8611– 每个架构师都应该研究下康威定律http://36krcom/p/5042735html

二八定律 – 80%的结果取决于20%的原因

系统设计遵循的原则

1高并发原则

无状态

无状态应用，便于水平扩展

有状态配置可通过配置中心实现无状态

实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等

拆分

系统维度：按照系统功能、业务拆分，如购物车，结算，订单等

功能维度：对系统功能在做细粒度拆分

读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表

AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统

模块维度：对整体代码结构划分Web、Service、DAO

服务化

服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理

考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等

实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服

消息队列

目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等

大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)

数据校对: 解决异步消息机制下消息丢失问题

数据异构

数据异构: 通过消息队列机制接收数据变更，原子化存储

数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环

缓存银弹

用户层:

DNS缓存

浏览器DNS缓存

操作系统DNS缓存

本地DNS服务商缓存

DNS服务器缓存

客户端缓存

浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)

App客户缓存(js/css/image…)

代理层：

CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)

接入层：

Opcache： 缓存PHP的Opcodes

Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD

FastCGI Cache

Nginx+Lua+Redis: 业务数据缓存

Nginx为例：

PHP为例：

应用层：

页面静态化

业务数据缓存(Redis/Memcached/本地文件等)

消息队列

数据层：

NoSQL： Redis、Memcache、SSDB等

MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等

系统层：

CPU : L1/L2/L3 Cache/NUMA

内存

磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存

并发化

2高可用原则

降级

降级开关集中化管理：将开关配置信息推送到各个应用

可降级的多级读服务：如服务调用降级为只读本地缓存

开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略

业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能

限流

目的: 防止恶意请求攻击或超出系统峰值

实践：

恶意请求流量只访问到Cache

穿透后端应用的流量使用Nginx的limit处理

恶意IP使用Nginx Deny策略或者iptables拒绝

切流量

目的：屏蔽故障机器

实践:

DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢

HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度

LVS/HaProxy/Nginx: 摘除故障节点

可回滚

发布版本失败时可随时快速回退到上一个稳定版本

3业务设计原则

防重设计

幂等设计

流程定义

状态与状态机

后台系统操作可反馈

后台系统审批化

文档注释

备份

4总结

先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。

本文作者为网易高级运维工程师