[case3]聊聊系统设计中的trade-off

codecraft

本文主要小结一下系统设计当中的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

阅读 3.4k

code-craft
spring boot , docker and so on 欢迎关注微信公众号: geek_luandun

当一个代码的工匠回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧,这样,当他老的时候,可以很...

11.6k 声望
1.9k 粉丝
0 条评论

当一个代码的工匠回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧,这样,当他老的时候,可以很...

11.6k 声望
1.9k 粉丝
文章目录
宣传栏