墨菲定律
1 任何事都没有表面看起来那么简单
2 所有的事都会比你预计的时间长
3 可能出错的事总会出错
4 如果你担心某种情况发生，那么它就更有可能发生
康威定律
1 系统架构是公司组织架构的反映
2 应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本
3 如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整
4 在适合时机进行系统拆分，不要一开始就把系统/服务拆得非常细，虽然闭环，但是每个人维护的系统多，维护成本高
高并发原则
1 无状态
如果设计的应用是无状态的，那么比较容易进行水平扩展。实际中可能是：应用无状态，配置文件有状态
2 拆分
系统维度：按照系统功能/业务拆分，比如商品系统，购物车，结算，订单系统等
功能维度：对一个系统进行功能再拆分，比如优惠券系统可以拆分为后台券创建系统，领券系统，用券系统等
读写维度：根据读写比例特征进行拆分，
AOP维度：根据访问特征，按照AOP进行拆分。比如商品详情页可以分为CDN，页面渲染系统，CDN就是一个AOP系统
模块维度：比如基础模块分库分表，数据库连接池等
3 服务化
进程内服务->单机远程服务->集群手动注册服务->自动注册和发现服务->服务的分组/隔离/路由->服务治理如限流/黑白名单
4 消息队列
解耦一些不需要同步调用的服务或订阅一些自己系统关心的变化。使用消息队列可以实现服务解耦，异步处理，流量削峰/缓冲
5 数据异构
实现数据的自我控制，当其他系统出问题时，不影响自己的系统
6 缓存银弹
浏览器端缓存：设置请求的过期时间，适合对实时性不太敏感的数据，不适合价格，库存等实时要求高的数据
app客户端缓存：
CDN缓存：
接入层缓存：在nginx搭建一层接入层
应用层缓存：使用tomcat时，使用堆内缓存/堆外缓存。local redis cache，在应用所在服务器部署一组redis，直接读取本机redis，redis间主从同步，这样没有网络消耗，性能最优
分布式缓存：数据量太大，单服务器存储不了，可以使用分片机制的redis集群
7 并发化
高可用原则
1 降级
降级开关。
开关集中化管理：推送开关到各个应用
可降级的多级读：降级为只读本地缓存，只读分布式缓存等
开关前置化：开关前置到nginx接入层
业务降级：同步改异步，优先处理高级别数据
2 限流
防止恶意请求流量，恶意攻击，流量超出系统峰值
恶意请求流量只访问到cache
使用nginx的limit模块
nginx的deny屏蔽
3 切流量
DNS：切换机房入口
HttpDNS：主要是APP场景下，在客户端分配好流量入口
LVS/HaProxy：切换故障的nginx接入层
NGINX：切换故障的应用层
4 可回滚
版本化。事务回滚，代码回滚，部署回滚，数据回滚，静态资源回滚
业务设计原则
1 防重设计
防重key，防重表
2 幂等设计
3 流程可定义
4 状态与状态机
5 后台系统操作可反馈
6 后台系统审批化
7 文档和注释
8 备份
