考虑系统的
稳定性
一、微服务的稳定性
1、如何解决那些不稳定的因素/问题?也是常说的如何容错。
2、一个系统的高可用取决于它本身和其强依赖的组件的高可用
3、消除单点 保活机制 健康检查
注册中心如何保障稳定性
注册中心集群
微服务本身对注册信息的本地持久化 注册机制:关注下线/摘除的原因 网络抖动-->注册中心的保护机制,增量更新-->防止网络风暴 服务消费者如何保障稳定性
#### 超时机制
#### 容错机制 FailTry/FailOver/FailFast #### 熔断 给予服务提供者一定的恢复时间,等服务提供者恢复正常后再发起调用。这种保护机制大大降低了链式异常引起的服务雪崩的可能性 #### 隔离 隔离资源 #### 降级 服务提供者如何保障稳定性
限流 重启与回滚
服务由于Bug不能提供服务,要求消费者具备容错措施:熔断/降级,在运维上具备快速回滚到前一个版本的能力。
为了复盘问题,要尽力保留现场的上下文/数据,主要来自日志的收集(jvm GC/jstack,业务log )
二、功能稳定
1. 良好的代码设计:可扩展性高,不会因为一个需求导致大面积的重构
2. 测试用例覆盖率:特殊用例
3. 上线
4. 监控
三、性能稳定
限流
降级
熔断
不稳定的问题
### DB层
#### 死锁问题:概率小
#### 慢SQL查询
1.没有索引/错误地使用索引
2.并发高:访问量大/存在共享热表
3.复杂查询:使用搜索替代
4.数据爆表:数据量增速快 观察统计日/月/年增长量
#### 解决方案
```
并发高如何解决?
时效要求不高的后台定时任务:1. 按时间维度隔离 2.数量分片:任务分发
实时性高的交互:缓存/读写分离数据爆表如何解决?
分库分表
冷热数据归档
### 系统层面
时延或高或低:随着流量大小变化
负载不均衡
热点数据:访问倾斜
```
接口:梳理核心链路,非核心调用:同步改异步
系统:拆分业务,各业务模块高内聚,从而达成隔离文章来源地址https://www.toymoban.com/news/detail-430298.html
运维稳定
可扩展性
可以处理更大/更多规模的业务
功能扩展
应用扩展
硬件扩展文章来源:https://www.toymoban.com/news/detail-430298.html
到了这里,关于项目架构一些注意点的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!