概述
在中国的互联网行业最大的特点就是访问量大，我们在做项目时要考虑如何面对高并发，当一台服务器不能满足需求时，我们要考虑搭建多台服务器同时对外提供服务，这时候我们就要用到反向代理和负载均衡的技术，随着项目的扩展，对后端的数据库也有很大压力，我们需要用到一些缓存的技术来提高我们响应的速度，减轻对数据库的压力。还有一些场景下，我们需要优化用户体验，提高服务的稳定性或者减少模块之间的依赖，我们会采用异步化的方案如消息队列来架构我们的项目。
高可用(High Availability)
- 高可用(HA)就是抵御一些不确定的因素(不稳定性), 保证我们的系统在7*24小时可以提供正常的服务
- 不稳定性包括：
- 一些自然灾害：台风、地震、洪水
- 战争、恐怖袭击
- 通讯线路异常
- 服务器硬盘、内存出错
- 程序代码问题
- 黑客攻击, 数据库被删除等
- 如果系统一直可以提供服务, 那么我们就说我们系统的可用性是100
- 如果系统每运行100个时间单位种，有一个时间单位内无法提供服务，那么我们就说系统可用性是99%
- 很多企业的高可用目标是：99.99% (系统的全年停机时间不超过8个小时)
- 高可用是系统架构设计中必须考虑的因素之一，目标是减少系统不能提供服务的时间
- 为了保证高可用，系统架构设计的一个准则就是冗余
- 比如：汽车的备胎、动车有2个驾驶员等
- 在服务器方面如果可以做到多机器热备份, 也就是
双机热备、多机热备一台出现问题可以切换到另一台上就保证了高可用 - 对于机房而言也需要有异地的热备份,
异地双活、异地多活都是通过冗余来提高系统的高可用 - 冗余可以解决的问题大部分都是意外产生的问题
- 如果是代码问题或者版本升级产生的问题，冗余就无法解决了
- 第二个准则是灰度发布与回滚
- 灰度发布指让一小部分用户先体验新功能, 通过监控来对比观察, 没有异常就增加功能, 直到最后全量发布
- 这种方式在项目上线时复杂度就增加了, 但可以保证大部分用户高可用
- 第三个准则是限流
- 应对突然增长的访问量，超过了系统承载能力时, 我们可以让用户排队，如12306抢票时的排队机制
- 第四个准则是降级
- 为了保证核心业务，将一些不重要的功能暂停，让服务器资源集中处理核心业务
高并发(High Concurrency)
- 高并发(HC)是指通过对系统的设计保证能够同时、并行的处理很多请求, 保证单位时间内为更多人提供服务
- 并发用户量是指同时能够承载正常使用系统的用户数量
- 例如一些直播系统的在线量，一定程度上反映了系统的并发数
- 高并发设计的核心准则是扩展
- 从硬件层面上可以升级CPU、内存，以提升速度，这种扩展叫
垂直扩展, 还可以通过添加机器数量来提高响应能力，这种扩展叫水平扩展 - 在项目早期预算充足，我们优先考虑增加单机的性能
- 如果随着业务的增加, 单机很快就会有瓶颈, 我们要考虑水平扩展，这是终极方案
- 水平扩展对系统架构设计是有要求的, 需要遵循系统设计原则
- 从硬件层面上可以升级CPU、内存，以提升速度，这种扩展叫
- 水平扩展系统设计原则
- 无状态设计
- 先说什么是有状态：如果我们在开发项目时使用服务器自带的session, 这种情况下横向扩容时还要考虑session在不同服务器上的同步问题, 这时我们的系统是有状态的
- 无状态则是指避免这样的情况发生
- 服务拆分
- 我们不要把所有服务都集中在一起, 我们要适当的将服务拆分开来, 就是现在流行的
微服务 - 用于减少模块之间的干扰, 降低耦合度, 也会让水平扩展变得更容易些
- 我们不要把所有服务都集中在一起, 我们要适当的将服务拆分开来, 就是现在流行的
- 缓存
- 使用缓存减少对后端数据库的请求, 以提升响应速度
- 响应快了，系统承载的并发也就高了
- 队列
- 通过一些异步化的方式来提升系统的并发能力
- 无状态设计
经典的架构设计
-
在第一层是项目入口
- 包括PC、移动端的请求
- 所有的请求被接入到了入口层
-
第二层是入口层
- 第一层所有的请求都会被接入
- 需要做负载均衡，将前端请求均衡的分配到后端服务上面
- 比如分配到后端的http server上，而http server有可能是很多服务器组成(集群)
- 通过反向代理将流量平均分配到每一台服务器上来实现负载均衡技术
-
第三层是后端服务器层
- 服务器处理请求和响应
- 在上面我们说的水平扩展(横向扩容), 主要是扩展http-server这一块
- 主要是配合第二层和第四层实现
-
第四层主要是缓存和异步层
- 缓存在应用服务器和数据库之间
- 在取数据的时候，我们会把数据放一份在缓存中，再响应出去
- 当第二次再响应的时候，我们可直接从缓存中取数据，不会再次请求数据库从而提高性能
- 对于可以异步化处理的内容如：用户注册后的邮件通知, 短信通知等, 可以考虑放到消息队列中来, 慢慢处理
- 通过队列将同步的任务转变为异步的任务, 再借助第三层的worker服务器从MQ中取任务在后台并行的处理
- 通过异步队列只需要响应一些核心任务之后就可以返回了
-
第五层是存储层
- 主要是一些常用的关系型数据库如: mysql等
- 还有一些KV类型的存储系统如: redis、mongodb
