序
本文主要小结一下系统设计当中的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，其他的还有待后续进一步提炼。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。