高可用架构

Posted 2023-04-02 林帆003

CAP理论

一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）

FMEA方法

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等

分析方法

• 给出初始的架构设计图。
• 假设架构中某个部件发生故障。

• 分析此故障对系统功能造成的影响。
• 根据分析结果，判断架构是否需要进行优化。

1. 功能点
2. 故障模式--故障点和故障形式

1. 故障影响
2. 严重程度

1. 故障原因
2. 故障概率

1. 风险程度
2. 已有措施

1. 规避措施
2. 解决措施

1. 后续规划

高可用存储架构

双机架构

主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 mysql、Redis、MongoDB 等。

主从复制

主机负责读写操作，从机只负责读操作，不负责写操作。

主主复制

主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作。

集群

数据集中集群

1 主多备、1 主多从

问题

主机如何将数据复制给备机；备机检测主机状态；主机故障后，决定新的主机（zab算法）

数据分散集群

数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。

问题

均衡性、容错性、可伸缩性

数据集中集群架构中，客户端只能将数据写到主机；数据分散集群架构中，客户端可以向任意服务器中读写数据。

一般来说，数据集中集群适合数据量不大，集群机器数量不多的场景。例如，ZooKeeper 集群，一般推荐 5 台机器左右，数据量是单台服务器就能够支撑；而数据分散集群，由于其良好的可伸缩性，适合业务数据量巨大、集群机器数量庞大的业务场景。例如，Hadoop 集群、HBase 集群，大规模的集群可以达到上百台甚至上千台服务器。

数据分区

考虑的问题：数据量、分区规则（位置，异地多活）、复制规则

复制规则

集中式、互备式、独立式

高可用架构

主备

主从

集群

对称集群

非对称集群

业务高可用的保障：异地多活

备份系统平常没有流量，如果直接上线可能触发平常测试不到的故障。
再实时的系统也会有数据延时，如果涉及到金融这种系统，仍然是不敢直接切换的。
系统运行过程中会有很多中间数据，缓存数据等。系统不经过预热直接把流量倒过来，大流量会直接把系统拖垮

三种不同类型的异地多活架构

同城异区

关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计，无须额外考虑。

跨域异地

关键在于数据不一致的情况下，业务不受影响或者影响很小，这从逻辑的角度上来说其实是矛盾的，架构设计的主要目的就是为了解决这个矛盾。

跨国异地

主要是面向不同地区用户提供业务，或者提供只读业务，对架构设计要求不高。

技巧

保证核心业务的异地多活

分析核心业务，用户关注的业务。

保证核心数据最终一致性

• 尽量减少异地多活机房的距离问题，搭建告诉网络。
• 尽量减少数据同步问题，只同步核心业务相关的数据。

• 保证最终一致性，不保证实时一致性。

采取多种手段同步数据

避免只使用存储系统的同步功能，可以将多种手段配合存储系统的同步来使用，甚至可以不采用存储系统的同步方案，改用自己的同步方案。

只保证绝大部分用户的异地多活

四个步骤

业务分级

访问量大的业务

核心业务

产生大量收入的业务

数据分类

数据量

唯一性

实时性

可丢失性

可恢复性

数据同步

存储系统同步

消息队列同步

重复生成

异常处理

问题发生时，避免少量数据异常导致整体业务不可用。

问题恢复后，将异常的数据进行修正。

对用户进行安抚，弥补用户损失。

接口级故障解决

优先保证核心业务和优先保证绝大部分用户

降级

熔断

限流

排队

架构高可用高并发系统的设计原则

通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨

参考技术A 通过学习《亿级流量网站架构核心技术》及《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.总结
先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。
本文作者为网易高级运维工程师