极客大学架构师训练营第四周作业

问：一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。

相比传统互联网，大型互联网具有高并发、大流量、业务快速迭代、网络环境复杂、海量数据等特点，这就对系统有更高的要求，需要能高可用、高性能、高可扩展、更高的安全性、更灵活的CICD等等，下面将复杂的系统架构分层分模块，基于自己现有的认知对相关技术方案和手段进行总结：

高并发

• 负载均衡

大型系统并发请求量很大，而一台服务器的资源有上限，所以一般大型系统都是集群部署，并且会分布在不同的机房，此时请求具体分发到哪一台服务器，就需要负载均衡根据一定的算法进行分发，常见的负载均衡技术有：

• DNS负载：在网络链路上，请求发起的第一步是需要通过域名解析到实际的请求地址，而一般大型系统都是异地多机房集群部署，此时可以利用DNS解析，将域名解析到就近机房

• F5硬件负载：硬件负载具有比软件负载更强劲的性能和吞吐量，具有百万级的并发能力，但价格昂贵

• Nginx+OpenRestry软件负载：Nginx是一款高性能的网络服务器，能支持十万级的并发请求，能实现负载均衡，也能作为反向代理服务器，是一般公司的常规选择，OpenRestry是扩展后的Nginx，基于LUA扩展，能提供比原始Nginx能灵活和更高性能的服务，也能方便的实现降级和限流

• 应用网关负载：通常在请求达到应用层后，一般应用层还有会自己的网关层，比如consul，kong，spring-cloud-gateway等

• 缓存

对于高并发系统而言，缓存可谓是抗流量的银弹，请求链路上的各个环节都有使用缓存的可能性

• DNS缓存：DNS的作用是解析域名并返回域名对应的地址，对于大型系统而言，一般会在不同的城市建立自己的机房，可以将与用户最接近的地址缓存到DNS服务器，能更快返回用户解析结果，不需要到Root DNS查找

• 客户端缓存：对于一般的静态资源，可以开启客户端缓存，用户在再次请求时，可以不用发起网络请求

• 代理服务器缓存：比如Nginx，可以将一些静态资源直接放到Nginx，离用户更近，不需要到应用服务器

• CDN：内容分发网络，将静态资源放到运营商服务器，用户可以就近访问到

• 分布式缓存：一般是应用层缓存，通常基于Redis实现

• 页面静态化：对于大请求量，内容基本不变的内容，可以静态化，比如商品详情页，大部分内容大部分情况下都是固定的，可以将页面静态化，请求时可以直接返回静态页面。

• 服务无状态：大型系统，高并发的情况下，服务可能需要灵活可扩展，当瞬时请求过高时，要能支持方便的增加服务，此时需要服务是无状态的

• 消息队列：异步、流量削峰等

• RabbitMQ

• RocketMQ

• Kafka

高可用

• 限流和降级：面对复杂的网络环境和大并发量的请求，很可能存在恶意攻击或者服务不可用，此时可以利用限流过滤掉一部分请求，对于不重要的请求进行服务降级，只满足核心流量

• 令牌桶

• 漏桶

• 滑动时间窗口

• Guava

• 多线程与异步：资源利用最大化

• 隔离

• 线程隔离

• 进程隔离

• 资源隔离

• 机房隔离：异地多活

• 热点隔离

• 动静隔离

• 超时与重试

• 熔断：防止服务雪崩

分布式

• 服务化：服务按不同的维度，比如功能、模块、读写等进行拆分，将核心的和非核心的应用分离开，能更最大化资源利用率，更方便的实现扩展

• 分布式数据库

• 读写分离

• 主从

• 分库分表：mycat，sharding-jdbc

• NoSql

• Redis

• mongo

• 分布式事务

• XA协议

• TCC

• 基于消息队列

• 服务发现与服务注册

• zookeeper

• consul

• etcd

• nacos

• eureka

• 共识算法和分布式缓存

• paxos

• zab

• nwr

• 分布式缓存

• Redis

• Ecache

• Memcache

• 配置中心

• consule

• spring-cloud-config

• nacos

• apollo

• etcd

• zookeeper

• 链路监控与跟踪

• Dapper论文

• skywalking

• pinpoint

• 分布式日志

• ELK

• 应用监控

• Prometheus

• Grafna

• influx

• 分布式任务调度

• 分布式锁：zookeeper、redis

大数据和实时计算

• storm

• kafka

• flink

• Hbase

• Hadoop

• HDFS与OSS：分布式文件存储