2021客户端架构调研过程记录

前言

近期因目标客户电脑特殊性(国产处理器加国产系统)，而提出调研当下流行的跨平台解决方案，以求判断电脑客户端架构是否有更合适的设计方案。

计划是先根据其业务性质选择软件架构，然后根据需求寻找一些比较合适的技术，最后根据公司实际情况来做取舍。

发布在 CSDN 上仅是为了对于所耗费的时间做一个记录，后续有相关工作能以此为起点提供思路而不必从头开始。

软件架构

架构一词在软件发明时的 N 多年以前，就已经存在了，这个词最早是跟随着建筑出现的。

在软件工程中，架构以理解为 目标系统按某个原则的进行切分。对切分出来的部分，并行或串行开展工作，并对这些部分，设立沟通机制。使得各部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

常见的软件架构

分层模式 (Layered pattern)

 对结构化设计的软件进行层次上独立的抽象。
 适用于 桌面应用程序、WEB应用

• 表示层（也称为 UI 层）
   真实世界的表现层，主要是用户前端。

• 应用层（也称为服务层）
   服务层提供商定的协议，可重用性，跨平台的部署。用户做的每一件事都通过表现层和用户界面。

• 业务逻辑层（也称为领域层）

• 数据访问层（也称为持久化层）
  
  

客户端／服务器模式 (Client-server pattern)

 由一个服务器与多个客户端构成
 适用于 电子邮件应用、文件共享应用、在线业务应用

• 服务器
   服务器组件同时为多个客户端组件提供服务。
   此外，服务器持续监听来自客户端的请求。
• 客户端
   客户端向服务器发启服务请求，服务器将相应服务信息回应给客户端。
   可以用来编写客户端的技术非常多，不同的语言，不同的排序，简单列举一些我查到的。
  
  

主／从模式 (Master-slave pattern)

 由主设备与从设备两个部分构成，核心思想是基于分而治之的思想
 适用于 数据库集群

• 主服务组件
   主服务组件将作业分发给多个从设备组件，并根据这些从设备反馈的结果，计算生成最终结果。
• 从设备组件
   实际的作业执行者，并将执行结果反馈给主服务组件
  
  

管道／过滤器模式 (Pipe-filter pattern)

 适用于 生成及处理数据流的系统、编译器

代理模式（Broker pattern）

 对结构化系统的组件解耦
 适用于 消息中间件软件

对等模式 (Peer-to-peer pattern)

 由对等体组件构成，对等体可同时作为客户端与服务端运行
 适用于 网络文件共享、流媒体应用

事件总线模式（Event-bus pattern）

 应用于事件处理，由四个组件构成
 适用于 Android开发、通告服务

• 事件源
• 事件侦听者
• 通道
• 总线
  
  

模型／视图／控制器 (MVC) 模式（Model-view-controller pattern）

 由三个部分构成，模型、视图、控制器
 适用于 互联网网页应用、Django 与 Rails 等网页应用

• 模型
   包含核心功能及数据
• 视图
   呈现信息给用户
• 控制器
   处理用户的输入操作
  
  

黑板模式（Blackboard pattern）

 应用未预知的问题确定解决策略，于由三个部分构成，黑板、知识、控制
 适用于 语音识别、车辆识别和追踪、蛋白质的结构鉴定、声纳信号解析

• 黑板
   用于储存空间对象的结构化全局内存
• 知识
   源，能自我表意的专用模块
• 控制
   组件，可将新生成的数据对象写入黑板，也可以通过模式匹配从黑板中获取知识源
  
  

解析器模式（Interpreter pattern）

 用于设计语言的解析程序
 适用于 SQL查询语言，通讯协议扫描语言>

需求

1. 电脑客户机本地客户端高适配性
2. 调研当前流行的实现方式
   
   

当前使用的软件架构及技术搭配

 业务层使用 java、服务层使用 thrift、UI层使用 Electron + Vue、数据访问层使用 临时缓存

简单收集的解决方案

• 方案1~用Rust来写业务逻辑，用Neon来做中间连接，用Electron来做UI层
• 方案2~类似于Software+Services的架构，客户端除了GUI什么都没有，全部的应用逻辑都在远端。

方案设计

基于业务场景和需求选择软件架构与技术选型，有很多可选技术不支持跨平台所以并未列举

分层模式

业务逻辑层（也称为领域层）

1. 用Java来写业务层。基于JVM机制，跨平台性突出，且生态圈成熟；
2. 用golng来写业务层。go语言不具依赖性，不需要使用虚拟机。Go语言的代码可以直接输出为二进制可执行文件，性能优秀，与C/C++、Java同量级，但桌面软件方向应用较少。

应用层（也称为服务层）

1. 用thrift写服务层。RPC框架，有人反馈它在0.9.0版本不稳定，目前在现有的项目中都没有暴露过此种问题。支持跨语言，性能比较优秀，相比hessian，高出80％左右；
2. 用Hessian写服务层。RPC框架/WebService框架，传输量 < 2M 、并发数未超过 1000 req/s 使用Hessian是够的。支持跨语言，关注度低，上手难度低；
3. 用gRPC写服务层。RPC框架，主要面向移动应用开发并基于HTTP/2协议标准而设计，支持众多开发语言，性能低于thrift。

表示层（也称为 UI 层）

1. Electron写表现层。支持跨系统，且可以一份代码同时得到网页版和桌面版。开发效率高，执行效率上Electron尽管可以做出与 C++ 应用相媲美的用户体验，例如 Visual Studio Code，但通常难以优化到此地步；
2. QT写表现层。C++语言UI框架，支持跨系统，qt还支持移动端，但支持的并不好。发展多年，功能强大，拥有成熟的natvie控件库，但如果用它开发非 GPL 开放程式码(不开放源码)的软体，必須购买商业版本；
3. PYQT5写表现层。PyQt对Qt做了封装，可以用PyQt做Qt能做的大部分事情，允许使用Python语言调用Qt库中的API。要注意跨平台方面，如果全部使用QT库问题不大，但如果有用py库，特别是系统API级别的还是会有兼容问题。

数据访问层（也称为持久化层）

• 暂无调研需求

客户端／服务器模式

客户端

1. 使用Electron写客户端。用HTML，CSS和JavaScript来构建跨平台桌面应用程序。优点是支持跨系统，开发快，web端与桌面端代码通用。缺点是同标准下没有C++语言的QT高效；
2. 使用QT写客户端。优点是有着完整的生态体系，稳定可靠，性能突出。缺点是web端与移动端虽然支持，但生态不完善，相对不够流行。
3. 使用JavaFx写客户端。优点是可以跨平台，并且是 Java语言UI框架，缺点是并不流行，生态环境不好；
4. 使用Air写客户端。优点是可以跨平台，可以利用Flash做很多动画特效。缺点是开发效率低，随着Flash在浏览器上的节节败退，Air也悄无声息的消失在了大众的视野当中。
5. 使用React Native写移动客户端。目前支持iOS和Android两个平台。
6. 使用Weex写移动客户端。思想及原理和React Native类似，最大的不同是React Native使用React.js作为开发框架，而Weex则使用Vue.js作为开发框架。也是用来写手机客户端。

服务端

• 暂无调研需求