Go 进阶训练营（二）（完整版）

Go 进阶训练营（二）

Go 架构实践 - 微服务(微服务可用性设计)

点点我download：Go 进阶训练营 提取马：d17c

目录

隔离 超时控制 过载保护 限流 降级 重试 负载均衡 最佳实践 References

隔离

隔离，本质上是对系统或资源进行分割，从而实现当系统发生故障时能限定传播范围和影响范围，即发生故障后只有出问题的服务不可用，保证其余服务仍然可用。 服务隔离：动静分离、读写分离 轻重隔离：核心、快慢、热点 物理隔离：线程、进程、集群、机房

隔离 - 服务隔离

动静隔离: 小到 CPU 的 cacheline false sharing、数据库 mysql 表设计中避免 bufferpool 频繁过时，隔离动静表，大到架构设计V（cmL46679910）中的图片、静态资源等缓存加速。本质上都体现的同样的思路，即加速/缓存访问变换频次小的。好比 CDN 场景中，将静态资源和动态 API 分离，也是体现了隔离的思路: 1）下降应用服务器负载，静态文件访问负载所有经过CDN。 2）对象存储存储费用最低。 3）海量存储空间，无需考虑存储架构升级。 4）静态CDN带宽加速，延迟低。

archive: 稿件表，存储稿件的名称、做者、分类、tag、状态等信息，表示稿件的基本信息。 在一个投稿流程中，一旦稿件建立改动的频率比较低。 archive_stat: 稿件统计表，表示稿件的播放、点赞、收藏、投币数量，比较高频的更新。 随着稿件获取流量，稿件被用户V（cmL46679910）所消费，各种计数信息更新比较频繁。 MySQL BufferPool 是用于缓存 DataPage 的，DataPage 能够理解为缓存了表的行，那么若是频繁更新 DataPage 不断会置换，会致使命中率降低的问题，因此咱们在表设计中，仍然能够沿用相似的思路，其主表基本更新，在上游 Cache 未命中，透穿到 MySQL，仍然有 BufferPool 的缓存。

读写分离：主从、Replicaset、CQRS。

隔离 - 轻重隔离

一、核心隔离 业务按照 Level 进行资源池划分(L0/L1/L2)。 1)核心/非核心的故障域的差别隔离(机器资源、依赖资源)。 2)多集群，经过冗余资源来提高吞吐和容灾能力。

二、快慢隔离 咱们能够把服务的吞吐想象为一个池，当忽然洪流进来时，池子须要必定时间才能排放完，这时候其余支流在池子里待的时间取决于前面的排放能力，耗时就会增高，对小请求产生影响。 日志传输体系的架构设计中，整个流都会投放到一个 kafka topic 中(早期设计目的: 更好的顺序IO)，流内会区分不一样的 logidV（cmL46679910），logid 会有不一样的 sink 端，它们以前会出现差速，好比 HDFS 抖动吞吐降低，ES 正常水位，全局数据就会总体反压。

按照各类纬度隔离：sink、部门、业务、logid、重要性(S/A/B/C)。 业务日志也属于某个 logid，日志等级就能够做为隔离通道。 三、热点隔离 何为热点？热点即常常访问的数据。不少时候咱们但愿统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行缓存。好比： 小表广播: 从 remotecache 提高为 localcache，app 定时更新，甚至可让运营平台支持广播刷新 localcache。atomic.Value

主动预热: 好比直播房间页高在线状况下bypass 监控主动防护。

隔离 - 物理隔离

线程隔离 主要经过线程池进行隔离，也是实现服务隔离的基础。把业务进行分类并交给不一样的线程池进行处理，当某个线程池处理一种业务请求发生问题时，V（cmL46679910）不会讲故障扩散和影响到其余线程池，保证服务可用。 对于 Go 来讲，全部 IO 都是 Nonblocking，且托管给了 Runtime，只会阻塞Goroutine，不阻塞 M，咱们只须要考虑 Goroutine 总量的控制，不须要线程模型语言的线程隔离。