 |
1
Ketteiron 2 天前
除了工作，应该没地方能学到。开源项目的大型、复杂与现实中的不是一回事。电商类的项目可以参考下，应该算比较接近的，java 那堆 xxx-mall 的培训班刷 star 垃圾项目可以看看，与现实中的大型不可回收垃圾项目一模一样。
|
 |
2
xuanbg 1 天前
大型系统或者复杂系统其实也没什么神秘的，一般都是臭不可闻的屎山。
要想设计好大型系统，就必须要做好这几点： 1 、抽象。要尽可能的将普适的、共性的功能抽取出来进行能力化。红极一时的中台就是具体的体现了。中台为啥最后变成人人喊打的落水狗，倒不是中台做错了，而是中台做多了。做了自己不该做的功能，结果就变成两面不讨好，人人厌弃了。 2 、分治。一定要将业务梳理清楚，不能多个业务纠缠在一起。微服务就是这个需求的最佳实践。但微服务有比较高的门槛，大多数程序员不懂业务不懂自动化运维玩不转。 所以，要想学习大型系统的设计，不但要有洞见本质的能力，还要精通业务，还需要对自动化运维有一定的了解。 |
 |
3
mascteen 1 天前
可以看下代码大全
|
 |
4
Xheldon 1 天前
多了解下你所在的公司的业务，然后尝试想象如果是你设计会怎么设计，然后看公司代码跟你想象的有什么出入就行了。从业务中学，大型系统的设计是基于业务复杂度来的，如果你没有使用的场景，学了也会忘记。
|
 |
5
wangguyu 1 天前
《 DDIA 》
|
 |
6
dododada 1 天前  3
去看下开源的 IM 系统研究研究，这玩意儿一上来就是大型的，没有小型的说法，小型玩不转，当然底层的内容看起来不太多，但是周边有些庞大，运维也很复杂
|
 |
7
andyskaura 1 天前
我的个人经验是，严格按照第三范式把数据库关系图画好，业务开发围绕数据库来。
|
 |
8
isno 1 天前
以“解决当前的问题”的方式演进。比如：
- 要解决单体服务的复杂性，那就进行拆分，这就演变成了微服务架构 - 要解决大量微服务的部署问题，使用容器化 - 要解决容器的编排问题，使用 Kubernetes ，变成云原生架构 - 要解决海量存储、复杂软件关联.. 等等，使用 xx 等等 推荐我刚出炉的新书，《深入高可用系统原理与设计》，名字有高可用，但高可用可从来不是”不宕机“，而是： - 成本可用 —— 资源成本的平衡、资源弹性调度、海量规模下日志的存储与分析，以及技术复杂度的控制； - 敏捷可用 —— 借助现代云技术，实现系统的快速迭代与演进； - 规模可用 —— 软件规模日益庞大，但依托不可变基础设施、容器与容器编排等云原生技术，依然能够保持可控。 整部书的内容，应该是你所希望的”大型系统设计指南“。 |
|
9
isno 1 天前
|
Select Language