0°

系统架构设计入门扫盲

内容预览:
  • 3、调用关系不允许出现三角关系 原先的设计图中没有特别标明主从关系,...~
  • 4、要能从设计层面识别程序模块 必须明确的指导,哪个系统是一个什么样...~
  • 14、视频元计算不可分割,不用考虑分布式集群计算 15、日志必须是可以丢...~

作者:汉家松鼠cg

来源:CSDN博客


最近负责一个项目的系统架构设计,刚开始粗粗给了个草案。经过一次修订后带着草案稿去找了一下公司首席科学家——传说中的“老天”,促膝长谈一整天,虽然被批判得一无是处,但是我却觉得异常之爽,顿时觉得在系统架构设计上已经渐渐扫盲开始进入正轨。极度欢迎有理由的对我批判,越狗血淋头越过瘾。。(是不是有些犯贱了,哈哈)

结合项目实际情况,总结一下一些改进建议和以后值得注意的地方:

1、平台API先不用考虑


我原先第一版就在平台上考虑了公用API,但是实际上在第一版描述中,其用途不大,并且以后想扩展的话很简单。所以为了降低系统复杂度,不用考虑。


2、设计要更加细化,必须拍板必要的技术选型


系统设计绝不是对需求的再描述,作为系统架构师,必须刚开始就对关键的技术选型拍板。


3、调用关系不允许出现三角关系


原先的设计图中没有特别标明主从关系,于是导致了看似三角关系的出现。实际上应该标明调用方向,主动发起者是箭头的起始位置。


4、要能从设计层面识别程序模块


必须明确的指导,哪个系统是一个什么样的程序。(如命令行程序、系统服务程序、WEB服务程序?)


5、本系统不是分层系统,而是一个网络枢纽系统(星型)


分层系统一般对于底层是完全封闭的菜适用,星形系统不能描述为分层系统。


6、对业务的拆分放到业务层,任务系统必须业务无关


尽量拆分业务无关模块,业务相关的任务下达必须在业务层完成。


7、计算过程拆分后,中间计算过程不能直接主动的记录结果,而必须调度系统汇总。(事务,防崩溃)


中间任务模块要考虑事务的崩溃恢复。


8、计算系统和外部管理系统可以进一步抽象成计算单元


9、调度系统与业务的耦合应该使用数据库隔离


10、配置信息也要在架构设计体现


11、所有调用关系必须明确


12、参考状态 > 参考历史


13、所有系统尽量被动


这样可以降低系统耦合以及开发的复杂度。


14、视频元计算不可分割,不用考虑分布式集群计算


15、日志必须是可以丢弃的,不然就是业务


这句话经典啊。


16、计算节点自动升级从开始就可以设计


版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


-END- 系统架构设计入门扫盲

架构文摘

ArchDigest

架构知识丨大型网站丨大数据丨机器学习

系统架构设计入门扫盲

更多精彩文章,请点击下方:阅读原文

原文始发于微信公众号(架构文摘):系统架构设计入门扫盲

以上就是:系统架构设计入门扫盲 的全部内容。

本站部分内容来源于互联网和用户投稿,如有侵权请联系我们删除,谢谢。
Email:[email protected]


0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论