如何成为架构师系列：以协议为核心的框架（二）

     上一篇介绍了我实际工作中设计的一套以协议为核心的服务器端框架，我们接着分析相应的客户端架构。

     首先是客户端的设计方向，大体来说有两个方向：胖客户端和瘦客户端。

     在CS架构中，如果客户端本地存留大量数据，并进行复杂逻辑处理，则称为胖客户端。如果客户端本地基本不存数据，基本没有逻辑，只作为界面展现和用户交互的工具，则称为瘦客户端。当然，也有一些客户端介于二者之间，这是一个权衡的问题。

   瘦客户端优势：

–①便于从CS架构转型成BS架构

–②便于从PC端移植到移动端（安卓、苹果）

–③便于多客户端的部署和维护

–④便于客户端升级、产品及项目重用、二次开发

    瘦客户端劣势：

–①服务器更加复杂，性能、网络压力更大，稳定性要求更高。

–②客户端的响应将延迟五到二十毫秒，特殊情况下（网络拥塞或者服务器处理能力更不上）将有更长延迟。会稍微增加音视频数据上设备的延迟（取决于服务器处理能力，零到几毫秒级别）。

–③长期来看，需要增加前端和脚本人员。

    从平台开发难度上来说，瘦客户其实是难于胖客户端的，应为有更多的抽象、封装、协议。但平台成型后，后期项目的开发瘦客户端是加速的，我们甚至可以用新人来完成较复杂项目的客户端开发工作，或者直接把客户端开发通过脚本方式予以实现。

    这一版我们设计的瘦客户端框架如下：

    

     从上图可以看到，新的客户端架构有几个特点：

     1）以协议为中心。在网络的入口和出口都对接了一套完整的协议栈；这其实可以理解为RPC远程过程调用的原始实现方式。协议栈也是让服务器给客户端提供完整、稳定且可复用支持的基础。

     2）控件化。为了使得客户端代码的可复用性更强，将常用的一些设备及功能抽象成控件；在后续使用这些设备或功能时，只需new一个控件即可。这将大大提高代码复用能力，也是客户端代码大规模复用及后续脚本化的基础。

      上述架构的其他模块，基本是为了协议和控件服务的。

      上述的框架基本可以支持我们这个二十人团队，在视音频控制领域（或者说大屏领域）快速、稳定的定制项目。随着协议和控件的完善，对项目的对接将会越来越成熟稳定及快速。这也是最终形成自有开发平台的基础。

     其实最初，我们也考虑过要不要引入开源的RPC方式，但最终被否定，理由是我们的需求很少，不应该为此引入并学习、维护一个太复杂的模块。技术选型的相关问题，在本系列的前面有过描述，其实道理都相通。

      至于控件化的思想，不管有没有瘦客户理念，或者做不做平台，只要你想尽可能在客户端级别实现代码复用，就是难以避免的。我在后面文章里，会对控件的实现做详细一些的分享。

     事实上，在这种集成项目中，工作量最大的代码通常不是服务端，而是客户端；而从复用程度而言，客户端的复用也是最难的，毕竟每一个项目都有定制的界面，和定制的用户逻辑。及时做了控件化的工作，在最初的三四个月内，也出现控件定制困难、和服务器对接困难以及复用困难的问题。这些问题会在下一版本的框架：基于数据库的框架里逐一解决。