高并发网站架构的设计方案是怎样的？

技术这玩意儿，你不深入使用它，你就不知道它有多牛，更不知道会有多难！

并发:指定时间段内的请求数！

高并发:指定时间段内的超多请求数！

比如tomcat，单机最大支持并发数为8000左右，redis理论值可达到几万！

那么怎么设计一套可支持高并发的系统呢？使用技术如下:

1，分布式系统，微服务:使用springcloud家族包括eureka，zuul，feign，hysrix等或者dubbo搭建一套微服务框架！

2，前后端分离:使用node.js搭建前端服务系统！

3，静态化处理:将页面，后台枚举，数据库定义表等使用静态处理方式做处理！

4，文件服务器剥离:采用单独的文件服务器，防止页面加载的阻塞！

5，缓存:使用redis，memcache等将运行时数据缓存，代替频繁的操作数据库！

6，数据库:读写分离或者分库分表，采用druid等有性能监控系统的数据库连接框架！

7，消息中间件:使用xxxmq，kafka等消息中间件，解耦服务，而且异步处理效率更高！

8，反向代理:使用nginx等负载均衡服务！

9，代码层:避免大量创建对象，避免阻塞IO，避免多层for循环，避免线程死锁，避免大量同步！

10，各种优化:包括jvm优化，表结构优化，sql优化，关键字段加索引（注意避免索引失效），连接池优化等等！

11，搜索引擎:sql有大量的like语句，有必要切换成solr等搜索引擎！

12，cdn:使用CDN技术将请求分发到最合适的主机上，避免网络传输的延迟！

13，使用batch:增删改能一次做的别分为两次，但要注意batch合理设计，防止数据丢失！

14，限流，削峰！

大型网站遇到的挑战，主要是大量的用户，高并发的访问，就算一个简单的增删查改的功能，如果面对的是百万、千万甚至亿级的用户，都是一件难度很大的事情。

数据从数据库到浏览器的过程：数据库->应用数据集->内存对象->动态页面->HTTP服务器->用户浏览器。 那么我们可以把高并发的设计分成几个层次：

前端是指，用户的请求还没有到服务前的环节。

系统架构大了，部署的服务器多了，很多事情不可能通过人工完成了，比如一个接口调用发生了错误，不可能人工登录到服务器上去查日志吧，所以这些东西也是必不可少的。

都是说个大概，后面有机会的话，会把每一项都展开详细说明。

希望我的回答能够帮助到你！

我们通过这些架构要素来衡量我们整体系统架构设计的优劣，来判断是否达到了我们的要求。

性能是大型网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题，也正因为性能问题几乎无处不在，在请求链路的任何一个环节，都是我们去做极致性能优化方案中的切入点。

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

网站的伸缩性是指不需要改变服务器的硬件设计，仅仅靠改变应用服务器的部署数量，就可以扩大或缩小服务器的处理能力。

网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目标。

互联网跟传统软件不同，它是开放的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

安全性架构，具体来说说就是保证数据的保密性、完整性、真实性、占有性。

要完全掌握大型网站的架构设计方案，或许你可以点击我头像，进入我的专栏"深入大型网站核心架构实战"。

这期专栏是笔者总结了当下这些互联网行业中相对成熟且经过大型网站检验的技术和方案，内容涵盖构建大型互联网系统服务所需的关键技术。

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

架构设计三大定律

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

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

二八定律 – 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.总结

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

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

---