谈系统骨架的建立——公司第四次交流会内容

目录

宏观上的“系统架构”

  • 系统主要功能(需求分析)
  • 确定系统最终使用场合
  • 系统划分模块
  • 各模块间怎样协作
  • 每个模块技术模式(C/S(或单机)、B/S、移动app)
  • 每个模块采用什么技术开发
  • 出系统架构图、相关文档
  • 系统框架搭建(编码)、项目组成员培训(指导)
系统架构图(举例:微信)
 
微观上的“系统设计”
  • 系统运行的持续性(动力)
  • 系统处理数据的重复性
  • 系统的可扩展性(=>框架)
  • 系统的容错性
  • 系统的通用性(=>框架)
生产者-消费者模式 设计图(举例)
宏观架构与微观设计的区别

前者:

  • 站得高看得远,将重点放在整个系统组成上。几乎不涉及到“编码”;
  • 架构者需要熟悉各种技术,了解各种技术优劣以及适用场合;
  • 架构者需要丰富的项目经验。

后者:

  • 注重代码实现,侧重系统内部实现原理;
  • 设计者需要丰富的编码经验;
  • 设计者与if/else/while等打交道。
孰轻孰重?
三种线程
泵的作用
代码中泵的作用
常见泵结构(1)——Windows消息处理(部分)
 
常见泵结构(二)——Windows消息(完整)
常见泵结构(三)——Socket数据接收
常见泵结构(四)——Web Server(同步)
常见泵结构(五)——Web Server(异步)
串行处理数据的泵
并行处理数据的泵
“泵”对系统的意义
什么是框架?

当你为了解决某个具体问题而设计一个系统时,如果做到了:

  • 通用性好。不过分依赖其他模块,不限制处理特定业务;
  • 容错性高。内部包含一套专门异常处理机制;
  • 扩展性强。方便增加新的功能;
  • 提供一套专门类库。

这时候,就可以把该系统当作一个框架。它可以用来处理某一类问题。

框架的特点
  • 动力性
  • 持续性
  • 通用性强
  • 可扩展性高
  • 容错性好

理论上,任何一个框架不做任何改变,直接编译即可运行。

框架的作用(一)

框架的作用(二)

“机场资源调度模拟仿真系统”设计草图

几个问题

  • 整个系统怎样维持一个“持续运转“的状态?
  • 服务端怎样能够持续处理客户端的输入?
  • 怎样维持地图中各元素的状态?
  • 系统时间怎样统一?
  • 怎样维护训练脚本状态?
问题答案(一)
问题答案(二)
微观上看“机场系统”
PTT下载
 
(以上内容为公司第四次交流会内容)
posted @ 2015-05-25 18:14 周见智 阅读(...) 评论(...) 编辑 收藏