服务治理topic

寻找一个技术Topic时的小感想：在最初《企业IT架构转型之道》时，觉得是泛泛而谈的书籍，没有具体详细的技术介绍；可是当需要去做一个服务治理或者微服务架构的topic，会发现就是需要这种简洁全面的书籍，去告诉我们一个topic需要哪些功能模块，如配置中心、流控中心等，因为这个时候我们关注的时候有哪些功能，需要的是一个方向。(书籍的作用要分清：技术细节还是技术方向topic)。
 
1、服务治理最终目标是什么？服务健康、稳定。
2、服务治理（服务架构部门职责）包含   微服务架构（服务注册、服务发现、网关等）、容灾部署、治理服务中间件建设（流量治理、报警/监控等）、业务中间件（redis、MQ、mysql、分库分表等） 和 服务稳定性保障。  
3、服务治理和稳定性关系？服务治理和包含稳定性建设。或者可以理解为稳定性是目标，服务治理是手段，通过服务治理实现稳定性
 

稳定性指标

1、SLA： N个9 

为了提升稳定性指标，需要

screenshot-20220721-135332

2、故障数。

1 微服务架构topic

1、✅注册中心 Eureka
2、✅网关 zuul。
3、RPC。Feigen/Thrift
4、开关中心。
交易开关、产品上下架等业务开关。
5、领域驱动的三层架构
6、统一技术栈和版本。
6、日志规范
7、数据库
数据库连接池配置、读写分离、慢查询、大事务、读写超时设置。
8、下游服务超时、重试配置。
9、 服务依赖梳理
避免循环依赖
10、监控报警建设
开始发现和定位问题。
11 、业务指标大盘

2 容灾部署

1、业务多机房部署
2、中间件容灾部署：多机房、主备。 （数据库/MQ/Redis中间服务）

3 治理服务中间件

1、✅指标建设和监控报警：（指南针）
（1）指标收集：确定指标有哪些。比如服务的有api指标（流量、耗时、错误数）、还有一些中间件的指标
（2）指标聚合
（3）指标存储。influxdb
（4）展示。Grafanan
。自己实现的指南针系统：包括了如IP占比、集群占比、topN等
（5）监控报警
报警监控系统搭建
（6）服务健康度大盘。
定义健康度模型。
2、报警归因平台
报警统计、报警分析归因、自动故障恢复（切主）
3、✅流控中心（流量调度、限流和熔断降级Sentinel） —流量治理
流量调度：机房路由（同机房自动路由，实现机房隔离；指定机房路由，实现机房容灾）、按比重路由。
限流：单机、集群。
熔断、超时和重试。
5、Trace。(Zipkin，Pinpoint，SkyWalking)—日志治理
分析耗时链路、查看那个服务引起问题。
6、配置中心 Apollo  —配置治理
7、日志检索( elasticseach)  — 日志治理
8、API管理 swagger  —API治理
9、分布式任务调度 xxl-job  — 任务治理
10、✅对账平台（实时对账和离线对账，保证链路数据一致性）  —数据一致性治理
11、全链路压测平台。
12、 容量管理平台。–容量治理
扩缩缩容；节约成本和应急扩容；当前服务容量信息；
13、故障演练平台。阿里的混沌工程ChaosBlade。
14 、预案平台。快速执行预案，降低止损时间。
 

4 业务中间件

1、分布式数据库组件 hsb、sharding-sphere（分库分表+分布式事务）、mycat
2、缓存 redis、
3、 消息kafka

5 服务稳定性保障

前置：压测和容量预估
稳定性四大法宝：扩容、缓存、限流、降级（业务兜底+开关、熔断）。

5.1 容灾怎么做

经常被问到服务容灾怎么做的呢或者做了什么容灾措施？或者服务稳定性怎么做是同一个问题？
容灾就是解决故障，一个故障 包括故障预防、故障发现、故障定位、故障处理-止损、故障复盘。（事前、事中、事后）
2222

5.2 监控报警

快速发现和定位问题。
1、指标收集
2、监控大盘
mysql: 连接数、qps、耗时、错误类型
下游服务粒度指标： qps、耗时、错误qps（快速定位是哪个服务问题）
下游接口粒度指标：qps、耗时、错误码
服务监控： 错误日志、pqs、耗时、命中限流监控（tag为接口名称）
接口接口： pqs、耗时、错误码

5.3 全链路压测和容量预估

1、 压测服务当前最大承载能力，进行后续容量扩缩容和限流

2、发现整个系统瓶颈在哪里，如何优化。

5.4 容灾预案（限流、降级、切流）

1、限流
单机限流、集群限流。
2、降级（业务兜底+开关、熔断、中间件）–下游服务容灾（业务系统和中间件）
（1）下游业务容灾降级：业务兜底
下游服务降级，出问题时的场景，通常借助开关降级。比如feed推荐挂了，那么可以使用默认的推荐内容；重大活动场景中前端的降级页面。
72444984
（2）中间件容灾降级预案（REDIS、数据库、MQ等）：通过主备、异构存储等措施。
  • 数据库切主库
  • 服务切机房
  • redis宕机
（3）熔断降级和超时&重试。
  • 下游业务：通过流量治理平台进行配置。
  • 中间级。比如mysql、redis、my都会初始化时配置连接超时时间。
3、切流 (主备切换、机房切换-机房故障)
4、预案演练(主备切换、机房切换、业务兜底) === 混沌工程。故障演练平台。
 

6 一次活动稳定保障

① 活动链路流量梳理（流量预估和流量漏斗）-》 ② 资源预估和申请 -》 ③ 业务服务稳定性保证：扩容、 缓存、限流、降级（熔断、兜底策略） -》 ④ 全链路压测 -》 ⑤ 容灾预案和演练 -》⑥ 监控报警
  •  兜底策略包括服务端和客户端。

参考

聊聊服务稳定性保障这些事 https://www.infoq.cn/article/69TYjy_v9u4FxXNUk2gK

Related Posts:

分类&标签