不管我一生中取得了多大的成功,其主要原因都不是我知道多少事情,而是我知道在无知的情况下自己应该怎么做。我一生中学到的最重要的东西是一种以原则为基础的生活方式,是它帮助我发现真相是什么,并据此如何行动。
——瑞·达利欧(Ray Dalio)
原则上只允许较高层次依赖较低层次,不允许反向依赖。
-
系统依赖转换为数据依赖;
-
接口依赖,通过底层定义SPI,业务层实现,这种做法其实是不得已为之,同时,我们在设计过程中还是尽可能避免走这条路;
-
通过事件机制解耦依赖。
系统设计时,尽量减少系统之间的依赖,同时需要避免系统之间出现循环调用。
较高层次不允许之间跨层调用底层。
架构设计应该使得系统中数据的冗余最小。
-
数据存储安全:敏感数据加密、日志输出脱敏。
-
数据传输安全:包括加密、传输通道规范,最少字段传输(够用原则),尤其是我们金融部门,需要将数据输出给到外部第三方机构情况比较多,这块上面会控制比较严格。
-
数据输出展示:前端展示需要防止水平越权,另外,前端的展示可以埋点和方便数据采集。
-
可核对和可监控:上下游系统的数据模型核对关联关系简单、稳定(具备通用性,和产品无关)。
-
可熔断:对关键资损链路需要做到可熔断。
-
悲观锁:代码编码规范——一锁二判三更新。
-
乐观锁:必须在事务内更新。
避免流量倾斜,导致单台机器/单个数据表/数据库集中读写。
分表分库规则在设计时需要考虑数据分布均匀,避免单库或者单表数据倾斜。
可压测:对性能要求高的链路,需要做到可以压测。
-
优先使用编程式事务:为了更好的控制事务,一般要求使用编程式事务,避免潜在的跨事务问题。
-
事务更新需要保证顺序一致性:强一致要求还是最终一致,强一致是否会涉及到跨库,事务操作时需要相同记录的更新顺序保证一致。
-
事务中不进行远程调用。
-
区分系统调用错误和业务失败:远程调用失败,不代表下游系统没有接收请求,更不能做为业务失败依据,需要严格区分系统调用错误和业务失败。
-
可重试:任何一行代码执行时都有可能因系统重启而中断,所以需要支持可重试。
-
异步处理必须增加核对:最终一致性离不开恢复重试策略,也需要有系统间数据核对用于及时发现数据不一致,同时在核对时需要增加处理时效的监控,及时发现长时间未处理成功的数据。
API设计时需要考虑防范水平越权。
调用方必须提供用于幂等控制的参数,为了控制幂等,同一个请求的幂等参数不变。
API升级和调整,需要兼容老的版本。
0 条评论