最近负责一个项目的系统架构设计，刚开始粗粗给了个草案。经过一次修订后带着草案稿去找了一下公司首席科学家——传说中的“老天”，促膝长谈一整天，虽然被批判得一无是处，但是我却觉得异常之爽，顿时觉得在系统架构设计上已经渐渐扫盲开始进入正轨。极度欢迎有理由的对我批判，越狗血淋头越过瘾。。（是不是有些犯贱了，哈哈）
结合项目实际情况，总结一下一些改进建议和以后值得注意的地方：
1、平台API先不用考虑
我原先第一版就在平台上考虑了公用API，但是实际上在第一版描述中，其用途不大，并且以后想扩展的话很简单。所以为了降低系统复杂度，不用考虑。
2、设计要更加细化，必须拍板必要的技术选型
系统设计绝不是对需求的再描述，作为系统架构师，必须刚开始就对关键的技术选型拍板。
3、调用关系不允许出现三角关系
原先的设计图中没有特别标明主从关系，于是导致了看似三角关系的出现。实际上应该标明调用方向，主动发起者是箭头的起始位置。
4、要能从设计层面识别程序模块
必须明确的指导，哪个系统是一个什么样的程序。（如命令行程序、系统服务程序、WEB服务程序？）
5、本系统不是分层系统，而是一个网络枢纽系统（星型）
分层系统一般对于底层是完全封闭的菜适用，星形系统不能描述为分层系统。
6、对业务的拆分放到业务层，任务系统必须业务无关
尽量拆分业务无关模块，业务相关的任务下达必须在业务层完成。
7、计算过程拆分后，中间计算过程不能直接主动的记录结果，而必须调度系统汇总。（事务，防崩溃）
中间任务模块要考虑事务的崩溃恢复。
8、计算系统和外部管理系统可以进一步抽象成计算单元
9、调度系统与业务的耦合应该使用数据库隔离
10、配置信息也要在架构设计体现
11、所有调用关系必须明确
12、参考状态 > 参考历史
13、所有系统尽量被动
这样可以降低系统耦合以及开发的复杂度。
14、视频元计算不可分割，不用考虑分布式集群计算
15、日志必须是可以丢弃的，不然就是业务
这句话经典啊。
16、计算节点自动升级从开始就可以设计
了解更多技术，关注下方公众号
网友评论