项目架构一些注意点

考虑系统的

稳定性

一、微服务的稳定性

1、如何解决那些不稳定的因素/问题？也是常说的如何容错。

2、一个系统的高可用取决于它本身和其强依赖的组件的高可用

3、消除单点 保活机制 健康检查

注册中心如何保障稳定性

注册中心集群

微服务本身对注册信息的本地持久化

注册机制：关注下线/摘除的原因

网络抖动-->注册中心的保护机制，增量更新-->防止网络风暴

服务消费者如何保障稳定性

#### 超时机制

#### 容错机制    FailTry/FailOver/FailFast

#### 熔断   给予服务提供者一定的恢复时间，等服务提供者恢复正常后再发起调用。这种保护机制大大降低了链式异常引起的服务雪崩的可能性

#### 隔离    隔离资源

#### 降级

服务提供者如何保障稳定性

限流

重启与回滚 服务由于Bug不能提供服务，要求消费者具备容错措施：熔断/降级，在运维上具备快速回滚到前一个版本的能力。 为了复盘问题，要尽力保留现场的上下文/数据，主要来自日志的收集（jvm GC/jstack,业务log ）

二、功能稳定

1. 良好的代码设计：可扩展性高，不会因为一个需求导致大面积的重构

2. 测试用例覆盖率：特殊用例

3. 上线
4. 监控

三、性能稳定

限流

降级

熔断

不稳定的问题

### DB层

#### 死锁问题：概率小

#### 慢SQL查询 

1.没有索引/错误地使用索引

2.并发高：访问量大/存在共享热表

3.复杂查询：使用搜索替代

4.数据爆表：数据量增速快 观察统计日/月/年增长量

#### 解决方案

```
并发高如何解决？
时效要求不高的后台定时任务：1. 按时间维度隔离 2.数量分片：任务分发
实时性高的交互：缓存/读写分离

数据爆表如何解决？
分库分表
冷热数据归档

### 系统层面

时延或高或低：随着流量大小变化

负载不均衡

热点数据：访问倾斜

```
接口：梳理核心链路，非核心调用：同步改异步
系统：拆分业务，各业务模块高内聚，从而达成隔离

 

 

运维稳定

可扩展性

可以处理更大/更多规模的业务

功能扩展

应用扩展

硬件扩展