序

本文主要小结一下系统设计当中的trade-off

trade-off

trade-off翻译过来大致是折中的意思，也就是说系统设计通常牵扯的点比较多，有的设计方案这个方面比较好，但是又有其他缺点，没有十全十美的方案，只是在特定的上下文，特定的约束条件下，权衡选取比较合适的方案。但是一旦这个上下文或约束条件随着业务变化，基础设施变化等等，原来的折中的方案可能也就不合适了。于是就需要重新架构。

常见的trade-off

• 缓存

以空间换取时间，牺牲内存来加快读取速度，但同时也带来一致性维护问题

• 数据库三范式

以时间换取空间，数据库的范式设计，有些表仅仅有主键，但是业务查询经常需要带上姓名等其他字段，这个时候就得在展示层去根据用户id再去获取用户姓名去组装数据，在持久层保持了一致性，但是对于展示层来说得额外再去关联表或查询姓名，牺牲了时间。

• CAP

比如noSQL大多是选择以AP为主，牺牲C

• 微服务

将单体架构拆分为微服务，则在部署成本上可能比单体架构要多一些，但是带来的是服务的拆分隔离之后的相对稳定性和可维护性，但是同时也可能带来诸多一致性问题。

• 高级语言vs汇编语言

高级语言比汇编语言更容易让人掌握，但是最后还是要转为机器懂的0和1，相比汇编是牺牲了性能，但是带来的是可维护性。

• bean vs map

java bean比map的好处是里头的属性类型确定，不像map是个黑盒，每次用数据都得根据key去换取，然后强转，无形之中就给编码带来很多坑，提醒了易错性，但是map的好处是通用；bean就是相对不如map那么万能，但是由于每个属性确定，用的时候直接调用getter去获取，也不用类型强转，有多少属性也很明了，提升了编程的可靠性，但是坏处就是不通用。

小结

本文只是粗略列举了一些trade-off，其他的还有待后续进一步提炼。

doc

• Software Design Tradeoff Factors