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