WinNet平台第一个框架设计的背景，是基于一个大项目。
该项目总体约两三千万，其中WinNet软件两三百万。WinNet软件的需求，可以看成上一篇“设计文档”中一个子集。软件的性能要求包括：高稳定性、高扩展性和低延迟。
为什么要讨论到性能要求呢。因为我个人认为，框架第一关注的是需求，因此有了上一篇的设计文档；第二关注的应该是性能，所以本篇会着重介绍性能要求；其次才是功能实现、成员技能等方面。
很多项目都会以稳定作为第一优先级的性能。高稳定性，要求软件bug少，测试充分，可用性高。为此，做了一系列工作，后面会有叙述。
高扩展性，是因为项目初期需求对接并不是我去的，招投标文件里的要求和用户实际关注的功能并不相符。因此我预料软件部署之后会有很大的改动。果不其然，整个软件在半年内修改了10版；在几周前，甚至被迫做出了重构的决定。
低延迟，是因为软件的核心功能之一，是图像和声音信号的调度；因为硬件和系统复杂性，较长的视音频调度路径要经过3个矩阵，1个编码器，1个解码器，1个图控器；调度算法堪比网络中的路由。又因为用户有开会的需要，领导在上面讲话，大屏幕里的嘴型不能和领导实际嘴型延迟太对，因此有了低延迟的要求。
受限于当时掌握的需求以及团队成员的技能，WinNet第一版本框架采用了c++的服务器以及qt的客户端。服务器架构图如下所示：
线程交互逻辑：
1）服务器分为三个线程，主线程、设备控制线程和动态数据计算线程。线程划分和功能模块划分并不等价。
2）青色部分（设备控制线程+设备执行函数）属于设备控制线程；暗黄部分（动态数据计算线程+动态中心）属于动态数据计算线程。
3）设备控制器是线程交互的关键模块，有两个作用：通过设备代理和设备控制线程交互；以及生成动态数据线程所需的控制信令，该信令将顺着设备控制线程在设备执行函数模块提交给动态数据消息队列，属于一种信令延迟提交。
4）除了3）提供的线程交互路径，另一条线程交互路径为：客户端管理模块在客户端注册时将“动态信息推送信令”提交给动态数据计算线程。
5）暂时不允许出现其他的线程交互情况
6）编解码服务器及其他设备自带的网络线程不纳入本框架考虑
要具体解释为什么搭建上图那样一个框架，涉及到需求、性能指标、时间、经验、个人风格等等等等方面，是很难用少量文字说的清楚的。这里只提出几点略带共性的意见，供大家参考。
1）对于中小型的框架，分层是一种简单而又实用的思考方式。虽然当下微服务、面向服务的架构、面向切面等等理念或手段盛行，但对于一个架构新人，踏踏实实掌握分层的理念和手段是必要的，就像学Java数据库编程，纵使模板类、Structs等方式盛行且有效，但新人还是有必要学一学JDBC一样。
2）可以简单的把一个框架分成要思考的几部分：工具、数据、通信和逻辑。再以这几个中心为基础，把架构填丰满，然后再考虑各部分之间穿插交互的问题。
3）架构设计不可一直盯着性能。很多时候，设计简单甚至编程简单都远比性能好更实在。在很多场景下，公司需要的是在有限资源（人力、人员级别、时间）内能把事做的比较好的人；而不是技术狂人。
4）各模块的定义一定要准确，模块和模块边界一定尽可能清晰。对于架构新人，不妨把自己的架构解释自己听，解释给别人听。你说的过程当中，就能不断的把自己的架构优化得更为清晰。
客户端架构图如下所示：
客户端总体上是一个重量级的MVC。当时考虑到界面不管从UI还是从逻辑都会相当复杂（房间有近10个，最大的房间内设备数量上百）；又考虑到需求的不明确（很多时候，强求需求明确真心做不到，和软件部门无关），以及未来升级的压力，因此在客户端舍弃了性能甚至时延，采用了一个大体量的笨重框架。
这里也分享几点经验：
（1）客户端编程一定要把UI部分和数据、控制部分割裂开，越干净越好（比如在不同的层，或不同的类里）。因为UI编程免不了有大量代码，如果把控制和数据隐藏其中，不管阅读、扩展都会比较困难。
（2）一种简单却有效的客户端框架理念：从一个不可分割的控件开始（比如Button），逐步往上形成层或类（比如按钮往上是按钮组、再往上带叶签的按钮组），把每一级的“对象”定义清楚（比如按钮组管按钮，但不涉及按钮本身），最后生成所需要的View（比如房间类）。这样看起来啰啰嗦嗦，代码量大，又有一堆代码少的小类，但等到复杂View、数据处理、UI间通讯时，哪怕是新人，也会容易上手了。
限于篇幅，这一节就到这里。下一节，会聊聊上面两个框架在实际开发中，我感受到的的优劣之处。