读书笔记：交易型系统设计的一些原则

from 《亿级流量网站架构核心技术 – 跟开涛学搭建高可用高并发系统》

概述

一个好的设计要做到，解决现有的需求和问题，把控实现和进度风险，预测和规划未来，不要过度设计，从迭代中演进和完善。

在设计系统时，应多思考墨菲定律：

1、任何事情都没有表面看起来那么简单。 2、所有的事都会比你预计的时间长。 3、可能出错的事总会出错。

在系统划分时，也要思考康威定律：

1、系统架构是公司组织架构的反映。 2、应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/松耦合，减少沟通成本。 3、如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整。 4、在合适的时机进行系统拆分，不要一开始就把系统/服务拆的非常细，虽然闭环，但是维护成本高。

高并发原则

1、无状态。应用无状态，配置文件有状态。（可以用在我的毕设指导里） 你可以轻易修改配置文件，但是应用发布了，就是发布了。

2、拆分。在系统设计初期，是做一个大而全的系统，还是按功能模块拆分系统，这个需要根据环境进行权衡。 有很多维度可以考虑，比方说：系统维度、功能维度、读写维度、and so on。 我jio的吧，有资源就拆，不然就先憋着吧。

3、服务化（不知道怎么概括那段话，经验不足）

4、消息队列。基本概念就不说啦。使用消息队列时，还要注意处理生产消息失败，以及消息重复接收时的场景。对于不能容忍生产失败的业务场景来说，一定要做好后续的数据处理工作。对于消息重复的问题，特别是一些分布式消息队列，处于对性能和开销的考虑，在一些场景下会发生消息重复接收，需要在业务层面进行防重处理。

大流量缓冲：

扣减库存设计（正打算这样干）

订单交易系统

数据校对： 在使用了消息异步机制的场景下，可能存在消息的丢失，需要考虑进行数据校对和修正来保证数据的一致性和完整性。可以通过扫描原始表，通过对业务数据进行校对，有问题的要进行补偿，扫描周期根据实际场景进行定义。

5、数据异构与数据闭环

6、缓存银弹 浏览器缓存、APP客户端缓存、CDN缓存、接入层缓存、应用层缓存、分布式缓存

7、并发化

高可用原则

1、降级（在我的毕设后续版本迭代中会出现，不过之前不是很明朗具体要怎么做）。 对于高可用服务，很重要的一个设计就是降级开关。

2、限流（这个也知道要做，也知道要用什么做，但是目前也是不知道要怎么做，还没去研究）

1、对于恶意请求流量只访问到cache 2、对于穿透到后端应用的流量可以考虑使用 Nginx 的 limit 模块处理 3、对于恶意 IP 可以使用 nginx deny 进行屏蔽

不过要怎么区分恶意流量呢？是在一定的时间内请求过于频繁吗？或者是爬虫？或者二者都是，加上一些其他的未知的。 那就反过来看，只放过善意流量。

3、切流量 这个目前我会用 nginx 做故障服务器下线，切换备胎上线。

4、可回滚

业务设计原则

防重设计（流水号 + 滑窗）、幂等设计、流程可定义（模板方法模式）、状态与状态机（待付款、待发货、已发货、完成）（取消、退款）等，要考虑是否要使用状态机来驱动状态的变更和后续流程节点操作，尤其是当状态很多的时候。还要考虑并发下的状态修改问题。

文档和注释

在一个系统发展的一开始就应该有文档库（设计架构、设计思想、数据字典、业务流程、现有问题），业务代码和特殊需求都要有注释、

包括代码和人员都应该有备份。 代码备份就不用多说了。人员备份可以参考一下结对编程。既能提高效率，而且即使其中一名离职了也不会出现新人接收之后手忙脚乱事故频发的状况。