上几篇中描述了框架演进中的基本框架，也讨论了一下基本框架的优缺点。
在我的实际工作当中，基本框架只用了一次就被废弃；基本框架搭起来的项目在一年后进行了重构，因此基本框架最终只存在不到一年时间。但对于架构师新手们，从设计一个基本框架开始，逐渐摸索、积累出对公司更有价值的框架，是一条可以切实落地的路。更重要的是，对一个没有软件基础的公司而言，不管是框架、方案乃至方向，其实都是从一个项目一个项目中积累起来；项目积累多了之后，从公司战略层面、研究院研究方向层面以及软件部自身发展层面，都是需要抽象、升级、更新软件体系（从需求到设计到实现）的。因此，以实现项目为目标，花较少的力气迅速搭建一个基本框架，再在演进当中升级框架，不失为一个好的策略。
基本框架之后，我的第二个过渡框架是以客户端和服务器的通信协议为核心的。具体而下如下。
服务器端：
这是服务器端的顶层抽象。
这是服务器端的分层架构。
从上面两个图可以看出，该架构主要考虑了几个因素：
1）对信息入口和信息出口的抽象和管理。
2）模块化，并基于模块提供服务。
3）信息、解释、服务、回复的链条。
对信息入口进行抽象、集中和管理非常重要。这些信息入口通常是服务器运行当中，一个新的事务的起点；捋清了起点，就更容易搭建一个易读、易改、易扩展的体系，随之而来还有易开发、易调试、易讲解等好处；是我个人比较喜欢的一种方式。
对于视音频行业的软件来说，最重要的入口信息有两大类：一是客户端来的交互信息；一是设备来的交互信息。因此，信息入口最终落到了Win服务器的一个网络接口函数，以及Codec服务器、设备代理服务器的设备回复网络接口函数当中。
对信息出口做出抽象和管理也同样重要。最重要的，这是和设备交互的基础；另一方面，这也是和客户端交互的基础；最后，可以基于此实现可靠的双机热备。和设备交互的出口封装在了Codec服务器、设备代理服务器的信息发送函数中，和客户端交互的功能封装到了Win服务器的信息发送及广播函数中。
在分层架构里面，可以比较明显看到，从下到上依次有工具层、服务层、解析层和入口层。其中服务层是内容最多，也最复杂的；其他层在架构定下来后，编码量和编码难度并不大。
对服务层采用了强模块化设计，只向上层提供服务并严格限制了模块间的同层调用，对于框架的分工、优化、扩展，尤其是复用，是非常必要的。事实上，在上述框架的落地过程当中，Win服务器层、主备模块都较难不利用同层间的模块调用，在后期进行了调整。
事实上，如果你的框架只用一次，而且项目小好分工（尤其是一个人写的），强模块化会增加不少工作量，意义也并不大。但如果核心代码超过了五个人合作，或者以后的项目也得复用代码，那强模块化是难以避免的。
最后，从分层框架里能看出信息接入、解释信息、对外部命令进行服务、给与回复的一个事务链条。对于客户端服务器架构，这个链条存在的意义是显而易见的。因此对这个链条予以规范、抽象，对于实现功能、排查问题都很有帮助。
下一篇会介绍该版本客户端的框架。