架构的设计原则随笔

本文会分N次更新

设计一个优秀的大型系统，需要遵循以下原则

高并发原则

1）服务拆分，也就是微服务
首先必须得按照业务功能维度拆分，不然也太另类了
其次，可在功能维度拆分完毕的基础上，再按照读写维度拆分
2）集群
3）消息队列
4）数据异构
5）缓存
6）代码层次的并发（JUC）
上述6点总结就是如下

高可用

• 1降级：降级是一个“退而求其次”的策略，当因为某种原因不能正确执行正常的需求流程的时候，不得不进行B计划
  示例1.当实时查询第三方数据（或其他服务）有问题，则可降级为从缓存中读取数据
  示例2.有些业务非常核心，例如订单业务，并且这种业务如果能保证数据的最终一致性，那么也是可以的，所以对于这种业 务，可以将同步调用降级为异步调用，最终走定时任务做数据补偿
  当然，前面也说了，降级是一个“退而求其次”的策略，它要求我们的业务需求至少有一个保底（兜底）数据或策略才行，例如管理员修改某个用户权限这种需求，这种简单的需求降级的意义不大，且成本又高，还不如提示用户“系统繁忙”
• 2限流：限流就是对频繁的请求加以判断，如果是恶意请求，那么采用屏蔽或者只允许访问到缓存的方式，这部分代码通常我们很少自己去实现，可以采用nginx的limit模块或者各种网关自带的功能模块即可
• 3切流量
• 4回滚

业务需求设计原则

防重
幂等
流程可定义
状态记录
文档注释

上述3点原则总结
暂未完成