插话：系统设计是一个不断迭代的过程，在迭代过程中发现问题并修复问题，这是一个持续的过程，目前没有什么完美架构银弹，场景、时间不同，即使相同的需求系统设计也会不同。
但是如果设计系统前，能有一些好的基础系统设计能力，能够让你在未来更容易达到一个比较满意的目标
一个好的设计要做到，解决现有的需求和问题，把控实现和进度的风险，预测和规划未来，但不要过度设计，在迭代中演进和完善
12306型系统设计 - 只是一些原则，并不是规定，可自行根据自己的业务场景拆分和组合
- 高并发原则
- 无状态 - 可简单理解无共享资源
- 服务拆分
- 分布式服务化
- 消息队列
- 数据异构
- 缓存银弹
- 并发话
- 高可用原则
- 降级
- 限流
- 切流量
- 可回滚
- 无状态：可简单理解无共享资源，如果设计的应用是无状态的，那么应用比较容易进行水平扩展。像数据源这种就是有状态的，这时可通过配置文件或配置中心指定，方便应用水平扩展
- 服务拆分：一般刚开始用户量不大的时候，为了快速开发业务，基本所有的功能都是在一个系统中，当随着业务快速发展，用户量渐渐增多，系统越来越庞大，快速迭代就变得越来越不现实了，有时候为了开发一个小功能，可能会造成牵一发动全身，因此就需要进行服务拆分，一般拆分的考虑维度如下几种
- 系统维度：按照系统功能／业务拆分
- 功能维度：对一个系统进行功能再拆分。比如：抽奖系统可以拆分为后台创建奖品系统、奖品发放系统等
- 读写维度：根据读写比例拆分。比如商品系统，可以拆分成商品读服务，商品写服务，不同的服务设计不同
- AOP维度：根据访问特征，按照AOP进行拆分。比如。商品详情页可以分为CDN、页面渲染系统
- 模块维度：按照基础或者代码维护特征进行拆分。代码结构一般按照三层架构（Web、Service、DAO）进行拆分
- 分布式服务化：
- 消息队列：使用消息队列可以实现服务解耦、异步处理、流量削峰／缓冲等
- 数据异构：
- 数据异构：订单分库分表使用订单ID做分片策略，这时有通过用户ID进行查询，每次都要对所有表进行查询并聚合数据，效率太低，可通过数据异构解决，耦合一份数据使用用户ID做分片策略，简单就是用数据耦合的方式解决该问题
- 数据闭环：当一个页面需要查询10几个接口才能完整的显示，可以通过将这10几个接口的数据聚合起来存储，这样前端只需要调用一次即可完成展示
- 缓存银弹：
- 浏览器端缓存
- APP客户端缓存
- CDN缓存
- 接入层缓存
- 应用层缓存
- 分布式缓存
- 并发化：比如一个接口中需要调用很多个接口，尽量将这些接口并行化，而不是串行调用
- 降级：降级思路如下：
- 开关集中化管理
- 可降级的多级读服务：比如服务抵用降级只读本地缓存、只读分布式缓存、只读默认降级数据
- 开关前置化：比如可以在前端请求时就消减流量
- 业务降级：保障核心接口，将一些非核心接口直接关闭或者不处理
- 限流：限流的目的是防止恶意请求流量、恶意攻击、或者防止流量超出系统的峰值。可参考如下思路-越早限流越好
- 恶意请求的流量只访问到cache
- 对于穿透到后端的应用流量可以考虑使用一些 limit 的技术
- 对于恶意IP可使用nginx 进行屏蔽
- 切流量：
- DNS
- HttpDNS
- LVS/HaProxy
- Nginx
- 可回滚:当程序或者数据出现问题时，如果有版本化机制，那么就可以通过回滚恢复到最近一个正确的版本，比如事物回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制可保证系统某些场景下的高可用
设计系统时，应多思考墨菲定律
- 任何事都没有表面看起来那么简单
- 所有的事都会比你预计的要长
- 可能出错的事总会出错
- 如果你担心某种情况会发生，那么它就更有可能发生
系统划分时，应多思考康威定律
- 系统架构是公司组织架构的反映
- 应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本
- 如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整
- 在合适时机进行系统拆分，不要一开始就把系统／服务拆分的非常细，虽然闭环，但是每个人维护的系统多，维护成本高
